# RPO ve RTO Nedir? İş Sürekliliğinin İki Kritik Metriği

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/backup-yedekleme-is-surekliligi/rpo-ve-rto-nedir

![RPO ve RTO Nedir? İş Sürekliliğinin İki Kritik Metriği](/images/bilgi-merkezi/covers/cover-backup-07.webp)

Bir kurumda backup bulunması tek başına yeterli değildir.

Asıl önemli olan iki sorunun net şekilde cevaplanmasıdır:

#### Ne kadar veri kaybını kabul edebiliriz?

ve

#### Sistemi ne kadar sürede yeniden çalışır hale getirmeliyiz?

Bu iki sorunun karşılığı bilgi teknolojileri ve iş sürekliliği dünyasında iki temel kavramla ifade edilir:

#### RPO – Recovery Point Objective

ve

#### RTO – Recovery Time Objective

Bu iki metrik;

backup stratejisi,

disaster recovery,

iş sürekliliği,

cloud mimarisi,

veritabanı tasarımı,

yüksek erişilebilirlik,

ransomware recovery

gibi birçok kritik kararın temelini oluşturur.

Çünkü bir kurumun bütün sistemleri aynı öneme sahip değildir.

Bir sistemin 24 saat kapalı kalması kabul edilebilirken başka bir sistemin 30 dakika çalışmaması ciddi finansal veya operasyonel zarar oluşturabilir.

Benzer şekilde bir sistemde 12 saatlik veri kaybı tolere edilebilirken kritik finans uygulamasında birkaç dakikalık veri kaybı bile kabul edilemeyebilir.

Bu nedenle doğru backup mimarisi şu soruyla başlamaz:

**“Hangi ürünü satın alalım?”**

Doğru soru şudur:

**“İş birimleri ne kadar veri kaybını ve ne kadar kesintiyi kabul edebilir?”**

### RPO Nedir?

RPO, yani **Recovery Point Objective**, bir sistemde kabul edilebilir maksimum veri kaybı süresini ifade eder.

Başka bir ifadeyle:

#### Bir felaket yaşandığında ne kadar geriye gitmeyi kabul edebiliriz?

Örneğin RPO değeri:

#### 24 saat

olan bir sistem için kurum en kötü durumda son 24 saat içerisindeki verileri kaybetmeyi kabul ediyor olabilir.

RPO:

#### 1 saat

ise veri kaybı toleransı yaklaşık bir saate düşer.

RPO:

#### 15 dakika

ise backup veya replikasyon mimarisinin en fazla 15 dakikalık veri kaybına izin verecek şekilde tasarlanması gerekir.

### RPO Basit Bir Örnekle Nasıl Açıklanır?

Bir ERP sisteminin her gece saat 00:00'da backup aldığını düşünelim.

Ertesi gün saat 16:00'da sistem tamamen kaybedildi.

Son kullanılabilir backup:

gece 00:00.

Bu durumda yaklaşık:

#### 16 saatlik veri

kaybedilebilir.

Dolayısıyla bu mimari 15 dakikalık RPO hedefini karşılamaz.

Sistem yalnızca günde bir kez backup alıyorsa teorik veri kaybı penceresi oldukça büyüktür.

### RPO Backup Sıklığıyla Aynı Şey midir?

Tam olarak değil.

Backup sıklığı RPO'yu etkileyen en önemli faktörlerden biridir.

Ancak RPO bir **iş hedefidir**.

Backup frequency ise bu hedefi sağlayan teknik yöntemlerden biridir.

Örneğin iş birimi:

**RPO = 30 dakika**

belirlemiş olabilir.

BT ekibi bunu;

30 dakikada bir incremental backup,

transaction log backup,

continuous data protection,

storage replication

gibi yöntemlerle sağlayabilir.

Dolayısıyla:

**RPO = Gereksinim**

**Backup Frequency = Teknik uygulama**

olarak düşünülmelidir.

### RPO Sıfır Olabilir mi?

Teorik olarak:

**RPO = 0**

hiç veri kaybının kabul edilmediği anlamına gelir.

