- Konu sahibi
- #1
Yedek alıyor olmak tek başına yeterli değildir; asıl ihtiyaç, gerektiğinde o yedeğin gerçekten geri yüklenebildiğini bilmektir. Bu yüzden düzenli geri yükleme testi, sadece “yedek bozulmuş mu?” sorusunu değil, aynı zamanda prosedürün çalışıp çalışmadığını, erişim yetkilerinin doğru olup olmadığını ve toparlanma süresinin beklentiyi karşılayıp karşılamadığını da gösterir. Resmi dokümantasyonlar da yedek stratejisinin test edilmesini, geri yükleme denemeleri yapılmasını ve geri yüklenen verinin bütünlüğünün kontrol edilmesini açıkça önerir.
Geri yükleme testini yalnızca “dosya açılıyor mu?” seviyesinde düşünmek eksik kalır. İyi bir testte en az üç şey doğrulanır: yedek okunabiliyor mu, geri yükleme adımları uygulanabiliyor mu, geri yüklenen sistem ya da veritabanı beklenen şekilde çalışıyor mu. Microsoft’un SQL Server ve Azure belgeleri, geri yükleme öncesi/sonrası doğrulama ve bütünlük kontrolünün yedek stratejisinin parçası olması gerektiğini söyler. AWS tarafında da restore test sonrası doğrulama akışı önerilir.
Buradaki pratik hedef şudur: "Bu yedeği almış olmak yerine, bu yedeği üretim benzeri bir ortamda geri getirebiliyorum" diyebilmek.
En kullanışlı yöntem, testi üç katman halinde ele almaktır:
Bu yaklaşım, sadece dosya kopyasının mevcut olup olmadığını değil, bütün kurtarma zincirinin çalışıp çalışmadığını gösterir. Özellikle veritabanlarında yalnızca yedeği almak değil, test ortamına geri yükleyip bütünlük denetimi yapmak önerilir. SQL Server dokümantasyonunda da yedeklerin test sistemine geri yüklenmesi ve ardından bütünlük kontrolü çalıştırılması vurgulanır. Oracle dokümantasyonu ise yedeklerin kullanılabilirliğini ayrı bir host üzerinde geri yükleyerek sınamayı önerir.
Basit ama etkili bir kontrol listesi şu maddelerden oluşabilir:
Buradaki amaç, yalnızca “restore tamamlandı” mesajını görmek değildir. Örneğin bir veritabanı kurtarma işlemi başarılı görünse bile eksik yetki, yanlış sıralanmış adımlar ya da bozuk bir yedek zinciri yüzünden uygulama ayağa kalkmayabilir. Microsoft’un yedekleme ve kurtarma kılavuzları ile AWS Well-Architected notları, başarı ölçütünün pratik geri dönüş ve doğrulama olması gerektiğini açıkça destekler.
En yaygın hata, testi gerçek geri yükleme yerine yalnızca yedek dosyasının oluşturulduğunu doğrulamakla sınırlamaktır. Bu, içeriğin gerçekten kullanılabilir olduğu anlamına gelmez. İkinci yaygın hata, testi üretim sunucusunda veya üretimle aynı erişim sınırları içinde yapmaya çalışmaktır; bu da hem risk hem de gürültü yaratır. Üçüncü hata ise testin yalnızca arıza sonrası yapılmasıdır. Oysa düzenli aralıklarla yapılan testler, sorun çıkmadan önce eksikleri gösterir.
Bir başka önemli nokta da günlük ve iz kayıtlarının korunmasıdır. Recovery testini anlamlı kılmak için, olay sırasında ne olduğunu gösterecek logların da elde kalması gerekir; aşırı agresif saklama politikaları sorun anında teşhis için gerekli veriyi silebilir. Azure Well-Architected rehberi bu konuda açık bir uyarı yapar.
Bunun tek bir sabit cevabı yoktur; sistemin kritikliği, veri değişim hızı ve kabul edilen RTO/RPO hedeflerine göre değişir. Yine de mantıklı yaklaşım, en kritik sistemlerde daha sık, daha az kritik sistemlerde ise düzenli periyotlarla test yapmaktır. Özellikle şema değişikliği, depolama yapısı değişikliği, yeni yedekleme aracı kullanımı veya yetki modeli değişikliği sonrası test yapmak çok değerlidir. Microsoft’un güvenilirlik ve kurtarılabilirlik metinleri, geri yükleme başarı oranı ve geri dönüş süresi gibi ölçülerin düzenli izlenmesini önerir.
Kısacası, yedekleme politikası ile geri yükleme testi ayrı iki görev değil, aynı kurtarma zincirinin iki parçasıdır. Yedek almayı biliyor olmak başka, o yedeği belirli bir süre içinde ve sorunsuz biçimde geri getirebilmek bambaşka bir şeydir. Bu yüzden her ciddi bakım düzeninde, geri yükleme testi bir “ek kontrol” değil, yedek stratejisinin kendisi olarak görülmelidir.
Testin amacı ne olmalı?
Geri yükleme testini yalnızca “dosya açılıyor mu?” seviyesinde düşünmek eksik kalır. İyi bir testte en az üç şey doğrulanır: yedek okunabiliyor mu, geri yükleme adımları uygulanabiliyor mu, geri yüklenen sistem ya da veritabanı beklenen şekilde çalışıyor mu. Microsoft’un SQL Server ve Azure belgeleri, geri yükleme öncesi/sonrası doğrulama ve bütünlük kontrolünün yedek stratejisinin parçası olması gerektiğini söyler. AWS tarafında da restore test sonrası doğrulama akışı önerilir.
Buradaki pratik hedef şudur: "Bu yedeği almış olmak yerine, bu yedeği üretim benzeri bir ortamda geri getirebiliyorum" diyebilmek.
Nasıl bir test düzeni kurabilirsiniz?
En kullanışlı yöntem, testi üç katman halinde ele almaktır:
- İlk katman: Yedek dosyasının varlığını ve tutarlılığını kontrol etme.
- İkinci katman: Ayrı bir test sunucusunda veya izole bir ortamda geri yükleme yapma.
- Üçüncü katman: Uygulama, veritabanı ya da servis tarafında temel çalışırlık kontrolü yapma.
Bu yaklaşım, sadece dosya kopyasının mevcut olup olmadığını değil, bütün kurtarma zincirinin çalışıp çalışmadığını gösterir. Özellikle veritabanlarında yalnızca yedeği almak değil, test ortamına geri yükleyip bütünlük denetimi yapmak önerilir. SQL Server dokümantasyonunda da yedeklerin test sistemine geri yüklenmesi ve ardından bütünlük kontrolü çalıştırılması vurgulanır. Oracle dokümantasyonu ise yedeklerin kullanılabilirliğini ayrı bir host üzerinde geri yükleyerek sınamayı önerir.
Test sırasında hangi kontrolleri yapmalısınız?
Basit ama etkili bir kontrol listesi şu maddelerden oluşabilir:
- Yedek dosyası eksiksiz mi?
- Geri yükleme için gerekli şifreleme anahtarı, hesap yetkisi veya erişim izni var mı?
- Geri yükleme süresi beklenen aralıkta mı?
- Geri yüklenen veri tutarlı mı?
- Servisler açılıyor ve temel istekleri yanıtlıyor mu?
- Loglarda hata, eksik tablo, bozuk dosya veya izin sorunu var mı?
Buradaki amaç, yalnızca “restore tamamlandı” mesajını görmek değildir. Örneğin bir veritabanı kurtarma işlemi başarılı görünse bile eksik yetki, yanlış sıralanmış adımlar ya da bozuk bir yedek zinciri yüzünden uygulama ayağa kalkmayabilir. Microsoft’un yedekleme ve kurtarma kılavuzları ile AWS Well-Architected notları, başarı ölçütünün pratik geri dönüş ve doğrulama olması gerektiğini açıkça destekler.
Sık yapılan hatalar
En yaygın hata, testi gerçek geri yükleme yerine yalnızca yedek dosyasının oluşturulduğunu doğrulamakla sınırlamaktır. Bu, içeriğin gerçekten kullanılabilir olduğu anlamına gelmez. İkinci yaygın hata, testi üretim sunucusunda veya üretimle aynı erişim sınırları içinde yapmaya çalışmaktır; bu da hem risk hem de gürültü yaratır. Üçüncü hata ise testin yalnızca arıza sonrası yapılmasıdır. Oysa düzenli aralıklarla yapılan testler, sorun çıkmadan önce eksikleri gösterir.
Bir başka önemli nokta da günlük ve iz kayıtlarının korunmasıdır. Recovery testini anlamlı kılmak için, olay sırasında ne olduğunu gösterecek logların da elde kalması gerekir; aşırı agresif saklama politikaları sorun anında teşhis için gerekli veriyi silebilir. Azure Well-Architected rehberi bu konuda açık bir uyarı yapar.
Ne sıklıkla test edilmeli?
Bunun tek bir sabit cevabı yoktur; sistemin kritikliği, veri değişim hızı ve kabul edilen RTO/RPO hedeflerine göre değişir. Yine de mantıklı yaklaşım, en kritik sistemlerde daha sık, daha az kritik sistemlerde ise düzenli periyotlarla test yapmaktır. Özellikle şema değişikliği, depolama yapısı değişikliği, yeni yedekleme aracı kullanımı veya yetki modeli değişikliği sonrası test yapmak çok değerlidir. Microsoft’un güvenilirlik ve kurtarılabilirlik metinleri, geri yükleme başarı oranı ve geri dönüş süresi gibi ölçülerin düzenli izlenmesini önerir.
Kısacası, yedekleme politikası ile geri yükleme testi ayrı iki görev değil, aynı kurtarma zincirinin iki parçasıdır. Yedek almayı biliyor olmak başka, o yedeği belirli bir süre içinde ve sorunsuz biçimde geri getirebilmek bambaşka bir şeydir. Bu yüzden her ciddi bakım düzeninde, geri yükleme testi bir “ek kontrol” değil, yedek stratejisinin kendisi olarak görülmelidir.
