Disaster Recovery ve İş Sürekliliği: Farklar, RTO/RPO ve Kurumsal Rehber 2026

Sunucunuz çöktü. Fidye yazılımı tüm verilerinizi şifreledi. Veri merkezinizde yangın çıktı. Bu senaryolardan biri gerçekleştiğinde işletmeniz ne kadar süre içinde normale döner? Hangi veriler geri gelir, hangileri sonsuza dek kaybolur?

Bu soruların cevabı iki kritik kavrama bağlıdır: Disaster Recovery (Felaket Kurtarma) ve İş Sürekliliği (Business Continuity). Çoğunlukla birbirinin yerine kullanılan bu iki kavram aslında farklı problemlere farklı çözümler sunar — ve ikisini de anlamadan gerçek bir koruma planı oluşturulamaz.

Disaster Recovery (DR) Nedir?

Disaster Recovery (Felaket Kurtarma); siber saldırı, donanım arızası, doğal afet veya insan hatası gibi yıkıcı bir olayın ardından kurumun BT altyapısını, sistemlerini ve verilerini önceden tanımlanmış hedefler doğrultusunda geri yüklemeyi amaçlayan kapsamlı bir strateji ve süreçler bütünüdür.

DR planı şu soruları yanıtlar: Sistemler çöktüğünde kim ne yapacak? Veriler nereden geri yüklenecek? Kritik sistemler ne kadar sürede ayağa kaldırılacak?

İş Sürekliliği (Business Continuity — BC) Nedir?

İş Sürekliliği; olağanüstü bir durum sırasında ve sonrasında kurumun temel iş fonksiyonlarının kesintisiz veya minimum aksaklıkla sürdürülmesini sağlamaya yönelik proaktif bir strateji ve planlar bütünüdür.

BC planı şu soruları yanıtlar: Sistemler çalışmıyorken iş nasıl sürdürülür? Müşterilerle iletişim nasıl sağlanır? Çalışanlar alternatif ortamda çalışmaya nasıl devam eder?

Disaster Recovery ile İş Sürekliliği Arasındaki 5 Temel Fark

Fark 1 — Odak ve Kapsam

Disaster Recovery: BT altyapısına odaklanır. Sunucular, veri tabanları, ağ sistemleri ve uygulamaların teknik olarak geri yüklenmesi DR’ın birincil hedefidir.

İş Sürekliliği: Tüm iş operasyonlarını kapsar. BT’nin yanı sıra insan kaynakları, tedarik zinciri, müşteri iletişimi, fiziksel tesis ve iş süreçlerinin sürekliliği BC’nin kapsamına girer.

Fark 2 — Zaman Çerçevesi

Disaster Recovery: Anlık ve kısa vadeli müdahaleye odaklanır. Sistemler çöktükten sonra ne kadar hızlı geri döneceğinizi tanımlar.

İş Sürekliliği: Uzun vadeli sürekliliği hedefler. Bir felaket birkaç gün, hafta veya ay sürebilir — BC bu süre boyunca işin nasıl yürüyeceğini planlar.

Fark 3 — Tetikleyici

Disaster Recovery: Genellikle belirli teknik olaylar tarafından tetiklenir: sunucu çökmesi, fidye yazılımı saldırısı, veri merkezi arızası, veri bozulması.

İş Sürekliliği: Daha geniş kapsamlı durumları içerir: pandemi, kilit personelin ani ayrılışı, tedarikçi iflası, yangın, sel, uzun süreli elektrik kesintisi.

Fark 4 — Bileşenler

Disaster Recovery: Yedekleme sistemleri, replikasyon, failover mekanizmaları, kurtarma prosedürleri ve teknik test süreçleri.

İş Sürekliliği: Kriz iletişim planı, alternatif çalışma lokasyonları, manuel iş süreçleri, tedarikçi yedekleme anlaşmaları, müşteri bildirim prosedürleri.

Fark 5 — Başarı Ölçütleri

Disaster Recovery: RTO (Kurtarma Süresi Hedefi) ve RPO (Kurtarma Noktası Hedefi) metrikleriyle ölçülür.

İş Sürekliliği: İş sürekliliği egzersizleri, simülasyonlar ve kritik iş fonksiyonlarının tanımlanmış SLA’lar dahilinde sürdürülmesiyle değerlendirilir.

RTO ve RPO Nedir? Neden Bu Kadar Kritik?

Bu iki metrik, DR planınızın teknik temelini oluşturur. Yanlış belirlenen RTO/RPO değerleri hem aşırı harcamaya hem de yetersiz korumaya yol açar.

