- Konu sahibi
- #1
Yedek almak tek başına yeterli değildir; asıl soru, o yedeğin ihtiyaç anında gerçekten geri dönüp dönmediğidir. Bu yüzden yönetim tarafında en sağlıklı yaklaşım, yedeği sadece saklamak değil, düzenli aralıklarla geri yükleyerek doğrulamaktır. Böylece bozuk arşiv, eksik veri, yanlış izinler ya da beklenenden uzun süren kurtarma gibi sorunlar daha yedek “güvenli” kabul edilmeden ortaya çıkar.
Bir geri yükleme testinde amaç yalnızca dosyaların açılıp açılmadığını görmek değildir. Daha geniş bakmak gerekir:
Özellikle iş kritik sistemlerde, geri yüklemenin RTO ve RPO hedeflerini karşılayıp karşılamadığı da testin parçası olmalıdır. RTO, sistemin ne kadar sürede geri gelmesi gerektiğini; RPO ise ne kadar veri kaybının kabul edilebilir olduğunu anlatır.
En güvenli yöntem, üretim ortamına dokunmadan ayrı bir test alanında deneme yapmaktır. Genel akış şu şekilde ilerler:
Eğer tam bir test ortamı kurmak mümkün değilse, en azından yedekten seçilen dosya, veritabanı veya sanal makine parçası üzerinde kontrollü doğrulama yapılmalıdır. Ama bu yöntem, tüm sistemin geri dönebileceğini tek başına kanıtlamaz; sadece kısmi güven sağlar.
En yaygın hata, yedekleme işinin başarılı görünmesini yeterli sanmaktır. Oysa “yedek alındı” mesajı, geri yükleme başarısını garanti etmez. Diğer sık hatalar şunlardır:
Düzenli bir plan kurmak zor olmak zorunda değil. Haftalık ya da aylık olarak şu kontrol yeterli olabilir:
Bu yaklaşım, özellikle tek sunuculu veya sınırlı kaynaklı yapılarda, büyük bir felaket yaşanmadan önce zayıf noktaları görünür hale getirir. Asıl değer de burada ortaya çıkar: yedeklerin gerçekten kurtarma aracı olduğunu önceden kanıtlamak.
Ne doğrulanmalı?
Bir geri yükleme testinde amaç yalnızca dosyaların açılıp açılmadığını görmek değildir. Daha geniş bakmak gerekir:
- Yedek dosyası okunabiliyor mu?
- Geri yüklenen veri eksiksiz mi?
- Uygulama veya servis ayağa kalkıyor mu?
- Veri tutarlı mı, bozulma var mı?
- Kurtarma süresi kabul edilebilir mi?
Özellikle iş kritik sistemlerde, geri yüklemenin RTO ve RPO hedeflerini karşılayıp karşılamadığı da testin parçası olmalıdır. RTO, sistemin ne kadar sürede geri gelmesi gerektiğini; RPO ise ne kadar veri kaybının kabul edilebilir olduğunu anlatır.
Pratik test yöntemi
En güvenli yöntem, üretim ortamına dokunmadan ayrı bir test alanında deneme yapmaktır. Genel akış şu şekilde ilerler:
- Son yedek setini seçin.
- Test ortamında aynı ya da benzer bir yapı hazırlayın.
- Yedeği geri yükleyin.
- Servislerin açıldığını, veritabanlarının bağlandığını ve temel işlevlerin çalıştığını kontrol edin.
- Sonuçları not alın: ne kadar sürdü, hangi adımda sorun çıktı, ne düzeltildi.
Eğer tam bir test ortamı kurmak mümkün değilse, en azından yedekten seçilen dosya, veritabanı veya sanal makine parçası üzerinde kontrollü doğrulama yapılmalıdır. Ama bu yöntem, tüm sistemin geri dönebileceğini tek başına kanıtlamaz; sadece kısmi güven sağlar.
Sık yapılan hatalar
En yaygın hata, yedekleme işinin başarılı görünmesini yeterli sanmaktır. Oysa “yedek alındı” mesajı, geri yükleme başarısını garanti etmez. Diğer sık hatalar şunlardır:
- Testi yalnızca acil durumda denemek
- Sadece dosya varlığını kontrol edip içeriği doğrulamamak
- Test ortamını üretimden çok farklı kurmak
- Geri yükleme süresini ölçmemek
- Sonucu belgelememek ve prosedürü güncellememek
Küçük ekipler için basit kontrol listesi
Düzenli bir plan kurmak zor olmak zorunda değil. Haftalık ya da aylık olarak şu kontrol yeterli olabilir:
- Bir yedek seç
- Ayrı bir ortama geri yükle
- Dosya, servis ve veritabanı kontrolü yap
- Hata varsa not al
- Başarılıysa tarih ve süreyi kaydet
Bu yaklaşım, özellikle tek sunuculu veya sınırlı kaynaklı yapılarda, büyük bir felaket yaşanmadan önce zayıf noktaları görünür hale getirir. Asıl değer de burada ortaya çıkar: yedeklerin gerçekten kurtarma aracı olduğunu önceden kanıtlamak.
