Özet: Felaket Kurtarma Planı (Disaster Recovery Plan, DRP), donanım arızası, siber saldırı, doğal afet veya insan hatası nedeniyle yaşanan kesintilerde kritik BT sistemlerini önceden belirlenmiş RTO ve RPO hedefleri içinde tekrar çalışır hale getirmek için hazırlanan belgelenmiş prosedürler bütünüdür. Plan; teknolojiyi, rolleri, iletişim kanallarını ve adım adım runbook'ları tanımlar.
Ana noktalar:
- DRP, BCP'nin BT alt setidir; yedekleme almak DR planına sahip olmak anlamına gelmez.
- RTO sistemin ne kadar sürede ayağa kalkacağını, RPO ne kadar veri kaybının kabul edilebileceğini tanımlar.
- Fidye yazılımına karşı immutable ve hava-boşluklu (air-gapped) yedek zorunludur.
- BDDK kapsamındaki finansal kurumlar için DR planı, test ve raporlama yasal zorunluluktur.
- Plan yılda en az bir kez tam failover testi, çeyrekte bir parsiyel testle sınanmalıdır.
İstanbul'da bir Çarşamba sabahı veri merkezinde elektrik kesintisi yaşanır; jeneratör devreye girmez ve şirketin tüm operasyonları üç saat boyunca durur. Cuma günü bir fidye yazılımı bordro sistemini şifreler ve geri yüklenebilir tek bir yedeklemenin bir hafta öncesine ait olduğu fark edilir. Bu senaryolar her ay Türkiye'de farklı boyutlarda yaşanmaktadır. ENISA Tehdit Görünümü raporları, fidye yazılımı ve veri merkezi kesintilerinin Avrupa genelinde en kritik siber tehdit kategorileri arasında yer aldığını ortaya koymaktadır. Hazırlıklı olan kurumlar saatler içinde toparlanırken, planı olmayanlar günler, hatta haftalar içinde toparlanabilir, bazıları kapanır.
Bu rehber; BT yöneticileri, risk yönetimi sorumluları, BDDK kapsamındaki finansal kurumların iş sürekliliği ekipleri ve KOBİ sahipleri için hazırlandı. Felaket kurtarma planının (Disaster Recovery Plan, DRP) ne olduğunu, hangi senaryolara karşı koruma sağladığını, kritik metrikler olan RTO ve RPO'yu, plan şablonunu, adım adım yol haritasını, Türkiye'deki yasal gereklilikleri ve plan testini ele alacağız. Hedef; "DR planımız var" diyebileceğiniz değil, bir kriz anında işleyen bir plana sahip olabilmektir.
Felaket kurtarma; teknik bir yedekleme işi değil, organizasyonel bir hazırlık disiplinidir. Doğru kurulduğunda kesinti sürelerini saatlere, hatta dakikalara indirir ve müşteri güvenini korur.
Felaket kurtarma planı nedir?
DR planının amacı
Felaket kurtarma planı; donanım arızası, siber saldırı, doğal afet veya insan hatası nedeniyle yaşanan kesintilerde kritik BT sistemlerini önceden belirlenmiş süre içinde tekrar çalışır hale getirmek için hazırlanan belgelenmiş bir prosedürler bütünüdür. Plan; teknolojiyi, rolleri, iletişim kanallarını ve adım adım yapılacakları tanımlar.
Bir DR planının temel amacı belirsizliği ortadan kaldırmaktır. Kriz anında karar verme yetisi sıkışır; herkes ne yapacağını bilmek ister. Önceden hazırlanmış runbook'lar, iletişim listeleri ve karar matrisleri bu anda hayat kurtarır.
DR planı vs iş sürekliliği planı (BCP) farkı
İş sürekliliği planı (BCP), tüm iş süreçlerinin (insan kaynakları, operasyonlar, tedarik zinciri, müşteri iletişimi) krizde nasıl devam edeceğini ele alır. DR planı ise BCP'nin BT alt setidir; yalnızca teknoloji altyapısı ve verinin kurtarılmasına odaklanır. İkisi birbirini tamamlayıcıdır; DR planı olmadan BCP teknik tarafta eksik kalır, BCP olmadan DR planı kurumsal koordinasyonun dışında çalışır.
DR planı vs backup'ın farkı
Yedekleme, verinin kopyalanmasıdır. DR planı, o kopyalardan üretim sisteminin yeniden ayağa kaldırılmasıdır. Yedekleme alıyor olmak DR planına sahip olmak değildir. Yedekten geri yükleme süresi, donanım sağlanması, ağ yapılandırması, kullanıcı yönlendirmesi ve doğrulama gibi adımlar planlı yönetilmediğinde, elinizde yedek olsa bile sistemin tekrar çalışır hale gelmesi günler sürebilir.
Bir DR planı ne tür afetlere karşı koruma sağlar?
Donanım arızası ve veri merkezi kesintisi
Disk arızası, sunucu çökmesi, ağ ekipmanı sorunu en sık görülen DR tetikleyicileridir. Daha ağır bir senaryo, tüm veri merkezi düzeyinde kesintidir; elektrik, soğutma, fiber kesintisi veya yangın bu kategoriye girer. İkinci bir lokasyona replikasyon ile bu senaryolar yönetilebilir hale gelir.
Siber saldırı ve fidye yazılımı
Fidye yazılımı tehdidi son yıllarda hızla arttı. Türkiye'de KOBİ'ler bu saldırının başlıca hedefi olmaktadır. Aktif sistemleri şifreleyen saldırı, eğer yedekler de aynı ağda erişilebilir durumdaysa yedekleri de kapsayabilir. DR planında immutable yedekler ve hava-boşluklu (air-gapped) kopya zorunludur.
Doğal afet (deprem, sel, yangın)
Türkiye'nin deprem coğrafyasında, ana lokasyon ile DR lokasyonunun farklı fay hatları üzerinde olması önemlidir. İstanbul'daki bir veri merkezi ile Ankara veya Avrupa'da bir DR sitesi tipik bir konfigürasyondur. Sel ve yangın için de fiziksel uzaklık gereklidir.
İnsan kaynaklı hatalar
Yanlış komut çalıştırma, kazara silme, yapılandırma hatası en sık görülen veri kaybı sebepleridir. Point-in-time recovery yetenekleri ve detaylı versiyonlama, bu hatalardan dönüş sağlar. Çoğu DR olayı doğal afetten değil insan hatasından kaynaklanır.
DR planının temel metrikleri: RTO ve RPO
Recovery Time Objective (RTO) nedir?
RTO, bir sistemin felaket sonrası ne kadar süre içinde tekrar çalışır hale gelmesi gerektiğini belirten süredir. RTO 4 saat ise sistemin dört saat içinde ayakta olması taahhüt edilir. RTO ne kadar kısa olursa, gereken yatırım o kadar büyük olur.
Recovery Point Objective (RPO) nedir?
RPO, ne kadarlık veri kaybının kabul edilebilir olduğunu belirtir. RPO 15 dakika ise, felaket anında son 15 dakikalık verinin kaybı tolere edilebilir demektir. Senkron replikasyon RPO'yu sıfıra yaklaştırır; günlük yedekleme RPO'yu 24 saate çıkarır.
Sistem tipine göre RTO/RPO örnekleri (kritik ERP, web sitesi, e-posta)
| Sistem | Kritiklik | Tipik RTO | Tipik RPO |
|---|---|---|---|
| Bankacılık core | Çok yüksek | < 15 dk | < 1 dk |
| ERP (1C, SAP) | Yüksek | 1-4 saat | 15 dk |
| E-ticaret web sitesi | Yüksek | 30 dk - 2 saat | 5 dk |
| Kurumsal e-posta | Orta-yüksek | 2-4 saat | 1 saat |
| İç dosya paylaşımı | Orta | 4-8 saat | 4 saat |
| Test/dev ortamları | Düşük | 24 saat | 24 saat |
Bir DR planı hangi bölümlerden oluşur? (Şablon)
1. Yönetici özeti ve plan sahipliği
Planın ne amaçla hazırlandığını, kapsamını ve sorumlularını tanımlayan giriş bölümü. Plan sahibi (genellikle BT Direktörü veya CISO), yedek sorumlu, onaylayan üst yönetici belirtilir.
2. Risk analizi ve iş etki analizi (BIA)
Olası tehditler (siber, doğal, donanım, insan) ve bunların iş üzerindeki etkisi değerlendirilir. Her sistemin saatlik, günlük ve haftalık kesinti maliyeti hesaplanır; bu rakamlar RTO/RPO kararlarını yönlendirir.
3. Kritik sistemlerin envanteri ve sınıflandırması
Tüm üretim sistemleri listelenir ve kritiklik seviyesine göre sınıflandırılır (Tier 1, Tier 2, Tier 3). Her sistem için bağımlılıklar (veritabanı, ağ, kimlik doğrulama) belgelenir.
4. RTO/RPO hedefleri (sistem bazında tablo)
Her sistem için belirlenmiş RTO ve RPO değerleri bir tabloda toplanır. Bu tablo, teknoloji seçimini ve sözleşme şartlarını doğrudan etkiler.
5. Kurtarma stratejisi ve teknoloji seçimleri (DRaaS, replikasyon, soğuk site)
Her sistem için kurtarma stratejisi seçilir: senkron veya asenkron replikasyon, DRaaS (Disaster Recovery as a Service), pilot light, warm standby, hot standby veya yedekten geri yükleme. Stratejinin RTO/RPO hedefini karşıladığı doğrulanır.
6. Roller, sorumluluklar ve iletişim listesi
Kim ne yapacak? Olay komutanı, teknik koordinatör, iletişim sorumlusu, müşteri/medya iletişimi, üst yönetim bilgilendirmesi rollerinin sahipleri ve telefonları belgelenir. Yedek personel de tanımlanır.
7. Runbook (adım adım operasyonel prosedürler)
Her senaryo için adım adım yapılacaklar (failover komutları, DNS değişikliği, kullanıcı bildirimi, doğrulama testleri) belgelenir. Runbook, sistemi hiç bilmeyen bir teknik personelin de takip edebileceği netlikte olmalıdır.
8. Test planı ve sıklığı
Plan en az yılda bir tam test, çeyrekte bir parsiyel test ile sınanmalıdır. Test türü, kapsamı, başarı kriterleri ve dokümantasyonu tanımlanır.
9. Versiyon yönetimi ve düzenli güncelleme
Plan canlı bir belgedir. Sistem değişiklikleri, personel değişiklikleri, yeni tehditler nedeniyle düzenli güncellenir. Versiyon kontrolü ve değişiklik geçmişi tutulur.
DR planı hazırlamak için 10 adımlık yol haritası
Adım 1: İş etki analizi (BIA) yapın
Her iş süreci için kesintinin saatlik, günlük ve haftalık maliyetini hesaplayın. Müşteri kaybı, regülatif ceza, itibar zararı, operasyonel maliyet kalemlerini içerin. Bu çalışma planın geri kalanının temel girdisidir.
Adım 2: Kritiklik seviyelerini belirleyin
Sistemleri Tier 1 (kritik), Tier 2 (önemli), Tier 3 (destekleyici) olarak sınıflandırın. Tier 1 sistemler için yüksek yatırımlı çözümler haklıyken Tier 3 için daha ekonomik yaklaşımlar uygundur.
Adım 3: RTO/RPO hedeflerini tanımlayın
Her sistem için RTO ve RPO değerlerini belirleyin. Yönetim onayı şarttır; çünkü bu değerler doğrudan bütçeyi belirler.
Adım 4: Mevcut altyapıyı değerlendirin
Bugünkü yedekleme, replikasyon ve felaket kurtarma yetenekleri hedeflerin neresinde? Eksiklikler net biçimde belgelenir. Çoğu kurum bu adımda kritik açıklarla yüzleşir.
Adım 5: Teknoloji ve sağlayıcı seçin
Boşlukları kapatacak teknoloji seçilir. Hot standby için DRaaS, warm için periyodik replikasyon, cold için yedekten geri yükleme tipik seçimlerdir. Sağlayıcı seçiminde SLA, lokasyon, KVKK uyumu ve maliyet değerlendirilir. Türkiye lokasyonlu sağlayıcılar yasal süreçleri basitleştirir.
Adım 6: Runbook'u yazın
Her senaryo için adım adım operasyonel prosedürleri belgeleyin. Komutlar, ekran görüntüleri, kontrol listeleri ile destekleyin. Runbook gece yarısı uykudan kaldırılan bir teknisyenin de takip edebileceği netlikte olmalıdır.
Adım 7: Eğitim verin
Plan rollerine atanmış tüm personel eğitilir. Sistem operatörleri runbook'a, iletişim ekibi mesaj şablonlarına, üst yönetim eskalasyon süreçlerine hâkim hale getirilir.
Adım 8: İlk testi yapın
Tabletop testi (masa üstü simülasyon) ile başlayın; rolleri kim üstlenir, hangi kararları verir, hangi sırada hareket eder konuşulur. Eksiklik ve belirsizlikler not edilir.
Adım 9: Sonuçları değerlendirin ve düzeltin
Test sonrası retrospektif yapın. Hangi adım beklenenden uzun sürdü? Hangi runbook adımı net değildi? Hangi rolü kimse üstlenmedi? Bu girdilerle plan güncellenir.
Adım 10: Düzenli test ve güncelleme döngüsü
Yılda bir tam failover testi, çeyrekte bir parsiyel test rutin haline getirilir. Yeni sistem eklendiğinde, kritik personel değiştiğinde plan güncellenir.
DR planı için yasal ve sektörel gereklilikler (Türkiye)
KVKK ve veri sahibi haklarının korunması
KVKK kapsamında veri sorumlusu, kişisel verilerin korunması için her türlü teknik ve idari tedbiri almakla yükümlüdür. Bir felaket sonrası verilerin geri yüklenmesi de bu yükümlülüğün parçasıdır. DR planı bu yükümlülüğün kanıtı olarak denetimlerde sunulur.
BDDK kılavuzu (finansal kurumlar)
BDDK'nın "Bilgi Sistemleri Yönetimi" ve "Bilgi Sistemleri Bağımsız Denetimi" tebliğleri, finansal kurumların DR planına sahip olmasını, düzenli test etmesini ve raporlamasını şart koşar. RTO/RPO hedefleri, ikincil veri merkezi ve test sıklığı belgeli olmalıdır.
ISO 22301 iş sürekliliği standardı
ISO 22301, iş sürekliliği yönetim sistemi için uluslararası standarttır. Sertifikasyon almak isteyen kurumlar için yapılandırılmış bir çerçeve sunar; tedarik zincirinde uluslararası müşterilerle çalışan firmalar için artı bir kalite belgesidir.
DR planı testi nasıl yapılır?
Tabletop test (masa üstü senaryo)
Senaryo (örneğin ana veri merkezinde elektrik kesintisi) sözle anlatılır; ekip planı izleyerek "şu an ne yapardım?" sorusuna yanıt verir. Düşük maliyetli, eksiklikleri ortaya çıkaran ilk adımdır.
Parsiyel test (tek sistem)
Belirli bir sistemin failover'ı gerçekten yapılır. Üretim trafiği etkilenmeden DR ortamı doğrulanır. Çeyrekte bir tekrarlanması önerilir.
Tam failover testi
Tüm sistemler DR sitesine yönlendirilir; bir süre orada çalıştırılır, geri dönüş yapılır. Yılda en az bir kez yapılması önerilir. Üretim etkisi olabileceğinden hafta sonu veya planlı bakım penceresinde yapılır.
Sıkça sorulan sorular
DR planı kim hazırlamalı?
DR planının birincil sahibi BT Direktörü veya CISO'dur; plan hazırlığı sistem yöneticileri, ağ ekibi, veritabanı yöneticileri, güvenlik ekibi ve iş birimi temsilcilerinin katkısıyla yürütülür. Üst yönetim onayı ve bütçe taahhüdü şarttır; çünkü RTO/RPO hedefleri doğrudan altyapı yatırımını belirler.
Plan ne sıklıkla güncellenmeli?
En az yılda bir kapsamlı revizyon yapılmalı, her büyük altyapı değişikliği veya kritik personel değişimi sonrasında ilgili bölümler güncellenmelidir. Test sonrası ortaya çıkan iyileştirmeler her zaman plana yansıtılır; plan canlı bir belgedir, statik bir doküman değildir.
KOBİ için DR planı zorunlu mu?
Yasal olarak BDDK kapsamı dışındaki KOBİ'ler için kapsamlı bir DR planı zorunlu değildir; ancak KVKK kişisel veriyi koruma yükümlülüğü kapsamında temel önlem alma sorumluluğu doğurur. Pratikte; DR planı olmayan bir KOBİ ciddi bir kesintide veya saldırıda kapanma riskiyle yüzleşir, bu nedenle ölçek küçük olsa da minimum bir DR planı önerilir.
Cloud4U Türkiye Felaket Kurtarma (DRaaS) ile planınızı uygulamaya geçirin
DR planınızı kâğıt üzerinde hazırlamak iyi bir başlangıçtır; ancak gerçek koruma planın çalışan teknoloji altyapısıyla desteklenmesinden gelir. Cloud4U Türkiye Disaster Recovery as a Service, planınızı uygulamaya geçirir.
Türkiye ve Avrupa veri merkezleri arası replikasyon
Birincil sisteminiz İstanbul veri merkezimizde çalışırken, replikası farklı bir lokasyonda (Türkiye'de veya Avrupa'da) sürekli güncel tutulur. Coğrafi izolasyon ile deprem, yangın gibi lokal afetlere karşı koruma sağlanır.
Düşük RTO/RPO, otomatik failover testi
- RPO 15 dakikanın altına kadar inebilen senkron ve asenkron replikasyon seçenekleri
- 15 dakika ile 4 saat arasında RTO seçenekleri
- Otomatik failover testleri ile planın gerçekten çalıştığı düzenli doğrulanır
- 7/24 Türkçe konuşan DR operasyon ekibi
Demo ve fiyat teklifi
Sistemlerinizin envanteri, RTO/RPO hedefleriniz ve mevcut altyapınıza özel ücretsiz DR değerlendirmesi sunuyoruz. Pilot uygulama ile bir sistem üzerinde DRaaS'ı gerçek koşullarda deneyimleyebilirsiniz.
Detaylı DR yapılandırma seçenekleri ve demo talebi için Cloud4U Türkiye Disaster Recovery sayfasını ziyaret edin ve felaket kurtarma planınızı bu çeyrekte hayata geçirin.
