RPO ve RTO Nedir? Yedekleme ve Felaket Kurtarma Rehberi

RPO veri kaybı penceresini, RTO hizmetin geri dönüş süresini belirler

Bir olay saat 15.00'te gerçekleştiğinde son doğrulanmış kopya saat 14.30'a aitse geri dönüş noktası ile olay arasında otuz dakikalık veri penceresi vardır. İşletme otuz dakikalık işlemi yeniden oluşturabiliyorsa bu sonuç hedefle uyumlu olabilir; sipariş, üretim veya sağlık kaydı gibi kritik veriler için kabul edilemez de olabilir. RPO tam olarak bu toleransı iş diliyle belirler. Hedefin beş dakika olması, sadece her beş dakikada dosya kopyalamak demek değildir. Veritabanı transaction logu, uygulama tutarlılığı, aktarım gecikmesi, çoğaltma kuyruğu ve kopyanın korunması birlikte değerlendirilir. Asenkron replikasyonda gecikme sıfır değildir; mantıksal bozulma veya fidye yazılımı da hızlı biçimde hedefe taşınabilir. Bu nedenle kısa RPO için sürümleme, değiştirilemez kopya ve zaman içinde geri dönüş noktaları birlikte planlanır.

RTO'nun başlangıcı olayın ne zaman fark edildiğiyle karıştırılmamalıdır. İşletme açısından kesinti, hizmet kullanılamaz olduğunda başlar; algılama, bildirim, karar, erişim, geri yükleme, uygulama kontrolü ve kullanıcı kabulü toplam süreye dahildir. Bir sanal makinenin on dakikada açılması, bağlı veritabanı, DNS, sertifika, kimlik ve ağ politikası çalışmıyorsa hizmetin geri döndüğü anlamına gelmez. Hedeflenen işlev düzeyi ayrıca tanımlanmalıdır: yalnız kritik sipariş işlemi mi, tüm raporlama mı, yoksa normal kapasitenin tamamı mı? RTO teknik restore süresinden daha geniştir. Gerçek hedef, saat tutulmuş masaüstü tatbikatı ve kontrollü geri dönüş testiyle ölçülür. Olay algılama süresi için RTA veya MTTD gibi ek göstergeler kullanılabilir; ancak bunlar RPO ve RTO'nun yerine geçmez.

RPO başlangıcı

Son doğrulanmış ve tutarlı kopya ile olay anı arasındaki kabul edilebilir veri penceresi iş sahibi tarafından belirlenir.

RTO başlangıcı

Kesinti anından hedeflenen işlev düzeyinin kullanıcı tarafından doğrulanmasına kadar geçen uçtan uca süre esas alınır.

İşlev düzeyi

Minimum hizmet, kritik işlem, tam kapasite ve ertelenebilir raporlama gibi geri dönüş kapsamları açıkça ayrılır.

Tutarlılık

Veritabanı, dosya, uygulama ve bağımlı servislerin aynı geri dönüş noktasında tutarlı olup olmadığı kontrol edilir.

Kanıt

Yedek görevi kaydı değil, zaman damgalı restore testi, veri kontrolü ve iş sahibi kabulü hedefin kanıtını oluşturur.

Hedefler uygulama bazında iş etkisi ve bağımlılık analiziyle sınıflandırılmalıdır

RPO ve RTO değerleri teknik ekibin tek başına seçtiği ürün ayarı değildir. Finansal kayıp, yasal yükümlülük, güvenlik, üretim duruşu, müşteri deneyimi ve manuel çalışma olanağı iş birimleriyle değerlendirilir. Her hizmet için sahip, kullanıcı grubu, kritik dönem, veri değişim hızı, maksimum tolere edilebilir kesinti ve manuel telafi kapasitesi yazılır. Örneğin aylık arşiv raporu için 24 saatlik RPO kabul edilebilirken aktif sipariş veritabanı için dakikalar gerekebilir. Bordro uygulaması ayın çoğunda daha düşük, ödeme döneminde daha yüksek kritiklik taşıyabilir. Değerler yuvarlak ve iddialı sayılarla değil, iş etkisi ve bütçe karşılığıyla seçilir. Sıfır veri kaybı ve sıfır kesinti çoğu sistemde çok maliyetli, hatta bazı olay türlerinde teknik olarak gerçekçi olmayan bir hedeftir.

