# Disaster Recovery (DR) Nedir? Felaket Kurtarma Merkezi ve DR Senaryoları

**URL:** https://securesys.com.tr/tr/bilgi-merkezi/backup-yedekleme-is-surekliligi/disaster-recovery-nedir-dr-senaryolari

![Disaster Recovery (DR) Nedir? Felaket Kurtarma Merkezi ve DR Senaryoları](/images/bilgi-merkezi/covers/cover-backup-08.webp)

Bir kurumun yedeğinin bulunması, o kurumun felaket anında çalışmaya devam edebileceği anlamına gelmez.

Backup veriyi korur.

Ancak iş sürekliliği açısından çoğu zaman daha fazlasına ihtiyaç vardır.

Örneğin ana veri merkezi tamamen kullanılamaz hale gelirse ne olur?

Sunucular sağlam backup’lara sahip olabilir.

Ancak;

veri merkezi elektriksiz kalmış,

network altyapısı zarar görmüş,

storage kullanılamıyor,

yangın çıkmış,

şehir genelinde kesinti oluşmuş

veya büyük bir ransomware olayı yaşanmış olabilir.

Bu durumda yalnızca backup dosyasının bulunması yeterli değildir.

Kurumun kritik sistemlerini başka bir altyapıda tekrar çalıştırabilmesi gerekir.

İşte bu noktada:

#### Disaster Recovery – DR

yani:

#### Felaket Kurtarma

kavramı devreye girer.

Disaster Recovery, ciddi bir kesinti veya felaket sonrasında bilgi teknolojileri sistemlerinin kabul edilebilir süre ve veri kaybı seviyesinde yeniden çalışır hale getirilmesini sağlayan teknik, operasyonel ve yönetsel süreçlerin bütünüdür.

DR yalnızca ikinci bir veri merkezi değildir.

Aynı zamanda;

plan,

prosedür,

teknoloji,

personel,

network,

replikasyon,

backup,

test,

failover

ve failback

süreçlerinden oluşur.

### Disaster Recovery Nedir?

Disaster Recovery, kurumun kritik BT sistemlerinin büyük bir kesinti sonrasında yeniden devreye alınmasını sağlayan kurtarma yaklaşımıdır.

Bu kesinti;

doğal afet,

yangın,

sel,

deprem,

uzun süreli elektrik kesintisi,

storage arızası,

network problemi,

ransomware,

siber saldırı,

insan hatası

gibi birçok nedenle oluşabilir.

DR’nin temel hedefi:

**kritik iş sistemlerinin kabul edilebilir RPO ve RTO değerleri içerisinde yeniden çalıştırılmasıdır.**

### Disaster Recovery ile Backup Arasındaki Fark Nedir?

Bu iki kavram sıklıkla birbirine karıştırılır.

#### Backup

Verinin kopyasını oluşturur.

Amaç kaybolan veya bozulan veriyi geri getirmektir.

#### Disaster Recovery

Teknolojik hizmetin başka bir ortamda yeniden çalıştırılmasını sağlar.

Amaç tüm sistemin hizmet vermeye devam etmesidir.

Basit ifadeyle:

**Backup = Veriyi geri getirir.**

**DR = Hizmeti geri getirir.**

### Backup Varsa Neden DR Gerekir?

Örneğin kurumun 20 TB büyüklüğünde kritik ERP ortamı olsun.

Backup sağlam durumda olabilir.

Ancak ana veri merkezi tamamen kapalıysa bu backup’ı nereye restore edeceksiniz?

Yeni server gerekiyor.

Storage gerekiyor.

Network gerekiyor.

Firewall gerekiyor.

DNS gerekiyor.

Active Directory gerekiyor.

Lisanslar gerekiyor.

İnternet bağlantısı gerekiyor.

Backup yalnızca veriyi sağlar.

DR ise bu verinin üzerinde çalışacağı alternatif altyapıyı hazır tutar.

### Disaster Recovery Hangi Senaryolara Karşı Tasarlanır?

DR yalnızca doğal afet için hazırlanmaz.

Modern DR stratejisinde birçok senaryo değerlendirilmelidir.

Örneğin:

- Veri merkezinin tamamen kaybedilmesi
- Uzun süreli elektrik kesintisi
- Yangın
- Deprem
- Flood veya su baskını
- Storage arızası
- Core network arızası
- İnternet bağlantısının uzun süre kaybedilmesi
- Hypervisor altyapısının kaybedilmesi
- Ransomware
- Active Directory compromise
- Kritik database corruption
- Cloud region outage