Ancak gerçek hayatta sıfır veri kaybını garanti etmek teknik olarak zor ve maliyetli olabilir.

Bu seviyeye yaklaşmak için;

synchronous replication,

yüksek erişilebilirlik cluster,

continuous replication

gibi mimariler gerekebilir.

Bu sistemlerin;

network,

storage,

latency,

data center

gereksinimleri oldukça yüksek olabilir.

Bu nedenle her sistem için sıfır RPO hedeflemek ekonomik değildir.

### RTO Nedir?

RTO, yani **Recovery Time Objective**, bir sistemin kesinti sonrasında ne kadar sürede tekrar çalışır hale getirilmesi gerektiğini ifade eder.

Başka bir ifadeyle:

#### Sistem en fazla ne kadar süre kapalı kalabilir?

Örneğin bir sistem için:

**RTO = 4 saat**

belirlenmişse felaket sonrasında sistemin yaklaşık dört saat içerisinde yeniden hizmet vermesi hedeflenir.

RTO:

30 dakika

ise recovery altyapısının son derece hızlı olması gerekir.

### RTO Basit Bir Örnekle Nasıl Açıklanır?

Bir şirketin e-ticaret sistemi saat 10:00'da çöktü.

RTO:

#### 2 saat

olarak belirlenmiş olsun.

Bu durumda hedef:

#### 12:00'ye kadar sistemi yeniden çalıştırmak

olmalıdır.

Eğer backup'tan restore 8 saat sürüyorsa mevcut backup mimarisi iş hedefini karşılamıyor demektir.

### RPO ve RTO Arasındaki Temel Fark

RPO:

#### Ne kadar veri kaybedebiliriz?

sorusuna cevap verir.

RTO:

#### Ne kadar süre çalışmadan kalabiliriz?

sorusuna cevap verir.

Basitçe:

**RPO = Veri**

**RTO = Zaman**

olarak düşünülebilir.

### RPO ve RTO Örnekleri

Bir muhasebe sistemi düşünelim.

RPO:

#### 4 saat

RTO:

#### 8 saat

olabilir.

Bu durumda kurum;

en fazla 4 saatlik veri kaybını

ve

en fazla 8 saatlik kesintiyi

kabul ediyor demektir.

Ancak internet bankacılığı sistemi için:

RPO:

**birkaç dakika**

RTO:

**çok kısa**

olabilir.

Bu nedenle iki sisteme aynı backup politikasını uygulamak doğru değildir.

### Tüm Sistemlerin RPO ve RTO Değeri Aynı Olmalı mı?

Hayır.

Bu, kurumlarda yapılan en büyük hatalardan biridir.

Her uygulamanın iş etkisi farklıdır.

Örneğin;

ERP,

CRM,

e-posta,

dosya sunucusu,

web sitesi,

Active Directory,

CCTV arşivi,

test sunucusu

aynı kritik seviyede değildir.

Bu nedenle sistemler sınıflandırılmalıdır.

### Tier Bazlı RPO ve RTO Yaklaşımı

Kurumlar sistemlerini kritik seviyelerine göre farklı sınıflara ayırabilir.

Örneğin:

#### Tier 0 – Kritik Altyapı

Active Directory, DNS, temel network ve kimlik servisleri.

RPO ve RTO çok düşük olabilir.

#### Tier 1 – İş Kritik Sistemler

ERP, ödeme, üretim veya müşteri işlemleri.

Örneğin:

RPO: 15 dakika

RTO: 1 saat

#### Tier 2 – Önemli Sistemler

İş süreçlerini etkiler ancak kısa süreli kesinti tolere edilebilir.

Örneğin:

RPO: 4 saat

RTO: 8 saat

#### Tier 3 – Standart Sistemler

Daha düşük öncelikli sistemler.

Örneğin:

RPO: 24 saat

RTO: 48 saat

Bu değerler yalnızca örnektir.

Her kurum kendi iş ihtiyaçlarına göre belirlemelidir.

### RPO ve RTO'yu Kim Belirlemeli?

