Güncellendi:
Bu rehber, VMware Site Recovery Manager (SRM) için araştırma yapan ekiplerin kurtarma planı tasarlamasına odaklanır. Kaynak olarak verilen Protection and Recovery 9.1 belgesi; sanal makinelerin, açılış sırasının ve ağ ayarlarının bir kurtarma planıyla nasıl düzenlendiğini açıklar. İşlem adımlarını kurulu ürün ve sürümle eşleştirin. Veri çoğaltma, yedek saklama ve uygulama doğrulaması ayrı sorumluluklar olmaya devam eder.
Görseli büyüt →
Orkestrasyon neyi yönetir?
Kurtarma yalnız sanal makineleri açmak değildir. Ağ eşleştirmesi, IP ve DNS düzeni, uygulama bağımlılıkları ve açılış sırası birlikte ele alınır. Bir veritabanı hazır olmadan uygulama sunucusunun açılması kullanıcının hizmet alabildiğini göstermez. Plan, bu bağımlılıkları ve doğrulama adımlarını görünür hale getirmelidir.
SRM ile ilişkili veri çoğaltma seçenekleri kurulu sürüm ve desteklenen altyapıya bağlıdır. vSphere Replication veya desteklenen depolama entegrasyonları gibi yolların koşulları aynı değildir. Ürün ailesinin güncel adını, uyumluluk matrisini ve lisans kapsamını mevcut kurulumla eşleştirmeden eski bir kurulum tarifini uygulamayın.
Replikasyon, yedek ve kurtarma planı
Replikasyon, verinin başka bir konuma aktarılmasını sağlar; hatalı silme veya bozulma da çoğaltılabilir. Yedekleme, uygun saklama politikasıyla geçmiş bir duruma dönme ihtiyacına hizmet eder. Kurtarma orkestrasyonu ise seçilen kopyayla hizmeti yeniden çalıştıracak adımları düzenler. Bu üç işlev birbirinin bütün görevlerini üstlenmez.
RPO, kabul edilebilir veri kaybı aralığını; RTO, hizmete dönüş için hedeflenen süreyi tanımlar. İkisi de iş ihtiyacından türetilmelidir. Replikasyon aralığı tek başına uygulamanın gerçek veri kaybını, sanal makinenin açılış süresi de tam hizmete dönüş süresini kesinleştirmez.
Planlı geçiş ve kesinti sonrası kurtarma
Planlı geçişte kaynak ortamla koordinasyon kurmak ve son veriyi eşitlemek mümkün olabilir. Beklenmedik kesintide kaynak erişilemeyebilir; son kullanılabilir kopya ve mevcut altyapıyla karar verilmesi gerekir. Bu iki senaryonun kontrol ve veri kaybı koşulları aynı değildir.
Aynı uygulamanın iki tarafta kontrolsüz yazma yapması veri ayrışmasına yol açabilir. Kaynak tarafın durumunu, erişim kesme adımlarını ve yetkili karar sahibini planlayın. “Kurtar” düğmesine basılması, kullanıcı trafiğinin doğru yere gittiğini veya eski örneğin güvenli şekilde devreden çıktığını tek başına göstermez.
Testte uygulamayı doğrulayın
- Deneme ağının üretim sistemlerine istenmeyen erişim veya bildirim üretmediğini kontrol edin.
- Veritabanı, kimlik, DNS, lisans ve dış servis bağımlılıklarını hesaba katın.
- Temsilî kullanıcı işlemleriyle okuma ve yazma bütünlüğünü doğrulayın.
- Gerçekleşen süreleri, kullanılan veri noktasını ve başarısız adımları kaydedin.
- Test kaynaklarını ve geçici erişimleri kontrollü şekilde temizleyin.
Bir testin geçmişte başarılı olması yeni sürüm, ağ değişikliği veya farklı veri boyutunda aynı sonucu garanti etmez. Kurtarma planını önemli değişikliklerden sonra yeniden değerlendirin. Deneme sonucunu “makineler açıldı” yerine uygulama kabul ölçütleriyle raporlayın.
Geri dönüşü baştan planlayın
İkincil ortamda çalışmaya başladıktan sonra kaynak sisteme dönmek ayrı bir süreçtir. Yeni verinin hangi yönde korunacağı, yeniden koruma işlemleri ve bir sonraki geçişin koşulları belirlenmelidir. Desteklenen sürüme göre süreç değişebilir. Geri dönüş planı yoksa geçici kurtarma ortamı beklenenden uzun süre tek üretim noktası haline gelebilir.
Sık sorulan sorular
- SRM yedekleme ürünü müdür?
-
Temel rolü kurtarma adımlarını orkestre etmektir. Kullanılan veri kopyası, replikasyon ve geçmiş sürümlerden geri yükleme gereksinimi ayrıca tasarlanır.
- Başarılı kurtarma testi kesinti olmayacağını garanti eder mi?
-
Hayır. Test belirli koşullarda kanıt sağlar. Yeni bağımlılıklar, veri büyümesi ve gerçek arızanın niteliği sonucu değiştirebilir.
Sonraki adım
Replikasyon ve yedekleme rehberlerini birlikte kullanın. Önce işin veri kaybı ve hizmete dönüş hedeflerini yazın; ardından kurulu ürüne uygun kurtarma akışını doğrulayın.
