dataiotech Labs
dbaguidedbaguideDBAdataxtoolsdataopsphere
Runbook #32
sqlserver
BackupSEV1 · KRİTİK KESİNTİ15-30 dakika / 15-30 minssysadmin / CONTROL SERVER / VIEW SERVER STATE

SQL Server Atlanan Yedek: Full ve Log Yedek Zincirini Kontrol Etme

Son başarılı full/differential/log yedeklerini ve SQL Agent job hatalarını kontrol eder; RPO açığını kapatırken yedek zincirini bozmadan yeni yedek alır.

İlişkili Metrik:M33
İlişkili Script:S46S53
#backup#msdb#sql-agent#rpo#restore-test

Operasyonel Güvenlik ve Risk Uyarısı

Bu runbook müdahale adımları içerir; birçok adım yazma etkilidir (KILL, terminate, DROP, RESIZE). Önce test ortamında deneyin, üretimde adımları sırayla ve doğrulayarak uygulayın.

🟢 Salt Okunur (Read-Only)·🟡 Geri Alınabilir (Reversible)·🔴 Yüksek Etkili / Geri Alınamaz (High Impact)

1. Belirti / Symptom

- M33'te full yedek yaşı hedefi aşıyor, log yedeği aralığı uzuyor veya SQL Agent backup job başarısız.

- `msdb.dbo.backupset` içinde beklenen başarılı yedek kaydı yok. **Bu yalnızca o instance'ın msdb geçmişidir**; harici/managed yedekleri dışlayabilir.

2. Etki / Impact

Felaket halinde son sağlam yedeğe kadar veri kaybı (RPO) ve kurtarma süresinde artış (RTO). FULL/BULK_LOGGED modelde log yedeği alınmıyorsa transaction log büyüyebilir; `mssql-transaction-log-full` senaryosunu tetikleyebilir.

3. Teşhis / Diagnosis

🟢 Salt Okunur1. S46'ya göre yalnızca hedef, çevrimiçi kullanıcı veritabanlarının son yedeklerini ayırın:
sql
SELECT d.name, d.recovery_model_desc,
       MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END) AS last_full,
       MAX(CASE WHEN b.type = 'I' THEN b.backup_finish_date END) AS last_diff,
       MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END) AS last_log
FROM sys.databases AS d
LEFT JOIN msdb.dbo.backupset AS b ON b.database_name = d.name
WHERE d.database_id > 4 AND d.state_desc = 'ONLINE'
GROUP BY d.name, d.recovery_model_desc
ORDER BY d.name;

`SIMPLE` modelde log yedeği beklemeyin. `COPY_ONLY` full yedek, differential base'i değiştirmez; normal full zincirini ayrıca değerlendirin.

🟢 Salt Okunur2. S53 ile son SQL Agent job sonucunu/hatasını alın. Job çalışıyor mu, yanlış sunucuya mı bağlanıyor, yedek yolu erişilebilir mi, disk dolu mu, yetki veya checksum hatası mı? Yönetilen yedek hizmeti kullanılıyorsa onun panel ve olay kayıtlarına bakın.
🟢 Salt Okunur3. RPO açığını ölçün: Son **kurtarılabilir** yedeğin zamanı ile olay zamanı arasındaki farkı, işin RPO hedefiyle karşılaştırın. Yedek dosyasının gerçekten mevcut olup olmadığını ve medyanın bütünlüğünü doğrulayın.

4. Müdahale / Response

🟡 Geri Alınabilir1. Önce job'ın kök nedenini (disk, izin, yol, depolama, SQL Agent hizmeti) düzeltin. **Aynı yedek dosyasını `WITH INIT` ile üzerine yazmayın.** Ayrı, onaylı ve yeterli boş alanlı hedef kullanın.
🟡 Geri Alınabilir2. Mevcut differential base'i değiştirmeden acil tek seferlik full yedek gerekiyorsa `COPY_ONLY` kullanın (gerçek veritabanı/yol ile değiştirin):
sql
BACKUP DATABASE [OrnekDb]
TO DISK = N'D:\SQLBackups\OrnekDb_emergency_copy_20261103.bak'
WITH COPY_ONLY, CHECKSUM, STATS = 10;

Bu, normal full job'ının yerine **kalıcı olarak geçmez**; log aralığının uygunluğunu ayrıca inceleyin.

🟡 Geri Alınabilir3. FULL/BULK_LOGGED modelde log yedeği geciktiyse, **zincirde kullanılacak benzersiz dosya adı** ve onaylı depolama yoluyla log yedeği alın (geçerli full tabanı olmalı):
sql
BACKUP LOG [OrnekDb]
TO DISK = N'D:\SQLBackups\OrnekDb_log_20261103_001.trn'
WITH CHECKSUM, STATS = 10;

Düzenli job'ı hemen onarıp yeniden başlatın; harici yedek yazılımının zincir politikasıyla koordinasyon kurun.

🔴 YÜKSEK RİSK / GERİ ALINAMAZ4. Eski yedekleri temizleyip yer açmadan önce retention, bağımlı differential/log zinciri ve offsite kopyaları doğrulayın. Sırf alan açmak için recovery modelini `SIMPLE` yapmayın; log yedek zincirini kırar.

5. **Kalıcı çözüm:** Yedek başarı alarmına ek olarak dosya varlığı, yaşı, otomatik restore testi ve RPO/RTO karşılanmasını izleyecek iş akışı kurun.

5. Doğrulama / Verification

- `msdb.dbo.backupset` içinde yeni yedek `backup_finish_date` ile görünüyor; dosya hedef depolamada mevcut.

- `RESTORE VERIFYONLY FROM DISK = N'D:\SQLBackups\OrnekDb_emergency_copy_20261103.bak' WITH CHECKSUM;` hatasız. **VERIFYONLY gerçek restore testi değildir**; izole sunucuda tam restore + gerekiyorsa differential/log zinciriyle açılma testi yapın.

- M33 RPO hedefine indi, bir sonraki planlı SQL Agent job başarılı tamamlandı.

6. Geri Alma / Rollback

- Yedek almak veri değişikliği değildir; oluşturulan dosyayı hemen silmek yerine retention ve zincir güvenliğine göre saklayın.

- Job değişikliğini önceki yapılandırmasına döndürün; bir kere kaçırılan RPO zaman aralığı sonradan tamamen geri alınamaz.

Diğer SQLSERVER Runbook'ları