RPO ve RTO yalnızca BT departmanının belirlemesi gereken değerler değildir.

Çünkü veri kaybının veya sistem kesintisinin gerçek etkisini iş birimleri bilir.

Bu nedenle süreçte;

iş birimleri,

BT,

siber güvenlik,

risk yönetimi,

iş sürekliliği,

üst yönetim

birlikte çalışmalıdır.

### Business Impact Analysis – BIA Nedir?

RPO ve RTO değerlerini belirlemenin en önemli araçlarından biri:

#### Business Impact Analysis – BIA

yani:

#### İş Etki Analizi

çalışmasıdır.

BIA, kritik iş süreçlerinin kesintiden nasıl etkileneceğini analiz eder.

Örneğin;

finansal kayıp,

müşteri kaybı,

itibar kaybı,

regülasyon ihlali,

operasyonel duruş,

üretim kaybı

gibi etkiler değerlendirilir.

### BIA'da Hangi Sorular Sorulur?

Bir iş birimine şu sorular yöneltilebilir:

Sistem 1 saat kapalı kalırsa ne olur?

4 saat kapalı kalırsa?

24 saat kapalı kalırsa?

Hangi iş süreçleri durur?

Kaç çalışan etkilenir?

Müşteri hizmeti durur mu?

Finansal işlem yapılamaz mı?

Regülasyon ihlali oluşur mu?

Ne kadar veri kaybı kabul edilebilir?

Bu cevaplar RTO ve RPO hedeflerinin belirlenmesine yardımcı olur.

### BIA ile Backup Arasında Nasıl Bir İlişki Vardır?

Backup mimarisi BIA sonucuna göre tasarlanmalıdır.

Örneğin BIA sonucu:

RPO = 15 dakika

RTO = 30 dakika

olan bir sistem için:

gece bir kez full backup

yeterli değildir.

Bu sistem için;

continuous replication,

sık incremental,

transaction log backup,

instant recovery,

standby system

gibi çözümler gerekebilir.

### RPO Değeri Backup Teknolojisini Nasıl Değiştirir?

Bir sistem için RPO:

24 saat

ise günlük backup yeterli olabilir.

RPO:

4 saat

ise günde birkaç kez backup gerekebilir.

RPO:

15 dakika

ise;

incremental,

log backup,

snapshot,

replication

gibi yöntemler kullanılabilir.

RPO:

saniyeler

seviyesine yaklaşıyorsa sürekli replikasyon gerekebilir.

### RTO Değeri Teknolojiyi Nasıl Değiştirir?

RTO:

24 saat

olan sistem tape backup'tan restore edilebilir.

Ancak RTO:

15 dakika

olan bir sistem için tape recovery uygun olmayabilir.

Bu durumda;

hot standby,

failover cluster,

replica,

instant recovery

gibi yöntemler değerlendirilebilir.

### Backup ile High Availability Arasındaki Fark

RPO ve RTO konuşulurken sık yapılan bir hata backup ile high availability'yi aynı şey sanmaktır.

Backup:

**veriyi geçmiş bir noktaya döndürür.**

High Availability:

**servisin kesintisiz veya minimum kesintiyle devam etmesini sağlar.**

Örneğin iki database server cluster olarak çalışıyorsa bir server bozulduğunda diğeri devreye girebilir.

Bu RTO'yu çok düşürür.

Ancak yanlışlıkla database tablosu silinirse bu silme cluster üzerinde de gerçekleşebilir.

Bu durumda backup gerekir.

### Replication RPO'yu Düşürür mü?

Evet.

Replication RPO'yu çok düşük seviyelere indirebilir.

Ancak replication backup değildir.

Örneğin ransomware dosyaları şifrelerse şifrelenmiş veriler replica sisteme de gönderilebilir.

Bu nedenle:

#### Replication + Backup

birlikte kullanılmalıdır.

### Synchronous Replication Nedir?

Synchronous replication'da veri iki storage veya sistem üzerine aynı anda yazılır.

Bir işlem diğer lokasyona da yazılmadan tamamlanmış sayılmaz.

Avantajı:

