RTO ve RPO Nedir? Farkları, Nasıl Belirlenir ve Hangi Teknolojiyle Sağlanır

RTO ve RPO, bir kesinti sonrasında sistemlerin ne kadar sürede geri gelmesi ve en fazla ne kadar verinin kaybedilebileceği sorularına verilen ölçülebilir cevaplardır. RTO (Recovery Time Objective) kurtarma süresi hedefini, RPO (Recovery Point Objective) ise geri dönülecek veri noktasını tanımlar. Bu iki değer belirlenmeden yapılan bir yedekleme ya da felaket kurtarma yatırımı, ihtiyaçtan ya fazla ya da eksik kalır.

Bu rehber RTO nedir, RPO nedir sorularını örneklerle açıklar; iki hedefin işletme için nasıl belirlendiğini, hangi teknolojiyle karşılandığını ve maliyetle nasıl dengelendiğini anlatır.

RTO nedir?

RTO, bir sistemin kesinti sonrasında kurtarma aşamasında kalabileceği en uzun süredir; bu süre aşılırsa işletmenin faaliyetleri ciddi biçimde etkilenir. ABD Ulusal Standartlar ve Teknoloji Enstitüsü de RTO’yu, bir bilgi sisteminin bileşenlerinin kurum faaliyetlerini olumsuz etkilemeden kurtarma aşamasında kalabileceği toplam süre olarak tanımlar (NIST Glossary).

Örneğin bir e-ticaret sitesinin sipariş sistemi için RTO 1 saat olarak belirlenmişse, sunucu arızası anında sistemin en geç 1 saat içinde yeniden hizmet vermesi gerekir. Muhasebe arşivi için aynı hedef 1 iş günü olabilir.

RPO nedir?

RPO, kesinti sonrasında verinin geri döndürüleceği zaman noktasıdır; pratikte kabul edilebilir en fazla veri kaybını gösterir. NIST, RPO’yu bir kesintiden sonra verinin geri yüklenmesi gereken zaman noktası olarak tanımlar (NIST Glossary).

RPO 24 saat ise, her gece alınan bir yedek yeterlidir; ancak arıza akşam saatlerinde olduğunda o günün tüm işlemleri yeniden girilmek zorunda kalır. RPO 15 dakika ise yedek ya da kopya en az 15 dakikada bir alınmalıdır.

RTO ile RPO arasındaki fark nedir?

RTO zamana, RPO veriye bakar. RTO “sistem ne kadar sürede geri gelmeli?” sorusunu, RPO “en fazla ne kadarlık veriyi kaybetmeyi göze alabiliriz?” sorusunu cevaplar. İki hedef birbirinden bağımsızdır: bir sistemin RTO’su uzun ama RPO’su çok kısa olabilir.

Bu iki hedefe bir üçüncü kavram daha eşlik eder: azami tolere edilebilir kesinti süresi (MTD). MTD, iş sürecinin ciddi zarar görmeden durabileceği en uzun süredir; RTO bu sürenin içinde kalmalıdır.

RTO ve RPO nasıl belirlenir?

RTO ve RPO, bilişim ekibinin tek başına seçtiği değerler değil, iş birimleriyle birlikte yapılan iş etki analizinin sonucudur. NIST’in süreklilik planlama rehberi de kurtarma stratejilerinin, iş etki analiziyle belirlenen hedeflere göre seçilmesini önerir (NIST SP 800-34 Rev. 1).

Uygulamada izlenen sıra şöyledir:

1. Sistemler iş süreçleriyle eşleştirilir: Sipariş, üretim planlama, muhasebe, e-posta gibi süreçler ve bunları çalıştıran sunucular eşleştirilir.
2. Kesintinin saatlik maliyeti hesaplanır: Kayıp ciro, personel maliyeti, sözleşme cezası ve itibar etkisi birlikte değerlendirilir.
3. Veri kaybının etkisi ölçülür: Kaybolan işlemlerin yeniden girilip girilemeyeceği, yasal kayıt yükümlülüğü olup olmadığı belirlenir.
4. Sistemler katmanlara ayrılır: Kritik, önemli ve ertelenebilir sistemler için farklı hedefler yazılır.
5. Hedefler bütçeyle karşılaştırılır: Her hedefin teknoloji maliyeti çıkarılır ve yönetimle onaylanır.

