"RPO'nuz ne kadar?" diye sorulduğunda çoğu kişi aslında RTO'yu kastederek cevap verir, ya da tam tersi. İkisi de felaket kurtarma (disaster recovery) planlamasının temel taşı ama tamamen farklı iki soruyu yanıtlarlar.
RPO (Recovery Point Objective) — Ne Kadar Veri Kaybedebilirsiniz?
RPO, bir kesinti anında ne kadar veriyi kaybetmeye razı olduğunuzu ifade eder. Saat cinsinden ölçülür ve "en son ne zaman alınan yedeğe geri dönebiliriz" sorusunun cevabıdır.
Örneğin RPO'nuz 4 saat ise, sisteminiz saat 14:00'te çöktüğünde, en kötü ihtimalle saat 10:00'daki duruma geri dönersiniz — 10:00 ile 14:00 arası tüm veri kaybolur. RPO'yu küçültmek (örneğin 4 saatten 15 dakikaya indirmek) daha sık backup almayı, ya da CDP (Continuous Data Protection) gibi sürekli koruma teknolojilerini gerektirir.
RTO (Recovery Time Objective) — Ne Kadar Sürede Ayağa Kalkarsınız?
RTO ise "kesintiden itibaren sistemler tekrar çalışır hale gelene kadar geçmesine izin verilen maksimum süre"dir. RPO veri kaybıyla ilgiliyken, RTO kesinti süresiyle ilgilidir.
RTO'su 1 saat olan bir sistem, çökmeden 1 saat içinde tamamen ayağa kalkmalıdır — bu, otomatik failover, hazır bekleyen DR (Disaster Recovery) sitesi veya hızlı restore prosedürleri gerektirir.
İkisi Neden Karıştırılır?
Çünkü ikisi de "ne kadar" sorusuna saat/dakika cinsinden cevap verir ama farklı eksenlerdedir:
| Soru | Cevap | Ölçü |
|---|---|---|
| Ne kadar veri kaybederiz? | RPO | Kesinti öncesine göre geriye dönük süre |
| Ne kadar sürede toparlanırız? | RTO | Kesintiden sonra ileriye doğru süre |
Bir analoji: RPO, "en son ne zaman fotoğraf çektiniz" sorusudur. RTO, "yeni fotoğrafı çekmeniz ne kadar sürer" sorusudur.
Neden Önemli — Maliyetle Doğrudan İlişkili
RPO ve RTO hedeflerini küçültmek (yani daha sıkı korumayı) doğrudan maliyeti artırır. Sıfıra yakın RPO/RTO isteyen bir sistem; sürekli replikasyon, ikinci bir veri merkezi, otomatik failover altyapısı ve önemli bir bant genişliği gerektirir. Bu nedenle her uygulama için aynı RPO/RTO hedefini belirlemek hem gereksiz pahalı hem de yetersiz koruma riski taşır.
Pratikte kurumlar, uygulamalarını kritiklik seviyesine göre katmanlara ayırır:
- Katman 1 (Kritik): RPO < 15 dk, RTO < 1 saat — ERP, ödeme sistemleri, müşteri yüzü uygulamalar
- Katman 2 (Önemli): RPO 1-4 saat, RTO 4-8 saat — dahili uygulamalar, e-posta
- Katman 3 (Standart): RPO 24 saat, RTO 24-48 saat — dosya sunucuları, arşiv sistemleri
RPO/RTO Hedefini Kim Belirler?
Bu, IT'nin tek başına karar vereceği bir konu değildir — iş birimleriyle birlikte belirlenmelidir. "Bu uygulama 1 saat çalışmazsa şirkete maliyeti nedir?" sorusunun cevabı, doğru RTO'yu; "Bu uygulamada 4 saatlik veri kaybı kabul edilebilir mi?" sorusunun cevabı doğru RPO'yu belirler.
Backup Mimarinize Etkisi
Belirlenen RPO/RTO hedefleri, doğrudan hangi teknolojiyi seçeceğinizi şekillendirir:
- Düşük RPO hedefi → CDP (Continuous Data Protection) veya sık aralıklı snapshot
- Düşük RTO hedefi → Replikasyon + otomatik failover, ya da Veeam SureBackup gibi sürekli doğrulanmış kurtarma noktaları
- Yüksek RPO/RTO toleransı → Standart günlük backup + manuel restore yeterli olabilir
İmmutable backup gibi güvenlik katmanları RPO/RTO ile doğrudan ilişkili değildir ama ransomware senaryosunda "geri dönülebilir bir nokta var mı" sorusunu garanti eder — bu konuyu Immutable Backup nedir, nasıl test edilir rehberinde detaylı işledik.
Özet
RPO, veri kaybı toleransınızı; RTO, kesinti süresi toleransınızı tanımlar. İkisini karıştırmadan, her uygulama için ayrı ayrı ve iş birimleriyle birlikte belirlemek, hem gereksiz maliyetten kaçınmanızı hem de kritik anda yetersiz kalmamanızı sağlar.
