İş sürekliliği, modern işletmelerin en kritik risklerinden biri haline geldi. Bir yangın, bir ransomware saldırısı veya basit bir DB korruption’ı yüzlerce çalışanın saatlerce iş yapamamasına, milyonlarca TL gelir kaybına ve müşteri güveninin sarsılmasına neden olabilir. Felaket kurtarma (Disaster Recovery), bu risklerin yönetildiği disiplindir — sadece veri yedekleme değil, tam iş süreçlerinin önceden tanımlanmış sürede yeniden çalışır hale getirilmesidir. Bu rehberde RTO/RPO planlaması, DR-tier modeli, gerçek vakalar ve Türkiye’deki düzenleyici gereksinimleri pratik bir şekilde ele alıyoruz.
Felaket kurtarma nedir?
Felaket kurtarma, planlanmamış kesintiler sonrası BT sistemlerinin ve verilerin önceden tanımlanmış süre içinde geri çağrılma sürecidir. Yangın, sel, donanım arızası, siber saldırı, insan hatası — hepsi bir felaket sayılır.
Felaket kurtarma vs yedekleme — fark
Yedekleme sadece veri kopyalamadır. Felaket kurtarma ise verilerin yanı sıra çalışan sistem ortamının geri yüklenmesini içerir: sunucular, ağ konfigürasyonları, kullanıcı yetkileri, uygulama bağımlılıkları. Sadece backup’ınız varsa, felaket sonrası sistemleri yeniden ayağa kaldırmak günler sürebilir. Detaylı backup stratejisi için bulut yedekleme rehberimizi okuyun.
Tipik felaket senaryoları
- Donanım arızası (disk, sunucu, ağ ekipmanı)
- Veri merkezi seviyesinde olay (yangın, deprem, elektrik kesintisi)
- Siber saldırı (ransomware, veri silme, DDoS koruması ile bağlantılı tehditler)
- İnsan hatası (yanlış komut, yanlış tablo silme)
- Yazılım hatası (uygulama bug’ı sonucu veri korruption)
RTO ve RPO: DR planının iki temel metriği
RTO (Recovery Time Objective) nedir?
RTO, felaket anından sistemlerin tekrar çalışır hale gelmesine kadar geçen kabul edilebilir süredir. E-ticaret için RTO genelde 15 dakika - 1 saat; back-office uygulamalar için 4-24 saat olabilir.
RPO (Recovery Point Objective) nedir?
RPO, kabul edilebilir veri kayıp miktarıdır — kaç dakika/saat öncesinin verisine geri dönülebilir. Finans için RPO 0 (zero data loss), CRM için 15 dakika, dosya paylaşımı için 24 saat tipik değerlerdir.
İş kritikliği matrisi ile RTO/RPO belirleme
| Sistem | Kritiklik | RTO | RPO |
|---|---|---|---|
| E-ticaret ön yüz | Çok yüksek | 15 dk | 0 |
| Sipariş veritabanı | Çok yüksek | 30 dk | 5 dk |
| CRM | Yüksek | 2 saat | 15 dk |
| Kurumsal e-posta | Yüksek | 1 saat | 5 dk |
| Raporlama / BI | Orta | 24 saat | 4 saat |
| Test ortamı | Düşük | 72 saat | 24 saat |
Felaket kurtarma seviyeleri (Tier 0-7)
IBM’in tanımladığı standart DR-tier modeli:
Tier 0: planlanmamış kurtarma
Hiç DR planı yok. Felaket olursa sıfırdan başlanır — günler/haftalar sürebilir.
Tier 1-3: yedekleme tabanlı kurtarma
- Tier 1: Off-site tape backup, manuel kurtarma
- Tier 2: Hot site (alternatif veri merkezi) + tape
- Tier 3: Elektronik backup (replikasyon yerine kopyalama)
RTO: saatler-günler. RPO: 24 saate kadar.
Tier 4-6: aktif çoğaltmalı kurtarma
- Tier 4: Point-in-time backup, sık snapshot’lar
- Tier 5: İki yönlü senkron replikasyon (aktif-pasif)
- Tier 6: Sıfır veri kaybı (synchronous replication)
RTO: dakikalar-saatler. RPO: 0 - dakikalar.
Tier 7: gerçek zamanlı yüksek erişilebilirlik
Otomatik failover, sıfır insan müdahalesi, RTO < 1 dakika, RPO 0. Maliyet en yüksek tier; finans, kritik altyapı için kullanılır.
DRaaS (Disaster Recovery as a Service) avantajları
CapEx yerine OpEx
Geleneksel DR ikinci bir veri merkezi, ikinci donanım seti, fiziksel güvenlik ve BT ekibi gerektirir — milyonlarca TL’lik CapEx. DRaaS aylık fatura ile aynı korumayı sağlar.
Otomatik failover ve failback
Sağlayıcı tarafından yönetilen failover ve failback prosedürleri, insan hatasını minimize eder ve test edilebilir hale getirir.
Test edilmiş senaryolar ve drill desteği
Profesyonel DRaaS sağlayıcıları gerçek production’a etki etmeden DR drill’leri yapmanıza olanak tanır — bu, planın gerçekten çalışacağını doğrulamak için en önemli uygulamadır.
Türkiye’de DR planlaması: KVKK ve BDDK gereksinimleri
Finansal kuruluşlar için BDDK DR şartları
BDDK düzenlemelerine göre bankalar ve ödeme kuruluşları RTO < 4 saat, RPO < 15 dakika seviyesinde DR planı bulundurmak zorundadır. Yıllık tatbikat yapma yükümlülüğü vardır.
KVKK’da veri yedekleme zorunluluğu
KVKK, kişisel verilerin kayba ve hasara karşı korunmasını açıkça gerektirir. Yedeksiz veri kaybı durumunda kuruluşun sorumluluğu doğrudan ortaya çıkar.
ISO 22301 iş sürekliliği yönetimi
ISO 22301 sertifikasyonu artan sayıda B2B müşteri için tedarikçi seçim kriteri. Ciddi bir DR planı, sertifikasyon sürecinin temelidir.
Mini case study: Ransomware sonrası 90 dakika
Bir Türk lojistik şirketi 2024’te ransomware saldırısı aldı — production VMware cluster’ı şifrelendi. Cloud4U DRaaS (vCloud Availability) sayesinde:
- İlk algılama (SOC alarm): 04:12
- DR planı tetiklenmesi: 04:18
- Failover işlem süresi: 22 dakika
- Kritik sistemler erişilebilir: 04:40
- Tam operasyon: 05:42 (toplam 90 dakika)
- Veri kaybı: 6 dakika (RPO target 15 dk içinde)
- Fidye ödendi mi?: Hayır
- İş kaybı: ~80.000 TL (vs muhtemel 2-5 milyon TL fidye + iş kaybı)
DR drill yılda 2 kez yapıldığı için ekip prosedürü ezbere biliyordu.
DR planı nasıl yazılır? Adım adım
1. Kritik iş süreçlerinin haritalanması
Tüm iş süreçlerinizi listeleyip kritiklik seviyesine göre sıralayın. Mali yansıma, müşteri etkisi, yasal yükümlülük açısından değerlendirin.
2. RTO/RPO belirleme
Her süreç için RTO/RPO net olarak belirleyin ve C-level onayı alın. Bu, teknik tasarımın temelidir.
3. Teknik mimari ve replikasyon stratejisi
Senkron mu asenkron mu? Hangi veri merkezleri arasında? Bant genişliği yeterli mi? Bu sorular DR mimarisini tanımlar. bulut depolama sistemleri ve bulut yedekleme entegrasyonu temel bileşenler.
4. Failover prosedürleri ve runbook
Adım adım yazılı runbook olmazsa kriz anında ekip kaybolur. Her senaryo için (DB korruption, ransomware, VM kaybı) ayrı runbook hazırlayın.
5. Düzenli test ve drill
Yılda en az iki kez kontrollü drill yapın. Sonuçları belgeleyin, runbook’u güncelleyin.
Yaygın hatalar ve kaçınma yolları
Test edilmemiş DR planı
İstatistiksel olarak hiç test edilmemiş DR planlarının %60’ı gerçek krizde başarısız olur. Düzenli test olmadan DR yatırımı boştur.
Eski runbook ve dökümantasyon
Sistemler değişir, runbook güncellenmezse kriz anında işe yaramaz. Her major release ile DR runbook revize edilmeli.
Sadece backup ile yetinmek
Backup ≠ DR. Backup verinin kopyasıdır; DR ise iş süreçlerinin geri çağrılma planıdır. Sadece backup’ınız varsa, kriz anında günler kaybedersiniz.
Business Impact Analysis (BIA) şablonu
DR planının temeli BIA — hangi sürecin ne kadar kritik olduğunu sayısal olarak belirleyen analiz:
| Süreç | RTO hedef | RPO hedef | Saatlik kayıp | Yıllık risk | Tier |
|---|---|---|---|---|---|
| Sipariş alımı | 15 dk | 0 | 80.000 TL | 4.5M TL | Tier 6 |
| Ödeme entegrasyonu | 30 dk | 0 | 60.000 TL | 3.2M TL | Tier 6 |
| Müşteri panel | 1 saat | 5 dk | 15.000 TL | 800K TL | Tier 5 |
| ERP / muhasebe | 4 saat | 1 saat | 8.000 TL | 400K TL | Tier 4 |
| BI / raporlama | 24 saat | 4 saat | 1.000 TL | 50K TL | Tier 3 |
| Test ortamı | 72 saat | 24 saat | 0 | 0 | Tier 1 |
C-level onayı bu tablodan başlar. Yatırım kararları sayısal temele oturur.
DR runbook örneği — DB korruption senaryosu
Adım adım runbook (sayfa 1, gerçek runbook 5-10 sayfa olur):
SENARYO: Production DB korruption
RTO HEDEF: 30 dakika
RPO HEDEF: 5 dakika
ON-CALL: DBA + DevOps lead
ADIM 1: Doğrulama (0-2 dk)
[ ] mysql client ile bağlanmayı dene
[ ] SHOW ENGINE INNODB STATUS; → corrupted page hata ara
[ ] Application logs → OperationalError artışı
[ ] Karar: Korruption onaylandı? E/H
ADIM 2: Trafiği durdur (2-5 dk)
[ ] Application'ı maintenance mode'a al (load balancer)
[ ] Tüm worker pod'ları durdur (kubectl scale --replicas=0)
[ ] Backup başlat: son state'i kurtarmak için (mysqlbinlog son binlog)
ADIM 3: Failover (5-15 dk)
[ ] Replikadayı promote et: STOP SLAVE; RESET SLAVE ALL;
[ ] Application config DB hostname update
[ ] Read-only test: SELECT yapabiliyor muyuz?
[ ] Write test: küçük bir test transaction
[ ] Onay: Replika master oldu
ADIM 4: Trafiği geri aç (15-25 dk)
[ ] Worker'ları aç (kubectl scale --replicas=N)
[ ] Maintenance mode kapat (load balancer)
[ ] Real-time monitoring (sipariş akışı, error rate)
[ ] Müşteri bilgilendirmesi (status page update)
ADIM 5: Eski master'ı analiz et (25 dk - sonsuz)
[ ] Disk health check
[ ] Backup integrity check
[ ] Eski master'ı yeni replica olarak resync veya replace
[ ] Post-mortem doc başlat
ROLLBACK: Yeni master da problem yaşarsa son backup'a restore.
ESCALATION: 30 dk içinde çözülmezse CTO'ya bildir.Tier’a göre maliyet hesaplaması
DR mimarisi seçimi mali tablo şöyle olur:
| Tier | Yıllık maliyet (orta ölçek) | Beklenen veri kaybı/yıl | RTO ortalama |
|---|---|---|---|
| Tier 0 (yok) | 0 | 5-15 milyon TL | Günler |
| Tier 1 (off-site backup) | 20.000 TL | 800K-2M TL | 24-72 saat |
| Tier 3 (electronic backup) | 80.000 TL | 200-500K TL | 4-12 saat |
| Tier 5 (active replication) | 250.000 TL | 50-150K TL | 30 dk-2 saat |
| Tier 6 (zero data loss) | 600.000 TL | <30K TL | 5-30 dk |
| Tier 7 (auto failover) | 1.5M TL | 0 | <1 dk |
Çoğu orta-büyük işletme Tier 5 veya 6’da konsolide olur. Tier 7 sadece bankalar ve kritik altyapı için.
DR drill kontrol listesi
Yıllık tatbikat için minimum kontrol listesi:
- ☐ Drill öncesi tüm paydaşlara bildirim (1 hafta önce)
- ☐ Sandbox ortamına gerçek production verisi (anonimize)
- ☐ Failover komutlarının hepsini gerçek olarak çalıştır
- ☐ Süreyi ölç: actual RTO/RPO vs hedef
- ☐ Application healthcheck’leri yeşil mi?
- ☐ Application performance hedeflenmiş seviyede mi?
- ☐ Failback prosedürünü de test et
- ☐ Lessons-learned dokümanı yaz
- ☐ Runbook’ları güncelle
- ☐ Sonraki drill tarihini planla (6 ay sonra)
KVKK ve GDPR DR uyumluluğu
Verilerin coğrafi yerleşimine dikkat:
- KVKK: Türk vatandaşı kişisel verisi tercihen Türkiye’de
- GDPR: AB vatandaşı verisi AB veya adequacy decision olan ülkede
- DR replikasyon hedefi de bu kuralları sağlamalı
- Cross-border DR replikasyonu için açık hukuki temel gerekir
- Audit trail: kimin, ne zaman, hangi DR aksiyonunu aldığı loglanmalı
Cloud4U Türkiye Felaket Kurtarma Hizmeti
VMware vCloud Availability ile otomatik failover
Cloud4U Türkiye Felaket Kurtarma hizmeti, VMware vCloud Availability tabanlı otomatik failover ve failback sunar. RTO < 15 dakika, RPO 5-15 dakika aralığında çalışan tier-5/6 koruma standart olarak gelir.
Türkiye veri merkezleri arası replikasyon
İki Türkiye veri merkezimiz arasında senkron veya asenkron replikasyon ile veriler her zaman iki konumda tutulur. KVKK uyumlu, %99.99 SLA garantili. Felaket kurtarma stratejinizi doğrulamak için ücretsiz drill ve mimari değerlendirme talep edebilirsiniz.
