Herhangi bir kurumun bilgi teknolojileri (BT) altyapısı iş sürekliliğinin en kritik parçalarından biridir. Ancak hiçbir sistem yüzde yüz güvenli değildir donanım arızaları, siber saldırılar, doğal afetler veya insan hataları sebebiyle sistemler durabilir.
İşte bu noktada Felaket Kurtarma (Disaster Recovery – DR) planları devreye girer. Bu planların merkezinde iki kavram yer alır:
- RTO (Recovery Time Objective)
- RPO (Recovery Point Objective)
Her ikisi de iş sürekliliği stratejisinde “ne kadar kayba katlanabilirim?” sorusuna farklı açılardan yanıt verir.
RTO Nedir?
Recovery Time Objective (RTO) bir sistemin çökmesinden sonra en fazla ne kadar sürede tekrar çalışır hale gelmesi gerektiğini ifade eder.
Başka bir deyişle: “Sistem kapandı, en fazla ne kadar süre bekleyebilirim?”
- Düşük RTO (dakikalar/ saatler): Kritik sistemlerde kullanılır (ör. bankacılık, e-ticaret, sağlık hizmetleri).
- Yüksek RTO (günler): Daha az kritik sistemlerde kabul edilebilir (ör. arşiv sistemleri, test ortamları).
Örnek Senaryo
Bir e-ticaret sitesinin RTO’su 1 saat olabilir. Çünkü sistem 1 saatten fazla kapalı kalırsa:
- Satışlar durur,
- Müşteri güveni zedelenir,
- Rakipler avantaj elde eder.
RPO Nedir?
Recovery Point Objective (RPO), sistemin çökmesi halinde en fazla ne kadar veri kaybının tolere edilebileceğini belirtir.
Yani: “Çökmeye kadar olan son hangi noktadaki veriye kadar geri dönmek kabul edilebilir?”
- Düşük RPO (saniyeler/dakikalar): Finansal işlemler, borsa, bankacılık gibi alanlarda kritik öneme sahiptir.
- Yüksek RPO (saatler/günler): Daha az kritik ortamlarda kabul edilebilir (ör. iç yazışmalar, log kayıtları).
Örnek Senaryo
Bir banka için RPO sıfır olmalıdır. Çünkü müşteri bir para transferi yaptıysa, sistem çökse bile bu işlemin kaybolması kabul edilemez.
Ama bir şirketin iç yazışmalarında RPO 24 saat olabilir; en kötü ihtimalle bir günlük e-postaların kaybolması tolere edilebilir.
RTO ve RPO Arasındaki Fark
- RTO → Zaman odaklıdır.
Sistemin ne kadar sürede ayağa kalkması gerektiğini ifade eder. - RPO → Veri odaklıdır.
En fazla ne kadar veri kaybına izin verileceğini gösterir.
İkisinin birlikte planlanması gerekir. Çünkü:
- Çok düşük RTO ve RPO hedeflemek yüksek maliyet getirir.
- İşin doğasına göre denge kurulmalıdır.
Kullanım Senaryoları
Senaryo 1 – Banka Sistemi
- RTO: 15 dakika (ATM ve internet bankacılığı 15 dakikadan fazla kapalı kalamaz).
- RPO: 0 saniye (hiçbir müşteri işlemi kaybolamaz).
- Çözüm: Senkron replikasyon, yüksek erişilebilirlik (HA), çift veri merkezi.
Senaryo 2 – Hastane Bilgi Sistemi
- RTO: 30 dakika (doktorların hasta verisine erişimi kritik).
- RPO: 5 dakika (hasta bilgisi kaybı çok kritik, ama 5 dakikaya kadar tolere edilebilir).
- Çözüm: Sürekli replikasyon + yedekli sunucular.
Senaryo 3 – Küçük İşletme Muhasebe Programı
- RTO: 24 saat (bir günlük duruş tolere edilebilir).
- RPO: 12 saat (yarım gün verisi kaybolabilir, manuel tekrar işlenebilir).
- Çözüm: Günlük yedekleme.
RTO ve RPO Belirlerken Dikkat Edilmesi Gerekenler
- İş Önceliklendirmesi: Her sistemin kritikliği aynı değildir.
- Maliyet Dengesi: Daha düşük RTO/RPO → Daha pahalı çözüm.
- Teknoloji Seçimi:
- Snapshot, replika, yedekleme, cluster çözümleri.
- Bulut tabanlı felaket kurtarma (Azure Site Recovery, AWS DR, VMware SRM).
- 3-2-1-0 Yedekleme Kuralı:
- 3 kopya,
- 2 farklı medya,
- 1 tanesi uzak lokasyonda,
- 0 hata (doğrulanmış yedek).
RTO ve RPO, felaket kurtarma ve iş sürekliliği planlarının en kritik parametreleridir.
- RTO, sistemin ne kadar sürede ayağa kalkması gerektiğini,
- RPO ise ne kadar veri kaybına tahammül edilebileceğini belirler.
Bu iki kavram doğru analiz edilmezse:
- Gereksiz maliyetler ortaya çıkabilir,
- Ya da felaket anında iş sürekliliği sağlanamaz.
Dolayısıyla her kurum kendi iş ihtiyaçlarını değerlendirerek RTO ve RPO hedeflerini belirlemeli, buna uygun teknolojik çözümleri hayata geçirmelidir.
