Düşük Bütçeyle Felaket Kurtarma — Sanal Sunucu Replikasyonu

"Yedeğimiz var" cümlesi, donanım arızasında hizmetin kaç saat içinde ayağa kalkacağı sorusunu cevaplamaz. Yedekten dönüş saatler sürebilir; replikasyon ise çalışmaya hazır bir kopyayı bekletir. Sanal sunucu replikasyonu projesinde kısıtlı donanım kaynağıyla bu esnekliği nasıl kazandığımızı anlatacağım.

Yedekleme ve replikasyon aynı şey değil

İkisi birbirinin alternatifi değil, tamamlayıcısıdır:

Yedekleme geçmişe dönük kopyalar tutar; silinen dosyayı, şifrelenen diski, aylar önceki durumu kurtarır. Geri dönüş süresi (RTO) uzundur.
Replikasyon kritik sunucunun ikinci donanımda çalışmaya hazır bir kopyasını tutar; kayıp süresi (RPO) replikasyon aralığı kadardır, dönüş dakikalar mertebesindedir.

Fidye yazılımı senaryosunda replika da şifreli veriyi kopyalayacağı için tek başına replikasyon yeterli değildir — yedekleme her durumda kalır.

Önce ölçün: her sunucu kritik değil

Bütçe kısıtlıysa ilk iş envanteri önceliklendirmek. Sorulacak soru şu: "Bu sunucu bir gün kapalı kalırsa ne olur?" Cevaba göre:

Kritik (etki alanı denetleyicisi, ERP, dosya sunucusu…) → replikasyon + yedek
Önemli ama bekleyebilir → yalnızca sık yedek
Yeniden kurulabilir (test, geçici işler) → standart yedek

Bu ayrım, "her şeyi replike edecek kadar disk yok" problemini çoğu zaman kendiliğinden çözüyor: replikasyon listesi sanıldığından kısa çıkar.

Kurulumda işe yarayan kararlar

İkinci donanım birinciyle aynı güçte olmak zorunda değil. Felaket anında geçici olarak düşük performansla çalışmak, hiç çalışmamaktan iyidir; eldeki emekli edilmiş bir sunucu bile DR hedefi olabilir.
Replikasyon aralığını RPO'ya göre seçin. Her sunucuya aynı aralık dayatmak yerine veri değişim hızına bakın: dosya sunucusu için kısa, az değişen uygulama sunucusu için uzun aralık kaynakları rahatlatır.
İlk replikayı mesai dışında alın. İlk kopya tam veri transferidir ve ağı ciddi yorar; sonrası yalnızca değişen bloklardır.
Retention'daki restore point sayısını sınırlı tutun. Replika üzerindeki her geri dönüş noktası hedef diskinde snapshot olarak yaşar; kontrolsüz artarsa hedef depolamayı doldurur.

Test edilmeyen DR, DR değildir

En sık atlanan adım: failover'ı gerçekten denemek. Planlı bir bakım penceresinde replikaya geçip uygulamaların açıldığını, IP/DNS ayarlarının doğru geldiğini görmeden o replikaya güvenilmez. Takvime bağlanmış (örneğin üç ayda bir) bir failover tatbikatı, felaket gününde sürprizleri sıfırlıyor.

Sonuç

Felaket kurtarma çoğu zaman bir bütçe problemi gibi görünür; pratikte ise bir önceliklendirme problemidir. Kritik sunucular doğru seçilip mevcut donanımdan ikinci bir hedef çıkarıldığında, yeni yatırım olmadan da kuruma gerçek bir kurtarma esnekliği kazandırılabiliyor.