'Yedekleme Stratejisinde RPO ve RTO Nasıl Belirlenir?'

Yedekleme projelerinde en sık duyulan sorulardan biri şudur: “Ne kadar veri kaybını kabul edebiliriz?” ve “Sistem ne kadar sürede ayağa kalkmalı?” Bu soruların yanıtları RPO (Recovery Point Objective) ve RTO (Recovery Time Objective) metrikleriyle ifade edilir.

RPO nedir?

RPO, kabul edilebilir veri kaybı penceresini tanımlar. Örneğin RPO 4 saat ise, son yedekten bu yana en fazla 4 saatlik veri kaybı tolere edilir. Bu değer ne kadar düşükse yedekleme sıklığı ve altyapı maliyeti o kadar artar.

RTO nedir?

RTO, bir kesinti sonrası sistemin ne kadar sürede tekrar hizmet vermesi gerektiğini belirtir. ERP, e-posta ve dosya sunucusu için RTO hedefleri farklı olabilir; her sistem aynı önceliğe sahip değildir.

Belirleme süreci

1. Kritik sistem envanteri: Hangi uygulamalar durduğunda iş durur?
2. İş etkisi analizi: Saatlik/dakikalık operasyonel ve finansal etkiyi değerlendirin.
3. Teknik gerçekçilik: Mevcut altyapı hedefleri karşılıyor mu, test edildi mi?
4. Maliyet dengesi: Her sistem için “altın standart” gerekmez; katmanlı koruma uygulanabilir.

Pratik örnek tablo

| Sistem | RPO | RTO | Not |

|---------------|-------|--------|------------------------------|

| E-posta | 1 saat| 4 saat | Bulut yedek + hızlı geri dönüş |

| ERP | 15 dk | 2 saat | Replikasyon + sık snapshot |

| Dosya arşivi | 24 saat| 8 saat | Günlük offsite yedek |

Test etmek şart

Tanımlanan RPO/RTO değerleri yalnızca kağıt üzerinde kalmamalıdır. Periyodik kurtarma tatbikatları, gerçek süreleri ortaya çıkarır ve eksikleri görünür kılar.

Proxis Bilişim, yedekleme ve iş sürekliliği projelerinde politika tasarımından kurtarma testlerine kadar uçtan uca destek sunar.