- Konu sahibi
- #1
Yedek almak tek başına yeterli değildir; asıl kritik nokta, ihtiyaç olduğunda o yedeğin gerçekten geri döndüğünü kanıtlamaktır. Bunun için en pratik yaklaşım, geri yükleme testini plansız bir kriz anına bırakmadan, bakım penceresinin içine küçük ve kontrollü bir test olarak yerleştirmektir. NIST, yedeklerin periyodik olarak geri yüklenmesini; AWS ise bu testin RTO ve RPO hedeflerine uygunluğunu doğrulamayı önerir. Microsoft da planlı bakım için önceden duyurulan bir zaman aralığının ayrı bir çalışma alanı olarak ele alınabileceğini belirtir.
Amaç, "yedek var" demekten çok daha fazlasıdır. Test sırasında şu soruların yanıtı aranır:
NIST ve AWS dokümanları, testin hem teknik doğrulama hem de operasyonel prova olduğunu açıkça gösterir. Bu yüzden sonuç sadece "dosya geldi" olmamalı; sistemin kullanıma hazır hale gelip gelmediği de görülmelidir.
En sağlıklı yöntem, önce küçük ve riskleri sınırlı bir kapsam seçmektir. Örneğin tüm sistemi değil, yalnızca bir veritabanını, bir site koleksiyonunu, tek bir uygulama klasörünü ya da belirli bir servisi geri yüklemeyi deneyebilirsiniz. Seçim, iş yükünün yapısına ve geri dönüş hedefinize göre yapılmalıdır. Microsoft’un SharePoint dokümanlarında da kurtarma düzeyinin bütün farm’dan tek bir öğeye kadar değişebileceği belirtilir; bu mantık, diğer sistemler için de geçerlidir.
Bakım penceresinde uygulanabilecek sade bir akış şöyledir:
Burada önemli nokta, üretim sistemini doğrudan riske atmadan prova yapmaktır. NIST, testin üretim dışı sistemlerde tekrarlanmasını özellikle vurgular.
En yaygın hata, geri yükleme testini yalnızca dosya indirildi mi diye kontrol etmektir. Oysa bir yedek dosyasının açılması, uygulamanın çalışacağı anlamına gelmez. Veritabanı tutarsız olabilir, izinler eksik olabilir veya uygulama sürümü yedekten geri dönen yapı ile uyumsuz olabilir.
Bir diğer hata, testin gerçek bakım penceresine hiç benzememesidir. Yani yedek, farklı disk yapısında ya da eksik bağımlılıklarla denenir ve sonuç başarılı görünür; fakat gerçek olayda aynı akış çalışmaz. Bu yüzden test ortamı mümkün olduğunca operasyonel koşullara yakın olmalıdır. Microsoft ve NIST dokümanlarında yer alan planlama ve dokümantasyon vurgusu da bu nedenle önemlidir.
Kısa ama işe yarar bir kontrol listesi şöyle olabilir:
Bu yaklaşım, hem güvenlik hem süreklilik açısından daha sağlıklıdır. Özellikle fidye yazılımı, insan hatası veya disk arızası gibi durumlarda, gerçekten çalıştığı doğrulanmış bir geri yükleme prosedürü, salt yedek bulundurmaktan daha değerlidir. NIST’in yedekleri düzenli test etme ve geri yükleme prosedürlerini belgeleme yaklaşımı da bunu destekler.
Eğer bakım pencereniz kısıtlıysa, önce en kritik veri parçasını seçip küçük bir geri yükleme testi yapın. Amaç, büyük bir felaket senaryosunu taklit etmek değil; prosedürün gerçekten çalıştığını görmektir. Test başarılıysa prosedürü sabitleyin, başarısızsa sorunu kayda geçirip sonraki bakım penceresinde düzeltin.
Bu testin amacı nedir?
Amaç, "yedek var" demekten çok daha fazlasıdır. Test sırasında şu soruların yanıtı aranır:
- Yedek dosyası okunabiliyor mu?
- Geri yükleme adımları beklenen sırayla çalışıyor mu?
- Veri bozukluğu, eksik parça veya yetki sorunu var mı?
- Geri dönüş süresi, kabul edilen kesinti süresine uyuyor mu?
NIST ve AWS dokümanları, testin hem teknik doğrulama hem de operasyonel prova olduğunu açıkça gösterir. Bu yüzden sonuç sadece "dosya geldi" olmamalı; sistemin kullanıma hazır hale gelip gelmediği de görülmelidir.
Bakım penceresine nasıl yerleştirilir?
En sağlıklı yöntem, önce küçük ve riskleri sınırlı bir kapsam seçmektir. Örneğin tüm sistemi değil, yalnızca bir veritabanını, bir site koleksiyonunu, tek bir uygulama klasörünü ya da belirli bir servisi geri yüklemeyi deneyebilirsiniz. Seçim, iş yükünün yapısına ve geri dönüş hedefinize göre yapılmalıdır. Microsoft’un SharePoint dokümanlarında da kurtarma düzeyinin bütün farm’dan tek bir öğeye kadar değişebileceği belirtilir; bu mantık, diğer sistemler için de geçerlidir.
Bakım penceresinde uygulanabilecek sade bir akış şöyledir:
- Testin kapsamını netleştir: hangi veri, hangi sistem, hangi süre?
- Geri yükleme yapılacak hedefi belirle: test ortamı mı, izole bir sunucu mu?
- Ön koşulları kontrol et: disk alanı, erişim yetkisi, sürüm uyumu, bağımlı servisler.
- Geri yüklemeyi çalıştır ve süreyi ölç.
- Uygulamanın açılıp açılmadığını, verinin tutarlı olup olmadığını doğrula.
- Bulunan hataları not et ve prosedürü güncelle.
Burada önemli nokta, üretim sistemini doğrudan riske atmadan prova yapmaktır. NIST, testin üretim dışı sistemlerde tekrarlanmasını özellikle vurgular.
Sık yapılan hatalar
En yaygın hata, geri yükleme testini yalnızca dosya indirildi mi diye kontrol etmektir. Oysa bir yedek dosyasının açılması, uygulamanın çalışacağı anlamına gelmez. Veritabanı tutarsız olabilir, izinler eksik olabilir veya uygulama sürümü yedekten geri dönen yapı ile uyumsuz olabilir.
Bir diğer hata, testin gerçek bakım penceresine hiç benzememesidir. Yani yedek, farklı disk yapısında ya da eksik bağımlılıklarla denenir ve sonuç başarılı görünür; fakat gerçek olayda aynı akış çalışmaz. Bu yüzden test ortamı mümkün olduğunca operasyonel koşullara yakın olmalıdır. Microsoft ve NIST dokümanlarında yer alan planlama ve dokümantasyon vurgusu da bu nedenle önemlidir.
İyi bir kontrol listesi nasıl görünür?
Kısa ama işe yarar bir kontrol listesi şöyle olabilir:
- Yedek türü ve tarihi doğru mu?
- Geri yüklenecek kapsam net mi?
- Test ortamı hazır mı?
- Tahmini geri dönüş süresi kabul edilebilir mi?
- Geri yüklenen veri doğrulandı mı?
- İşlem adımları dokümante edildi mi?
- Eksikler bir sonraki bakım penceresi için kaydedildi mi?
Bu yaklaşım, hem güvenlik hem süreklilik açısından daha sağlıklıdır. Özellikle fidye yazılımı, insan hatası veya disk arızası gibi durumlarda, gerçekten çalıştığı doğrulanmış bir geri yükleme prosedürü, salt yedek bulundurmaktan daha değerlidir. NIST’in yedekleri düzenli test etme ve geri yükleme prosedürlerini belgeleme yaklaşımı da bunu destekler.
Son karar
Eğer bakım pencereniz kısıtlıysa, önce en kritik veri parçasını seçip küçük bir geri yükleme testi yapın. Amaç, büyük bir felaket senaryosunu taklit etmek değil; prosedürün gerçekten çalıştığını görmektir. Test başarılıysa prosedürü sabitleyin, başarısızsa sorunu kayda geçirip sonraki bakım penceresinde düzeltin.