Her senaryoda recovery yöntemi farklı olabilir.

### DR Site Nedir?

DR Site, ana sistemlerin kullanılamaz hale gelmesi durumunda devreye alınmak üzere hazırlanmış alternatif lokasyondur.

Bu lokasyon;

ikinci veri merkezi,

başka şehirdeki ofis,

cloud altyapısı,

hosting sağlayıcısı

veya DRaaS platformu

olabilir.

Ana lokasyon genellikle:

#### Primary Site

olarak adlandırılır.

Alternatif kurtarma lokasyonu ise:

#### DR Site

veya:

#### Secondary Site

olarak ifade edilir.

### Primary Site Nedir?

Primary Site, kurumun normal operasyon sırasında hizmet verdiği ana veri merkezi veya BT ortamıdır.

Örneğin:

ERP,

database,

mail,

Active Directory,

dosya sunucuları

burada çalışır.

Felaket durumunda bu sistemlerin DR lokasyonuna taşınması veya oradan çalıştırılması hedeflenir.

### DR Lokasyonu Aynı Binada Olabilir mi?

Teknik olarak olabilir ancak gerçek felaket kurtarma açısından ciddi risk taşır.

Örneğin ana sistem:

- \1. katta

ve DR sistemi:

- \2. katta

bulunuyorsa yangın, elektrik veya bina kaynaklı bir olay iki ortamı da etkileyebilir.

Bu nedenle DR lokasyonunun ayrı failure domain içerisinde bulunması tercih edilir.

### Geographic Separation Nedir?

Geographic Separation, Primary Site ile DR Site arasında coğrafi ayrım oluşturulmasıdır.

Amaç aynı afetin iki lokasyonu aynı anda etkilemesini azaltmaktır.

Örneğin;

iki farklı bina,

iki farklı ilçe,

iki farklı şehir,

iki farklı bölge

kullanılabilir.

Ancak mesafe arttıkça latency ve replikasyon sorunları ortaya çıkabilir.

Bu nedenle doğru mesafe iş ve teknik gereksinimlere göre belirlenmelidir.

### Hot Site Nedir?

Hot Site, felaket anında hızlı şekilde devreye alınabilecek yüksek hazırlık seviyesine sahip DR ortamıdır.

Bu ortamda;

server’lar,

storage,

network,

uygulamalar,

replike veriler

hazır durumda olabilir.

Bazı sistemler sürekli çalışıyor olabilir.

Felaket sırasında yalnızca failover işlemi gerekebilir.

### Hot Site Avantajları

Hot Site’in en büyük avantajı düşük RTO’dur.

Kritik sistemler kısa sürede devreye alınabilir.

Özellikle;

finans,

e-ticaret,

üretim,

kritik altyapı

gibi kesinti toleransı düşük ortamlarda tercih edilebilir.

### Hot Site Dezavantajları

En önemli dezavantaj maliyettir.

Çünkü ikinci lokasyonda da;

server,

storage,

network,

lisans,

operasyon

gereklidir.

Bazı durumlarda production’a yakın kapasitede ikinci altyapı tutulur.

Bu nedenle Hot Site yüksek maliyetli olabilir.

### Warm Site Nedir?

Warm Site, Hot Site ile Cold Site arasında orta seviyede hazırlık sunar.

Bu ortamda temel altyapı bulunur ancak tüm sistemler sürekli production seviyesinde çalışmayabilir.

Örneğin;

server kapasitesi hazırdır,

network hazırdır,

backup veya replica verileri bulunur,

ancak bazı uygulamaların restore veya başlatılması gerekir.

Bu nedenle RTO Hot Site’e göre daha uzundur.

### Warm Site Ne Zaman Tercih Edilir?

Kesinti toleransı birkaç saat olan sistemlerde ekonomik bir seçenek olabilir.

Örneğin kurum:

RTO = 6 saat

hedefine sahipse Warm Site yeterli olabilir.

### Cold Site Nedir?

Cold Site, minimum hazırlığa sahip alternatif lokasyondur.

Örneğin;

fiziksel alan,

elektrik,

network bağlantısı

hazır olabilir.

Ancak server ve sistemlerin kurulması gerekebilir.

Bu nedenle en uzun RTO’ya sahiptir.

### Cold Site Avantajı Nedir?

Ana avantaj maliyettir.

Sürekli çalışan ikinci bir altyapı gerekmez.

Ancak felaket anında recovery süresi uzun olabilir.

