"Yedeklerimiz var" cümlesi çoğu zaman güven verir; ta ki bir sunucu çöktüğünde geri yüklemenin iki gün süreceği anlaşılana kadar. Yedekleme ile felaket kurtarma aynı şey değildir ve ikisini ayırt etmenin en iyi yolu iki basit ölçüdür: RPO ve RTO.
İki temel kavram
RPO — Kurtarma Noktası Hedefi
Recovery Point Objective: En fazla ne kadarlık veri kaybını kabul edebilirsiniz? Günde bir kez gece yedek alıyorsanız, öğleden sonra yaşanan bir arızada o günün tüm verisini kaybedebilirsiniz; RPO'nuz fiilen 24 saattir.
RTO — Kurtarma Süresi Hedefi
Recovery Time Objective: Sistem en fazla ne kadar süre kapalı kalabilir? Bu süre; arızanın fark edilmesini, karar verilmesini, donanım veya ortamın hazırlanmasını, geri yüklemeyi ve doğrulamayı kapsar.
| RPO | RTO | |
|---|---|---|
| Sorduğu soru | Ne kadar veri kaybedebiliriz? | Ne kadar süre çalışamayabiliriz? |
| Belirleyen | Yedekleme veya replikasyon sıklığı | Kurtarma yöntemi ve altyapısı |
| İyileştirme yolu | Daha sık yedek, sürekli replikasyon | Hazır bekleyen ortam, otomasyon, test |
Yedekleme ve felaket kurtarma arasındaki fark
Yedekleme, verinin bir kopyasını tutmaktır. Silinen bir dosyayı, bozulan bir veritabanını veya fidye yazılımından etkilenen bir sunucuyu geri getirmenizi sağlar.
Felaket kurtarma (DR) ise tüm bir sistemin veya lokasyonun kullanılamaz hale gelmesi durumunda, işin belirlenen sürede başka bir yerde devam etmesini sağlayan plan, altyapı ve süreçlerin bütünüdür. Yangın, sel, uzun süreli elektrik kesintisi veya tüm sunucuların şifrelendiği bir fidye yazılımı saldırısı bu senaryolara örnektir.
Kısacası: yedekleme olmadan felaket kurtarma olmaz; ama yalnızca yedeklemeyle de felaket kurtarma yapılmış olmaz.
Her sistem aynı öneme sahip değil
Tüm sistemler için "sıfır veri kaybı, sıfır kesinti" istemek hem teknik olarak zor hem de çok pahalıdır. Doğru yaklaşım, sistemleri iş üzerindeki etkisine göre sınıflandırmaktır. Buna iş etki analizi denir ve ISO 22301 iş sürekliliği standardının da temel adımlarından biridir.
Her sistem için şu soruları iş birimleriyle birlikte cevaplayın:
- Bu sistem 1 saat, 1 gün, 1 hafta kapalı kalırsa ne olur? Satış mı durur, üretim mi, yalnızca raporlama mı gecikir?
- Son 1 saatin, son 1 günün verisi kaybolursa yeniden oluşturulabilir mi?
- Yasal veya sözleşmesel bir yükümlülük var mı?
Örnek sınıflandırma
| Kademe | Örnek sistemler | Tipik RPO | Tipik RTO |
|---|---|---|---|
| Kritik | ERP, e-ticaret, üretim planlama | Dakikalar | 1–4 saat |
| Önemli | E-posta, dosya sunucusu, CRM | Birkaç saat | 4–24 saat |
| Standart | Arşiv, test ortamları, raporlama | 24 saat | Birkaç gün |
Bu değerler örnektir; sizin hedefleriniz iş etki analizinin sonucuna göre belirlenmelidir.
Hedefe göre teknik yaklaşım
- Günlük yedekleme: RPO yaklaşık 24 saat. Standart sistemler için genellikle yeterli.
- Sık artımlı yedekleme ve anlık görüntüler: RPO birkaç saate veya daha azına iner.
- Replikasyon: Sanal makinelerin ikinci bir lokasyona veya buluta sürekli ya da sık aralıklarla kopyalanması. RPO dakikalara, RTO ise hazır bekleyen kopya sayesinde saatlere hatta dakikalara iner.
- Buluta felaket kurtarma (DRaaS): İkinci bir veri merkezi kurmadan, felaket anında sistemlerin bulutta ayağa kaldırılması.
- Anında geri yükleme (instant recovery): Bazı yedekleme yazılımları sanal makineyi doğrudan yedek deposundan çalıştırabilir; tam geri yükleme arka planda devam ederken RTO kısalır.
Fidye yazılımını hesaba katın
Klasik felaket senaryoları altyapının fiziksel olarak kaybını varsayar. Fidye yazılımında ise altyapı yerindedir ama güvenilmezdir; saldırgan yedekleri de hedef alır. Bu nedenle:
- Yedeklerin en az bir kopyası değiştirilemez (immutable) veya çevrimdışı olmalı.
- Replikasyon tek başına yeterli değildir: şifrelenen veri de hedefe kopyalanır. Geriye dönük birden fazla kurtarma noktası tutulmalıdır.
- Kurtarma planı, "hangi yedeğin temiz olduğunu nasıl anlarız?" sorusuna cevap vermelidir.
Test edilmemiş plan, plan değildir
RTO ve RPO kâğıt üzerinde değil, testte ölçülür. Yılda en az bir kez kritik sistemler için tam geri yükleme testi yapın ve gerçekte ne kadar sürdüğünü kaydedin. Hedefe ulaşılamıyorsa ya teknik yaklaşımı güçlendirin ya da hedefi iş birimleriyle yeniden konuşun. Testte ortaya çıkan eksikler (unutulan bir parola, belgelenmemiş bir bağımlılık, yetersiz bant genişliği) gerçek bir felakette çok daha pahalıya mal olur.
Kısa kontrol listesi
- Kritik sistemler ve iş etkileri belirlendi
- Her sistem için RPO ve RTO hedefleri iş birimleriyle birlikte kararlaştırıldı
- Yedekleme sıklığı ve yöntemi RPO hedefleriyle uyumlu
- Kurtarma altyapısı RTO hedeflerini karşılayabiliyor
- En az bir yedek kopyası değiştirilemez veya çevrimdışı
- Felaket kurtarma planı yazılı ve güncel
- Geri yükleme testi son 12 ay içinde yapıldı ve sonuçları kaydedildi