çok düşük RPO sağlamasıdır.

Ancak lokasyonlar arasındaki latency performansı etkileyebilir.

Bu nedenle genellikle birbirine yakın veri merkezlerinde kullanılır.

### Asynchronous Replication Nedir?

Asynchronous replication'da veri önce production sisteme yazılır.

Daha sonra ikinci lokasyona aktarılır.

Bu nedenle küçük bir gecikme bulunur.

RPO sıfır olmayabilir.

Ancak daha uzak veri merkezleri arasında kullanılabilir.

### RPO ile Backup Retention Aynı Şey midir?

Hayır.

RPO:

ne kadar veri kaybını kabul ettiğinizi

gösterir.

Retention:

backup'ın ne kadar süre saklanacağını

gösterir.

Örneğin:

RPO = 1 saat

Retention = 90 gün

olabilir.

Yani her saat backup alınır ve belirli kopyalar 90 gün saklanabilir.

### Recovery Window Nedir?

Recovery Window, sistemin kurtarılması için kullanılan genel zaman penceresidir.

Bu süre içerisinde;

backup bulunur,

storage hazırlanır,

sistem restore edilir,

network bağlanır,

uygulama kontrol edilir

ve kullanıcıya açılır.

RTO belirlerken bütün bu işlemler dikkate alınmalıdır.

### Restore Süresi RTO'nun Tamamı mıdır?

Hayır.

Bu önemli bir noktadır.

Örneğin 5 TB server'ın backup'tan restore edilmesi 2 saat sürebilir.

Ancak sonrasında;

database kontrolü,

uygulama testi,

DNS değişikliği,

security validation,

kullanıcı testi

gerekebilir.

Dolayısıyla gerçek recovery süresi 4 saat olabilir.

### Work Recovery Time – WRT Nedir?

Bazı iş sürekliliği modellerinde:

#### Work Recovery Time – WRT

kavramı kullanılır.

WRT teknik sistem geri geldikten sonra iş süreçlerinin normal operasyon seviyesine ulaşması için gereken ek süredir.

Örneğin:

Teknik restore: 2 saat

Kullanıcı kontrolleri ve operasyonun açılması: 1 saat

Toplam iş recovery süresi:

3 saat

olabilir.

### Maximum Tolerable Downtime – MTD Nedir?

MTD:

#### Maximum Tolerable Downtime

yani:

#### Maksimum Tolere Edilebilir Kesinti Süresi

olarak ifade edilir.

Bir iş sürecinin ciddi zarar oluşmadan önce en fazla ne kadar süre durabileceğini gösterir.

Örneğin:

MTD = 12 saat

ise iş sürecinin 12 saatten uzun durması kabul edilemez seviyede zarar oluşturabilir.

RTO bu sürenin içerisinde belirlenmelidir.

### MTPD Nedir?

Bazı metodolojilerde:

#### Maximum Tolerable Period of Disruption – MTPD

terimi kullanılabilir.

Mantığı MTD'ye benzer.

İş faaliyetinin kabul edilemez seviyeye ulaşmadan önce dayanabileceği maksimum kesinti süresini ifade eder.

### RTO MTD'den Büyük Olabilir mi?

Mantıksal olarak olmamalıdır.

Örneğin iş süreci:

8 saatten sonra kabul edilemez seviyede zarar görüyor

ancak teknik ekibin RTO hedefi:

24 saat

ise hedefler birbiriyle çelişmektedir.

Bu nedenle:

#### RTO < MTD

olması beklenir.

### SLA ile RTO Aynı Şey midir?

Hayır.

SLA, yani Service Level Agreement bir hizmet seviyesini tanımlar.

Örneğin:

%99,9 uptime

veya

4 saat incident resolution

gibi hedefler içerebilir.

RTO ise felaket veya ciddi kesinti sonrasında sistemin ne kadar sürede geri getirileceğini ifade eder.

Birbirleriyle ilişkili olabilirler ancak aynı kavram değildir.

### %99,9 Uptime Ne Anlama Gelir?