### Hot, Warm ve Cold Site Karşılaştırması

| Özellik | Hot Site | Warm Site | Cold Site |
| --- | --- | --- | --- |
| Hazırlık Seviyesi | Çok yüksek | Orta | Düşük |
| RTO | Çok düşük | Orta | Yüksek |
| Maliyet | Yüksek | Orta | Düşük |
| Veri Güncelliği | Çok yüksek olabilir | Orta | Backup’a bağlı |
| Failover Hızı | Hızlı | Orta | Yavaş |

Doğru seçim iş ihtiyacına göre yapılmalıdır.

### Active-Active DR Nedir?

Active-Active mimaride iki veya daha fazla lokasyon aynı anda aktif şekilde hizmet verebilir.

Örneğin:

İstanbul DC

ve

Ankara DC

aynı anda kullanıcı trafiği alıyor olabilir.

Bir lokasyon kaybedildiğinde diğer lokasyon hizmeti devam ettirebilir.

Bu yöntem son derece düşük RTO sağlayabilir.

### Active-Active Avantajları

- Çok düşük kesinti süresi
- Load balancing imkanı
- Kapasitenin aktif kullanılması
- Otomatik failover imkanı

Ancak tasarımı oldukça karmaşıktır.

### Active-Active Dezavantajları

En önemli sorunlar:

data consistency,

latency,

database replication,

session management,

network design

konularıdır.

Her uygulama Active-Active mimariye uygun değildir.

### Active-Passive DR Nedir?

Active-Passive yapıda ana sistem Primary Site’ta çalışır.

DR Site normal şartlarda pasif veya standby durumdadır.

Felaket meydana geldiğinde DR ortamı aktif hale getirilir.

Bu işlem:

#### Failover

olarak adlandırılır.

### Active-Passive Neden Yaygın Kullanılır?

Active-Active mimariye göre daha basit ve ekonomik olabilir.

Özellikle birçok kurumsal altyapıda:

Production → DR

replikasyon modeli kullanılır.

### Failover Nedir?

Failover, ana sistem kullanılamaz hale geldiğinde hizmetin alternatif sisteme veya lokasyona geçirilmesidir.

Örneğin:

Primary Database çöktü.

Secondary Database aktif hale getirildi.

Bu işlem failover’dır.

Failover;

manuel,

yarı otomatik,

otomatik

olabilir.

### Automatic Failover Nedir?

Automatic Failover’da sistem kesintiyi algılar ve insan müdahalesi olmadan ikinci sistemi devreye alır.

Bu özellikle yüksek erişilebilirlik sistemlerinde kullanılır.

Ancak otomatik failover yanlış tasarlanırsa split-brain gibi ciddi sorunlar oluşturabilir.

### Manual Failover Nedir?

Manual Failover’da yetkili ekip karar verir ve geçiş işlemini başlatır.

Bu yöntem daha yavaş olabilir ancak özellikle ransomware gibi olaylarda avantaj sağlayabilir.

Çünkü saldırı sırasında otomatik olarak compromised verinin DR ortamına taşınması istenmeyebilir.

### Failback Nedir?

Felaket sona erdikten ve Primary Site tekrar kullanılabilir hale geldikten sonra sistemlerin ana ortama geri alınması:

#### Failback

olarak adlandırılır.

Birçok kurum failover planı hazırlar ancak failback sürecini planlamaz.

Bu ciddi bir hatadır.

### Failback Neden Zordur?

DR lokasyonunda sistem çalışırken yeni veriler oluşur.

Primary Site tekrar açıldığında bu yeni verilerin geri senkronize edilmesi gerekir.

Yanlış failback veri kaybına neden olabilir.

Bu nedenle failback prosedürü mutlaka önceden test edilmelidir.

### Replication DR’nin Temeli midir?

Çoğu modern DR mimarisinde evet.

Veri Primary Site’tan DR Site’a replikasyon ile aktarılır.

Bu;

storage replication,

database replication,

VM replication,

application replication

şeklinde olabilir.

### Synchronous Replication DR’de Nasıl Kullanılır?

Synchronous replication’da veri iki lokasyona aynı anda yazılır.

Bu nedenle çok düşük RPO sağlanabilir.

Ancak network latency kritik hale gelir.

Lokasyonlar çok uzaksa uygulama performansı etkilenebilir.

### Asynchronous Replication DR’de Nasıl Kullanılır?

Asynchronous replication’da veri önce Primary Site’a yazılır.

Sonra DR Site’a gönderilir.

