SQL veritabanı yedekleme ve geri dönüş (restore) testi süreci

SQL Veritabanı Yedekleme: Yedeğiniz Var mı, Geri Dönebiliyor musunuz?

Yedekleme konusunda sahada gördüğümüz en yaygın durum şudur: yedek alınıyordur, ama kimse o yedekten geri dönülüp dönülemeyeceğini bilmez. Bu iki cümle arasındaki fark, bir şirketin faaliyetine devam edip edememesi kadar büyüktür.

Yedek almak bir görev değil, geri dönebilmek bir yetenektir. Test edilmemiş yedek, yedek sayılmaz.

Önce iki soruyu cevaplayın: RPO ve RTO

Teknik detaylara girmeden önce iş tarafının karar vermesi gereken iki rakam vardır:

  • RPO (Recovery Point Objective): Bir felakette en fazla ne kadarlık veri kaybını kabul edebilirsiniz? 24 saat mi, 1 saat mi, 5 dakika mı?
  • RTO (Recovery Time Objective): Sistemin yeniden çalışır hale gelmesi en fazla ne kadar sürebilir? Yarım gün mü, 2 saat mi?

Bu iki rakam belirlenmeden kurulan her yedekleme planı tahmine dayanır. Günde bir kez gece yedeği alan bir şirketin RPO’su 24 saattir; yani öğleden sonra yaşanacak bir arızada o günkü tüm faturalar, siparişler ve tahsilatlar kaybolur. Bu kabul edilebilir mi? Cevabı teknik ekip değil, yönetim verir.

SQL Server yedek türleri

Tam yedek (Full backup): Veritabanının bütünü. Her geri dönüşün temelidir.

Fark yedeği (Differential backup): Son tam yedekten bu yana değişenler. Geri dönüş süresini kısaltır, yedek boyutunu küçültür.

İşlem günlüğü yedeği (Transaction log backup): Yalnızca FULL recovery model’de mümkündür. Belirli bir ana (örneğin hatalı silme işleminden bir dakika öncesine) dönebilmenizi sağlar ve log dosyasının sonsuz büyümesini engeller.

Tipik bir kurgu şöyledir: haftada bir tam yedek, günlük fark yedeği, 15 dakikada bir log yedeği. Bu kombinasyon RPO’yu 15 dakikaya indirir.

Recovery model tuzağı

Veritabanınız FULL recovery model’deyse ve log yedeği almıyorsanız, log dosyası büyümeye devam eder ve bir gün disk dolar. Bu, “SQL çöktü” diye bildirilen vakaların klasik sebeplerindendir.

Kural basittir: FULL model kullanıyorsanız düzenli log yedeği almak zorundasınız. Almıyorsanız ve dakikalık geri dönüş ihtiyacınız yoksa, SIMPLE model daha doğru tercihtir.

3-2-1 kuralı

Kabul görmüş sağlıklı bir yedekleme dağılımı:

  • 3 kopya veri
  • 2 farklı ortam/medya
  • 1 kopya tesis dışında (offsite)

Buna günümüzde bir madde daha eklenmelidir: 1 kopya çevrimdışı veya değiştirilemez (immutable). Fidye yazılımları artık önce erişebildikleri yedekleri şifreler veya siler. Aynı ağdaki bir NAS’ta duran yedek, ana sunucuyla birlikte kaybedilebilir.

Yedek doğrulama ve bütünlük kontrolü

Yedek alındıktan sonra:

RESTORE VERIFYONLY FROM DISK = 'D:BackupERP_full.bak';

Bu komut yedeğin okunabilirliğini doğrular, ancak içeriğin sağlamlığını garanti etmez. Bu nedenle veritabanı üzerinde düzenli olarak bütünlük kontrolü de çalıştırılmalıdır:

DBCC CHECKDB ('VeritabaniAdi') WITH NO_INFOMSGS;

Bozuk bir veritabanının yedeğini almak, bozukluğu yedeğe taşımak demektir. Sorun aylar sonra fark edilirse, elinizdeki tüm yedekler kullanılamaz durumda olabilir.

Restore testi: en çok atlanan adım

En az üç ayda bir, gerçek bir yedekten ayrı bir sunucuya geri dönüş denemesi yapılmalı ve şunlar kayıt altına alınmalıdır:

  • Geri dönüş ne kadar sürdü? (Gerçek RTO’nuz budur.)
  • Hangi adımlarda takılma yaşandı?
  • Uygulama, geri dönen veritabanıyla sorunsuz çalıştı mı?
  • Kullanıcı hesapları (login/user eşleşmesi), yetkiler ve job’lar tamam mı?

Bu testi hiç yapmamış bir şirketin RTO’su bilinmiyor demektir; kriz anında öğrenmek ise en pahalı yöntemdir.

Sık yapılan hatalar

  • Yedekleri veritabanıyla aynı diskte tutmak
  • Yedeklemenin başarısız olduğunda kimseye bildirim gitmemesi
  • Şifrelenmemiş yedeklerin paylaşılan bir klasörde durması
  • Sistem veritabanlarının (master, msdb) yedeklenmemesi
  • Yedekleme kadar önemli olan saklama süresi (retention) politikasının hiç tanımlanmaması

Sonuç

Yedekleme, bir maliyet kalemi değil sigortadır; ve her sigorta gibi değeri yalnızca kötü günde ortaya çıkar. Yedeklerinizin varlığından değil, geri dönebildiğinizden emin olun.

ÇAP Teknoloji olarak yedekleme stratejisi kurgusu, otomasyonu, izlemesi ve düzenli restore testleri konusunda destek veriyoruz. Mevcut yedekleme yapınızın gerçekten çalışıp çalışmadığını görmek isterseniz SQL danışmanlığı hizmetimiz hakkında bilgi alabilir veya bizimle iletişime geçebilirsiniz.