RTO — Recovery Time Objective (Kurtarma Süresi Hedefi)

“Sistemler ne kadar sürede geri dönmeli?”

RTO, bir felaket sonrasında sistemlerin kabul edilebilir işlevsellik düzeyine geri dönmesi için belirlenen maksimum süredir.

Örneğin: RTO = 4 saat ise, sistem arızasından itibaren 4 saat içinde sistemlerin çalışır hale gelmesi hedeflenir.

RTO’yu belirleyen faktörler:

• Her saatlik kesintinin iş operasyonlarına maliyeti
• Müşteri ve SLA taahhütleri
• Yasal ve düzenleyici gereklilikler
• Kritik iş süreçlerine bağımlılık

RPO — Recovery Point Objective (Kurtarma Noktası Hedefi)

“Ne kadar veri kaybını göze alabiliriz?”

RPO, felaket anından geriye dönük olarak kabul edilebilir maksimum veri kaybı miktarıdır.

Örneğin: RPO = 1 saat ise, sistem en fazla son 1 saatlik veriyi kaybedebilir. Bu, en az saatlik yedekleme yapılması gerektiği anlamına gelir.

RPO’yu belirleyen faktörler:

• Veri değişim hızı ve hacmi
• Veri kaybının iş operasyonlarına etkisi
• Yedekleme altyapısı maliyeti
• Sektörel uyumluluk gereksinimleri

RTO ve RPO İlişkisi

RTO ve RPO değerleri düştükçe — yani koruma arttıkça — altyapı maliyeti de artar. Doğru denge, iş gereksinimlerine göre belirlenir.

DR ve BC Birbirini Nasıl Tamamlar?

Disaster Recovery ve İş Sürekliliği ayrı planlar değil, birbirini tamamlayan bir bütünün parçalarıdır.

Bir fidye yazılımı saldırısı senaryosunu ele alalım:

DR devreye girer: Sistemler izole edilir, temiz yedeklerden geri yükleme yapılır, RTO hedefi dahilinde kritik sistemler ayağa kaldırılır.

BC devreye girer: Sistemler geri yüklenirken müşteriler bilgilendirilir, kritik işlemler manuel olarak sürdürülür, tedarikçilerle iletişim kurulur, çalışanlar alternatif süreçler üzerinden çalışmaya devam eder.

DR olmadan BC zayıf kalır; BC olmadan DR eksik kalır. İkisi birlikte kurumun gerçek anlamda dirençli olmasını sağlar.

Etkili Bir DR Planı Nasıl Oluşturulur?

1. İş Etkisi Analizi (BIA)

Hangi sistemler ve veriler kritik? Her sistemin çökmesinin saatlik maliyeti ne? Bu analiz olmadan RTO/RPO hedefleri doğru belirlenemez.

2. Risk Değerlendirmesi

Kurumunuzu tehdit eden olası felaket senaryolarını belirleyin: donanım arızası, fidye yazılımı, doğal afet, insan hatası, tedarikçi kesintisi. Her senaryonun olasılığı ve etkisi ölçülür.

3. Kurtarma Stratejisi Seçimi

Kurtarma stratejileri maliyet ve hız açısından farklılaşır:

Cold Standby: Yedek sistemler hazır ama aktif değil. En düşük maliyet, en yüksek RTO (saatler/günler).

Warm Standby: Yedek sistemler hazır ve güncel, ancak aktif trafik almıyor. Orta maliyet, orta RTO (saatler).

Hot Standby: Yedek sistemler aktif, anlık trafik alıyor, failover saniyeler içinde gerçekleşir. En yüksek maliyet, en düşük RTO.

Bulut Tabanlı DR: Fiziksel ikincil lokasyon yerine bulut altyapısı kullanılır. Esneklik yüksek, başlangıç maliyeti düşük.

4. Yedekleme Stratejisi

Etkili bir yedekleme stratejisi 3-2-1 kuralını izler:

• 3 kopya veri
• 2 farklı ortam/medya türü
• 1 kopya coğrafi olarak uzak konumda (off-site veya bulut)

5. Test ve Tatbikat

Bir DR planının değeri, gerçek bir felaket anında test edilir. Ama o ana kadar beklemek yerine düzenli tatbikat yapmak şarttır. Yılda en az bir kez tam kapsamlı DR testi, aylık kısmi testler ve sürekli yedekleme doğrulama önerilir.

6. Dokümantasyon ve Rol Tanımları

