Yedekleme konsolunda bütün işler yeşil görünebilir. Buna rağmen bir kesintide uygulamanın kaç dakikada açılacağını, hangi saate kadar olan verinin döneceğini ve kimin kontrol edeceğini bilmiyor olabiliriz. Bu boşluğu kapatmanın yolu, gerçek ihtiyaca göre tasarlanmış bir yedekten dönüş provası.
Önce hedefi anlaşılır hale getirelim
RTO, kesintiden sonra hizmeti geri getirmek için hedeflenen süreyi; RPO ise geri dönülecek verinin zaman olarak kabul edilebilir kaybını ifade eder. Bu hedeflerin iş etkisi üzerinden belirlenmesi, NIST'in süreklilik planlama rehberinin temel yaklaşımıdır. Her uygulamaya aynı rakamı yazmak, kritik hizmetle ertesi gün açılabilecek bir arşivi aynı kefeye koyar.
Örnek olarak RTO'su iki saat, RPO'su bir saat olan bir uygulamayı düşünelim. Bunlar örnek hedefler. Provanın başlangıç saati 10.00 ve doğrulanmış kurtarma noktası 08.30 ise, uygulama yarım saatte açılsa bile veri kaybı hedefi sağlanmamış olur. Süre ve veri güncelliğini ayrı ölçmek gerekiyor.
Testin sınırını çizelim
İlk prova için üretimi durdurmak gerekmez. Geri yüklenen sistemin üretimle çakışmayacağı, dışarıya mesaj veya işlem göndermeyeceği izole bir ortam hazırlayın. Aynı kimlikle açılan bir sunucunun üretime karışması, kurtarma denemesini gerçek arızaya dönüştürebilir. Ağ izolasyonu, adresleme ve uygulamanın dış bağlantıları test öncesinde kontrol edilmeli.
Senaryoyu tek cümleyle tarif edin: “Ana sanal makine kullanılamıyor, son geçerli yedekten uygulamayı açacağız.” Ardından hangi ekiplerin katılacağını, hangi kaynakların hazır varsayıldığını ve hangi koşulda testin durdurulacağını yazın. Hazır bir depolama alanını kullanmakla sıfırdan altyapı kurmak aynı senaryo değildir.
Kronometreyi doğru yerde başlatalım
Kayıt altına alınacak ara zamanlar şunlar olabilir:
- Kesintinin fark edilmesi ve kurtarma kararının verilmesi
- Yedeğe ve gerekli erişim bilgilerine ulaşılması
- Verinin geri yüklenmesi ve sistemin açılması
- Bağımlı servislerin hazırlanması
- Uygulama sahibinin işlev kontrolünü tamamlaması
Sadece dosya kopyalama süresini raporlamak, karar ve hazırlık aşamalarındaki beklemeyi gizler. Prova raporunda ölçümün nerede başlayıp nerede bittiği açık olmalı. Hazırlık sırasında geçen süreyi dışarıda bıraktıysanız bunu ayrıca belirtin.
Açıldıktan sonra neyi kontrol edeceğiz?
Oturum ekranının görünmesi iyi bir başlangıç. Kabul testi ise uygulamaya uygun, küçük ve tekrar edilebilir bir iş akışı olmalı: örnek kaydı aramak, son tamamlanan işlemi doğrulamak, ilişkili bir belgeyi açmak veya zararsız bir test kaydını kontrol etmek. Verinin tutarlılığı için uygulama sahibinin hazırladığı kontrol listesini kullanın.
Bazı ürünler bu kontrollerin bir bölümünü otomatikleştirir. Örneğin Veeam SureBackup, yedekteki makineleri izole ortamda başlatıp doğrulama testleri çalıştırabilir. Otomatik sonuçların yanına iş uygulamasına özgü kabul kontrolünü eklemek, raporu daha anlamlı hale getirir.
Provanın çıktısı bir sonraki işi belirlesin
Kısa raporda hedef, gerçekleşen süre, kullanılan kurtarma noktası, başarısız kontrol ve sorumlu kişi bulunsun. Anahtarın bulunamaması, eksik lisans bilgisi veya yavaş aktarım birbirinden farklı aksiyonlar gerektirir. Her bulguya bir sahip ve yeniden deneme tarihi verin.
Test verisini ve geçici kaynakları kapatırken üretimle karışmayacak bir temizlik planı uygulayın. Büyük altyapı değişikliklerinden sonra provayı yenileyin; diğer tekrarların sıklığını hizmetin kritikliği belirlesin. Böylece “yedek var” cümlesinin yanına ölçülmüş, kapsamı belli bir kurtarma sonucu koyabiliriz.
Yorumlar (0)
Henüz onaylanmış yorum yok.