Kesintinin saatlik maliyetini hızlıca görmek için kesinti maliyeti hesaplayıcı kullanılabilir; çıkan rakam, hangi sistem için ne kadar yatırımın anlamlı olduğunu gösterir.

Hangi RPO ve RTO hangi teknolojiyle sağlanır?

Hedef ne kadar kısalırsa, onu sağlayan teknoloji de o kadar sürekli çalışmak zorundadır. Aşağıdaki tablo genel bir çerçeve sunar; gerçek değerler veri hacmine, ağ bağlantısına ve uygulamanın yapısına göre değişir.

Yedekleme ve replikasyon birbirinin yerine geçmez. Replikasyon güncel kopyayı tutar ve kısa RPO sağlar, ancak yanlış silinen ya da şifrelenen veriyi de aynı hızla karşı tarafa taşır. Bu yüzden kısa RPO hedefi olan sistemlerde de geçmişe dönük yedek ve değiştirilemez kopya ayrıca tutulur. Replikasyon hizmetinin ayrıntıları cloud veri replikasyonu sayfasında yer alır.

Kısa hedef her zaman doğru hedef mi? Maliyet dengesi

Hayır. Her sistem için en kısa RTO ve RPO’yu istemek, bütçenin büyük kısmını kritik olmayan sistemlere harcamak anlamına gelir. Saniyeler düzeyinde RPO, sürekli çalışan replikasyon, ikinci lokasyonda hazır bekleyen kaynak ve yüksek bant genişliği gerektirir.

Doğru yaklaşım katmanlı hedeftir: yalnızca kesintisi saatte ciddi kayıp üreten sistemler en kısa hedefe alınır, geri kalanı yedekten dönüşle korunur. Böylece aynı bütçeyle hem kritik sistemler hızlı geri döner hem de tüm veri güvence altında kalır.

Genel uygulama ve doğru yaklaşım

Pek çok işletmede kurtarma hedefleri bir kez yazılır ve bir daha gözden geçirilmez. Doğru yaklaşım, hedefi iş etkisine bağlamak ve gerçek koşullarda ölçmektir:

• Aynı hedef yerine katman: Tüm sistemlere aynı hedef yazmak yerine sistemler kritikliğe göre ayrılır.
• Tek başına bilişim kararı yerine ortak onay: Hedefler iş birimleri ve yönetimle birlikte onaylanır.
• Kâğıt yerine tatbikat: Hedef, düzenli tatbikatla ölçülür ve sonuç kayıt altına alınır.
• Yalnız sunucu yerine tüm zincir: DNS, ağ, kimlik doğrulama ve uygulama bağımlılıkları da süreye dahil edilir.

RTO ve RPO belirlerken sık yapılan hatalar

Hataların çoğu, hedefin gerçek koşullarda hiç ölçülmemesinden kaynaklanır. Kâğıt üzerinde 1 saat yazan bir RTO, tatbikatta ağ ayarları ve kullanıcı erişimleri nedeniyle çok daha uzun sürebilir.

• Yedek sıklığını RPO ile karıştırmak: Yedek her gece alınıyor ama yedek işi sabaha kadar sürüyorsa gerçek RPO daha uzundur.
• Geri yükleme süresini ölçmemek: Büyük veritabanlarının internet üzerinden geri yüklenmesi saatler sürebilir; RTO bu süreyi içermelidir.
• Bağımlılıkları atlamak: Uygulama sunucusu ayağa kalksa da veritabanı veya kimlik doğrulama sunucusu yoksa hizmet başlamaz.
• Fidye yazılımı senaryosunu düşünmemek: Şifrelenmiş verinin kopyası da şifrelenmiş olabilir; temiz bir geri dönüş noktası ayrıca planlanmalıdır.

Hedeflerin plan içinde nasıl yer alacağı felaket kurtarma planı nasıl hazırlanır rehberinde adım adım anlatılır.

Türkiye’de veri lokasyonu ve KVKK açısından RTO ve RPO

Kurtarma hedefleri yalnızca teknik bir konu değildir. Kişisel veri içeren sistemlerde ikinci kopyanın hangi ülkede tutulduğu, 6698 sayılı Kanun kapsamındaki yurt dışı aktarım şartları açısından önem taşır. Bu bilgiler genel çerçeve niteliğindedir ve hukuki danışmanlık yerine geçmez.