Felaket anında “şimdi ne yapacağız?” sorusunu sormamak için rol ve sorumluluklar, iletişim ağaçları ve adım adım prosedürler önceden belgelenmiş olmalıdır.

İş Sürekliliği Planı (BCP) Nasıl Hazırlanır?

Kritik İş Fonksiyonlarını Belirleyin

Her departmanın hangi süreçleri kritik olduğunu ve bu süreçlerin maksimum ne kadar kesinti kaldırabileceğini (MTPD — Maximum Tolerable Period of Disruption) tanımlayın.

Alternatif Çalışma Yöntemleri Geliştirin

Sistemler çalışmıyorken hangi işlemler manuel olarak sürdürülebilir? Uzaktan çalışma nasıl organize edilir? Yedek tedarikçi anlaşmaları yapıldı mı?

Kriz İletişim Planı Oluşturun

Felaket anında müşteriler, tedarikçiler, çalışanlar ve kamuoyu nasıl bilgilendirilecek? Sözcü kim? Hangi kanallar kullanılacak? Mesaj ne olacak?

Simülasyon ve Tatbikatlar

BC planı teoride değil uygulamada test edilmelidir. Masa başı tatbikatlar (tabletop exercises) ve saha simülasyonları planın gerçekçiliğini doğrular.

2026’da DR ve BC’yi Zorlaştıran Yeni Tehditler

Fidye Yazılımı

Son 5 yılda fidye yazılımı saldırılarının kurbanı olan işletmelerin sayısı büyük ölçüde arttı. Modern fidye yazılımları artık yedekleme sistemlerini de hedef alıyor — bu nedenle yedeklerin ayrı, izole ve şifreli tutulması kritik önem taşıyor.

Tedarik Zinciri Saldırıları

Kullandığınız bir yazılımın veya tedarikçinin ele geçirilmesi, tüm ağınıza sıçrayabilir. BC planınız tedarikçi kaynaklı kesintileri de kapsamalıdır.

Yapay Zeka Destekli Saldırılar

Daha hızlı, daha uyarlanabilir saldırılar daha kısa RTO hedefleri gerektiriyor. 2026 itibarıyla kurumların “ne zaman saldırıya uğrayacağım?” değil, “saldırı geldiğinde ne kadar sürede toparlanabilirim?” sorusunu sorması gerekiyor.

KVKK ve Yasal Uyumluluk Açısından DR

Türkiye’de 6698 sayılı KVKK kapsamında işletmeler, kişisel verilerin güvenliğini sağlamak için teknik önlemler almakla yükümlüdür. Bu yükümlülük doğrudan yedekleme ve felaket kurtarma stratejisini etkiler:

• Kişisel veri içeren yedeklerin şifreli tutulması
• Yedeklere erişimin sınırlandırılması ve kayıt altına alınması
• Veri ihlali durumunda 72 saat içinde bildirim yapılabilmesi için gerekli altyapının hazır olması

Bunun yanı sıra BDDK denetimindeki finansal kurumlar ve sağlık sektörü için sektörel DR gereksinimleri çok daha katıdır.

DR ve BC Planınızı Değerlendirmek İçin 5 Soru

1. Son ne zaman DR testinizi yaptınız? Hiç test edilmemiş bir plan, plan değildir.
2. RTO ve RPO hedeflerinizi biliyor musunuz? “Mümkün olduğunca hızlı” bir hedef değildir.
3. Yedekleriniz off-site veya bulutta mı? Aynı lokasyondaki yedekler fidye yazılımından sizi korumaz.
4. Kriz iletişim planınız var mı? Felaket anında kim kimi arar, ne söyler?
5. Son 12 ayda planınızı güncellediniz mi? Sistemler, ekipler ve tehditler değişir; planın da değişmesi gerekir.

MBR Teknoloji Veri ve İş Sürekliliği Çözümleri

MBR Teknoloji olarak işletmenizin kritik verilerini ve operasyonlarını her türlü felaket senaryosuna karşı koruyan uçtan uca çözümler sunuyoruz.

Hizmet kapsamımız:

• İş Etkisi Analizi (BIA) ve risk değerlendirmesi
• RTO/RPO hedef belirleme ve optimizasyon
• Yedekleme altyapısı tasarımı ve kurulumu (3-2-1 modeli)
• Hot/Warm/Cold standby DR mimarisi
• Bulut tabanlı felaket kurtarma
• DR test ve tatbikat yönetimi
• İş sürekliliği planı hazırlama
• KVKK uyumlu veri koruma stratejisi

Veri ve İş Sürekliliği Çözümlerimizi inceleyin →