Yedekleme7 dakika

RPO ve RTO ile Yedekleme ve Felaket Kurtarma Planı

Yedekleme planı, hangi yazılımın kullanıldığından önce iki iş sorusunu yanıtlamalıdır: Ne kadar veri kaybı kabul edilebilir ve sistemler ne kadar sürede yeniden çalışmalıdır? RPO ve RTO bu beklentileri teknik ekiple işletme yönetimi arasında ortak bir dile çevirir.

Hazırlayan: ESPO Bilişim Teknik Ekibi

Kısa özet

  • RPO kabul edilebilir veri kaybı penceresini, RTO ise hizmetin geri dönme hedefini tanımlar.
  • Her sistem aynı kritik seviyede değildir; hedefleri iş etkisine göre sınıflandırın.
  • Yedekleme başarısını düzenli geri dönüş testleriyle doğrulayın.
  • Kimlik bilgileri, dokümantasyon ve iletişim planı olmadan teknik yedek tek başına kurtarma planı değildir.

RPO nedir?

Recovery Point Objective (RPO), bir kesinti sonrasında en fazla ne kadar geriye dönülebileceğini ifade eder. Örneğin iş emri verisi için 30 dakikalık RPO belirlenmişse yedekleme veya çoğaltma tasarımı en fazla 30 dakikalık veri kaybını hedeflemelidir.

RPO doğrudan yedekleme sıklığı değildir. Uygulama tutarlılığı, veri tabanı günlükleri, bağlantı kapasitesi ve yedeğin hedefe gerçekten ulaşması da bu hedefi etkiler.

RTO nedir?

Recovery Time Objective (RTO), bir servis kesildikten sonra kabul edilen geri dönüş süresidir. Donanım tedariki, veri indirme süresi, sanal makine açılışı, ağ ve kimlik yapılandırması ile doğrulama adımları bu süreye dâhildir.

Çok kısa RTO daha yedekli mimari, otomasyon ve düzenli test gerektirebilir. Bu nedenle hedef, iş kaybı ile çözüm maliyeti birlikte değerlendirilerek belirlenmelidir.

Sistemleri iş etkisine göre sınıflandırın

Sınıflandırmayı sunucu adına göre değil iş sürecine göre yapın. Aynı sunucudaki iki uygulamanın kayıp ve kesinti toleransı farklı olabilir.

  • Kritik: üretimi, sevkiyatı veya temel müşteri hizmetini durduran sistemler
  • Yüksek: kısa süreli kesintisi tolere edilebilen fakat gün içinde dönmesi gereken sistemler
  • Normal: geçici alternatif süreçle sürdürülebilen uygulamalar
  • Arşiv: günlük operasyonu durdurmayan, yasal veya geçmiş kayıt niteliğindeki veriler

3-2-1 yaklaşımını test edilebilir hâle getirin

Yaygın 3-2-1 yaklaşımı; verinin en az üç kopyasını, iki farklı ortam türünde ve bir kopyası tesis dışında olacak şekilde düşünmeyi önerir. Ransomware riskinde çevrimdışı veya değiştirilemez bir kopya, üretim sistemindeki yetkilerin yedeklere sıçramasını zorlaştırır.

  • Yedek hedefi için ayrı yetki ve MFA
  • Silme/değiştirme koruması olan kopya
  • Kritik sistemler için uygulama tutarlı yedek
  • Başarısız iş, kapasite ve saklama süresi uyarıları

Geri dönüş testi nasıl planlanır?

Test kaydında kaynak yedek, başlangıç-bitiş zamanı, kullanılan adımlar, hata ve düzeltmeler ile iş birimi onayı bulunmalıdır. Gerçek sonuçlar hedeflerle karşılaştırılmadıkça RPO/RTO yalnız temenni olarak kalır.

  • Aylık: seçilen dosya veya posta kutusu öğesi geri dönüşü
  • Üç aylık: kritik uygulama veya sanal makinenin izole ortamda açılması
  • Yıllık: iş birimleriyle masa başı felaket senaryosu ve iletişim provası
  • Her önemli değişiklik sonrası: yeni sistemin yedek ve kurtarma kapsamının doğrulanması

Başvurulan kaynaklar

Bu rehber genel bilgilendirme amacıyla hazırlanmıştır. Uygulama kapsamı işletmenin riskleri ve altyapısına göre belirlenmelidir.