Yüksek erişilebilirlik seviyeleri yıllık izin verilen downtime üzerinden değerlendirilebilir.

Yaklaşık olarak:

%99 uptime → yılda günler seviyesinde kesinti

%99,9 uptime → yılda saatler seviyesinde kesinti

%99,99 uptime → yılda onlarca dakika seviyesinde kesinti

hedeflerine karşılık gelir.

Uptime hedefi yükseldikçe altyapı maliyeti de artar.

### RPO ve RTO Neden Maliyeti Belirler?

RPO ve RTO ne kadar düşükse çözüm genellikle o kadar maliyetli olur.

Örneğin:

RPO = 24 saat

RTO = 48 saat

için basit backup yeterli olabilir.

Ancak:

RPO = 0

RTO = birkaç dakika

için;

çift veri merkezi,

synchronous replication,

high availability,

otomatik failover

gerekebilir.

Bu nedenle iş birimleri gerçekçi hedefler belirlemelidir.

### Her Şey İçin 0 RPO ve 0 RTO İstenirse Ne Olur?

Teknik ekip açısından ideal görünse de ekonomik olarak mantıklı olmayabilir.

Örneğin test ortamının:

RPO = 0

RTO = 0

olması için yüksek maliyetli altyapı kurmak gereksiz olabilir.

Bu nedenle kritik sistem sınıflandırması önemlidir.

### RPO ve RTO Değerleri Nasıl Belgelenir?

Kurum bir iş sürekliliği tablosu oluşturabilir.

Örneğin:

| Sistem | Kritik Seviye | RPO | RTO |
| --- | --- | --- | --- |
| Active Directory | Kritik | 1 saat | 1 saat |
| ERP | Kritik | 15 dk | 2 saat |
| E-posta | Yüksek | 1 saat | 4 saat |
| Dosya Sunucusu | Orta | 4 saat | 8 saat |
| Test Sistemi | Düşük | 24 saat | 48 saat |

Bu değerler örnektir ve her kurumun kendi iş analizine göre belirlenmelidir.

### Active Directory İçin RPO ve RTO Neden Özel Olarak Düşünülmeli?

Active Directory diğer birçok sistemin bağımlı olduğu altyapıdır.

AD çalışmıyorsa;

kullanıcı login işlemleri,

DNS,

Group Policy,

service account authentication,

uygulama erişimleri

etkilenebilir.

Bu nedenle AD recovery priority listesinde genellikle üst sıralarda bulunur.

### Database Sistemlerinde RPO Nasıl Düşürülür?

Veritabanlarında düşük RPO için;

transaction log backup,

continuous log shipping,

database replication,

Always On,

standby database

gibi teknolojiler kullanılabilir.

Örneğin SQL Server transaction log backup her 5 dakikada bir alınabilir.

Böylece teorik veri kaybı penceresi ciddi şekilde azaltılabilir.

### Point-in-Time Recovery RPO İçin Neden Önemlidir?

Kullanıcı saat 14:32'de kritik veriyi silmiş olabilir.

Gece alınan full backup'a dönmek saatlerce veri kaybına neden olabilir.

Point-in-Time Recovery ile:

14:31:59

gibi belirli bir ana dönülebilir.

Bu özellikle database sistemlerinde değerlidir.

### Microsoft 365 İçin RPO ve RTO Nasıl Düşünülmeli?

SaaS sistemleri yüksek erişilebilir olabilir.

Ancak bu;

veri silme,

ransomware,

hesap ele geçirme

risklerini tamamen ortadan kaldırmaz.

Microsoft 365 backup politikası oluşturulurken;

Exchange,

SharePoint,

OneDrive,

Teams

verileri için iş ihtiyaçlarına göre RPO ve RTO hedefleri belirlenmelidir.

### Cloud Sistemlerde RPO ve RTO Nasıl Tasarlanır?

Cloud ortamında farklı seçenekler kullanılabilir.

Örneğin;

snapshot,

cross-region replication,

multi-region architecture,

cloud backup,

DRaaS

ile farklı RPO/RTO seviyeleri sağlanabilir.