MAV Cloud’un yedekleme, replikasyon ve felaket kurtarma hizmetleri Equinix İstanbul veri merkezindeki VMware tabanlı altyapıda, Veeam tabanlı olarak sunulur; kopyalar Türkiye lokasyonlu altyapıda tutulur.

MAV Cloud felaket kurtarmada RTO ve RPO hedefleri

MAV Cloud’un sürekli veri koruma (CDP) tabanlı felaket kurtarma hizmetinde kritik sistemler için hedef RPO 15–60 saniye, hedef RTO ise 5–15 dakikadır. Bu değerler taahhüt değil hedeftir; her projede proje başında yapılan geri dönüş testiyle doğrulanır.

• Erişilebilirlik hedefi: Yazılı SLA’da aylık %99,9 erişilebilirlik hedefi ve kritik olayda 15 dakikalık ilk müdahale hedefi.
• Belgelenmiş süreçler: ISO/IEC 27001 bilgi güvenliği ve ISO 22301 iş sürekliliği yönetim sistemleri.
• Katmanlı koruma: Kritik sistemler için replikasyon, diğerleri için yedekten dönüş ve değiştirilemez yedek.

Hizmetin kapsamı ve devreye alma süreci felaket kurtarma merkezi sayfasında yer alır.

Sıkça Sorulan Sorular

RTO nedir?

RTO (Recovery Time Objective), bir sistemin kesinti sonrasında yeniden hizmet vermesi için kabul edilebilir en uzun süredir. Bu süre aşıldığında iş süreçleri ciddi biçimde etkilenir.

RPO nedir?

RPO (Recovery Point Objective), kesinti sonrasında verinin geri döndürüleceği zaman noktasıdır. Pratikte kabul edilebilir en fazla veri kaybını, yani son yedek veya kopyadan sonra kaybolabilecek veri miktarını gösterir.

RTO ile RPO arasındaki fark nedir?

RTO kesinti süresini, RPO veri kaybını ölçer. RTO arızadan sonrasına, RPO arızadan öncesine bakar; biri geri yükleme hızıyla, diğeri yedek veya kopya sıklığıyla belirlenir.

RPO 0 olabilir mi?

Senkron replikasyon gibi yöntemlerle sıfıra çok yakın RPO hedeflenebilir; ancak bu yöntemler yüksek bant genişliği ve kısa mesafe gerektirir, maliyeti de yüksektir. Ayrıca fidye yazılımı gibi senaryolarda geçmişe dönük temiz bir kopya yine gerekir.

RTO ve RPO kim tarafından belirlenir?

Hedefler bilişim ekibi, iş birimleri ve yönetim tarafından birlikte belirlenir. Temel girdi, kesintinin ve veri kaybının işletmeye maliyetini ortaya koyan iş etki analizidir.

Günlük yedek almak RPO’yu ne kadar yapar?

Günde bir yedek alınıyorsa RPO en fazla 24 saattir. Arıza yedekten hemen önce olursa yaklaşık bir günlük veri kaybolabilir; yedek işinin süresi de bu hesaba eklenmelidir.

RTO ve RPO nasıl test edilir?

Belirli aralıklarla yapılan tatbikatta seçilen sistem yedekten veya ikinci merkezden ayağa kaldırılır, geçen süre ve geri dönülen veri noktası kaydedilir. Ölçülen değerler hedefle karşılaştırılarak plan güncellenir.

MAV Cloud’un RTO ve RPO hedefleri nedir?

CDP tabanlı felaket kurtarma hizmetinde kritik sistemler için hedef RPO 15–60 saniye, hedef RTO 5–15 dakikadır. Bu değerler taahhüt değil hedeftir ve proje başında yapılan testle doğrulanır.

Kavramları öğrenmek isteyen okur için tanımlar ve karşılaştırma tablosu yeterli bir başlangıçtır. Hedef belirlemeye hazırlanan ekipler beş adımlık süreci kendi sistem listesine uygulayabilir. Hedeflerini gerçekçi bir altyapıyla karşılamak isteyen işletmeler MAV Cloud ekibinden ön analiz talep edebilir.