- Konu sahibi
- #1
Birçok ekip yedek aldığını bilir ama o yedeğin gerçekten işe yarayıp yaramadığını düzenli olarak doğrulamaz. Asıl kritik nokta, yedek alma ile geri dönme sürecini üretim dışı bir ortamda test etmek ve bu testi bakım akışının doğal parçası haline getirmektir. Bulut sağlayıcılarının güncel rehberleri de kurtarma hedeflerinin belirlenmesini, geri yükleme testlerinin tekrarlanmasını ve operasyon ekibinin bu adımları uygulayabilmesini özellikle vurguluyor.
Yedekleme tek başına yeterli değildir; asıl soru, bir kesinti olduğunda sistemin ne kadar sürede ayağa kalkacağı ve ne kadar veri kaybının kabul edilebilir olduğudur. Bu yüzden RTO ve RPO gibi hedefleri önceden netleştirmek gerekir. Kurtarma testi, yalnızca dosyanın geri gelmesini değil, uygulamanın çalışır hale gelmesini de doğrular.
En pratik yaklaşım, kurtarma testini ayrı bir “acil durum işi” gibi değil, planlı bakım maddesi gibi ele almaktır. Örneğin aylık ya da çeyreklik bakım penceresinde şu sıra izlenebilir:
Bu yaklaşım, hem yedeklerin bozulmuş olma ihtimalini erken yakalar hem de ekip değiştiğinde süreç bilgisinin kaybolmasını engeller. AWS ve Google Cloud rehberleri de testlerin planlı yürütülmesini, adımların dokümante edilmesini ve öğrenilenlerin kaydedilmesini öneriyor.
Sadece “backup restore oldu” demek çoğu zaman yeterli değildir. Daha faydalı bir test senaryosu şu sorulara cevap vermelidir:
Burada amaç, yedeğin sadece dosya olarak mevcut olduğunu değil, hizmeti yeniden başlatmak için yeterli olduğunu kanıtlamaktır.
En yaygın hata, geri yükleme testini hiç yapmamaktır. İkinci yaygın hata, testi yalnızca aynı sunucuya geri yükleyip sonuç başarılıysa işi bitmiş saymaktır. Oysa gerçek senaryoda farklı disk yapısı, farklı ağ ayarları veya eksik bağımlılıklar devreye girebilir. Bir başka hata da test sonucunu not almamak; bu durumda bir sonraki bakımda aynı sorun tekrar yaşanır. Microsoft ve AWS dokümantasyonları, kurtarma prosedürlerinin yazılı tutulmasını ve düzenli olarak güncellenmesini özellikle vurguluyor.
Eğer ayrı bir DR laboratuvarınız yoksa bile daha küçük bir doğrulama akışı kurabilirsiniz. Önce kritik veriyi kapsayan bir yedeği seçin, ardından test ortamında geri yükleyin ve en azından şu üç şeyi kontrol edin: uygulama açılıyor mu, veri okunuyor mu, kullanıcı akışı bozulmadan ilerliyor mu. Bu, tam kapsamlı felaket kurtarma tatbikatının yerine geçmez; ama yedeklerin gerçekten kullanılabilir olup olmadığını anlamak için iyi bir başlangıçtır.
Bir yedek stratejisi ancak düzenli kurtarma testi varsa güvenilir sayılır. Bakım penceresini yalnızca güncelleme yapmak için değil, geri dönüş kabiliyetini ölçmek için de kullanmak gerekir. Böylece sorun çıktığında “yedek var mı?” sorusundan çok, “geri dönüş ne kadar sürer ve hangi parça aksar?” sorusuna hazır olursunuz.
Bu konu neden ayrı düşünülmeli?
Yedekleme tek başına yeterli değildir; asıl soru, bir kesinti olduğunda sistemin ne kadar sürede ayağa kalkacağı ve ne kadar veri kaybının kabul edilebilir olduğudur. Bu yüzden RTO ve RPO gibi hedefleri önceden netleştirmek gerekir. Kurtarma testi, yalnızca dosyanın geri gelmesini değil, uygulamanın çalışır hale gelmesini de doğrular.
Bakım akışına nasıl yerleştirilir?
En pratik yaklaşım, kurtarma testini ayrı bir “acil durum işi” gibi değil, planlı bakım maddesi gibi ele almaktır. Örneğin aylık ya da çeyreklik bakım penceresinde şu sıra izlenebilir:
- Yedek bütünlüğünü kontrol etme
- Test ortamına geri yükleme yapma
- Uygulama, veritabanı ve dosya erişimini doğrulama
- Logları ve hata çıktısını inceleme
- Gerekirse runbook’u güncelleme
Bu yaklaşım, hem yedeklerin bozulmuş olma ihtimalini erken yakalar hem de ekip değiştiğinde süreç bilgisinin kaybolmasını engeller. AWS ve Google Cloud rehberleri de testlerin planlı yürütülmesini, adımların dokümante edilmesini ve öğrenilenlerin kaydedilmesini öneriyor.
İyi bir test senaryosunda neler olmalı?
Sadece “backup restore oldu” demek çoğu zaman yeterli değildir. Daha faydalı bir test senaryosu şu sorulara cevap vermelidir:
- Yedek son alınan sürümü gerçekten temsil ediyor mu?
- Veri tabanı açılıyor mu, şema ve bağlantılar sağlam mı?
- Web uygulaması doğru yapılandırmayla çalışıyor mu?
- DNS, sertifika, servis hesabı veya izinler gibi dış bağımlılıklar sorun çıkarıyor mu?
- Geri dönüş süresi hedeflenen RTO içinde kalıyor mu?
Burada amaç, yedeğin sadece dosya olarak mevcut olduğunu değil, hizmeti yeniden başlatmak için yeterli olduğunu kanıtlamaktır.
Sık yapılan hatalar
En yaygın hata, geri yükleme testini hiç yapmamaktır. İkinci yaygın hata, testi yalnızca aynı sunucuya geri yükleyip sonuç başarılıysa işi bitmiş saymaktır. Oysa gerçek senaryoda farklı disk yapısı, farklı ağ ayarları veya eksik bağımlılıklar devreye girebilir. Bir başka hata da test sonucunu not almamak; bu durumda bir sonraki bakımda aynı sorun tekrar yaşanır. Microsoft ve AWS dokümantasyonları, kurtarma prosedürlerinin yazılı tutulmasını ve düzenli olarak güncellenmesini özellikle vurguluyor.
Küçük ekipler için uygulanabilir pratik
Eğer ayrı bir DR laboratuvarınız yoksa bile daha küçük bir doğrulama akışı kurabilirsiniz. Önce kritik veriyi kapsayan bir yedeği seçin, ardından test ortamında geri yükleyin ve en azından şu üç şeyi kontrol edin: uygulama açılıyor mu, veri okunuyor mu, kullanıcı akışı bozulmadan ilerliyor mu. Bu, tam kapsamlı felaket kurtarma tatbikatının yerine geçmez; ama yedeklerin gerçekten kullanılabilir olup olmadığını anlamak için iyi bir başlangıçtır.
Son karar kriteri
Bir yedek stratejisi ancak düzenli kurtarma testi varsa güvenilir sayılır. Bakım penceresini yalnızca güncelleme yapmak için değil, geri dönüş kabiliyetini ölçmek için de kullanmak gerekir. Böylece sorun çıktığında “yedek var mı?” sorusundan çok, “geri dönüş ne kadar sürer ve hangi parça aksar?” sorusuna hazır olursunuz.
