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.
Yedekleme Planını Yazılı Hale Getirin
Yedekleme düzeni yalnızca bir kişinin aklındaysa, o kişi ulaşılamaz olduğunda plan da ortadan kalkar. Kısa bir belge hazırlayıp güncel tutmanız, kriz anında zaman kazandırır. Belgede en az şunlar yer almalıdır:
- Yedeklenen veritabanlarının listesi ve her birinin iş tarafındaki sahibi
- Her veritabanı için kararlaştırılan RPO ve RTO değerleri
- Yedek türleri, zamanlaması ve saklandığı konumlar
- Başarısız yedek bildirimlerinin kime gittiği
- Yedek şifreleme kullanılıyorsa sertifika ve anahtarların nerede saklandığı
- Geri dönüş adımları ve bu adımları uygulamaya yetkili kişiler
Şifreli bir yedeği, sertifikası olmadan geri yükleyemezsiniz. Sertifikayı yedeklerle aynı yerde değil, ayrı ve güvenli bir konumda saklayın.
Arıza Anında Geri Dönüş Sırası
Bir arıza yaşandığında ilk tepki çoğu zaman hemen geri yüklemeye başlamaktır. Oysa doğru sıra, veri kaybını azaltır.
- Durumu değerlendirin ve mevcut dosyaların üzerine yazmayın. Hasarlı veritabanı daha sonra inceleme için gerekebilir.
- FULL recovery model kullanıyorsanız ve log dosyasına erişilebiliyorsa, önce son log yedeğini (tail-log) alın.
- Hangi ana dönmek istediğinize karar verin. Hatalı bir işlem söz konusuysa, o işlemden hemen önceki an hedeflenir.
- Tam yedeği, ardından fark yedeğini ve log yedeklerini sırasıyla geri yükleyin. Veritabanını son adımda kullanıma açın.
- Bütünlük kontrolü çalıştırın, ardından uygulamayı ve kullanıcı erişimlerini test edin.
Bu sırayı önceden prova etmek ve belgelemek için SQL danışmanlığı desteğinden yararlanabilirsiniz.
Haftalık Yedek Kontrol Rutini
Yedekleme işleri sessizce bozulabilir. Haftada bir kez ayıracağınız kısa bir kontrol, sorunu ihtiyaç anından önce fark etmenizi sağlar. Kontrolü bir kişiye atayın ve sonucunu kaydedin.
- Tüm veritabanlarının son yedek tarihini msdb’deki yedek geçmişinden kontrol edin.
- Başarısız olan veya hiç çalışmayan işleri inceleyin.
- Yedek diskindeki boş alanı ve büyüme eğilimini izleyin.
- Tesis dışı kopyanın gerçekten güncellendiğini doğrulayın.
- Yeni eklenen veritabanlarının plana dahil edildiğinden emin olun.
Yedeklerin ötesinde, tüm sistemleri kapsayan bir kurtarma düzeni kurmak için felaket kurtarma planı rehberimize göz atabilirsiniz.
Sıkça Sorulan Sorular
Sanal makine anlık görüntüsü (snapshot) SQL yedeğinin yerini tutar mı?
Tek başına tutmaz. Anlık görüntüler genellikle aynı altyapıda saklanır ve uzun süreli saklama için tasarlanmamıştır. Ayrıca log yedekleriyle mümkün olan belirli bir ana dönüş esnekliğini sunmaz. Anlık görüntüleri, SQL Server’ın kendi yedeklerini tamamlayan ek bir katman olarak değerlendirmeniz daha sağlıklı olur.
Yedek sıkıştırma (backup compression) kullanmalı mıyız?
Sıkıştırma, yedek dosyasının boyutunu küçültür ve diske daha az veri yazıldığı için çoğu zaman yedek süresini de kısaltır. Karşılığında yedek sırasında işlemci kullanımı artar. Yoğun saatlerde çalışan yedeklerde bu etkiyi izlemeniz, kullandığınız sürümün özelliği destekleyip desteklemediğini de kontrol etmeniz gerekir.
Yedekleri ne kadar süre saklamalıyız?
Bunun tek bir doğru cevabı yoktur. Saklama süresi, iş ihtiyaçlarınıza ve tabi olduğunuz yasal yükümlülüklere göre belirlenir. Bir veri hatasının ne kadar geç fark edilebileceğini de hesaba katın. Yükümlülüklerinizi mali ve hukuki danışmanlarınızla gözden geçirip süreyi yazılı bir politika olarak tanımlamanız önerilir.
COPY_ONLY yedek nedir, ne zaman kullanılır?
COPY_ONLY, mevcut yedek zincirini etkilemeden alınan bağımsız bir yedektir. Test ortamına veri taşımak veya bir güncelleme öncesinde ek kopya almak gibi plan dışı durumlarda kullanılır. Normal bir tam yedek, sonraki fark yedeklerinin dayandığı temeli değiştirir; COPY_ONLY ise bu düzeni bozmaz.
Ç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.