RPO ve RTO’ya Göre Yedekleme ve İş Sürekliliği Tasarımı
RPO ve RTO nedir, neden önce bunlar belirlenir?
RPO (Recovery Point Objective) kabul edilebilir veri kaybı süresidir: bir arıza anında en fazla kaç dakikalık veriyi kaybedebilirsiniz? RTO (Recovery Time Objective) kabul edilebilir kesinti süresidir: sistem en geç ne kadar sürede ayakta olmalı? Altyapı yatırımının boyutu bu iki sayıdan çıkar. İki sayı belirlenmeden alınan yedekleme ürünü, ihtiyaçtan ya pahalı ya da yetersiz olur.
Sistem başına farklı hedef koyun
Tek bir RPO/RTO tüm sistemler için uygulanırsa maliyet gereksiz büyür. Sistemleri işe etkisine göre ayırın:
- Satışı durduran sistemler (POS, ödeme, sipariş alma): düşük RPO, düşük RTO.
- Operasyonu yavaşlatan sistemler (ERP raporlama, CRM): orta seviye hedefler.
- Ertelenebilir sistemler (arşiv, iç portal): yüksek RPO/RTO kabul edilebilir.
Bu ayrım, replikasyon gibi pahalı çözümleri yalnızca gerçekten gereken yerde kullanmanızı sağlar.
Snapshot yedek değildir
Sanallaştırma anlık görüntüsü (snapshot), aynı depolama üzerinde tutulan bir zaman noktası kaydıdır. Depolama biriminin kendisi arızalandığında veya bir şifreleme saldırısı disk üzerindeki tüm verilere eriştiğinde snapshot da kaybolur. Bu nedenle snapshot hızlı geri alma için kullanılır; yedekleme yerine geçmez.
Kullanışlı temel kural 3-2-1'dir: verinin üç kopyası, iki farklı ortam, bir kopya tesis dışında. Fidye yazılımı riski nedeniyle bu kurala bir madde daha eklenir: en az bir kopya değiştirilemez (immutable) veya çevrimdışı olmalıdır.
Test edilmemiş yedek, yedek sayılmaz
Yedekleme sisteminin "başarılı" raporu, verinin geri dönebildiğini kanıtlamaz. Düzenli olarak şu üç testi yapın ve sonucu tarihiyle kaydedin:
- Dosya seviyesi geri dönüş: rastgele seçilen bir dosya geri getirilebiliyor mu?
- Uygulama seviyesi geri dönüş: veritabanı ayrı bir ortama geri yüklenip açılabiliyor mu?
- Senaryo tatbikatı: ana sistem tamamen kapatıldığında hizmet hedeflenen RTO içinde ayağa kalkıyor mu?
Üçüncü testin süresi ölçülüp yazılmadıkça RTO bir varsayımdır.
Yetki ve kayıt tarafını atlamayın
Süreklilik yalnızca donanım meselesi değildir; şube bağlantısının yedekliliği için [kurumsal ağ rehberine](/blog/network-rehberi) de bakın. Yedeklere kimin erişebildiği, yedeklerin silinmesi için kaç kişinin onayı gerektiği ve yönetici işlemlerinin kayıt altına alınıp alınmadığı da plana dâhildir. Kişisel veri içeren yedeklerde saklama süresi ve imha yöntemi de tanımlanmalıdır; bu, veri koruma mevzuatının doğrudan kapsamındadır.
Sık sorulan sorular
Bulut kullanıyorsak yedek almamıza gerek var mı?
Vardır. Bulut sağlayıcıları altyapının sürekliliğini üstlenir; sizin verinizin yanlışlıkla silinmesi, hatalı bir toplu güncelleme veya hesap ele geçirilmesi genellikle sağlayıcının sorumluluğunda değildir. Sorumluluk paylaşımı modelini sözleşmede doğrulayın.
Yedekler ne kadar süre saklanmalı?
Süre yasal saklama yükümlülüğü, olası uyuşmazlık süresi ve kişisel veri saklama sınırının kesişiminden çıkar. Tek bir doğru süre yoktur; her veri türü için ayrı yazılması gerekir.
Fidye yazılımına karşı en etkili tek önlem nedir?
Değiştirilemez veya çevrimdışı tutulan bir yedek kopyasıdır. Saldırganların ilk hedefi çevrim içi yedeklerdir; erişilemeyen kopya, geri dönüş şansını korur.