Ancak her ekstra dayanıklılık katmanı maliyeti artırabilir.

### RPO ve RTO ile Ransomware Arasındaki İlişki

Ransomware recovery klasik disaster recovery'den farklıdır.

Çünkü en son backup her zaman kullanılabilir olmayabilir.

Saldırgan günlerdir sistem içerisinde olabilir.

Bu nedenle:

#### Cyber Recovery RPO

kavramı önem kazanır.

En son temiz backup'ın tarihi gerçek veri kaybını belirler.

### Örnek Ransomware Senaryosu

Kurumun backup sistemi her 15 dakikada bir backup alıyor olsun.

Teorik:

RPO = 15 dakika.

Ancak saldırganın 10 gündür sistem içerisinde bulunduğu tespit edildi.

Son güvenilir restore point:

11 gün önce.

Bu durumda teknik backup RPO'su 15 dakika olmasına rağmen cyber recovery sırasında yaklaşık 11 günlük veri farkı oluşabilir.

Bu yüzden yalnızca backup frequency yeterli değildir.

### Ransomware RTO'yu Neden Uzatır?

Normal hardware failure durumunda:

restore → aç → devam et

mümkün olabilir.

Ransomware olayında ise;

forensic analiz,

credential reset,

network izolasyonu,

malware scan,

clean room recovery,

güvenlik doğrulaması

gerekebilir.

Bu nedenle gerçek cyber recovery süresi normal disaster recovery süresinden uzun olabilir.

### Recovery Time Actual – RTA Nedir?

Planlanan RTO ile gerçek kurtarma süresi aynı olmayabilir.

Bu nedenle tatbikatlarda gerçek süre ölçülmelidir.

Örneğin:

RTO hedefi = 2 saat

Tatbikatta gerçekleşen recovery = 6 saat

ise kurumun planı hedefi karşılamamaktadır.

Bu fark iyileştirme gerektirir.

### RPO Gerçekte Nasıl Test Edilir?

Backup sıklığına bakmak yeterli değildir.

Restore testi yapılmalıdır.

Örneğin:

en son başarılı backup bulunur,

restore edilir,

verinin timestamp'i kontrol edilir.

Böylece gerçek veri kaybı ölçülebilir.

### RTO Gerçekte Nasıl Test Edilir?

Kronometre gerçek felaket senaryosunda başlatılmalıdır.

Örneğin:

09:00 sistem kaybedildi.

09:15 incident ilan edildi.

09:30 restore başladı.

11:00 restore tamamlandı.

11:30 uygulama açıldı.

12:00 kullanıcı onayı verildi.

Gerçek recovery:

#### 3 saat

olarak ölçülebilir.

### DR Tatbikatı Olmadan RTO Bilinebilir mi?

Gerçek anlamda hayır.

Backup yazılımı:

“Restore 60 dakika sürer.”

diyebilir.

Ancak network, DNS, authentication ve uygulama kontrolleri toplam süreyi uzatabilir.

Bu nedenle RTO ancak gerçek veya gerçeğe yakın tatbikatlarla doğrulanabilir.

### RPO ve RTO Değerleri Ne Sıklıkla Gözden Geçirilmeli?

İş süreçleri değiştikçe RPO ve RTO değerleri de değişebilir.

Örneğin bir uygulama başlangıçta küçük olabilir.

Bir yıl sonra şirketin en kritik sistemi haline gelebilir.

Bu nedenle;

yıllık,

önemli sistem değişikliklerinde,

yeni regülasyon geldiğinde,

büyük incident sonrasında

BIA ve recovery hedefleri gözden geçirilmelidir.

### Yeni Sistem Devreye Alınırken RPO/RTO Belirlenmeli mi?

Evet.

RPO ve RTO sonradan düşünülmemelidir.

Yeni uygulama tasarlanırken şu sorular sorulmalıdır:

Kritikliği nedir?

Ne kadar veri kaybı kabul edilebilir?

Ne kadar süre kapalı kalabilir?

Hangi diğer sistemlere bağımlıdır?

Bu sayede doğru mimari baştan kurulabilir.