Bu nedenle küçük bir RPO oluşur.

Ancak uzak coğrafi lokasyonlarda daha pratiktir.

### DR Replikasyonu Backup Yerine Geçer mi?

Hayır.

Bu en önemli prensiplerden biridir.

Replikasyon:

**mevcut durumu kopyalar.**

Backup:

**geçmiş restore point’leri sağlar.**

Örneğin ransomware production dosyalarını şifrelerse şifrelenmiş dosyalar DR ortamına da replike olabilir.

Bu durumda iki lokasyon da etkilenebilir.

Bu nedenle:

#### DR + Backup

birlikte kullanılmalıdır.

### DR Ortamı da Backup Almalı mı?

Evet.

DR ortamı da ayrı güvenlik ve backup stratejisine sahip olmalıdır.

Çünkü DR lokasyonu kendi başına bir sistemdir ve veri kaybı yaşayabilir.

Ayrıca siber saldırı iki lokasyonu da etkileyebilir.

### DR ile Air-Gap Arasındaki Fark

DR erişilebilirlik sağlar.

Air-Gap izolasyon sağlar.

DR ortamı sürekli bağlı olabilir.

Air-gapped backup ise bilerek ayrılmıştır.

Bu nedenle güçlü mimarilerde:

**Production + DR + Immutable/Air-Gapped Backup**

birlikte kullanılabilir.

### Örnek Üç Katmanlı Mimari

Bir kurumda şu yapı kullanılabilir:

#### Katman 1 – Production

Ana sistemler çalışır.

#### Katman 2 – DR Site

Kritik sistemler replikasyonla tutulur.

#### Katman 3 – Cyber Recovery Vault

Immutable ve air-gapped backup’lar saklanır.

Bu yapı farklı felaket tiplerine karşı farklı recovery seçenekleri sağlar.

### Ransomware Saldırısında DR Ne Kadar Güvenlidir?

Bu tamamen tasarıma bağlıdır.

Eğer DR sürekli production ile aynı credential, network ve domain üzerinden yönetiliyorsa saldırgan ikinci lokasyona da ulaşabilir.

Bu nedenle DR’nin de siber güvenlik mimarisi bulunmalıdır.

### DR Site Aynı Active Directory Domain’inde Olmalı mı?

Operasyon açısından gerekebilir.

Ancak cyber recovery açısından risk oluşturabilir.

Domain tamamen compromise olursa DR ortamı da etkilenebilir.

Bu nedenle özellikle kritik kuruluşlar recovery için ayrı kimlik katmanları veya break-glass mekanizmaları değerlendirebilir.

### DR Ortamında Immutable Backup Olmalı mı?

Evet, değerlendirilebilir.

Replication yanlışlıkla veya saldırı nedeniyle bozulmuş veriyi DR’a taşıyabilir.

Immutable backup geçmişteki temiz restore point’e dönme imkanı sağlar.

### DRaaS Nedir?

DRaaS:

#### Disaster Recovery as a Service

anlamına gelir.

Kurum ikinci fiziksel veri merkezini kendisi kurmak yerine bir servis sağlayıcının cloud veya veri merkezi altyapısını kullanabilir.

Production sistemleri bu ortama replike edilir.

Felaket durumunda sistemler sağlayıcı altyapısında çalıştırılır.

### DRaaS Avantajları Nelerdir?

- İkinci veri merkezi yatırımı azaltılabilir.
- Daha hızlı kurulum sağlanabilir.
- Kapasite ihtiyaca göre artırılabilir.
- Coğrafi yedeklilik sağlanabilir.
- Otomasyon kullanılabilir.

### DRaaS Dezavantajları Nelerdir?

- Sağlayıcı bağımlılığı
- Network bağlantısına bağımlılık
- Egress maliyetleri
- Lisanslama
- Veri lokasyonu
- KVKK ve regülasyon
- Provider outage

gibi faktörler değerlendirilmelidir.

### Cloud DR Nedir?

Cloud DR, felaket kurtarma ortamının public veya private cloud üzerinde oluşturulmasıdır.

Normal zamanlarda minimum kaynak çalıştırılabilir.

Felaket olduğunda kaynaklar scale-up edilerek sistemler ayağa kaldırılabilir.

Bu yaklaşım maliyeti azaltabilir.

### Pilot Light DR Nedir?

Cloud dünyasında kullanılan modellerden biridir.

Pilot Light yaklaşımında kritik temel servisler sürekli açık tutulur.

