Restore testi hangi seviyede yapılmalı?
Yedek işinin başarılı olması, iş uygulamasının geri dönebildiğini tek başına göstermez. Testin hedefi, belirli bir kurtarma noktasından veriyi geri getirip hizmetin kabul kriterlerini doğrulamaktır. Aşağıdaki plan önerilen bir değerlendirme çerçevesidir; uygulanmış müşteri vakası veya performans garantisi değildir.
| Seviye | Örnek kapsam | Kabul kanıtı |
|---|---|---|
| Dosya | Seçilen klasör ve farklı tarihli belgeler | Dosya açılır; içerik, sürüm ve erişim izinleri doğrulanır. |
| Sanal makine | Sunucunun izole ağda açılması | İşletim sistemi, diskler ve gerekli servisler kontrol edilir. |
| Uygulama / veritabanı | ERP veya veri tabanında temsilî işlem | Uygulama sahibi kayıtları ve işlem sonucunu kabul eder. |
| Hizmet bütünü | Kimlik, DNS, ağ ve bağlı sistemlerle kurtarma | Kritik iş akışı hedef süre içinde çalışır; bağımlılıklar raporlanır. |
Bir dosyayı açabilmek tüm ERP sisteminin kurtarılabildiğini kanıtlamaz. Raporunuz hangi seviyenin test edildiğini ve hangisinin kapsam dışında kaldığını açıkça belirtmeli.
Altı adımda yedekten geri dönüş testi
- Hedefi ve sorumluları yazın. Kritik hizmeti, kabul edilebilir kesinti süresini (RTO), veri kaybı hedefini (RPO) ve iş birimi onayını belirleyin. RPO ve RTO rehberini inceleyin.
- Kurtarma noktasını seçin. Verinin hangi ana ait olduğunu, gerekli yedek zincirini, depoya erişimi ve şifreleme anahtarlarının kullanılabilirliğini doğrulayın. Anahtar ve parolaları test raporuna kopyalamayın.
- İzole test ortamını hazırlayın. Kaynak, ağ ve depolama ihtiyacını belirleyin. Aynı IP/isimlerin üretime karışmasını, otomatik e-posta ve zamanlanmış işlerin gerçek sistemlerde işlem oluşturmasını engelleyin.
- Geri dönüşü gerçekleştirin. Yetkili ekip üreticinin desteklediği yöntemi uygulasın. Bekleme, aktarım, açılış ve hata sürelerini ayrı kaydedin; yalnız veri kopyalama süresini toplam kurtarma süresi olarak sunmayın.
- İş akışını doğrulayın. Oturum açma, izinler, temsilî kayıtlar ve kritik işlemler için önceden tanımlanan kabul kriterlerini kullanın. Sunucuya ping yanıtı almak uygulama kabulü için yeterli değildir.
- Raporlayın ve yeniden test edin. Sonuç, kanıt, eksik bağımlılık, düzeltme sahibi ve tekrar test tarihini kaydedin. Test kopyalarını saklama politikasına göre temizleyin; üretim yedeklerini koruyun.
Raporun asgari alanları: hizmet, kapsam, kurtarma noktası, başlangıç/bitiş zamanları, RTO/RPO hedefleri, gözlenen sonuç, iş birimi kabulü, açık sorunlar ve düzeltme planı. Test kopyaları da erişim ve veri koruma kapsamındadır.
RTO ve RPO nasıl ölçülür? Örnek hesap
Bu saatler yalnız hesaplama örneğidir. Kurtarılan verinin temsil ettiği an 08.00, kesinti başlangıcı 08.40 olsun. Başka kurtarılabilir işlem kaydı bulunmadığı varsayımıyla veri kaybı penceresi 40 dakikadır. RPO hedefi 30 dakika ise hedef karşılanmaz.
Kurtarma işlemi 09.00'da başlayıp hizmet 09.55'te kabul edilirse toplam kesinti 75 dakikadır. İşlem süresi 55 dakika olsa da RTO hesabında 20 dakikalık beklemeyi dışarıda bırakmayın. RTO hedefi 60 dakika ise bu senaryo başarısızdır.
Her testte aynı başlangıç ve kabul tanımlarını kullanın. Test ortamının kaynakları, veri hacmi ve bağımlılıkları üretimden farklıysa bu sınırı rapora yazın; laboratuvar sonucunu doğrudan gerçek olay süresi garantisine dönüştürmeyin.
Veeam SureBackup ve test sıklığı
Veeam belgelerinde SureBackup için iki ayrı mod açıklanır: izole ortamda makineleri çalıştırarak canlı uygulamaları test eden tam kurtarılabilirlik testi; yedek bütünlüğü ve içerik taraması yapan doğrulama modu. Teklifte hangi modun ve iş yüklerinin kapsandığını belirtin. Resmî dokümantasyona bakın.
Otomatik test sonucunu uygulama sahibi kabulü, dış bağlantılar ve tüm hizmet bağımlılıklarıyla tamamlamayı öneriyoruz. Platform, sürüm ve lisans uygunluğunu kurulum öncesinde doğrulayın. Veeam hizmet kapsamını inceleyin.
Tek bir sıklığı bütün şirketlere uygulamayın. Kritik hizmet, değişim hızı ve kabul edilen risk için test takvimi belirleyin. Büyük uygulama, ağ veya yedekleme değişikliği sonrasında ilgili senaryoyu yeniden değerlendirin. Sorumluları felaket kurtarma çalışma planına ekleyin.
Restore testi hakkında sık sorulan sorular
Immutable yedek varsa test gerekir mi?
Değiştirilemezlik, belirlenen koşullarda yedeğin değiştirilmesi veya silinmesine karşı koruma sağlar. Uygulamanın doğru ve zamanında geri döndüğünü ayrıca doğrulayın. Immutable backup rehberini ve kurtarma senaryosunu birlikte inceleyin.
Test doğrudan üretimde yapılmalı mı?
Başlangıç için sınırları belirlenmiş izole ortam öneriyoruz. Üretime geçiş içeren tatbikatta kapsam, değişiklik onayı, bakım penceresi ve geri alma planı önceden hazırlanmalı.
Teklif için hangi bilgiler gerekir?
Kritik uygulamalar, sunucu/VM sayısı, veri hacmi, yedekleme ürünü ve sürümü, saklama süresi, kurtarma hedefleri ve mevcut test ortamını paylaşın. İlk görüşmede gerçek müşteri verisi, parola veya erişim anahtarı göndermeyin. Kapsamı lisans, test altyapısı, uygulama doğrulaması ve raporlama olarak ayrı değerlendirelim.