Yedekleme ve felaket kurtarma (Disaster Recovery) aynı amaca hizmet ediyormuş gibi görünür; oysa teknik rolleri, operasyon beklentileri ve planlama kapsamları birbirinden ayrılır. Bir ortamda düzenli yedekleme job'larının başarılı tamamlanması, büyük ölçekli bir kesinti anında otomatik geçişin hazır olduğu anlamına gelmez. Doğru mimari, her iki katmanın ne zaman devreye gireceğini ve hangi hedefleri karşılayacağını netleştirir.
Yedekleme ne işe yarar?
Yedekleme, üretim verisinin belirli aralıklarla veya sürekli olarak ayrı bir hedefe kopyalanmasıdır. Temel işlevi, geçmiş bir noktaya geri dönmek, yanlışlıkla silinen dosyaları kurtarmak veya bozulmuş bir sistemi yeniden oluşturmaktır. Yedek kopyalar genellikle saklama politikasına (retention) bağlıdır; eski noktalar belirli bir süre sonra silinir veya arşivlenir.
Yedekleme mimarisinde dikkat edilmesi gereken başlıklar arasında yedekleme penceresi, ağ bant genişliği, hedef depolama tipi ve erişim modeli yer alır. Üretim sistemlerinden ayrılmış yedekleme hesapları, mümkün olduğunca sınırlı ayrıcalıklar ve düzenli doğrulama adımları operasyonel güvenilirliği artırır. Yedekleme tek başına bir iş sürekliliği planı değildir; ancak çoğu kurtarma senaryosunun temel veri kaynağıdır.
Tam yedekleme, artımlı yedekleme ve sürekli veri koruması gibi farklı yöntemler farklı RPO profilleri sunar. Tam yedekleme daha basit geri yükleme sağlarken depolama ve süre maliyeti yüksektir; artımlı yedekleme depolamayı verimli kullanır ancak geri yükleme zinciri daha karmaşık olabilir. İş yükü tipine göre doğru yöntem seçilmelidir.
Felaket kurtarma neyi kapsar?
Felaket kurtarma, veri merkezi kaybı, uzun süreli bölgesel kesinti veya toplu sistem arızası gibi geniş çaplı olaylar sonrasında kritik sistemlerin tanımlı bir hedef ortama geri getirilmesini planlar. DR planı; hangi uygulamaların öncelikli olduğunu, hangi veri kaynağının kullanılacağını, geçişin nasıl tetikleneceğini ve başarı kriterlerinin ne olduğunu içerir.
DR senaryolarında yedekten geri yükleme yalnızca bir seçenektir. Replikasyon ile ikincil bir ortama sürekli veya periyodik kopya taşınması, failover süresini kısaltmayı hedefler. Hangi yöntemin uygun olduğu iş yükü kritikliği, mevcut altyapı ve operasyon modeline göre belirlenir; tek bir şablon tüm ortamlar için yeterli değildir.
DR planında iletişim protokolleri, karar yetkileri ve geçiş sonrası doğrulama adımları da tanımlanmalıdır. Teknik failover tamamlandığında DNS güncellemesi, uygulama sağlık kontrolleri ve kullanıcı erişim testleri planın parçasıdır. Bu operasyonel katman, yedekleme altyapısından bağımsız olarak DR sürecinin tamamlanması için gereklidir.
RPO ve RTO: ortak dil, farklı kararlar
RPO (Recovery Point Objective), kabul edilebilir veri kaybı miktarını; RTO (Recovery Time Objective) ise sistemin tekrar hizmet vermeye başlaması için hedeflenen süreyi ifade eder. Bu iki metrik hem yedekleme hem de DR planlamasında referans alınır, ancak anlamları farklıdır. Sık yedekleme ve kısa retention ile RPO daraltılabilir; RTO ise yalnızca yedekleme hızına değil, geri yükleme sürecine, ağ kapasitesine ve failover mekanizmasına bağlıdır.
Örneğin saatlik yedekleme yapan bir ortamda teorik RPO bir saate yakın olabilir; ancak geri yükleme işlemi saatler sürebilir ve bu durumda fiili RTO hedefi karşılanmaz. DR planında replikasyon veya önceden hazırlanmış ikincil ortam, RTO hedeflerine ulaşmak için sıkça devreye girer. Hedefler proje ve hizmet kapsamına göre tanımlanır; sabit bir rakam her iş yükü için geçerli değildir.
Replikasyonun yeri
Replikasyon, yedeklemenin yerine geçmez; farklı bir rol üstlenir. Yedekleme geçmiş noktalara dönüş ve uzun süreli saklama sağlarken, replikasyon aktif veya pasif ikincil ortama güncel kopya taşıyarak geçiş senaryolarını destekler. İki mekanizma birlikte kullanıldığında yedekleme uzun süreli koruma ve noktasal geri dönüş için, replikasyon ise hızlı failover veya kontrollü geçiş için konumlandırılır.
Replikasyon topolojisi seçilirken ağ gecikmesi, bant genişliği, tutarlılık modeli ve failover test sıklığı birlikte değerlendirilmelidir. Senkron replikasyon daha düşük veri kaybı potansiyeli sunarken ağ ve mesafe kısıtlarına daha duyarlıdır; asenkron replikasyon daha esnek olabilir ancak RPO hesabına yansıtılması gerekir. Bu kararlar teknik değerlendirme sürecinde iş yükü profili ile eşleştirilir.
Bulut tabanlı yedekleme ve replikasyon hizmetleri, ikinci lokasyon ihtiyacını operasyonel olarak basitleştirebilir. Yedeklerin üretim ortamından coğrafi veya mantıksal olarak ayrılmış hedeflere taşınması, ortak başarısızlık noktası riskini azaltır. Hedef seçiminde veri egemenliği, ağ kapasitesi ve erişim modeli birlikte değerlendirilmelidir.
Kurtarma testleri neden ayrı bir katmandır?
Yedekleme job'larının başarılı tamamlanması, kurtarmanın gerçekten işleyeceği anlamına gelmez. Dosya bütünlüğü, uygulama tutarlılığı, bağımlılık sırası ve ağ yapılandırması geri yükleme anında sorun çıkarabilir. DR planları da masa başında yazıldığında eksik kalabilir; failover sırasında DNS, kimlik doğrulama veya lisans bağımlılıkları gecikmeye neden olabilir.
Düzenli kurtarma testleri, planın gerçek dünyada çalışıp çalışmadığını doğrular. Test kapsamı tüm ortamı kapsamak zorunda değildir; seçilmiş kritik iş yükleri için periyodik geri yükleme veya kontrollü failover yeterli bir başlangıç olabilir. Test sonuçları RPO/RTO hedeflerinin gerçekçi olup olmadığını gösterir ve plan güncellemelerine girdi sağlar.
Tablo halinde özetlemek gerekirse: yedekleme günlük operasyonel kurtarma ve uzun süreli saklama için; replikasyon hızlı geçiş senaryoları için; DR planı büyük ölçekli kesinti sonrası koordineli geri dönüş için tasarlanır. Üçü birbirinin yerine geçmez; doğru kombinasyon iş yükü kritikliğine göre belirlenir.
Pratik ayrım: ne zaman hangisi?
Günlük operasyonel ihtiyaçlar — yanlışlıkla silinen dosya, bozulmuş veritabanı, tek sunucu arızası — çoğunlukla yedekleme ile çözülür. Veri merkezi veya bölgesel kesinti, toplu sistem kaybı veya uzun süreli erişim kaybı ise DR planının devreye girmesini gerektirir. İş sürekliliği planı bu iki katmanı ve iletişim, karar süreçleri gibi operasyonel unsurları bir araya getirir.
Mevcut mimarinizi değerlendirirken şu soruları yanıtlamak faydalıdır: Kritik sistemler için kabul edilebilir veri kaybı ve kesinti süresi nedir? Yedekler üretimden ayrılmış ve yetkisiz değişiklikten korunmuş mu? Replikasyon veya ikincil ortam varsa failover test edildi mi? Bu başlıklar netleştiğinde yedekleme ile felaket kurtarma rolleri birbirini tamamlayan bir bütün olarak görünür hale gelir.
Yönetilen yedekleme ve DR operasyonları, bu katmanların günlük izlenmesi, politika güncellemeleri ve test koordinasyonunu üstlenebilir. Self-servis veya hibrit modellerde ise sorumluluk paylaşımı erken aşamada netleştirilmelidir. Hangi modelin uygun olduğu organizasyonun operasyon kapasitesi ve kritiklik profiline göre belirlenir.
Sonuç olarak yedekleme ve felaket kurtarma aynı hedefe hizmet eden farklı katmanlardır. Yedekleme veri koruma ve noktasal geri dönüşün temelidir; DR ise büyük ölçekli kesinti sonrası koordineli geri dönüşü planlar. İkisini birlikte tasarlamak, hem günlük operasyonel ihtiyaçları hem de geniş çaplı senaryoları kapsayan sürdürülebilir bir süreklilik modeli oluşturur. Belirsiz kalan noktalar için teknik değerlendirme süreci somut mimari öneriler sunar.