Diğer kaynaklar felaket sırasında oluşturulur.

Bu model Hot Site ile Warm Site arasında düşünülebilir.

### Warm Standby Nedir?

Warm Standby modelinde production sisteminin daha küçük kapasiteli çalışan bir kopyası bulunur.

Felaket sırasında kapasite artırılır.

Bu sayede düşük RTO elde edilebilir.

### Backup and Restore DR Modeli

Cloud ortamlarında en ekonomik DR yöntemlerinden biri Backup and Restore yaklaşımıdır.

Sistemlerin backup’ları başka region veya account içerisinde tutulur.

Felaket sırasında altyapı yeniden oluşturulur ve backup restore edilir.

Maliyet düşüktür.

Ancak RTO uzundur.

### Multi-Site Active-Active Nedir?

En yüksek dayanıklılık modellerinden biridir.

İki veya daha fazla site aynı anda tam kapasite veya yakın kapasitede hizmet verir.

Traffic manager veya global load balancer kullanıcıları lokasyonlara dağıtır.

Bir site kaybedildiğinde trafik diğerine yönlendirilir.

Bu yöntem çok düşük RTO sağlayabilir.

Ancak en pahalı ve karmaşık modellerden biridir.

### DNS DR’de Neden Kritiktir?

Bir uygulama DR ortamında başarılı şekilde ayağa kalkabilir.

Ancak kullanıcı hâlâ Primary Site IP adresine yönleniyorsa hizmet kullanılamaz.

Bu nedenle DR planında:

DNS failover,

TTL,

load balancer,

global traffic management

planlanmalıdır.

### DNS TTL Neden Önemlidir?

DNS kaydının TTL değeri çok yüksekse failover sonrası kullanıcılar eski IP adresini uzun süre kullanabilir.

Örneğin TTL:

24 saat

ise DNS değişikliği geç yayılabilir.

Kritik sistemlerde doğru TTL stratejisi önemlidir.

### Load Balancer DR’de Nasıl Kullanılır?

Load balancer sistemlerin sağlık durumunu kontrol ederek trafik yönlendirebilir.

Primary Site erişilemiyorsa trafik DR Site’a gönderilebilir.

Bu yöntem otomatik failover sağlayabilir.

### Network DR Planı Olmadan Uygulama DR Çalışır mı?

Çoğu zaman hayır.

DR yalnızca VM replike etmek değildir.

Ayrıca;

IP planı,

routing,

firewall,

NAT,

VPN,

MPLS,

SD-WAN,

DNS

planlanmalıdır.

### Firewall Kuralları DR’a Nasıl Taşınır?

Firewall configuration backup’ları tutulmalıdır.

Ancak yalnızca config dosyasını saklamak yeterli değildir.

DR network topolojisi farklı olabilir.

Bu nedenle DR için ayrı ve test edilmiş firewall policy seti gerekebilir.

### Site-to-Site VPN DR’de Nasıl Kullanılır?

Kullanıcı ofisleri veya diğer lokasyonlar DR Site’a erişebilmelidir.

Bunun için yedek VPN veya SD-WAN yolları oluşturulabilir.

Primary Site kaybedildiğinde routing otomatik veya manuel olarak DR’a yönlendirilir.

### İnternet Servis Sağlayıcı Yedekliliği

DR Site’ın farklı ISP kullanması tek hata noktasını azaltabilir.

Aynı operatörün aynı altyapısını kullanmak coğrafi yedeklilik avantajını azaltabilir.

Bu nedenle carrier diversity değerlendirilebilir.

### Active Directory DR Planında Neden Kritik?

AD;

authentication,

DNS,

GPO,

service account

için temel servis olabilir.

DR Site’ta Domain Controller bulunması recovery süresini azaltabilir.

Ancak ransomware ve domain compromise senaryolarında dikkatli olunmalıdır.

### AD Forest Recovery Nedir?

Active Directory’nin tamamen compromise veya corrupt olması durumunda tüm forest’ın güvenilir backup’tan yeniden oluşturulması gerekebilir.

Bu:

#### Forest Recovery

olarak adlandırılır.

Normal DR failover’dan çok daha karmaşıktır.

Bu nedenle ayrı prosedür ve tatbikat gerektirir.

### Database DR Nasıl Yapılır?

Database sistemlerinde;

synchronous replication,

asynchronous replication,

log shipping,

Always On,

standby database,

database-native replication

gibi yöntemler kullanılabilir.

Database RPO/RTO hedeflerine göre doğru yöntem seçilir.

