- 01Disaster recovery yalnızca yedekleme değildir; iş etkisi, RPO/RTO, dependency order, recovery environment, test ve failback süreçlerini birlikte kapsar.
- 02RPO kabul edilebilir veri kaybı penceresini, RTO ise sistemin kabul edilebilir kesinti süresini ifade eder ve ikisi de iş hedeflerinden türetilmelidir.
- 03NIST contingency planning yaklaşımı iş etkisi analizi, recovery strategy, plan geliştirme, test/exercise ve plan bakımını birlikte ele alır.
- 04Backup/restore, pilot light, warm standby ve active-active farklı RPO/RTO ve maliyet profillerine sahiptir; tek bir DR modeli tüm workload'lar için uygun değildir.
- 05DR test sıklığı evrensel bir aylık veya yıllık kurala göre değil, sistem kritikliği, değişiklik hızı ve risk seviyesine göre belirlenmelidir.
Kısaca
Disaster recovery, ciddi bir kesinti sonrasında kritik uygulamaları, veriyi ve altyapı servislerini kabul edilebilir sürede geri getirmek için kullanılan plan, prosedür ve teknik kontroller bütünüdür. Yedekleme bunun yalnızca bir parçasıdır. Dynamis Teknoloji, felaket kurtarma planını iş etkisi, RPO/RTO, bağımlılık sırası, kurtarma ortamı, test ve failback adımlarıyla birlikte ele alır.
Disaster recovery nedir?
Disaster recovery, bilgi sistemlerinin büyük bir kesinti sonrasında tekrar çalışır hale getirilmesine odaklanır.
Bu kesinti:
- Donanım arızası
- Veri merkezi kesintisi
- Ransomware
- Yanlış yapılandırma
- İnsan hatası
- Network kesintisi
- Cloud region problemi
- Database bozulması
gibi nedenlerle oluşabilir.
Gerçek bir DR planı yalnızca "backup var" demek değildir.
En az şu bileşenleri kapsamalıdır:
- Kritik sistem envanteri
- İş etkisi analizi
- RPO
- RTO
- Kurtarma sırası
- Backup ve replika yapısı
- Alternatif çalışma ortamı
- Network ve DNS planı
- Kimlik ve erişim
- İletişim
- Test
- Failback
Disaster recovery ile iş sürekliliği aynı şey değildir
İş sürekliliği daha geniş bir kavramdır.
İş sürekliliği şu soruyu sorar:
Kritik iş süreçleri kesinti sırasında nasıl devam edecek?
Disaster recovery ise şu soruya odaklanır:
Bilgi
sistemleri ve veriler nasıl geri getirilecek?
Örneğin ödeme sistemi kapandığında:
- Müşteriye hangi kanal üzerinden bilgi verileceği iş sürekliliği planının parçasıdır.
- Database ve uygulamanın başka ortamda yeniden çalıştırılması disaster recovery planının parçasıdır.
İki plan birbirini tamamlar.
İlk adım: iş etkisi analizi yapın
NIST'in contingency planning yaklaşımında iş etkisi analizi kritik adımdır.
Her sistem için şunları belirleyin:
- Sistem durursa hangi iş süreci etkilenir?
- Gelir etkisi nedir?
- Müşteri etkisi nedir?
- Maksimum tolere edilebilir kesinti ne kadar?
- Hangi sistemlere bağımlıdır?
- Hangi sırayla geri gelmelidir?
Böylece her sistemi aynı kritik seviyede ele almak yerine kurtarma önceliği oluşturabilirsiniz.
RPO nedir?
RPO, kabul edilebilir veri kaybı penceresidir.
Örnek:
- Hedef RPO: 15 dakika
- Olay zamanı: 14:00
- Geri yüklenen son geçerli veri: 13:50
Veri kaybı penceresi 10 dakikadır ve hedef karşılanmıştır.
RPO, backup sıklığıyla ilişkili olsa da yalnız schedule değildir.
Gerçek restore testinde geri dönen verinin hangi zaman noktasını temsil ettiği ölçülmelidir.
RTO nedir?
RTO, sistemin kabul edilebilir kesinti süresidir.
Örnek:
- Olay başlangıcı: 14:00
- Uygulama tekrar kullanılabilir: 15:20
Gerçek RTO:
1 saat 20 dakika
RTO yalnız VM'in açılma süresi değildir.
Database, network, DNS, authentication ve uygulama doğrulaması tamamlanana kadar süre devam eder.
RPO ve RTO iş hedefidir
RPO/RTO'yu yalnız altyapı ekibi belirlememelidir.
Örnek:
- Teknik ekip 4 saat RTO verebilir
- İş birimi maksimum 30 dakika kesinti kabul edebilir
Bu durumda mimari hedefi karşılamıyor demektir.
Daha düşük RPO/RTO genellikle:
- daha sık replika
- daha fazla kapasite
- active-active veya warm standby
- daha gelişmiş otomasyon
gerektirdiği için maliyeti artırır.
Bu nedenle hedefler iş etkisi ve bütçeyle birlikte belirlenmelidir.
Felaket kurtarma stratejileri
Her sistem için aynı kurtarma modeli kullanılmaz.
Backup and restore
En basit modeldir.
Uygun olduğunda:
- RTO saatler seviyesinde kabul edilebiliyorsa
- Veri hacmi sınırlıysa
- Kritik olmayan sistemlerde
Avantajı düşük maliyettir.
Dezavantajı kurtarma süresinin daha uzun olmasıdır.
Pilot light
Hedef ortamda yalnızca kritik çekirdek servisler hazır tutulur.
Olay sırasında:
- compute artırılır
- uygulama ayağa kaldırılır
- trafik yönlendirilir
Backup/restore'a göre daha hızlıdır.
Warm standby
Hedef ortam düşük kapasitede sürekli çalışır.
Olay sırasında kapasite artırılır ve trafik taşınır.
RTO daha düşüktür ancak sürekli altyapı maliyeti vardır.
Active-active
Birden fazla ortam aynı anda production trafiği taşır.
En düşük kesinti süresini sağlayabilir ancak:
- data consistency
- routing
- deployment
- observability
karmaşıklığı yüksektir.
Kurtarma sırası bağımlılıklara göre yapılmalıdır
DR sırasında her sistem aynı anda ayağa kaldırılamaz.
Örnek sıra:
- Network ve VPN
- Identity / Active Directory
- DNS
- Database
- Queue
- Uygulama servisleri
- Load balancer
- Monitoring
- Kullanıcı erişimi
Bu sıra her ortamda farklı olabilir.
Önemli olan dependency map oluşturmak ve recovery order'ı önceden yazmaktır.
Yedekleme disaster recovery değildir
Yedekleme DR'nin temel bileşenidir ama tek başına yeterli değildir.
Şu durum sık görülür:
- Backup job başarılı
- Restore denenmemiş
- Encryption key kayıp
- Uygulama dependency'leri eksik
- DNS planı yok
- Kimlik servisi çalışmıyor
Bu ortamda yedek vardır ama disaster recovery kabiliyeti kanıtlanmamıştır.
3-2-1 yedekleme kuralı yedek mimarisini ayrı olarak ele alır.
Restore testi DR planının parçasıdır
DR planı test edilmeden güvenilir kabul edilmemelidir.
Test seviyesi:
- Tek dosya restore
- Database restore
- VM restore
- Uygulama restore
- Birden fazla servis recovery
- Tam DR tatbikatı
şeklinde kademeli olabilir.
Yedek geri yükleme testi RPO/RTO ölçümünü ve restore runbook'unu ayrı olarak detaylandırır.
Test sıklığı risk bazlı olmalıdır
Tüm kuruluşlar için tek bir evrensel "aylık" veya "yıllık" DR testi zorunluluğu yoktur.
Test sıklığını şu faktörlere göre belirleyin:
- Sistem kritikliği
- Mimari değişiklik sıklığı
- RPO/RTO
- Regülasyon
- Geçmiş test sonuçları
- Yeni deployment
- Backup altyapısı değişikliği
Kritik sistemler daha sık test edilebilir.
DR runbook içinde ne olmalı?
Her kritik sistem için runbook oluşturun.
Minimum alanlar:
- Olay türü
- Karar sahibi
- İletişim listesi
- Recovery source
- Hedef ortam
- Network adımları
- DNS değişiklikleri
- Authentication
- Database restore/replikasyon
- Uygulama başlatma sırası
- Smoke test
- RPO/RTO ölçümü
- Rollback/failback
- Kapanış kriteri
Runbook yalnız doküman değil, uygulanabilir prosedür olmalıdır.
Failover ile failback'i ayırın
Failover production iş yükünün alternatif ortama alınmasıdır.
Failback olay çözüldükten sonra normal hedef mimariye geri dönüştür.
Failback bazen failover'dan daha zordur çünkü:
- Yeni ortamda veri oluşmuştur
- Replikasyon yönü değişir
- DNS tekrar güncellenir
- Kullanıcı oturumları etkilenir
Bu nedenle DR planında yalnız "nasıl geçeriz?" değil, "nasıl geri döneriz?" sorusu da cevaplanmalıdır.
Ransomware senaryosunu ayrıca planlayın
Ransomware DR senaryosunda yalnız altyapının kapanması değil, backup'ın güvenilirliği de sorgulanır.
CISA'nın ransomware guidance'ı offline veya immutable backup kullanımını ve düzenli recovery testlerini özellikle önerir.
Kontrol edin:
- Backup production hesabından ayrı mı?
- Immutable veya offline kopya var mı?
- Admin credential compromise backup'a erişim sağlar mı?
- Restore ortamı temiz mi?
- Encryption key korunuyor mu?
Ransomware sonrası enfekte snapshot'ı geri yüklemek recovery değildir.
Cloud kullanmak DR'yi otomatik çözmez
Cloud sağlayıcı kullanmak donanım riskini azaltabilir ancak uygulama seviyesi felaket kurtarmayı otomatik sağlamaz.
IaaS ortamında müşteri hâlâ:
- region seçimi
- backup
- data replication
- application architecture
- IAM
- DNS
- recovery procedure
konularından sorumludur.
Cloud provider SLA ile sizin uygulama RTO'nuz aynı şey değildir.
Tek region production için DR var mı?
Tek region ortamda DR mümkündür ancak seçenekler sınırlıdır.
Örnek:
- Cross-region backup
- İkinci cloud
- On-prem recovery
- Başka veri merkezi
- Offline backup
kullanılabilir.
Asıl soru "multi-region var mı?" değil, tanımlanan RPO/RTO'nun hedef mimariyle karşılanıp karşılanmadığıdır.
DR planı için örnek tier modeli
| Tier | İş yükü | RTO | RPO | Yaklaşım |
|---|---|---|---|---|
| Tier 0 | Kimlik, kritik DB | Dakikalar | Dakikalar | Warm standby / active-active |
| Tier 1 | Core uygulama | < 1 saat | < 1 saat | Replika + hızlı failover |
| Tier 2 | İç sistemler | Saatler | Saatler | Backup + automated restore |
| Tier 3 | Arşiv / düşük kritik | Gün | Gün | Backup restore |
Bu değerler örnektir. Gerçek hedefleri BIA belirlemelidir.
Felaket kurtarma planı nasıl hazırlanır?
Adım 1: Sistem envanterini çıkarın
Production sistemleri, database'leri, network servislerini ve SaaS bağımlılıklarını listeleyin.
Adım 2: İş etkisi analizi yapın
Kesintinin gelir, müşteri ve operasyon etkisini ölçün.
Adım 3: RPO/RTO belirleyin
İş hedefini teknik recovery metriğine çevirin.
Adım 4: Recovery strategy seçin
Backup/restore, pilot light, warm standby veya active-active gibi model belirleyin.
Adım 5: Runbook yazın
Recovery adımlarını sıraya koyun.
Adım 6: Test edin
Restore ve failover işlemlerini kontrollü ortamda çalıştırın.
Adım 7: Bulguları kapatın
Test sonucu çıkan eksikleri aksiyon planına alın.
Adım 8: Planı güncel tutun
Mimari değişiklikler, yeni servisler ve ekip değişiklikleri DR planına yansıtılmalıdır.
Dynamis'te disaster recovery yaklaşımı
Dynamis'in kurumsal altyapı hizmeti kapsamında disaster recovery'yi yalnız backup ürünü olarak ele almıyoruz.
İlk değerlendirmede:
- kritik workload envanteri
- BIA
- RPO/RTO
- backup yapısı
- region ve data location
- dependency map
- recovery environment
- monitoring
- incident ownership
incelenir.
Ardından workload'a göre:
- backup/restore
- warm standby
- private cloud DR
- hybrid cloud
- multi-cloud
gibi modellerden uygun olan seçilir.
Sık yapılan hatalar
Backup var, DR tamam sanmak: Restore ve recovery order test edilmelidir.
RPO/RTO'yu teknik ekipte bırakmak: İş etkisi olmadan belirlenen hedefler gerçekçi olmayabilir.
Tüm sistemlere aynı recovery tier vermek: Kritik sistem ile arşiv aynı maliyet modelinde olmamalıdır.
Failback'i planlamamak: Alternatif ortamdan normal production'a dönüş ayrıca tasarlanmalıdır.
Yalnız altyapıyı test etmek: Kullanıcı login ve gerçek iş akışı doğrulanmalıdır.
Planı yıllarca güncellememek: Uygulama ve dependency değiştikçe DR runbook eskir.
Sırada ne var
- Active Directory nedir? Şirketlerde nasıl kullanılır?: Domain Controller, DNS ve AD DS recovery bağımlılıklarını kimlik altyapısı açısından planlayın.
- 3-2-1 yedekleme kuralı: backup katmanını doğru failure domain'lerle kurun.
- Bulut yedekleme fiyatları: maliyet nasıl hesaplanır?: RPO, RTO, ikinci kopya ve saklama süresini toplam yedekleme maliyetine bağlayın.
- Yedek geri yükleme testi: RPO/RTO'yu gerçek restore ile ölçün.
- Bulut sunucu mu, yönetilen altyapı mı?: DR operasyonunun kimde kalacağını belirleyin.
- Kurumsal altyapı hizmeti: backup, monitoring ve disaster recovery operasyonunu birlikte yönetin.
Kaynaklar
Kaynaklar
- 1.NIST SP 800-34 Rev. 1 Contingency Planning GuideNational Institute of Standards and Technology · 2026-09-21
- 2.Recovery Point ObjectiveNIST CSRC · 2026-09-21
- 3.Recovery Time ObjectiveNIST CSRC · 2026-09-21
- 4.CISA #StopRansomware GuideCybersecurity and Infrastructure Security Agency · 2026-09-21
Sık sorulan sorular
Disaster recovery nedir?
Disaster recovery, büyük bir kesinti sonrasında kritik bilgi sistemlerini, veriyi ve operasyon kabiliyetini kabul edilebilir süre içinde geri getirmek için kullanılan plan, prosedür ve teknik önlemler bütünüdür. Yalnızca yedek almak değil; öncelik, RPO/RTO, sorumluluk, kurtarma yöntemi ve test sürecini de kapsar.
Disaster recovery ile iş sürekliliği arasındaki fark nedir?
İş sürekliliği, kesinti sırasında kritik iş süreçlerinin nasıl devam edeceğini kapsayan daha geniş çerçevedir. Disaster recovery ise özellikle bilgi sistemleri, uygulamalar, altyapı ve verinin geri kazanılmasına odaklanır.
RPO ve RTO nasıl belirlenir?
RPO, kabul edilebilir veri kaybı penceresini; RTO ise sistemin kabul edilebilir kesinti süresini ifade eder. Bu hedefler teknik ekip tarafından tahmin edilmemeli; iş etkisi, gelir, müşteri etkisi, bağımlılıklar ve operasyon maliyeti birlikte değerlendirilerek belirlenmelidir.
Felaket kurtarma planı ne sıklıkla test edilmeli?
Tüm kuruluşlar için tek bir evrensel sıklık yoktur. Test sıklığı sistem kritikliği, değişiklik hızı, RPO/RTO hedefleri ve risk seviyesine göre belirlenmelidir. NIST test, training ve exercise faaliyetlerini plan bakımının parçası olarak; CISA ise backup ve recovery prosedürlerinin düzenli test edilmesini önerir.
Yedekleme tek başına disaster recovery sayılır mı?
Hayır. Yedekleme disaster recovery'nin temel bileşenlerinden biridir ancak tek başına yeterli değildir. Gerçek DR planı; bağımlılıkları, kurtarma sırasını, hedef ortamı, erişimleri, RPO/RTO'yu, iletişimi, rollback/failback'i ve test edilmiş prosedürleri de içerir.