Bağımlılık haritası hedeflerin uygulanabilirliğini belirler. Bir ERP sunucusu; veritabanı, Active Directory, DNS, firewall, storage, lisans sunucusu, entegrasyon API'si ve istemci ağına bağlı olabilir. ERP için bir saatlik RTO yazıp kimlik altyapısı için sekiz saat belirlemek çelişki üretir. Uygulamalar hizmet zinciri halinde sınıflandırılır ve geri dönüş sırası oluşturulur. Tier 1 sistemler için kısa hedefler, ayrılmış kaynak ve sık test; Tier 2 için daha dengeli kopya ve manuel adım; arşiv sınıfı için daha uzun hedef ve düşük maliyetli depolama kullanılabilir. Her tier'ın kabul ölçütü, sorumlusu, iletişim yöntemi ve bakım penceresi aynı katalogda tutulur. Yeni uygulama devreye alındığında veya süreç değiştiğinde iş etki analizi güncellenir.

• Uygulama sahibini, kullanıcıyı, kritik dönemi, veri değişim hızını ve manuel çalışma olanağını her hizmet için kaydedin.
• Finansal, operasyonel, yasal, güvenlik ve itibar etkisini kesinti süresi arttıkça ayrı ayrı değerlendirin.
• Active Directory, DNS, ağ, storage, lisans, entegrasyon ve dış sağlayıcı bağımlılıklarını hizmet zincirinde gösterin.
• Tier sınıflarını tekniğe değil iş etkisine bağlayın; her sınıf için RPO, RTO, test sıklığı ve bütçe sınırı tanımlayın.
• Hedefleri yılda en az bir kez ve önemli uygulama, lokasyon veya süreç değişikliklerinden sonra yeniden onaylayın.

Yedekleme, replikasyon, yüksek erişilebilirlik ve felaket kurtarma farklı riskleri karşılar

Yedekleme, belirli zaman noktalarındaki veriyi saklama ve geçmişe dönme yeteneği sağlar. Replikasyon, veriyi veya sistemi ikinci hedefe düşük gecikmeyle kopyalayarak RPO'yu kısaltabilir; fakat hatalı silme, bozulma ve kötü amaçlı şifreleme de çoğaltılabilir. Snapshot hızlı geri alma noktasıdır, çoğu durumda aynı yönetim veya storage hata alanındadır. Yüksek erişilebilirlik, node ya da servis arızasında iş yükünü başka kaynakta yeniden başlatabilir; bina, kimlik, ortak storage veya ağ gibi daha geniş felaketlere tek başına çözüm değildir. Felaket kurtarma ise ikincil ortam, insan, süreç, iletişim, runbook ve iş kabulünü bir araya getirir. Sağlam tasarım bu bileşenleri birbirinin yerine saymaz; hangi olay türünü hangi katmanın karşıladığını risk matrisiyle gösterir.

Mimari hedefe göre seçilir. Saatler mertebesindeki RPO için günlük artımlı yedek ve ayrık kopya yeterli olabilir. Dakikalık RPO, transaction log aktarımı veya sürekli replikasyon isteyebilir. Kısa RTO için boş donanım sipariş etmeyi beklemek yerine önceden ayrılmış compute, network ve erişim kapasitesi gerekir. Cloud kurtarma seçeneğinde veri aktarım süresi, egress, bölge bağımlılığı, kimlik, kota ve altyapı kodu kontrol edilir. İkincil veri merkezi aynı enerji, operatör veya coğrafi risk alanındaysa bağımsızlık sınırlıdır. Yedekler değiştirilemezlik, ayrı hesap, çok faktörlü kimlik, şifreleme ve offline veya air-gap yaklaşımıyla korunur. Kapasite hesabına normal veri büyümesi kadar olay sırasında yeniden senkronizasyon ve geri dönüş trafiği de eklenir.