### RPO/RTO ile Capacity Planning İlişkisi

RTO düşükse restore altyapısının yeterli kapasitede olması gerekir.

Örneğin 100 TB veriyi:

2 saat içerisinde

restore etmek isteniyorsa ciddi storage ve network throughput gerekir.

Bu nedenle RTO yalnızca operasyonel hedef değil aynı zamanda capacity planning parametresidir.

### Restore Throughput Neden Önemlidir?

Backup sistemi 10 Gbps network kullanabilir.

Ancak gerçek restore throughput daha düşük olabilir.

Storage IOPS,

CPU,

compression,

encryption,

network latency

restore hızını etkileyebilir.

Bu nedenle teorik bandwidth üzerinden RTO hesaplamak yanlış olabilir.

### Tier 1 Sistemlerde Instant Recovery Neden Kullanılır?

Instant Recovery teknolojisi VM'i tamamen restore etmeyi beklemeden backup storage üzerinden çalıştırabilir.

Bu yöntem RTO'yu saatlerden dakikalara indirebilir.

Ancak backup repository performansının yeterli olması gerekir.

### DRaaS RTO'yu Nasıl Etkiler?

Disaster Recovery as a Service, kritik sistemlerin cloud veya başka bir platformda standby tutulmasını sağlayabilir.

Felaket sırasında failover yapılır.

Bu sayede RTO önemli ölçüde düşebilir.

Ancak;

network,

DNS,

authentication,

application dependency

planları önceden hazırlanmalıdır.

### İş Birimleri Gerçekçi RPO ve RTO Nasıl Belirlemeli?

İş birimlerine:

“Kaç saat istersiniz?”

diye sormak çoğu zaman:

“0 saat.”

cevabını getirir.

Bunun yerine finansal ve operasyonel etki sorulmalıdır.

Örneğin:

1 saat kesinti size ne kadar kaybettirir?

4 saat?

8 saat?

24 saat?

Bu yöntem daha gerçekçi hedefler oluşturur.

### Cost of Downtime Nedir?

Cost of Downtime, sistem kesintisinin kuruma maliyetini ifade eder.

Örneğin;

satış kaybı,

üretim kaybı,

personel verimsizliği,

SLA cezası,

müşteri kaybı,

itibar zararı

dahil edilebilir.

Bu maliyet RTO yatırım kararlarını destekler.

### 1 Saat Kesinti 1 Milyon TL Kaybettiriyorsa

Bir sistem 1 saat kapalı kaldığında çok yüksek zarar oluşturuyorsa yüksek erişilebilirlik altyapısına yatırım yapmak ekonomik olabilir.

Ancak yıllık birkaç bin TL etkisi olan sistem için aynı yatırım mantıklı olmayabilir.

RPO ve RTO bu nedenle teknoloji ile iş maliyeti arasındaki köprüdür.

### RPO ve RTO İçin En Sık Yapılan Hatalar

Kurumlarda sık görülen hatalar şunlardır:

- tüm sistemlere aynı RPO vermek,
- tüm sistemlere aynı RTO vermek,
- değerleri yalnızca BT'nin belirlemesi,
- RPO'yu backup sıklığı zannetmek,
- RTO'yu yalnızca restore süresi olarak görmek,
- uygulama bağımlılıklarını hesaba katmamak,
- ransomware senaryosunu değerlendirmemek,
- test yapmadan hedef belirlemek,
- eski BIA çalışmalarını yıllarca güncellememek.

### Uygulama Bağımlılıkları RTO'yu Nasıl Bozar?

Bir ERP sistemi 30 dakikada restore edilmiş olabilir.

Ancak ERP'nin;

Active Directory,

DNS,

database,

storage,

network,

lisans server

bağımlılığı varsa bu sistemler çalışmadan ERP kullanılamaz.

Bu nedenle RTO uygulama bazında değil hizmet zinciri bazında değerlendirilmelidir.

### Dependency Mapping Nedir?

Dependency Mapping, sistemlerin birbirine olan teknik ve iş bağımlılıklarının belirlenmesidir.

