Felaket Kurtarma Planı Nasıl Hazırlanır? RTO ve RPO Rehberi
Felaket kurtarma planı (DRP), bir kesinti veya veri kaybı sonrasında kritik BT sistemlerinin hangi sırayla, kim tarafından ve ne kadar sürede yeniden çalıştırılacağını tanımlayan yazılı plandır. Planın iki temel ölçütü RTO (kabul edilen azami kesinti süresi) ile RPO'dur (kabul edilen azami veri kaybı). Bu değerler iş etki analiziyle belirlenir ve düzenli testlerle doğrulanır.
Felaket kurtarma planı (DRP) nedir ve iş sürekliliğinden farkı nedir?
Felaket kurtarma planı (Disaster Recovery Plan, DRP), kesinti veya veri kaybı sonrasında kritik BT sistemlerinin hangi sırayla, kim tarafından ve hangi adımlarla yeniden çalıştırılacağını anlatan yazılı plandır. İş sürekliliği planı (BCP) ise insanı, tesisi ve tedarikçileri de içeren tüm iş süreçlerini kapsar; DRP bunun BT ayağıdır.
Felaket denince doğal afetler akla gelir, ancak pratikte donanım arızası, elektrik kesintisi, insan hatası, yazılım hatası ve fidye yazılımı gibi olaylar çok daha sık yaşanır. İyi bir plan tek bir senaryoya değil, ‘sistem kullanılamıyor’ durumuna göre yazılır.
Plan genellikle şu bölümlerden oluşur: kapsam ve sorumlular, sistem envanteri, RTO ve RPO hedefleri, adım adım kurtarma prosedürleri, iletişim listesi ve test geçmişi. Bunların hepsi, kesinti anında kimsenin hafızasına ya da tek bir kişiye bağımlı kalmayacak biçimde yazılı tutulmalıdır.
RTO ve RPO nedir, aralarındaki fark nedir?
RTO (Recovery Time Objective), bir sistemin kesinti sonrası yeniden hizmet vermesi için kabul edilen azami süredir. RPO (Recovery Point Objective) ise kabul edilebilir azami veri kaybıdır; yani son kullanılabilir yedeğin veya replikasyon noktasının felaket anından en fazla ne kadar geride olabileceğini söyler. RTO zamanı, RPO veriyi ölçer.
Örneğin RTO 4 saat ve RPO 15 dakika olan bir sistem, en geç 4 saatte yeniden çalışmalı ve en fazla son 15 dakikalık işlemi kaybetmelidir. Gecelik yedek alan bir sistemde ise RPO fiilen 24 saattir; çünkü felaket yedekten hemen önce yaşanırsa bir günlük veri gider.
RTO yalnızca teknik geri yükleme süresi değildir; kesintinin fark edilmesi, karar verilmesi, ekibin toplanması, erişimin sağlanması ve sonucun doğrulanması da bu süreye dahildir. Planlarda sık yapılan hata, yalnızca verinin kopyalanma süresini hesaba katıp bu insan ve koordinasyon süresini unutmaktır.
| Sistem | Örnek RTO | Örnek RPO | Tipik yaklaşım |
|---|---|---|---|
| Sipariş veritabanı | 1 saat | Birkaç dakika | Sürekli replikasyon, sıcak site |
| ERP ve muhasebe uygulaması | 4 saat | 1 saat | Sık yedekleme ve replikasyon, ılık site |
| Dosya sunucusu | 24 saat | 24 saat | Gecelik yedekleme |
| Arşiv ve test ortamları | 72 saat | 1 hafta | Haftalık yedek, soğuk site |
İş etki analizi nedir ve sistemler kritiklik sırasına nasıl konur?
İş etki analizi (BIA), her iş sürecinin ve onu destekleyen sistemin durmasının işletmeye maliyetini ortaya koyan çalışmadır. Gelir kaybı, yasal yükümlülükler, müşteri etkisi ve itibar gibi etkiler zamana göre değerlendirilir; her sistem için RTO ve RPO bu analizden çıkar. Sonuç genellikle birkaç kritiklik sınıfı olur:
- Seviye 1, kritik: Dakikalar ile birkaç saat arası kesinti tolere edilir; ödeme, sipariş ve ana veritabanı sistemleri.
- Seviye 2, önemli: Birkaç saat ile bir gün arası; ERP, muhasebe ve müşteri ilişkileri uygulamaları.
- Seviye 3, standart: Bir ile üç gün arası; dosya sunucuları ve iç araçlar.
- Seviye 4, ertelenebilir: Bir haftaya kadar; arşiv, test ve geliştirme ortamları.
Sınıflandırmayı sade tutun; beş seviyeyi aşan karmaşık şemalar uygulamada işlemez. Analizi yalnızca BT ile değil, iş birimleriyle birlikte yapın; bir sürecin ne kadar kritik olduğunu en iyi o süreci yürüten ekip bilir. Çıktıyı yönetimin onayına sunmak, hedeflerin bütçeyle uyumlu olmasını sağlar.
Bağımlılıkları unutmayın: kritik bir uygulama, kimlik doğrulama, DNS, ağ ve veritabanı olmadan çalışmaz. Bu bileşenler en az uygulama kadar yüksek seviyede planlanmalı ve kurtarma sırasında önce ayağa kaldırılmalıdır.
Sıcak, ılık ve soğuk site arasındaki fark nedir?
Kurtarma sitesi, birincil lokasyon kullanılamadığında işlerin devam ettiği ikinci lokasyondur. Ne kadar hazır tutulduğuna göre üç türe ayrılır:
| Site türü | Durumu | Tipik kurtarma süresi | Maliyet |
|---|---|---|---|
| Sıcak site | Sistemler ikinci lokasyonda çalışır durumdadır, veri sürekli replike edilir | Dakikalar ile birkaç saat | En yüksek |
| Ilık site | Altyapı ve ana sistemler kuruludur, veri periyodik senkronize edilir; devreye almak için hazırlık gerekir | Birkaç saat ile bir gün | Orta |
| Soğuk site | Alan, güç ve ağ hazırdır; sistemler ve veri kesinti sonrası kurulur ve geri yüklenir | Günler | En düşük |
Siteler arası veri aktarımında iki yöntem öne çıkar. Eşzamanlı (senkron) replikasyon her yazma işlemini iki lokasyonda onaylar ve RPO'yu sıfıra yaklaştırır, ancak gecikmeye duyarlıdır ve bu nedenle mesafe sınırlıdır. Eşzamansız replikasyon küçük bir gecikmeyle çalışır ve uzak lokasyonlar için uygundur, fakat RPO sıfır olmaz.
Seçim RTO ve RPO değerlerine bağlıdır: RTO'su dakikalar ya da birkaç saat olan sistemler sıcak, günlerle ölçülebilen sistemler soğuk site ile uyumludur. Birçok işletme karma yaklaşım uygular; kritik sistemler sıcak veya ılık, geri kalanlar soğuk sitede tutulur. Kurtarma sitesinin birincil lokasyondan farklı bir şehirde ve bağımsız altyapıda olması, aynı olaydan birlikte etkilenme riskini azaltır.
Felaket kurtarma planı için adım adım kontrol listesi nedir?
- Kapsamı, plan sahibini ve yedek sorumluları belirleyin; iletişim zincirini (kim kimi arar) yazın.
- İş etki analizini yapın ve riskleri listeleyin: elektrik, ağ, donanım, siber saldırı, yangın ve afet.
- Sistemleri kritiklik sırasına dizin ve her biri için RTO ile RPO atayın.
- Kurtarma stratejisini seçin: yedekleme, replikasyon ve sıcak, ılık ya da soğuk site kombinasyonu.
- Kurtarma prosedürlerini adım adım yazın: erişim bilgileri, bağımlılık sırası ve geri dönüş (failback) adımları dahil.
- Yedekleme ve replikasyonu kurun, çalıştığını izleyin; bir kopyayı 3-2-1 kuralına uygun biçimde farklı lokasyonda tutun.
- Planı test edin: önce masa başı tatbikatı, sonra kısmi geri yükleme, en sonunda tam geçiş (failover) testi.
- Sonuçları kaydedin, aksayan yerleri düzeltin; planı altyapı, uygulama veya kadro değiştiğinde ve en az yılda bir güncelleyin.
Plan kâğıt üzerinde bırakılırsa değer taşımaz. Testte ölçülen gerçek kurtarma süresi RTO'dan uzunsa ya hedef ya da strateji değişmelidir. Planın basılı ya da çevrimdışı bir kopyasını da saklayın; çünkü plana ulaşmak için ihtiyaç duyduğunuz sistem çökmüş olabilir. Her tatbikatın sonunda üç soruyu yanıtlayın: ne planlandığı gibi çalıştı, ne çalışmadı ve bir sonraki testte neyi değiştireceğiz? Bu kayıtlar planın en değerli girdisidir.
Dcloud'da İstanbul-Ankara felaketten kurtarma senaryosu nasıl işler?
Dcloud, İstanbul Avrupa, İstanbul Anadolu ve Ankara'daki Tier 3 seviyesinde veri merkezleriyle hizmet verir. İstanbul'daki iki veri merkezi 10 Gbps fiber kablo altyapısıyla yedekli şekilde birbirine bağlıdır. Ankara FKM (Felaket Kurtarma Merkezi) 2013'ten beri Tier 3 seviyesinde hizmet verir ve coğrafi yedekleme, felaketten kurtarma ve iş sürekliliği çözümleri sunar.
İstanbul ve Ankara veri merkezleriyle tam entegre bir felaketten kurtarma senaryosu kurulur; böylece İstanbul'daki lokasyonları etkileyen bir olaya karşı farklı bir şehirde kurtarma merkezi bulunur. Hangi sistemin hangi RTO ve RPO değerleriyle korunacağı, iş etki analizinize göre belirlenir. Yedekleme tarafı için veri yedekleme ve kurtarma hizmetini, bu merkezlerin Tier seviyesinin anlamı için Tier 3 veri merkezi rehberini, lokasyon bilgisi için altyapı sayfasını inceleyebilirsiniz.
Sıkça Sorulan Sorular
Altyapınızı birlikte planlayalım
Bulut sunucu, yedekleme ve güvenlik ihtiyaçlarınız için uzman ekibimizle görüşün.
İlgili Yazılar ve Hizmetler
Yayın tarihi: 2 Ekim 2026. Son güncelleme: 2 Ekim 2026.
