SQL Server Yedek Doğrulaması

Problem neden önemlidir?

Bir yedekleme işinin başarılı görünmesi, dosyanın ihtiyaç anında okunabilir ve kullanılabilir olduğunu tek başına kanıtlamaz. Eksik zincirler, erişilemeyen hedefler veya doğrulanmamış dosyalar kurtarma riskini büyütür.

Nasıl teşhis edilir?

msdb geçmişinden son tam, fark ve log yedek zamanlarını veritabanı bazında inceleyin. RESTORE VERIFYONLY gibi doğrulama sonuçları ayrı otomasyon kayıtlarında tutulmalı ve gerçek restore testinden ayrılmalıdır.

Sorgu msdb yedek geçmişini okur ve dosyanın varlığını ya da okunabilirliğini doğrulamaz. Geçmiş temizlenmiş olabilir ve veritabanı adı değişiklikleri yorumlamayı etkileyebilir.

SELECT d.name,
       MAX(CASE WHEN bs.type = 'D' THEN bs.backup_finish_date END) AS last_full_backup,
       MAX(CASE WHEN bs.type = 'I' THEN bs.backup_finish_date END) AS last_diff_backup,
       MAX(CASE WHEN bs.type = 'L' THEN bs.backup_finish_date END) AS last_log_backup
FROM sys.databases AS d
LEFT JOIN msdb.dbo.backupset AS bs
  ON bs.database_name = d.name
 AND bs.is_copy_only = 0
GROUP BY d.name
ORDER BY d.name;

Güvenli çözüm yaklaşımı

Yedek politikası kurtarma noktası ve kurtarma süresi hedefleriyle eşleşmelidir. Dosya bütünlüğü kontrollerini otomatikleştirin, şifreleme anahtarlarını koruyun ve düzenli restore testleri planlayın.

Sürekli monitoring neden gerekir?

Tek bir kaçırılmış log yedeği kurtarma zincirini ve hedeflenen veri kaybı aralığını etkileyebilir. moon yedek yaşını ve iş sonuçlarını izleyip Slack, PagerDuty veya webhook üzerinden ilgili ekibe bildirebilir.