Felaket Kurtarmada RPO ve RTO Hedeflerini Gerçekten Ölçmek

RPO ve RTO nedir, neden çoğu zaman kağıt üzerinde kalır

Bir felaket kurtarma planının merkezinde iki sayı durur: RPO (Recovery Point Objective) ne kadar veri kaybını göze aldığınızı, RTO (Recovery Time Objective) sistemi tekrar ayağa kaldırmak için ne kadar süreniz olduğunu tanımlar. Bu iki sayıyı belirlemek kolaydır, bir toplantıda "RPO 15 dakika, RTO 4 saat" yazıp geçmek bir saat sürer. Zor olan bu sayıların gerçekten karşılanıp karşılanmadığını bilmektir. Çoğu ekip bunu hiç ölçmez, yedekleme işi her gece yeşil döndüğü için hedefin tutturulduğunu varsayar. Bu varsayım, gerçek bir kesintide en pahalı sürprizin kaynağıdır.

Yedek almak ile RPO'yu karşılamak aynı şey değil

Bir yedekleme aracının her gece başarıyla tamamlanması üç ayrı iddiayı doğrulamaz: alınan verinin tutarlı olduğunu, o veriden gerçekten geri dönülebildiğini ve geri dönüşün hedeflenen süre içinde bittiğini. Örnek: bir veritabanı dökümü, dosya sistemi tam o anda yazma işlemi yaparken alınırsa dosya boyutu doğru, içerik bozuk olabilir. Yedekleme aracı "0 hata" der, restore anında ilk sorgu patlar. Bunu yakalamanın tek yolu ara sıra gerçek bir restore denemesi yapmaktır; log dosyasına "success" yazması yeterli kanıt değildir.

İkinci sorun retention ve prune mantığında çıkar. Birçok yedekleme aracı eski anlık görüntüleri belirli bir politikaya göre siler. Bu silme işlemi bir kilit dosyası ya da yarım kalmış bir önceki çalışma yüzünden sessizce başarısız olabilir; araç yine de "backup tamam" der, çünkü ölçtüğü şey backup adımıdır, prune adımı değil. Sonuç: depo şişer, kimse fark etmez, ta ki disk dolana ya da bir gün gerçekten restore gerekene kadar. Bu yüzden yedekleme izlemesi yalnız "backup job başarılı mı" sorusuna değil, "depo büyüklüğü beklenen eğride mi" ve "en eski geçerli anlık görüntü ne zaman" sorularına da cevap vermelidir.

RTO'yu ölçerken atlanan değişkenler

RTO'yu "restore komutu ne kadar sürüyor" diye ölçmek yanıltıcıdır. Gerçek RTO şu adımların toplamıdır: erişim ve yetki almak (kimin hangi anahtara, hangi konsola erişimi var, bu bilgi kriz anında hatırlanacak mı), veriyi indirmek (ağ bant genişliği, veri büyüklüğüyle doğrusal büyür), veriyi geri yüklemek, servisleri doğru sırayla başlatmak ve bağımlılıkların (DNS, sertifika, harici servis) hazır olmasını beklemek.

Buradaki en yaygın hata, restore testini ilk kurulumdaki küçük veri setiyle yapıp o süreyi RTO diye kaydetmektir. Veri altı ay içinde on kat büyürse restore süresi de orantılı büyür, ama kimse tatbikatı tekrarlamadığı için kağıt üzerindeki RTO değişmez. Ölçüm tek seferlik bir sertifika değil, veri büyüklüğüyle birlikte güncellenmesi gereken bir sayıdır.

İkinci atlanan değişken insan faktörüdür. Kriz anında hangi belgeye bakılacağı, o belgenin hangi sistemde durduğu ve o sisteme kesinti sırasında erişilip erişilemeyeceği genelde hiç test edilmez. Runbook'un kendisi felaket senaryosunda erişilemez bir yerde (örneğin çökmüş sistemin kendi wiki'sinde) tutuluyorsa, restore adımlarının ne kadar hızlı çalıştığının önemi kalmaz.

Üç test yaklaşımı ve nerede işe yarar

Masabaşı tatbikat (tabletop exercise): Ekip bir araya gelir, "sunucu X çöktü" senaryosunu konuşur, kim ne yapar sırayla anlatılır. Maliyeti düşüktür, iletişim boşluklarını ortaya çıkarır (örneğin kimse yedek anahtarların nerede olduğunu bilmiyor) ama gerçek süreyi ölçmez. Küçük ekipler için başlangıç noktası olarak yeterlidir, tek başına RTO kanıtı olarak kullanılmamalıdır.

