Yedeğiniz olduğu için rahatsanız, şu soruyu cevaplayın: son yedeğinizi en son ne zaman geri yüklemeyi denediniz? Bu soruya net bir tarih veremeyen işletmelerin elinde yedek değil, yedek olduğuna dair bir varsayım vardır.
Kısa cevap: Yedekleme ile felaket kurtarma arasındaki fark nedir?
Yedekleme verinin kopyasını almaktır; felaket kurtarma ise işin ne kadar sürede yeniden çalışır hale geleceğini planlamaktır. Yedekleme bir dosya sorusudur, felaket kurtarma bir süre sorusudur. Yedeğiniz olabilir ama onu geri yüklemek üç gün sürüyorsa, iş sürekliliğiniz açısından yedeğiniz yok sayılır. İkisi birbirinin alternatifi değildir: felaket kurtarma, yedeklemeyi de içeren daha geniş bir plandır.
RTO ve RPO: her şeyi belirleyen iki rakam
Bu iki kısaltma teknik jargon gibi görünür, ancak aslında tamamen iş kararıdır ve teknik ekibin değil yönetimin cevaplaması gerekir:
- RTO (Recovery Time Objective) — Kurtarma Süresi Hedefi: Sistem çöktükten sonra ne kadar süre kapalı kalmayı kabul edebilirsiniz? Bir saat mi, bir gün mü, üç gün mü?
- RPO (Recovery Point Objective) — Kurtarma Noktası Hedefi: Ne kadarlık veri kaybını kabul edebilirsiniz? Son bir saatin verisi mi, son bir günün mü?
Bu iki rakam belirlenmeden yapılan her yedekleme yatırımı tahmine dayanır. Örneğin günde bir kez alınan yedek, RPO'nuzun 24 saat olduğu anlamına gelir — yani en kötü senaryoda bir günlük siparişi, faturayı ve müşteri kaydını kaybedersiniz. Bu kabul edilebilir mi? Cevap işletmeden işletmeye değişir ve kararı veren taraf yönetim olmalıdır.
Yedekleme ve felaket kurtarma: karşılaştırma
| Kriter | Yedekleme | Felaket Kurtarma |
|---|---|---|
| Sorduğu soru | Veri kopyası var mı? | İş ne kadar sürede devam eder? |
| Kapsam | Dosyalar, veritabanı | Sistem, yapılandırma, ağ, süreç, insan |
| Ölçüsü | Yedek sıklığı ve saklama süresi | RTO ve RPO |
| Test yöntemi | Geri yükleme denemesi | Senaryo tatbikatı |
| Yetmediği durum | Geri yükleme çok uzun sürüyorsa | Yedek bozuksa (temeli yedeklemedir) |
| Tipik maliyet | Düşük-orta | Orta-yüksek (hedeflenen RTO'ya bağlı) |
Tablonun özeti şu: yedekleme felaket kurtarmanın ön koşuludur, yerine geçmez. Yedeği olmayan bir felaket kurtarma planı olamaz; ama yalnızca yedeği olan bir işletmenin de felaket kurtarma planı yoktur.
3-2-1 kuralı hâlâ geçerli mi?
Klasik 3-2-1 kuralı şunu söyler: verinin 3 kopyası olsun, 2 farklı ortamda saklansın, 1 kopyası fiziksel olarak ayrı bir yerde bulunsun.
Bu kural hâlâ sağlam bir temeldir, ancak fidye yazılımı çağında bir ekleme gerektirir: kopyalardan en az biri değiştirilemez veya erişilemez olmalıdır. Nedeni basittir — sunucuya sürekli bağlı duran bir yedek diski, saldırı anında yedek değil ikinci bir hedeftir. Saldırganlar şifrelemeden önce ulaşabildikleri yedekleri silerler.
Pratik karşılığı: yedeklerinizden biri, ana sisteminizin kimlik bilgileriyle erişilemeyen bir konumda durmalıdır.
Geri yükleme tatbikatı: yedeğin gerçekten çalıştığını nasıl bilirsiniz?
Yedekleme sistemlerinin en yaygın sorunu, arıza vermeden çalışıyor görünmeleridir. Panelde "yedek başarılı" yazması, o yedeğin geri yüklenebileceğini kanıtlamaz. Yedek bozuk olabilir, eksik tablo içerebilir, ya da geri yükleme için gereken bir bileşen yedeklenmemiş olabilir.
Tatbikat şu adımlarla yapılır:
- Ayrı bir ortam hazırlayın. Canlı sisteme dokunmadan, izole bir yere geri yükleyin.
- Süreyi ölçün. Başlangıçtan sistemin çalışır hale gelmesine kadar geçen süre, gerçek RTO'nuzdur — tahmininiz değil.
- Bütünlüğü doğrulayın. Sadece dosyaların varlığına değil; veritabanının açıldığına, son kayıtların yerinde olduğuna ve uygulamanın çalıştığına bakın.
- Eksikleri not edin. Genelde yapılandırma dosyaları, SSL sertifikaları, cron tanımları ve e-posta ayarları unutulur.
- Yılda en az iki kez tekrarlayın ve büyük bir sistem değişikliğinden sonra mutlaka yapın.
Hangi işletmeye ne gerekir?
Kesintiye toleransı yüksek işletmeler (tanıtım sitesi, düşük işlem hacmi): düzenli, ayrılmış ve test edilmiş bir yedekleme çoğu durumda yeterlidir. Buradaki asıl risk yedeğin olmaması değil, hiç test edilmemiş olmasıdır.
Sürekli işlem alan işletmeler (e-ticaret, rezervasyon, müşteri paneli): RPO'nun saatlerle ölçülmesi gerekir. Günlük tek yedek burada kabul edilemez veri kaybı anlamına gelir. Ek olarak geri yükleme süresi de planlanmalıdır.
Kesintinin doğrudan yasal/mali sonucu olan işletmeler: yalnızca yedekleme değil, yazılı bir felaket kurtarma planı ve düzenli tatbikat gerekir. Burada plan, teknik bir doküman değil operasyonel bir prosedürdür: kim ne zaman ne yapacak, kime haber verilecek, müşteriye ne söylenecek.
Netişlem uzman görüşü: en sık gördüğümüz üç eksik
Kurtarma çalışmalarında karşımıza çıkan tablo neredeyse hep aynı üç eksikten oluşuyor.
Birincisi, yedeğin sunucuyla aynı yerde durması. Sunucu kaynaklı bir sorunda (donanım, saldırı, yanlış silme) yedek de aynı olaydan etkileniyor. Yedeğin değeri, ana sistemden ne kadar bağımsız olduğu kadardır.
İkincisi, yedeğin kapsamının eksik olması. Veritabanı yedekleniyor ama yüklenen dosyalar yedeklenmiyor; ya da uygulama yedekleniyor ama sunucu yapılandırması yedeklenmiyor. Geri yükleme anında bu eksikler saatler kaybettiriyor.
Üçüncüsü, sürenin hiç ölçülmemiş olması. "Yedeğimiz var" diyen işletmelerin çoğu, geri yüklemenin ne kadar süreceğini bilmiyor. Kriz anında bu bilinmezlik, teknik sorundan daha fazla zarar veriyor — çünkü ne müşteriye ne ekibe bir süre verilebiliyor.
Bu yüzden önerimiz her zaman aynı sırayla: önce yedeği ayırın, sonra kapsamını tamamlayın, sonra bir kez geri yükleyip süreyi ölçün. Üçü tamamlandığında elinizde gerçek bir güvence olur.
Sık sorulan sorular
Hosting sağlayıcım yedek alıyor, bu yeterli değil mi?
Sağlayıcı yedeği önemli bir katmandır ancak tek başına yeterli sayılmamalıdır. Kapsamının, saklama süresinin ve geri yükleme prosedürünün ne olduğu sözleşmede yazılı olmalıdır. Ayrıca kendi kontrolünüzde en az bir kopya bulundurmak, sağlayıcı kaynaklı bir sorunda tek çıkış yolunuz olabilir.
Bulut depolamaya senkronizasyon yedekleme sayılır mı?
Hayır. Senkronizasyon, değişikliği aynen kopyalar — bir dosya silinir veya şifrelenirse bulut kopyası da o hâliyle güncellenir. Yedekleme ise geçmişe dönebilme yeteneğidir. Sürüm geçmişi olmayan bir senkronizasyon, yedek yerine geçmez.
Ne sıklıkta yedek almalıyım?
Bu, kabul edebileceğiniz veri kaybına (RPO) bağlıdır. Günde bir yedek, en kötü senaryoda bir günlük kayıp demektir. Sipariş veya işlem alan sistemlerde daha sık aralık gerekir. Doğru soru "ne sıklıkta" değil, "ne kadar kaybı göze alabilirim" sorusudur.
Yedekleri ne kadar süre saklamalıyım?
Yalnızca son yedeği tutmak risklidir: bir bozulma veya saldırı fark edilmeden birkaç gün sürebilir ve tek yedeğiniz bozuk hâli içerebilir. Yaygın yaklaşım kademeli saklamadır — son birkaç günlük, birkaç haftalık ve birkaç aylık kopyaların birlikte tutulması. Yasal saklama yükümlülükleriniz varsa onlar da bu planı etkiler.
Felaket kurtarma planı yazmak pahalı mı?
Planın kendisi bir doküman olduğu için maliyeti düşüktür; maliyeti belirleyen, hedeflediğiniz kurtarma süresidir. Birkaç saatlik RTO ile birkaç günlük RTO çok farklı altyapılar gerektirir. Bu yüzden önce hedefi belirlemek, sonra maliyeti konuşmak doğru sıradır.
Sonuç
Yedekleme "verim duruyor mu?" sorusunun, felaket kurtarma ise "işim ne kadar sürede devam eder?" sorusunun cevabıdır. İkinci soruyu hiç sormamış bir işletmenin, ilk sorunun cevabı olumlu olsa bile hazırlıklı olduğu söylenemez.
Mevcut yedekleme kurgunuzu birlikte gözden geçirmemizi ve bir geri yükleme tatbikatı yapmamızı isterseniz bize ulaşın. Kurumsal yedekleme, güvenli barındırma ve SLA taahhüdümüzü inceleyebilirsiniz.