BAŞLAMADAN ÖNCE
Başlamadan önce kontrol edin
Replikasyon, bağımsız ve saklamalı yedeklemenin yerine geçmez. OpenStack/Safir Cinder veri yolu ile VMware-to-VMware VDDK/CBT veri yolu ayrı ön koşullara sahiptir. VMware-to-OpenStack tasarım belgesi üretimde doğrulanmış dönüşüm desteği sayılmaz. Diğer platformlara aynı akışı varsaymayın.
Doğrulama sınırı: rehberler yerel replikasyon şablonu ve işletim belgelerinden hazırlanmıştır. Bu tur Firefox laboratuvar kontrolü güncel sayfa içeriğini güvenilir okuyamadığı için yeni replikasyon/DR ekranı alınamadı; başka bir platformun görüntüsü bu akışın yerine kullanılmadı. Full/Incremental, kesinti/resume, checkpoint boot, failover ve failback canlı çalıştırılmadı. Menü ve kaynak kodu, kurulu sürümün uçtan uca kabulü değildir.
- Kaynak/hedef site, platform ve sürüm eşleşmesi
- Ağ/TLS, veri yolu rolleri ve hedef kapasitesi
- Checkpoint kimliği, veri tutarlılığı ve ölçülen RPO
- İzole test, kaynak fencing ve failback planı
011. Olayı ve kurtarma hedefini değerlendirin
Hizmet sahibi, olay sorumlusu ve altyapı sorumlusuyla etkilenen VM/uygulamaları, bağımlılık sırasını ve son sağlam veri zamanını belirleyin. Ransomware veya veri bozulması replikaya da taşınmış olabilir; en yeni checkpoint’in temiz olduğunu varsaymayın. Gerekirse bağımsız backup kurtarma yolunu seçin. Karar ve zaman çizelgesini kaydedin.
Beklenen sonuçİş önceliği ve kabul edilebilir veri noktası belirlenir.
022. Doğrulanmış checkpoint’i inceleyin
Replication → Details içinde status, generation, source instance/volume ve checkpoint kimliğini karşılaştırın. İncelenen arayüz Failover düğmesini yalnız checkpoint-available durumunda açar; bu uygulama tutarlılığı garantisi değildir. Bütün gerekli disklerin aynı kabul edilmiş nesle ait olduğunu ve hedef verinin erişilebilirliğini doğrulayın. Checkpoint yaşından olay anındaki gerçek veri kaybını ölçün.
Beklenen sonuçKurtarma noktası ve beklenen veri kaybı kanıtlıdır.
033. İzole test hedefini ve bağımlılıkları hazırlayın
DR compute, storage, network, project/datastore, güvenlik kuralları ve lisans kapasitesini kontrol edin. Test ağını üretimden ayırın; kopya IP, hostname, domain/cluster kimliği ve otomatik dış bağlantıları engelleyin. DNS, kimlik, veritabanı ve uygulama açılış sırasını planlayın. İzole test ile üretim trafiğini devralma farklı onay ve kabul aşamalarıdır.
Beklenen sonuçİzole hedef kaynakla çakışmadan test edilebilir.
044. Üretim geçişinden önce kaynağı fence edin
Kaynak VM’in ve varsa eski DR kopyasının kapalı ve yazamaz olduğunu altyapı sorumlusuyla doğrulayın. Yalnız ping yanıtı gelmemesi fencing kanıtı değildir. Aynı veriye iki taraftan yazmayı engelleyen erişim/power kontrollerini belgeleyin. İncelenen Failover formu FENCE CONFIRMED metni ister; metni yazmak fiziksel fencing işlemini yapmaz. Bu doğrulanmadan son Failover eylemine geçmeyin.
Beklenen sonuçTek yazan taraf ve kaynak izolasyonu doğrulanır.
055. Kontrollü failover ve uygulama kabulü yapın
Onaylı olay planında politika, checkpoint ve hedef eşlemesini son kez kontrol edin. Start Failover kuyruğa alma aşamasıdır; görev tamamlanması, hedef VM/disk kimliği ve adreslerini ayrıca izleyin. Önce boot ve veri hash’i, sonra servis/veritabanı ve kullanıcı senaryolarını kontrol edin. DNS/load balancer gibi üretim yönlendirmelerini yalnız hizmet kabulünden sonra değiştirin; işlem sürelerini kaydedin.
Beklenen sonuçAltyapı ve uygulama kabulü üretim geçişini destekler.
066. Hata durumunda duruş ve geri alma sınırını belirleyin
Boot, veri veya servis kabulü başarısızsa iki kopyayı aynı anda üretime açmayın. Son doğrulanmış checkpoint’i ve logları koruyun. DR tarafında yeni yazılar başladıysa eski kaynağı açmak veri kaybı/çatışma yaratabilir; geri alma için hangi tarafın otorite olduğunu belirleyip uygulama sorumlusuyla uzlaşma planı yapın. Otomatik rollback garantisi varsaymayın.
Beklenen sonuçGeri alma kararı güncel yazıların otoritesine göre verilir.
077. Failback’i ayrı bir değişiklik olarak planlayın
Ana site sağlığını, kapasitesini ve iki yönlü veri yolu erişimini doğrulayın. DR’deki yeni veriyi kaynağa geri eşitleme/reverse replication yöntemini kurulu sürüm için teknik ekiple netleştirin; bu incelemede tek tık failback doğrulanmadı. Son delta, kontrollü duruş, yeniden fencing, boot ve uygulama kabulü için yeni pencere planlayın. Gerçek RPO/RTO, backup/checkpoint kimlikleri ve iyileştirmeleri olay raporuna yazın.
Beklenen sonuçAna siteye dönüş güncel veri ve tek yazan tarafla kabul edilir.
MERAK EDİLENLER
Replikasyon başarılıysa DR testi gerekir mi?
Evet. Veri aktarımı; boot, uygulama tutarlılığı, fencing, ağ geçişi veya ana siteye geri dönüşün kabulü değildir. Bunlar izole test ve kayıtlı işletim planıyla ayrıca doğrulanır.