Yedekleme ile felaket kurtarma arasındaki fark ne?
Yedekleme verinin kopyasını saklamak, felaket kurtarma ise kesinti sonrası tüm hizmeti ikincil ortamda ayağa kaldırmaktır. Yedekleme "veriyi geri getirir" sorusuna, felaket kurtarma "operasyonu ne kadar sürede sürdürürüz" sorusuna cevap verir. İkisi aynı disiplinin iki katmanıdır: biri veri güvencesini, diğeri iş sürekliliğini sağlar.
Bu ayrım pratikte önemlidir, çünkü yalnızca yedeği olan bir kurum veriyi geri getirebilir ama hizmeti hızlı ayağa kaldıramayabilir. Kurgu, iki katmanı birlikte tasarladığında bütünlenir.
RPO ve RTO hedefleri neden başta belirlenir?
RPO ve RTO, tüm yedekleme ve kurtarma mimarisinin çıkış noktasıdır. Bu iki hedef netleşmeden teknoloji seçilmez:
- RPO (Recovery Point Objective · kurtarma noktası hedefi): Kabul edilebilir veri kaybı penceresidir. "En fazla ne kadarlık veriyi kaybedebiliriz?" sorusunun cevabı, yedekleme sıklığını belirler.
- RTO (Recovery Time Objective · kurtarma süresi hedefi): Hizmetin ne kadar sürede geri gelmesi gerektiğidir. "Ne kadar süre çevrimdışı kalabiliriz?" sorusunun cevabı, kurtarma yönteminin ve altyapının sınıfını belirler.
Bu hedefler sistemin kritikliğine göre değişir; kritik bir veritabanı ile arşiv sunucusu aynı hedefe sahip olmaz. Doğru kurgu, her sistemi kendi RPO ve RTO sınıfına yerleştirir. Bu iki hedefin nasıl belirlendiğini ilgili notta ayrıca ele alıyoruz.
Katmanlı bir yedekleme mimarisi neye benzer?
Sağlam bir mimari, birbirini tamamlayan katmanlara dayanır. Temel taşı 3-2-1 ilkesidir: verinin üç kopyası, iki farklı ortam türünde, en az bir kopya saha dışında. Bu düzenin üzerine kritiklik arttıkça ek katmanlar gelir:
| Katman | Ne sağlar | Tipik kullanım |
|---|---|---|
| Yerel yedek | Hızlı geri yükleme | Günlük dosya ve sistem geri dönüşü |
| Saha dışı kopya | Lokasyon kaynaklı kayba karşı güvence | Yangın, sel, hırsızlık senaryoları |
| Değiştirilemez kopya | Fidye yazılımına karşı koruma | Yazma korumalı, ayrıştırılmış erişim |
| İkincil saha replikasyonu | Düşük RTO ile hizmet devri | Kritik sistemler, kısa kesinti toleransı |
Devreye aldığımız her yedekleme kurgusuna baştan bir geri yükleme takvimi koyuyoruz. Sahada gördüğümüz en kritik ayrım şu: yedeğin başarıyla alınması, geri yüklenebileceğini kanıtlamaz. Düzenli örnek geri yükleme ve felaket kurtarma tatbikatı yapılmayan bir kurgu, ilk gerçek olayda sürprizle karşılaşır. Test edilen kurgu ise olay anında öngörülebilir davranır.
Felaket kurtarma nereye kadar götürülür?
Felaket kurtarmanın olgunluğu, RTO hedefiyle orantılı büyür. En temel seviyede yedekten yeni bir ortama geri yükleme yapılır; bu, veriyi getirir ama zaman ister. Kritiklik arttıkça ikincil sahaya sürekli replikasyon devreye girer ve hizmet, birincil saha düştüğünde ikincil sahada kısa sürede ayağa kalkar. Bulut tabanlı felaket kurtarma (DRaaS · Disaster Recovery as a Service), ikincil saha yatırımını hizmet modeline çevirerek bu güvenceyi erişilebilir kılar.
Hangi seviyenin doğru olduğu, sistemin RTO sınıfına ve bütçeye göre belirlenir. Bu kararlar, daha geniş veri merkezi ve sistem mimarisiyle birlikte tutarlı biçimde kurgulanır.
Kurgu nasıl sürdürülebilir kalır?
Yedekleme, bir kez kurulup unutulan sistem olmaktan çıktığında değer üretir. Ortam büyüdükçe yeni sistemler yedekleme kapsamına alınır, eskiyen politikalar gözden geçirilir ve geri yükleme testleri takvime bağlanır. İzleme, başarısız işleri anında yakalar; böylece bir sonraki gerçek olaydan önce sorun görünür olur.
Bu süreklilik, yönetilen hizmet kapsamında en verimli yürür: yedekleme işleri izlenir, testler düzenli yapılır ve durum düzenli raporlanır. Böylece güvence, zamanla eskimeyen bir disipline dönüşür.