Otomatik restore tatbikatı: Belirli aralıklarla (haftalık ya da aylık) en son yedek izole bir ortama gerçekten geri yüklenir, servis sağlık kontrolünden geçirilir, süre kaydedilir. Bu yaklaşım gerçek RPO ve RTO'yu üretir çünkü insan müdahalesi ve varsayım payı azdır. Maliyeti orta düzeydedir: izole bir ortam ve otomasyon script'i gerektirir, ama bir kez kurulunca sürdürme maliyeti düşüktür. Çoğu ekip için doğru denge burasıdır. Restore edilen ortamın donanım ve ağ profilinin üretimden çok farklı olmaması önemlidir; aynı veri merkezindeki hızlı iç ağ üzerinden yapılan bir test, gerçek felakette farklı bir bölgeden yapılacak transferin süresini gizler.

Canlı üzerinde gerçek failover testi (chaos/game day): Üretim trafiğinin bir kısmını ya da tamamını gerçekten yedek sisteme kaydırıp gerçek kesinti yaratarak test etmek. En gerçekçi sayıyı verir çünkü ağ, DNS TTL, önbellek ısınma süresi gibi hiçbir tatbikatta ortaya çıkmayan etkenleri de içerir. Riski ve maliyeti en yüksek yöntemdir, olgun bir izleme ve geri alma altyapısı olmadan denenmemelidir.

Pratik öneri: küçük ve orta ölçekli sistemler için otomatik restore tatbikatıyla başlayın. Bu size gerçek bir sayı verir ve üretim riski taşımaz. Kritiklik arttıkça (ödeme sistemi, tek nokta veritabanı) sıklığı artırın ve zamanla gerçek failover testine geçin.

Uygulanabilir adımlar

Tek bir organizasyon geneli RPO/RTO hedefi belirlemeyin. Verinin kritiklik seviyesine göre katmanlar tanımlayın: örneğin kullanıcı verisi ve finansal kayıtlar için RPO 15 dakika, log ve önbellek verisi için RPO 24 saat olabilir. Her katman için ayrı test sıklığı belirleyin; yüksek kritiklikte haftalık, düşük kritiklikte aylık ya da üç aylık yeterli olabilir.

Restore süresini bir metrik olarak toplayın, sadece "backup job süresi"ni değil. Restore başlangıcından servisin sağlık kontrolünü geçtiği ana kadar geçen süreyi kaydedin ve zaman içindeki trendini izleyin. Veri büyüdükçe bu sayı da büyüyecektir, bunu önceden görüp kapasiteyi ya da yedekleme stratejisini (artımlı yedek, paralel restore) buna göre ayarlayın.

Restore sonrası veri bütünlüğünü doğrulayın. Sadece komutun sıfır hatayla bittiğini değil, geri yüklenen veride beklenen kayıt sayısının, bir checksum'ın ya da uygulama düzeyinde bir smoke testin geçtiğini kontrol edin. "Restore komutu 0 döndü" ile "uygulama gerçekten doğru veriyle çalışıyor" arasında büyük bir fark vardır.

Şifreli yedeklerde anahtar yönetimini ayrı test edin. Yedekleme başarılı olabilir ama şifre çözme anahtarı rotasyonda kaybolmuşsa gerçek RPO sonsuzdur, bu sadece felaket anında fark edilir. Anahtarın kendisini de düzenli olarak "bu anahtarla gerçekten açılıyor mu" diye test edin ve anahtarın kendisinin de ayrı, bağımsız bir şekilde yedeklendiğinden emin olun.

Runbook'u kesinti senaryosunda erişilebilir bir yerde tutun ve tatbikat sırasında gerçekten o belgeyi takip ederek çalışın; belgeyi yazan kişinin hafızasına güvenerek yapılan bir tatbikat, belgenin eksik ya da güncel olmadığı yerleri gizler.

Ne zaman bu kadar yatırım yapmayın

Her sistem haftalık restore tatbikatı hak etmez. Düşük kritiklikte, kolayca yeniden üretilebilir (örneğin statik önbellek, log arşivi) sistemler için basit ve seyrek bir kontrol yeterlidir. Test sıklığını ve derinliğini o sistemin gerçek kesinti maliyetiyle orantılı tutun; aksi halde ekip zamanının çoğunu düşük riskli sistemleri test etmeye harcar, asıl kritik sistemin tatbikatı ihmal edilir. RPO ve RTO hedefleri bir onay kutusu değil, gerçek kesinti anında kaç dakikanızın veri kaybının hesaba katıldığı bir sözleşmedir; sözleşmeyi imzalamadan önce test edin.