Örneğin:

ERP

↓

Database

↓

Active Directory

↓

DNS

↓

Network

gibi bir bağımlılık olabilir.

Recovery sırası buna göre belirlenir.

### Recovery Priority Nasıl Oluşturulur?

BIA sonucunda sistemlere recovery priority atanabilir.

Örneğin:

#### Priority 1

AD, DNS, network, core database

#### Priority 2

ERP, ödeme, kritik uygulamalar

#### Priority 3

e-posta, dosya sistemleri

#### Priority 4

düşük öncelikli sistemler

Bu sıra felaket anındaki karmaşayı azaltır.

### ISO 22301 Açısından RPO ve RTO

ISO 22301 iş sürekliliği yönetim sistemi açısından kritik süreçlerin kesinti sonrasında kabul edilebilir süre içerisinde devam ettirilmesini hedefler.

Bu nedenle;

BIA,

maksimum kesinti toleransı,

recovery hedefleri,

bağımlılıklar

iş sürekliliği çalışmalarının temel parçalarıdır.

RPO ve RTO teknik recovery hedeflerinin belirlenmesinde önemli rol oynar.

### ISO 27001 Açısından RPO ve RTO

ISO/IEC 27001 bilgi güvenliği açısından erişilebilirlik ve iş sürekliliği kontrollerinin risk bazlı şekilde planlanmasını destekler.

Backup süreçlerinin;

iş ihtiyacına uygun,

test edilmiş,

korunan,

izlenen

olması önemlidir.

RPO ve RTO bu süreçlerin ölçülebilir hale gelmesini sağlar.

### DORA Perspektifinden RPO ve RTO

Finans kuruluşlarında dijital operasyonel dayanıklılık yalnızca backup bulunmasını değil kritik hizmetlerin büyük ICT kesintilerinden sonra geri getirilebilmesini gerektirir.

Bu nedenle;

recovery hedefleri,

DR,

backup,

resilience testing

birlikte değerlendirilmelidir.

### RPO ve RTO İçin Yönetimin Sorması Gereken 5 Soru

Bir yöneticinin teknik ayrıntıları bilmesine gerek olmadan şu beş soruyu sorabilmesi büyük değer sağlar:

- Kritik sistemlerimizin RPO'su nedir?
- Kritik sistemlerimizin RTO'su nedir?
- Bu değerleri gerçekten test ettik mi?
- Son DR tatbikatında hedefi tutturduk mu?
- Ransomware senaryosunda da aynı hedefler geçerli mi?

Bu sorular kurumun gerçek iş sürekliliği olgunluğunu ortaya çıkarır.

### Sonuç: RPO ve RTO Backup Stratejisinin Başlangıç Noktasıdır

Backup dünyasında teknoloji seçenekleri çok fazladır.

Full Backup,

Incremental Backup,

Immutable Backup,

Air-Gap,

Replication,

DRaaS,

Instant Recovery,

Cloud Backup

gibi birçok yöntem kullanılabilir.

Ancak hangi teknolojinin seçileceğini belirleyen temel unsur iş gereksinimidir.

Bu gereksinimin iki temel ölçüsü:

#### RPO

ve

#### RTO

dur.

RPO şu soruyu sorar:

**“Ne kadar veri kaybını kabul ediyoruz?”**

RTO ise:

**“Ne kadar süre çalışmadan kalabiliriz?”**

Bu iki hedef net değilse backup tasarımı teknoloji merkezli olur.

RPO ve RTO iş birimleriyle birlikte belirlenmişse backup mimarisi doğrudan iş sürekliliğine hizmet eder.

En kritik nokta ise şudur:

**Kağıt üzerinde yazan RPO ve RTO bir hedef olabilir; gerçek RPO ve RTO ancak restore ve disaster recovery tatbikatında ortaya çıkar.**

Bu nedenle modern iş sürekliliği yaklaşımının amacı yalnızca hedef yazmak değildir.

Amaç:

**hedefi ölçmek, test etmek ve gerçekten karşılayabildiğini kanıtlamaktır.**