### Uygulama Dependency Mapping Neden Önemlidir?

ERP server’ı DR’da açılmış olabilir.

Ancak database çalışmıyorsa ERP çalışmaz.

Database çalışıyor olabilir ancak AD yoksa kullanıcı login olamaz.

Bu nedenle sistemler recovery sırasına göre değerlendirilmelidir.

### DR Recovery Sırası Nasıl Belirlenir?

Örnek bir recovery sırası:

- Network altyapısı
- Firewall ve temel güvenlik sistemleri
- DNS ve Active Directory
- Storage
- Database
- Kritik uygulamalar
- Web servisleri
- Dosya sunucuları
- Kullanıcı sistemleri

Ancak gerçek sıra kurumun dependency mapping ve BIA çalışmasına göre belirlenmelidir.

### Business Impact Analysis DR’yi Nasıl Belirler?

BIA hangi iş süreçlerinin kritik olduğunu gösterir.

Bu sayede hangi sistemin önce DR’a alınacağı belirlenir.

Örneğin;

ödeme sistemi = Tier 1

ERP = Tier 1

dosya arşivi = Tier 3

olabilir.

Buna göre DR yatırımı yapılır.

### Tüm Sistemler İçin DR Gerekli mi?

Hayır.

Bazı düşük öncelikli sistemlerde backup yeterli olabilir.

Kritik sistemlerde ise Hot DR gerekebilir.

Bu nedenle maliyet ve risk birlikte değerlendirilmelidir.

### DR Kapasitesi Production ile Aynı Olmalı mı?

Her zaman değil.

Bazı kurumlar DR ortamını daha düşük kapasitede tutar.

Felaket sırasında yalnızca kritik iş yükleri çalıştırılır.

Bu:

#### Degraded Mode

veya sınırlı kapasite operasyonu olarak düşünülebilir.

### DR’da Minimum Viable Business Nedir?

Felaket sırasında tüm hizmetlerin çalışması gerekmeyebilir.

Amaç kurumun kritik faaliyetlerini sürdürebilmesidir.

Örneğin normalde 100 uygulama varsa felaket sırasında ilk aşamada yalnızca 20 kritik uygulama çalıştırılabilir.

Bu yaklaşım DR maliyetini azaltabilir.

### DR Planında İnsan Faktörü

DR yalnızca teknoloji değildir.

Felaket anında:

Kim karar verecek?

Kim failover başlatacak?

Kim müşterileri bilgilendirecek?

Kim network işlemlerini yapacak?

Kim uygulamayı doğrulayacak?

Bu roller önceden belirlenmelidir.

### Disaster Declaration Nedir?

DR planının ne zaman devreye alınacağı net olmalıdır.

Her 10 dakikalık kesintide DR’a geçilmez.

Belirli kriterler oluşturulabilir.

Örneğin:

Primary Site’ın 2 saat içinde geri dönemeyeceği öngörülüyorsa

#### Disaster Declaration

yapılır ve DR süreci başlatılır.

### DR Karar Yetkisi Kimde Olmalı?

DR failover ciddi bir operasyondur.

Bu nedenle karar yetkisi önceden belirlenmelidir.

Örneğin;

CIO,

IT Director,

Business Continuity Manager,

Crisis Committee

gibi roller yetkili olabilir.

### DR Runbook Nedir?

Runbook, felaket anında uygulanacak teknik adımları sıralayan prosedürdür.

Örneğin:

- Incident doğrula
- Primary Site izolasyonu
- DR replikasyon kontrolü
- Database failover
- VM başlatma
- DNS değiştirme
- Uygulama testi
- Kullanıcı erişimi

Runbook mümkün olduğunca açık ve güncel olmalıdır.

### DR Dokümanı Sadece PDF Olarak Yeterli mi?

Hayır.

Doküman yıllarca test edilmeden duruyorsa gerçek felakette işe yaramayabilir.

DR planı yaşayan bir süreç olmalıdır.

### DR Tatbikatı Nedir?

Disaster Recovery Test veya DR Drill, kurumun felaket kurtarma planını gerçek veya simüle edilmiş ortamda test etmesidir.

Bu testte gerçekten failover yapılabilir.

### DR Test Türleri

Farklı seviyelerde test uygulanabilir.

#### Tabletop Test

Ekipler masa başında senaryoyu tartışır.

#### Component Test

Belirli sistem restore edilir.

#### Partial Failover

Bazı hizmetler DR’a alınır.

#### Full DR Test