Yedek

Saklama, uygulama tutarlılığı, değiştirilemezlik, ayrı kimlik ve doğrulanmış geri yükleme ile geçmiş noktaya dönüş sağlar.

Replikasyon

Düşük veri kaybı hedefini destekler; gecikme, bozulmanın çoğaltılması ve hedef tarafın bağımsızlığı ölçülür.

Yüksek erişilebilirlik

Yerel bileşen arızasında yeniden başlatma veya failover sağlar; ortak hata noktaları ve gerçek kesinti süresi test edilir.

Felaket kurtarma

İkincil ortam, erişim, insan, iletişim, runbook, bağımlılık sırası ve iş kabulünü uçtan uca kapsar.

Geri dönüş

Felaket ortamından normal ortama dönüş, veri uzlaştırma ve kesinti penceresi önceden planlanır; yalnız failover düşünülmez.

RPO ve RTO ancak kontrollü geri dönüş testleri ve güncel runbook ile doğrulanır

Test programı yalnız yedek dosyasının açılmasıyla sınırlı değildir. Dosya seviyesi geri yükleme, veritabanı geri dönüşü, sanal makine kurtarma, uygulama zinciri ve tam lokasyon senaryoları ayrı kapsamda yapılır. Üretimi riske atmamak için izole ağ, maskelenmiş veri ve kontrollü test hesabı kullanılabilir. Her testte olay saati, karar saati, kopya seçimi, restore başlangıcı, servis açılışı, veri kontrolü ve kullanıcı kabulü zaman damgasıyla kaydedilir. Elde edilen gerçek veri kaybı ve geri dönüş süresi hedefle karşılaştırılır. Hedef aşılırsa yalnız daha hızlı donanım önerilmez; onay gecikmesi, erişim eksikliği, doküman hatası, bağımlılık sırası ve veri bütünlüğü gibi nedenler kök sebep analiziyle ayrılır. Test bulgusu için sorumlu ve kapanış tarihi atanır.

Runbook, olay sırasında ilk kez okunacak teorik belge olmamalıdır. İletişim listesi, karar yetkisi, erişim yöntemi, yedek konumu, bağımlılık sırası, komutlar, doğrulama sorguları, alternatif yol ve geri dönüş adımlarını içerir. Parola veya anahtar doğrudan belgeye yazılmak yerine güvenli kasaya referans verilir ve acil erişim düzenli test edilir. Tedarikçi SLA'sı kurumun RTO'suyla karıştırılmaz; sağlayıcının yanıt verme süresi, ortamı geri getirme süresinin yalnız bir parçasıdır. Aylık yedek sağlık raporu, üç aylık örnek restore ve yıllık kapsamlı felaket tatbikatı kritiklik seviyesine göre uyarlanabilir. Sonuçlar yönetime teknik jargon yerine hedef, gerçekleşen süre, veri kaybı, risk ve aksiyon halinde raporlanır.

• Dosya, veritabanı, VM, uygulama zinciri ve lokasyon kurtarma senaryolarını kritiklik seviyesine göre ayrı takvimde test edin.
• Olaydan kullanıcı kabulüne kadar tüm zaman damgalarını kaydedin; ölçülen veri noktası ve geri dönüş süresini hedefle karşılaştırın.
• Runbook içindeki erişim, iletişim, komut, bağımlılık, doğrulama ve geri dönüş adımlarını her testten sonra güncelleyin.
• Tedarikçi SLA'sı, donanım temini ve insan karar süresini kurumun uçtan uca RTO hesabına gerçekçi biçimde ekleyin.
• Bulguları sorumlu ve kapanış tarihiyle izleyin; hedef sağlanmıyorsa iş sahibiyle maliyet, risk veya hedef revizyonunu karara bağlayın.