Primary Site kullanılamaz kabul edilerek kritik sistemler DR’dan çalıştırılır.

### Full DR Test Neden Önemlidir?

Kağıt üzerinde tüm sistemlerin hazır olduğu düşünülebilir.

Gerçek testte;

DNS problemi,

eksik firewall kuralı,

expired certificate,

eksik license,

bozuk replica,

yanlış credential

gibi sorunlar ortaya çıkabilir.

Bu nedenle test yapılmadan DR kapasitesi gerçek anlamda bilinemez.

### DR Tatbikatında RTO Ölçülmeli mi?

Kesinlikle.

Örneğin hedef:

RTO = 2 saat

ancak testte sistem:

5 saat 40 dakikada

ayağa kalkıyorsa mevcut mimari hedefi karşılamamaktadır.

### DR Tatbikatında RPO Ölçülmeli mi?

Evet.

Failover sonrası son verinin timestamp’i kontrol edilmelidir.

Bu sayede gerçek veri kaybı ölçülür.

### DR Testinde İş Birimleri Yer Almalı mı?

Evet.

BT ekibi uygulamayı açabilir.

Ancak uygulamanın gerçekten doğru çalıştığını iş birimi doğrulamalıdır.

Örneğin ERP login olmak yeterli değildir.

Sipariş oluşturulabiliyor mu?

Fatura kesilebiliyor mu?

Rapor alınabiliyor mu?

Bunlar test edilmelidir.

### Cyber Disaster Recovery Nedir?

Geleneksel DR fiziksel felaketlere odaklanırken Cyber DR özellikle siber saldırı senaryolarını kapsar.

Örneğin:

ransomware,

Active Directory compromise,

credential theft,

supply chain attack

sonrası recovery.

Cyber DR’da yalnızca hizmeti hızlı açmak değil, güvenli ve temiz şekilde açmak önemlidir.

### Ransomware DR Tatbikatı Nasıl Farklıdır?

Normal DR testinde Primary Site bozuk kabul edilir.

Ransomware testinde ise:

**Primary Site düşman kontrolünde kabul edilmelidir.**

Bu durumda production credential’ları güvenilir olmayabilir.

DR bağlantıları riskli olabilir.

Replikasyon durdurulmalıdır.

Temiz restore point belirlenmelidir.

Bu çok daha zor bir senaryodur.

### Clean Room Cyber DR’de Neden Önemlidir?

Ransomware sonrası sistemler önce izole Clean Room ortamında doğrulanabilir.

Malware taraması yapılır.

IOC’ler kontrol edilir.

Credential’lar değiştirilir.

Daha sonra DR ortamı açılır.

### DR ve Cyber Recovery Vault Birlikte Nasıl Kullanılır?

Örnek yapı:

Production → hızlı replication → DR Site

Production → immutable copy → Cyber Recovery Vault

Ana veri merkezi fiziksel olarak kaybedilirse DR kullanılır.

Ransomware iki aktif ortamı da etkilediyse Cyber Recovery Vault’tan temiz restore yapılır.

Bu mimari çok daha güçlüdür.

### Cloud Region Failure Senaryosu

Cloud kullanılması felaket riskini sıfırlamaz.

Bir region’da ciddi kesinti oluşabilir.

Bu nedenle kritik uygulamalar;

multi-AZ,

multi-region,

cross-region backup

tasarımları kullanabilir.

### Availability Zone ile Region Aynı Şey midir?

Hayır.

Availability Zone aynı region içerisindeki ayrı altyapı alanıdır.

Region ise daha geniş coğrafi cloud lokasyonudur.

Region failure’a karşı yalnızca multi-AZ yeterli olmayabilir.

### Multi-Region DR Ne Zaman Gerekir?

Çok düşük RTO hedefleri veya yüksek kritik seviyelerde değerlendirilebilir.

Ancak network latency ve maliyet artar.

### DR’da Veri Egemenliği ve KVKK

DR Site veya cloud backup başka ülkede bulunuyorsa veri aktarımı açısından hukuki ve regülasyon gereksinimleri değerlendirilmelidir.

Özellikle kişisel veri içeren sistemlerde veri lokasyonu önemlidir.

### ISO 22301 Açısından Disaster Recovery

ISO 22301 iş sürekliliği yönetim sistemi standardıdır.

DR teknik iş sürekliliğinin önemli parçalarından biridir.

Ancak ISO 22301 yalnızca BT’ye odaklanmaz.

Ayrıca;

personel,

tesis,

tedarikçi,

iletişim,

kriz yönetimi

gibi iş sürekliliği konularını kapsar.

### ISO 27001 Açısından Disaster Recovery

ISO/IEC 27001 bilgi güvenliği yönetiminde erişilebilirlik ve ICT continuity açısından felaket kurtarma kabiliyeti önemlidir.

Kritik sistemlerin;

yedeklenmesi,

recovery süreçlerinin belgelenmesi,

test edilmesi

risk bazlı şekilde ele alınmalıdır.

### DR Planı ile Business Continuity Plan Aynı Şey midir?

Hayır.

DR Plan:

**teknolojiyi geri getirir.**

Business Continuity Plan:

**işi devam ettirir.**

Örneğin ERP kapalıysa BCP:

manuel sipariş prosedürü

belirleyebilir.

DR ise ERP’nin tekrar çalıştırılmasını sağlar.

### Incident Response ile DR Arasındaki Fark

Incident Response saldırıyı;

tespit eder,

analiz eder,

izole eder,

eradicate eder.

DR ise hizmetin yeniden çalışmasını sağlar.

Ransomware olayında iki ekip birlikte çalışmalıdır.

### Crisis Management DR’nin Neresindedir?

Büyük kesintiler yalnızca teknik olay değildir.

Üst yönetim,

müşteri iletişimi,

regülatör,

hukuk,

PR

süreçleri de devreye girebilir.

Bu nedenle DR daha geniş Crisis Management yapısının parçası olabilir.

### DR Tasarımında En Sık Yapılan Hatalar

Kurumlarda sık görülen hatalar:

- DR ile backup’ı aynı şey sanmak,
- ikinci lokasyonu aynı failure domain’de tutmak,
- replikasyonu backup olarak görmek,
- RPO/RTO belirlemeden ürün seçmek,
- dependency mapping yapmamak,
- network DR planlamamak,
- DNS failover’ı unutmak,
- Active Directory recovery planlamamak,
- yalnızca failover planlayıp failback’i unutmak,
- DR testlerini yıllarca yapmamak,
- ransomware senaryosunu DR planına dahil etmemek.

### DR Tasarımında Sorulması Gereken Kritik Sorular

Kurumlar şu sorulara cevap verebilmelidir:

Primary Site tamamen kaybolursa nereye geçiyoruz?

DR kapasitesi yeterli mi?

DR’daki veri ne kadar güncel?

RPO nedir?

RTO nedir?

Failover kim tarafından başlatılacak?

DNS nasıl değişecek?

Kullanıcılar sisteme nasıl erişecek?

AD çalışmazsa ne olacak?

Ransomware replica veriyi bozarsa hangi backup kullanılacak?

Failback nasıl yapılacak?

Bu soruların cevapları yoksa DR mimarisi eksiktir.

### Sonuç: Disaster Recovery Backup’ın Ötesinde Bir İş Sürekliliği Yeteneğidir

Backup bir felaket kurtarma stratejisinin temel parçalarından biridir.

Ancak tek başına Disaster Recovery değildir.

Gerçek DR;

**alternatif altyapı,**

**replikasyon,**

**network,**

**DNS,**

**kimlik servisleri,**

**uygulamalar,**

**backup,**

**failover,**

**failback**

ve **test**

süreçlerini bir araya getirir.

Kurumun ihtiyacına göre;

**Hot Site,**

**Warm Site,**

**Cold Site,**

**Active-Active,**

**Active-Passive,**

#### Cloud DR

veya **DRaaS**

modelleri kullanılabilir.

Ancak doğru modelin belirleyicisi teknoloji değildir.

Belirleyici olan:

**RPO, RTO, iş etkisi ve risk toleransıdır.**

Modern kurumların ayrıca klasik felaketlerle siber felaketleri birbirinden ayırması gerekir.

Bir deprem sonrasında DR Site’a failover yapmak yeterli olabilir.

Ancak ransomware olayında DR Site’ın kendisi de compromised olabilir.

Bu nedenle güçlü bir siber dayanıklılık mimarisi çoğu zaman şu üç katmanı birlikte kullanır:

#### Production

↓

#### Disaster Recovery

↓

#### Immutable / Air-Gapped Cyber Recovery

Böylece kurum yalnızca sistemi yedeklemez.

Aynı zamanda:

**sistemin tamamen kaybedildiği durumda nerede, ne kadar sürede ve hangi güvenilir veriden yeniden çalışacağını önceden belirler.**

Disaster Recovery’nin gerçek amacı budur.