# Felaket Kurtarma Merkezi (DRC) ve Disaster Recovery Hizmetleri

**URL:** https://securesys.com.tr/tr/hizmetler/felaket-kurtarma-merkezi-disaster-recovery-draas

Kurumsal bilgi teknolojileri altyapılarında yüksek erişilebilirlik, yedekleme ve güvenlik kontrolleri kritik öneme sahiptir. Ancak tüm bu önlemlere rağmen veri merkezi kesintisi, donanım arızası, ransomware saldırısı, doğal afet, enerji problemi, network kesintisi veya insan hatası gibi nedenlerle kritik sistemler tamamen kullanılamaz hale gelebilir.

Bu nedenle kurumların yalnızca yedekleme yapması değil, ana sistemlerin devre dışı kalması halinde kritik servisleri alternatif bir ortamda çalıştırabilecek **Felaket Kurtarma Merkezi (Disaster Recovery Center – DRC)** mimarisine sahip olması gerekir.

**SecureSys Felaket Kurtarma Merkezi ve Disaster Recovery Hizmetleri**, kurumların kritik sistemlerinin alternatif veri merkezi, private cloud veya cloud ortamında yeniden çalıştırılabilmesi için gerekli mimarinin tasarlanması, kurulması, replikasyonunun yapılması, test edilmesi ve işletilmesine yönelik uçtan uca hizmet sunar.

Hizmet kapsamında;

- Disaster Recovery Center,
- DRaaS,
- Secondary Data Center,
- Active-Passive DR,
- Hot Site,
- Warm Site,
- Cold Site,
- Cloud DR,
- Replication,
- Failover,
- Failback,
- RPO/RTO,
- DR Testleri,
- Business Continuity

gibi süreçler birlikte ele alınabilir.

SecureSys DR yaklaşımında temel amaç yalnızca ikinci bir veri merkezi kurmak değil, **kritik iş servislerinin gerçek bir felaket anında belirlenen süreler içerisinde alternatif ortamdan çalıştırılabilmesini** sağlamaktır.

### Felaket Kurtarma Merkezi Nedir?

Felaket Kurtarma Merkezi, ana veri merkezi veya üretim ortamı kullanılamaz hale geldiğinde kritik sistemlerin alternatif lokasyonda çalıştırılmasını sağlayan BT altyapısıdır.

Disaster Recovery Center içerisinde kurumun ihtiyaçlarına göre;

- sunucular,
- sanal makineler,
- database sistemleri,
- network altyapısı,
- firewall,
- storage,
- backup,
- Active Directory,
- uygulama servisleri,
- güvenlik sistemleri

konumlandırılabilir.

Bu yapı ana veri merkezinin birebir kopyası olmak zorunda değildir.

Kurumun kritik iş süreçlerine göre yalnızca öncelikli sistemler DR ortamına dahil edilebilir.

### Disaster Recovery Nedir?

Disaster Recovery, ciddi bir kesinti veya felaket sonrasında bilgi teknolojileri sistemlerinin tekrar çalışır hale getirilmesine yönelik teknik süreçlerin bütünüdür.

Disaster Recovery süreci;

**Hazırlık → Replikasyon → İzleme → Felaket → Failover → Doğrulama → Operasyon → Failback**

adımlarını içerebilir.

DR planının amacı kesintinin tamamen engellenmesi değil, kesinti meydana geldiğinde kurumun ne kadar hızlı ve ne kadar veri kaybıyla yeniden çalışabileceğini kontrol altına almaktır.

### DRaaS – Disaster Recovery as a Service

DRaaS, felaket kurtarma altyapısının kurum tarafından tamamen satın alınıp işletilmesi yerine yönetilen hizmet modeliyle sunulmasıdır.

SecureSys **Disaster Recovery as a Service** kapsamında;

- DR altyapısı,
- compute kaynakları,
- storage,
- replication,
- network,
- monitoring,
- failover,
- DR testleri

gibi süreçleri yönetilen hizmet kapsamında sunabilir.

Bu model özellikle ikinci bir veri merkezi kurmanın yatırım maliyetinden kaçınmak isteyen kurumlar için avantaj sağlayabilir.

### Secondary Data Center

Secondary Data Center, kurumun ana veri merkezinden farklı fiziksel lokasyonda bulunan yedek veri merkezi ortamıdır.

Ana veri merkezi kullanılamaz hale geldiğinde kritik sistemler Secondary Data Center üzerinden çalıştırılabilir.

SecureSys Secondary Data Center projelerinde;

- network bağlantısı,
- server altyapısı,
- storage,
- firewall,
- replication,
- backup,
- monitoring

bileşenlerini birlikte değerlendirir.

### Business Continuity ve Disaster Recovery Arasındaki Fark

Business Continuity ve Disaster Recovery birbirleriyle ilişkili ancak farklı kavramlardır.

**Business Continuity**, kurumun iş süreçlerinin kesinti sırasında devam edebilmesini hedefler.

**Disaster Recovery**, bu sürekliliği destekleyen bilgi teknolojileri sistemlerinin alternatif ortamda yeniden çalıştırılmasına odaklanır.

Bu nedenle Disaster Recovery, iş sürekliliği planının teknik altyapı bileşenlerinden biridir.

### RPO Nedir?

RPO – Recovery Point Objective, kurumun kabul edebileceği maksimum veri kaybı süresini ifade eder.

Örneğin RPO 15 dakika ise DR ortamındaki veri en fazla 15 dakika geride olmalıdır.

RPO hedefi;

- replication teknolojisi,
- backup sıklığı,
- network kapasitesi,
- storage altyapısı

seçimini doğrudan etkiler.

### RTO Nedir?

RTO – Recovery Time Objective, sistemin felaket sonrasında ne kadar sürede tekrar çalışır hale gelmesi gerektiğini ifade eder.

Örneğin RTO 2 saat ise kritik sistemlerin en geç 2 saat içerisinde alternatif ortamda erişilebilir olması hedeflenir.

SecureSys DR mimarisini RPO ve RTO hedeflerine göre tasarlar.

### RPO ve RTO Analizi

Tüm sistemlere aynı RPO/RTO değerinin uygulanması doğru değildir.

Örneğin;

- ERP sistemi,
- Active Directory,
- database,
- e-posta,
- dosya sunucusu,
- test sistemi

farklı kritik seviyelere sahip olabilir.

SecureSys sistemleri kritiklik seviyelerine göre sınıflandırarak her servis için uygun RPO/RTO hedeflerinin belirlenmesine destek sağlar.

### Hot Site

Hot Site, üretim ortamına en yakın yedek sistem modelidir.

Bu yapıda;

- server,
- storage,
- network,
- uygulamalar,
- database

aktif veya hazır durumda bulunabilir.

Veriler sürekli replikasyonla güncel tutulabilir.

Hot Site modeli düşük RTO gerektiren kritik sistemler için uygundur.

### Warm Site

Warm Site, altyapının hazır olduğu ancak bazı sistemlerin tam kapasitede veya sürekli aktif olmadığı DR modelidir.

Felaket halinde belirli sistemlerin başlatılması ve konfigürasyonların tamamlanması gerekebilir.

Bu model Hot Site'a göre daha düşük maliyetli ancak daha yüksek RTO'ya sahip olabilir.

### Cold Site

Cold Site, temel fiziksel veya altyapısal kaynakların hazır olduğu ancak sistemlerin sürekli çalışmadığı DR modelidir.

Felaket durumunda;

- sunucuların hazırlanması,
- backup restore,
- network konfigürasyonu,
- uygulama kurulumu

gibi işlemler gerekebilir.

Cold Site daha düşük maliyetli ancak daha uzun recovery sürelerine sahip olabilir.

### Active-Passive Disaster Recovery

Active-Passive DR mimarisinde production sistemleri ana veri merkezinde aktif çalışırken DR ortamındaki sistemler pasif veya standby durumda bulunur.

Ana sistem kullanılamaz hale geldiğinde DR sistemi aktif hale getirilir.

Bu model birçok kurumsal Disaster Recovery mimarisinde yaygın olarak kullanılır.

### Active-Active Disaster Recovery

Active-Active mimarisinde iki lokasyon aynı anda aktif olarak hizmet verebilir.

Trafik iki ortam arasında dağıtılabilir.

Bu yapı yüksek erişilebilirlik sağlar ancak;

- uygulama mimarisi,
- database,
- network,
- data consistency

açısından daha karmaşıktır.

SecureSys uygun uygulamalarda Active-Active DR seçeneklerini değerlendirebilir.

### Disaster Recovery Replikasyonu

DR ortamının güncel tutulması için verilerin ana sistemden yedek sisteme aktarılması gerekir.

Replication;

- storage replication,
- VM replication,
- database replication,
- application replication

seviyelerinde gerçekleştirilebilir.

### Synchronous Replication

Synchronous Replication modelinde veri ana ve yedek ortama aynı anda yazılır.

Bu yöntem düşük RPO sağlayabilir.

Ancak iki lokasyon arasındaki latency ve network kapasitesi kritik öneme sahiptir.

### Asynchronous Replication

Asynchronous Replication modelinde veri önce primary ortama yazılır, ardından secondary sisteme gönderilir.

Bu yaklaşım uzak lokasyonlar için daha uygun olabilir.

Ancak belirli miktarda veri kaybı riski oluşabilir.

### VM Replication

Sanal makineler primary data center'dan DR merkezine replikasyonla aktarılabilir.

SecureSys;

- VMware,
- Hyper-V,
- Proxmox

ve uygun sanallaştırma ortamlarında VM replication çözümlerini değerlendirebilir.

### Database Replication

Veritabanlarının DR ortamında güncel tutulması için database seviyesinde replication kullanılabilir.

SecureSys;

- MSSQL Always On,
- PostgreSQL replication,
- MySQL replication,
- Oracle standby

gibi teknolojileri değerlendirebilir.

### Storage Replication

Storage sistemleri arasında block veya volume seviyesinde veri replikasyonu gerçekleştirilebilir.

Bu yaklaşım özellikle büyük sanallaştırma ortamlarında kullanılabilir.

### Application-Level Replication

Bazı uygulamalar kendi replikasyon mekanizmasına sahip olabilir.

SecureSys DR mimarisinde uygulama üreticisinin önerdiği replication yöntemlerini de dikkate alır.

### Cloud Disaster Recovery

Cloud altyapıları DR ortamı oluşturmak için esnek seçenekler sağlar.

Kurumun kendi ikinci veri merkezini kurması yerine kritik sistemler cloud üzerinde standby olarak tutulabilir.

SecureSys Cloud DR kapsamında;

- compute,
- storage,
- replication,
- network,
- backup,
- failover

bileşenlerini tasarlayabilir.

### On-Premise to Cloud DR

Kurumun ana sistemleri kendi veri merkezinde çalışırken DR ortamı cloud üzerinde kurulabilir.

Örnek:

**On-Premise Production → Replication → Cloud DR**

Bu model ikinci fiziksel veri merkezi yatırım ihtiyacını azaltabilir.

### Cloud-to-Cloud DR

Public cloud üzerinde çalışan sistemlerin farklı region veya farklı cloud ortamında DR kopyası oluşturulabilir.

Bu yaklaşım region bazlı kesintilere karşı ek dayanıklılık sağlayabilir.

### Multi-Cloud Disaster Recovery

Kritik kurumlarda primary cloud ile DR cloud farklı sağlayıcılarda tutulabilir.

Bu model sağlayıcı bağımlılığını azaltabilir.

Ancak uygulama uyumluluğu, network ve maliyet dikkatle planlanmalıdır.

### DR Network Tasarımı

Disaster Recovery yalnızca sunucu ve storage projesi değildir.

DR merkezindeki;

- IP adresleri,
- VLAN'lar,
- routing,
- firewall,
- DNS,
- VPN,
- load balancer

yapılarının da hazırlanması gerekir.

SecureSys primary ve DR network mimarisini birlikte tasarlar.

### DR Firewall Politikaları

Felaket anında sistemlerin DR ortamında açılması yeterli değildir.

Firewall politikalarının da doğru şekilde devreye alınması gerekir.

SecureSys;

- security policy,
- NAT,
- VPN,
- DMZ,
- inter-zone access

konfigürasyonlarını DR senaryosuna dahil edebilir.

### DR VPN Bağlantıları

Kullanıcıların ve şubelerin DR ortamına ulaşabilmesi için alternatif VPN yolları oluşturulabilir.

Örneğin;

**Branch → VPN → Primary Data Center**

normal koşulda kullanılırken felaket halinde;

**Branch → VPN → DR Center**

aktif hale getirilebilir.

### DNS Failover

Uygulamaların DR ortamına yönlendirilmesi için DNS kayıtlarının değiştirilmesi gerekebilir.

SecureSys DNS failover süreçlerini DR planına dahil edebilir.

### Global Load Balancing

Daha gelişmiş yapılarda global load balancer teknolojileri kullanılarak primary ortamın erişilemez olması halinde trafik otomatik olarak DR merkezine yönlendirilebilir.

### DR Active Directory

Kritik sistemlerin DR ortamında çalışabilmesi için kimlik doğrulama servislerinin de erişilebilir olması gerekir.

SecureSys DR merkezinde ek Domain Controller konumlandırabilir.

Bu sayede primary veri merkezi kullanılamaz durumda olsa bile kullanıcı kimlik doğrulama süreçlerinin devam etmesi sağlanabilir.

### DNS ve DHCP Disaster Recovery

Active Directory ile birlikte DNS ve diğer kritik network servislerinin DR ortamında da kullanılabilir olması gerekebilir.

SecureSys bu servislerin yedeklilik ve replication durumunu değerlendirir.

### Database Disaster Recovery

Database sistemleri birçok kurumun en kritik veri bileşenidir.

SecureSys database DR mimarisinde;

- replication,
- backup,
- standby,
- failover,
- restore

teknolojilerini birlikte değerlendirebilir.

### DBaaS ve Disaster Recovery

SecureSys Database as a Service altyapısı DR ortamıyla entegre çalışabilir.

Örnek:

**Primary DBaaS → Replication → DR DBaaS**

Bu yapı database servislerinin ikinci ortamda hızlı şekilde çalıştırılmasını sağlayabilir.

### CaaS ve Kubernetes Disaster Recovery

Container platformlarında yalnızca Kubernetes cluster konfigürasyonunun yedeklenmesi yeterli olmayabilir.

SecureSys CaaS DR kapsamında;

- secondary Kubernetes cluster,
- private registry,
- persistent data,
- configuration,
- DNS

bileşenlerini birlikte değerlendirebilir.

### Kubernetes Multi-Cluster DR

Production ve DR için ayrı Kubernetes cluster'ları kurulabilir.

Örnek:

**Production Cluster → Application/Data Replication → DR Cluster**

Felaket halinde uygulamalar alternatif cluster üzerinde çalıştırılabilir.

### Cold Backup ve DR Entegrasyonu

Cold Backup, Disaster Recovery altyapısının önemli tamamlayıcılarından biridir.

Replikasyon sistemleri hızlı RTO sağlayabilir ancak ransomware gibi saldırılarda bozuk veya şifrelenmiş veri DR ortamına da replike olabilir.

Bu nedenle SecureSys;

**Production → Replication → DR**

mimarisine ek olarak;

**Production → Immutable Backup → Cold Backup**

katmanı oluşturabilir.

Bu sayede hem hızlı failover hem de temiz veri geri dönüş imkânı hedeflenir.

### Replication Backup Değildir

Replication ve backup kavramları birbirine karıştırılmamalıdır.

Replication primary sistemde yapılan değişiklikleri secondary ortama aktarır.

Yanlış silinen veya ransomware ile şifrelenen veri de replike olabilir.

Backup ise verinin geçmiş zaman noktalarına ait kopyalarını saklar.

Bu nedenle güçlü bir DR mimarisinde **Replication + Backup + Immutable/Cold Copy** birlikte kullanılmalıdır.

### Immutable Backup ve DR

Immutable Backup kullanılarak backup verilerinin belirli süre boyunca değiştirilmesi veya silinmesi engellenebilir.

Bu yapı ransomware saldırısı sonrasında güvenilir restore kaynağı oluşturabilir.

### Air-Gapped Backup ve DR

Kritik kurumlarda DR altyapısının yanında tamamen izole Air-Gapped Backup da bulunabilir.

Bu yaklaşım, hem primary hem DR ortamının etkilenmesi durumunda son güvenli veri kopyası sağlayabilir.

### Ransomware Disaster Recovery

Ransomware sonrası recovery yalnızca DR sistemlerini açmak anlamına gelmez.

Öncelikle saldırının;

- Active Directory,
- endpoint,
- network,
- backup,
- database,
- privileged accounts

üzerindeki etkisi analiz edilmelidir.

Aksi halde saldırgan DR ortamında da aktif kalabilir.

SecureSys ransomware recovery sürecinde siber olay müdahale ve DR ekiplerini birlikte çalıştırabilir.

### Clean Room Recovery

Kritik ransomware olaylarında sistemlerin doğrudan production veya DR ortamına restore edilmesi risk oluşturabilir.

Bunun yerine izole **Clean Room Recovery** ortamı oluşturulabilir.

Burada;

- sistem restore edilir,
- malware analizi yapılır,
- güvenlik kontrolleri uygulanır,
- kimlik bilgileri yenilenir,
- temizliği doğrulanan sistem üretime alınır.

### İzole Recovery Network

Recovery operasyonlarının standart production network içerisinde yapılması saldırının yeniden yayılmasına neden olabilir.

SecureSys restore süreçleri için ayrı ve kontrollü Recovery Network oluşturabilir.

### Kırmızı Ağ ve Disaster Recovery

Kritik sistemler Kırmızı Ağ içerisinde çalışıyorsa DR merkezinde de aynı güvenlik mimarisinin korunması gerekir.

Örnek:

**Primary Kırmızı Ağ → Secure Replication → DR Kırmızı Ağ**

DR ortamında kritik sistemlerin standart Yeşil Ağ'a taşınması izolasyon yaklaşımını bozabilir.

SecureSys güvenlik zonlarını DR merkezinde de aynı prensiplerle oluşturabilir.

### İzole DR Merkezi

Yüksek güvenlik gerektiren kurumlarda DR Center, production ortamından güvenlik açısından bağımsız tasarlanabilir.

Ayrı;

- firewall,
- network,
- management,
- identity,
- backup

sistemleri kullanılabilir.

Bu yapı ortak credential veya ortak network kaynaklı riskleri azaltabilir.

### DR ve Zero Trust

DR ortamının kullanılmıyor olması güvenilir olduğu anlamına gelmez.

SecureSys DR yönetiminde;

- MFA,
- PAM,
- minimum privilege,
- ayrı administrator hesapları,
- network isolation

kontrollerini değerlendirebilir.

### DR PAM Entegrasyonu

Felaket anında administrator hesaplarının yoğun şekilde kullanılması gerekir.

Bu nedenle DR ortamındaki privileged access süreçleri PAM üzerinden yönetilebilir.

PAM ile;

- parola kasalama,
- erişim onayı,
- oturum kaydı,
- süreli yetki

kontrolleri uygulanabilir.

### DR Yönetim Ağı

DR merkezindeki firewall, server, switch, storage ve hypervisor sistemleri ayrı Management Network üzerinden yönetilebilir.

Standart kullanıcı ağından bu sistemlere doğrudan yönetim erişimi sınırlandırılabilir.

### DR Monitoring

DR sistemlerinin pasif olması izlenmemeleri gerektiği anlamına gelmez.

SecureSys;

- replication status,
- storage capacity,
- VM health,
- database replication,
- backup,
- network connectivity

gibi bileşenleri merkezi olarak izleyebilir.

### 7x24 Disaster Recovery Monitoring

Kritik DR altyapısında replication sorunlarının günler sonra fark edilmesi ciddi risk yaratır.

SecureSys hizmet kapsamında DR altyapısının 7x24 izlenmesini sağlayabilir.

### Replication Monitoring

Replication sistemleri sürekli kontrol edilmelidir.

İzlenebilecek metrikler;

- replication lag,
- failed replication,
- data consistency,
- link status,
- storage capacity

olarak belirlenebilir.

### DR ve SOC 7x24 Entegrasyonu

DR sistemlerinin güvenlik logları SIEM ve SOC'a aktarılabilir.

Bu sayede standby ortamındaki;

- administrator girişleri,
- firewall değişiklikleri,
- beklenmeyen sistem aktiviteleri,
- backup işlemleri

izlenebilir.

### DR Ortamında EDR/XDR

DR merkezindeki sunucular pasif olsa bile saldırı yüzeyine sahip olabilir.

Desteklenen sistemlerde EDR/XDR agent'larının kullanılması DR ortamının da güvenlik görünürlüğüne dahil edilmesini sağlar.

### DR ve NDR

Network Detection and Response çözümleri DR network trafiğinin izlenmesinde de kullanılabilir.

Bu yaklaşım özellikle failover sırasında olağandışı network hareketlerini görünür hale getirebilir.

### Disaster Recovery Runbook

Başarılı bir DR operasyonunun yalnızca teknik altyapıya değil, doğru dokümantasyona da ihtiyacı vardır.

SecureSys DR Runbook içerisinde;

- hangi sistem önce açılacak,
- hangi ekip sorumlu,
- hangi network değişiklikleri yapılacak,
- DNS nasıl değiştirilecek,
- testler nasıl gerçekleştirilecek,
- kullanıcılar nasıl yönlendirilecek

gibi adımları dokümante edebilir.

### DR Sistem Önceliklendirmesi

Tüm sistemlerin aynı anda kurtarılması her zaman mümkün olmayabilir.

Bu nedenle sistemler öncelik seviyelerine ayrılabilir.

Örneğin;

**Tier 0:** Kimlik ve altyapı servisleri **Tier 1:** Kritik iş uygulamaları **Tier 2:** Önemli destek sistemleri **Tier 3:** Standart sistemler

Recovery sırası bu kritiklik modeline göre oluşturulabilir.

### Application Dependency Mapping

Bir uygulamanın açılması tek başına yeterli olmayabilir.

ERP uygulaması;

- Active Directory,
- DNS,
- database,
- file server,
- middleware

servislerine bağlı olabilir.

SecureSys DR planlamasında uygulama bağımlılıklarını analiz ederek doğru recovery sırası oluşturabilir.

### DR Failover Nedir?

Failover, production sistemlerinin kullanılamaz hale gelmesi durumunda servislerin DR ortamına geçirilmesidir.

Failover;

- manuel,
- yarı otomatik,
- otomatik

şekilde gerçekleştirilebilir.

Yöntem kurumun güvenlik, maliyet ve RTO gereksinimine göre belirlenir.

### Planned Failover

Planlı bakım veya veri merkezi taşınması gibi durumlarda kontrollü şekilde DR ortamına geçiş yapılabilir.

Planned Failover sırasında veri senkronizasyonu kontrollü biçimde tamamlanabilir.

### Unplanned Failover

Ani veri merkezi kesintisi veya felaket durumunda hızlı şekilde DR ortamına geçiş gerekebilir.

Bu senaryoda süreçlerin önceden hazırlanmış olması kritiktir.

### Failback Nedir?

Primary data center tekrar kullanılabilir hale geldiğinde sistemlerin DR merkezinden ana ortama geri taşınması gerekir.

Bu süreç **Failback** olarak adlandırılır.

Failback de failover kadar dikkatli planlanmalıdır.

### Reverse Replication

DR ortamında çalışılan süre boyunca oluşan yeni verinin primary ortama geri taşınması gerekir.

Bu nedenle failback öncesinde reverse replication uygulanabilir.

### DR Testleri

Bir DR altyapısının kurulmuş olması felaket anında çalışacağı anlamına gelmez.

Bu nedenle belirli periyotlarla DR testleri yapılmalıdır.

SecureSys testlerde;

- replication,
- VM startup,
- database,
- network,
- DNS,
- application,
- user access

senaryolarını doğrulayabilir.

### Masa Başı DR Tatbikatı

Her DR testi production sistemleri kapatılarak yapılmak zorunda değildir.

Tabletop Exercise ile;

- senaryo,
- sorumlular,
- iletişim,
- karar süreçleri,
- recovery sırası

masa başında test edilebilir.

### Teknik DR Tatbikatı

Teknik tatbikatlarda seçilen sistemler kontrollü biçimde DR ortamından çalıştırılır.

Bu test gerçek recovery sürelerinin ölçülmesine yardımcı olur.

### Full Failover Test

Daha olgun yapılarda tüm kritik servisler belirli bakım penceresinde DR merkezine taşınabilir.

Bu test, gerçek bir felakete en yakın doğrulama yöntemlerinden biridir.

### Isolated DR Test

Production kullanıcılarını etkilemeden DR ortamında izole test networkü oluşturulabilir.

Bu sayede replicated sistemler güvenli şekilde başlatılıp kontrol edilebilir.

### DR Test Raporu

DR testlerinden sonra;

- gerçekleşen RTO,
- gerçekleşen RPO,
- başarısız adımlar,
- dependency problemleri,
- network hataları,
- iyileştirme aksiyonları

raporlanabilir.

### RTO Doğrulaması

Plan üzerinde 2 saat olarak belirlenen RTO'nun gerçekten sağlanıp sağlanmadığı yalnızca DR tatbikatı ile anlaşılabilir.

SecureSys gerçekleşen recovery sürelerini ölçerek hedeflerle karşılaştırabilir.

### RPO Doğrulaması

Replication veya backup sistemindeki son kullanılabilir veri noktası kontrol edilerek gerçek RPO değeri doğrulanabilir.

### Disaster Recovery Health Check

SecureSys **DR Health Check** hizmeti kapsamında mevcut Disaster Recovery altyapısının teknik ve operasyonel durumu analiz edilir.

Çalışmada;

- replication,
- RPO/RTO,
- backup,
- DR network,
- firewall,
- DNS,
- Active Directory,
- failover,
- runbook,
- son DR testleri

incelenebilir.

### DR Readiness Assessment

DR altyapısı bulunmayan veya çalışıp çalışmadığından emin olmayan kurumlar için Disaster Recovery Readiness Assessment gerçekleştirilebilir.

Çalışmada;

- kritik sistemler,
- uygulama bağımlılıkları,
- mevcut backup,
- replication,
- secondary site,
- operasyon süreçleri

değerlendirilerek DR yol haritası oluşturulabilir.

### Single Point of Failure Analizi

DR planlamasında yalnızca veri merkezi değil, kritik bağımlılıklar da değerlendirilmelidir.

Örneğin DR ortamı hazır olmasına rağmen;

- tek internet hattı,
- tek DNS servisi,
- tek firewall,
- tek kimlik sistemi

bulunması kurtarma sürecini engelleyebilir.

SecureSys SPOF noktalarını analiz eder.

### DR Capacity Planning

DR ortamının üretim ortamıyla aynı kapasitede olması her zaman gerekli değildir.

Ancak kritik workload'ları çalıştırabilecek yeterli;

- CPU,
- RAM,
- storage,
- network

kapasitesi bulunmalıdır.

SecureSys DR sizing çalışması yapabilir.

### DR Resource Reservation

Cloud tabanlı DR modellerinde tüm compute kaynaklarının sürekli açık tutulması gerekmeyebilir.

Felaket halinde devreye alınacak kaynaklar tanımlanarak maliyet optimize edilebilir.

### DR Cost Optimization

Disaster Recovery projelerinde güvenlik ve erişilebilirlik kadar maliyet de önemlidir.

SecureSys;

- Hot Site,
- Warm Site,
- Cold Site,
- Cloud DR,
- DRaaS

seçeneklerini RTO/RPO ve bütçe hedefleriyle birlikte değerlendirir.

### DRaaS Maliyet Modeli

DRaaS modelinde kurum ikinci veri merkezinin tüm fiziksel yatırımını yapmak yerine ihtiyaç duyduğu compute, storage ve operasyon kapasitesini servis modeliyle kullanabilir.

Bu yaklaşım CAPEX yükünü azaltabilir.

### Felaket Kurtarma Merkezi ve KVKK

Kişisel verilerin DR ortamına kopyalanması durumunda yedek ve replica sistemlerin de uygun güvenlik kontrolleriyle korunması gerekir.

DR ortamının production kadar güvenli olması önemlidir.

### Felaket Kurtarma ve ISO/IEC 27001

ISO/IEC 27001 bilgi güvenliği yönetim sisteminde iş sürekliliği, bilgi yedekleme ve ICT readiness gibi kontroller önem taşır.

Disaster Recovery süreçleri bu kontrollerin teknik olarak desteklenmesine katkı sağlayabilir.

### Felaket Kurtarma ve ISO 22301

ISO 22301 İş Sürekliliği Yönetim Sistemi, kurumların kesintilere karşı hazırlıklı olmasını hedefler.

DR altyapısı, iş sürekliliği yaklaşımının kritik teknik bileşenlerinden biridir.

### Felaket Kurtarma ve DORA

Finansal kuruluşlarda ICT dayanıklılığı ve kritik sistemlerin kesintiler karşısında sürdürülebilirliği önemlidir.

Düzenli DR testleri ve recovery süreçleri operasyonel dayanıklılık yaklaşımını destekleyebilir.

### Disaster Recovery ve Siber Dayanıklılık

Modern DR yaklaşımı yalnızca donanım arızası veya doğal afetleri kapsamamalıdır.

Ransomware, credential compromise, veri silme ve supply-chain kaynaklı saldırılar da DR senaryolarına dahil edilmelidir.

Bu nedenle SecureSys Disaster Recovery yaklaşımını **Cyber Resilience** perspektifiyle ele alır.

### Cyber Recovery

Cyber Recovery, özellikle siber saldırılar sonrasında temiz ve güvenilir sistemlerin geri döndürülmesine odaklanan kurtarma yaklaşımıdır.

Bu modelde;

- immutable backup,
- Clean Room,
- izole recovery,
- credential reset,
- malware validation

süreçleri uygulanabilir.

### Disaster Recovery ve Incident Response

Büyük siber olaylarda Incident Response ve DR ekiplerinin ayrı çalışması riskli olabilir.

Olay müdahale ekibi saldırının temizlendiğini doğrulamadan sistemlerin restore edilmesi saldırının yeniden başlamasına neden olabilir.

SecureSys gerekli durumlarda;

**SOC/IR → Containment → Clean Recovery → DR Activation**

yaklaşımını kullanabilir.

### DR ve SOC Eskalasyon Süreci

Primary veri merkezinde kritik güvenlik veya erişilebilirlik olayı tespit edildiğinde SOC ve altyapı ekipleri birlikte değerlendirme yapabilir.

DR aktivasyonu belirlenmiş karar mekanizması ve eskalasyon prosedürüne göre gerçekleştirilebilir.

### Disaster Declaration

Her kesinti DR aktivasyonu gerektirmez.

Kurum içerisinde hangi koşullarda “Disaster” ilan edileceği önceden belirlenmelidir.

Örneğin;

- veri merkezinin tamamen erişilemez olması,
- kritik sistemlerin belirlenen süreden fazla çalışmaması,
- büyük ransomware saldırısı

DR declaration kriterleri arasında olabilir.

### DR Karar Matrisi

SecureSys DR runbook içinde;

- olay tipi,
- tahmini kesinti süresi,
- sistem etkisi,
- veri durumu,
- recovery seçeneği

üzerinden karar matrisi oluşturabilir.

### Emergency Communication

Felaket sırasında teknik ekipler kadar iletişim süreci de önemlidir.

DR planında;

- teknik ekip,
- yönetim,
- iş birimleri,
- üçüncü taraf sağlayıcılar

için iletişim ve eskalasyon listeleri bulunmalıdır.

### Üçüncü Taraf Bağımlılıkları

DR ortamı hazır olsa bile harici servis sağlayıcıların kullanılamaması sistemi etkileyebilir.

Örneğin;

- internet sağlayıcı,
- DNS,
- lisans sunucusu,
- SaaS,
- dış API

bağımlılıkları DR planına dahil edilmelidir.

### DR Dokümantasyonu

SecureSys proje kapsamında;

- DR topology,
- IP plan,
- server listesi,
- replication tablosu,
- recovery sırası,
- RPO/RTO,
- iletişim listesi,
- failover prosedürü,
- failback prosedürü

dokümantasyonu oluşturabilir.

### DR Topoloji Dokümantasyonu

Görsel DR mimarisinde;

**Primary Data Center → Replication → DR Center → Backup/Cold Backup**

bağlantıları gösterilebilir.

Network, firewall ve uygulama bağımlılıkları topolojiye eklenebilir.

### DR Envanter Yönetimi

DR kapsamındaki her sistem için;

- application owner,
- server,
- database,
- IP,
- RPO,
- RTO,
- replication,
- backup,
- DR priority

bilgileri tutulabilir.

### DR Change Management

Production sistemlerde yapılan büyük değişikliklerin DR ortamına da yansıtılması gerekir.

Aksi halde felaket anında eski konfigürasyonlarla karşılaşılabilir.

SecureSys DR change management sürecinde production ve secondary sistemlerin uyumluluğunu takip edebilir.

### Configuration Drift

DR ortamında uzun süre işlem yapılmadığında production ve DR konfigürasyonları birbirinden farklılaşabilir.

Bu durum failover sırasında sorun yaratabilir.

Periyodik kontrollerle configuration drift tespit edilebilir.

### Patch Management ve DR

Production sistemlere uygulanan kritik patch ve upgrade işlemlerinin DR ortamında da planlanması gerekir.

Aksi halde iki ortam arasında sürüm uyumsuzluğu oluşabilir.

### DR Monitoring Dashboard

Kritik DR göstergeleri merkezi dashboard üzerinden takip edilebilir.

Örneğin;

- replication health,
- backup status,
- RPO lag,
- resource capacity,
- system availability

görüntülenebilir.

### DR Raporlama

SecureSys periyodik Disaster Recovery raporlarında;

- replication durumu,
- RPO,
- backup,
- DR kapasitesi,
- test sonuçları,
- açık aksiyonlar,
- kritik riskler

sunabilir.

### Yönetici DR Raporu

Üst yönetim için teknik detaylardan arındırılmış şekilde;

- kritik servislerin DR hazırlığı,
- son test tarihi,
- gerçekleşen RTO/RPO,
- önemli riskler,
- aksiyon durumu

özetlenebilir.

### Disaster Recovery SLA

DRaaS veya Managed DR hizmet modelinde SLA kapsamında;

- monitoring,
- incident response,
- failover assistance,
- test frequency,
- technical support

gibi kriterler tanımlanabilir.

### Managed Disaster Recovery Hizmeti

SecureSys Managed Disaster Recovery hizmetinde kurumun DR altyapısının günlük operasyonları yönetilebilir.

Hizmet kapsamında;

- replication monitoring,
- backup kontrolü,
- DR system health,
- change management,
- failover desteği,
- DR testleri,
- raporlama

süreçleri yürütülebilir.

### 7x24 DR Operasyon Desteği

Kritik kurumlarda felaketin hangi saatte meydana geleceği bilinemez.

Bu nedenle hizmet modeline göre 7x24 Disaster Recovery operasyon desteği sağlanabilir.

### SecureSys Felaket Kurtarma Merkezi Hizmet Süreci

#### \1. İş Etki ve Kritiklik Analizi

Kritik iş sistemleri ve bağımlılıkları belirlenir.

#### \2. RPO ve RTO Belirleme

Her sistem için kabul edilebilir veri kaybı ve kesinti süreleri tanımlanır.

#### \3. DR Stratejisinin Seçilmesi

Hot Site, Warm Site, Cold Site, Cloud DR veya DRaaS modeli değerlendirilir.

#### \4. Hedef Mimari Tasarımı

Server, storage, network, firewall ve security mimarisi hazırlanır.

#### \5. Replication

VM, database, storage veya application seviyesinde replication yapılandırılır.

#### \6. Backup ve Cyber Recovery

Immutable Backup, Cold Backup ve gerektiğinde Air Gap katmanları oluşturulur.

#### \7. Güvenlik

PAM, MFA, network isolation, Kırmızı Ağ ve SOC entegrasyonları uygulanır.

#### \8. Monitoring

DR ve replication altyapısı sürekli izlenir.

#### \9. DR Runbook

Failover ve failback prosedürleri dokümante edilir.

#### \10. DR Testi

Teknik recovery senaryoları kontrollü olarak test edilir.

#### \11. Raporlama

Gerçekleşen RPO/RTO ve tespit edilen eksiklikler raporlanır.

#### \12. Sürekli İyileştirme

Production değişiklikleri ve yeni riskler doğrultusunda DR ortamı güncellenir.

### Neden SecureSys Felaket Kurtarma Merkezi Hizmeti?

Felaket Kurtarma Merkezi yalnızca ikinci lokasyonda birkaç sunucu çalıştırmak değildir.

Gerçek bir Disaster Recovery mimarisi;

**Server + Network + Database + Replication + Backup + Security + Identity + SOC + Runbook + DR Testleri**

bileşenlerinin birlikte yönetilmesini gerektirir.

SecureSys, Disaster Recovery projelerini klasik altyapı yaklaşımının ötesinde **siber dayanıklılık** perspektifiyle ele alır.

Özellikle ransomware senaryolarında yalnızca hızlı failover'a değil, temiz ve güvenilir veriye geri dönebilme kabiliyetine de odaklanır.

Bu nedenle gerektiğinde;

**Primary Data Center + DR Center + Immutable Backup + Cold Backup + Clean Room + SOC**

mimarileri birlikte tasarlanabilir.

### Sık Sorulan Sorular

#### Felaket Kurtarma Merkezi nedir?

Ana veri merkezi kullanılamaz hale geldiğinde kritik bilgi sistemlerinin alternatif ortamda çalıştırılmasını sağlayan yedek veri merkezi veya cloud altyapısıdır.

#### Disaster Recovery ile backup aynı şey midir?

Hayır. Backup verinin kopyasını saklar, Disaster Recovery ise kritik sistemlerin alternatif ortamda çalıştırılmasını sağlar.

#### DRaaS nedir?

DRaaS, Disaster Recovery altyapısının ve operasyonlarının yönetilen hizmet modeliyle sunulmasıdır.

#### Hot Site nedir?

Üretim sistemlerine yakın kapasitede ve hızlı devreye alınabilecek hazır DR ortamıdır.

#### Warm Site nedir?

Temel altyapının hazır olduğu ancak bazı servislerin felaket sırasında devreye alınması gereken DR modelidir.

#### Cold Site nedir?

Temel lokasyon ve altyapının bulunduğu ancak sistemlerin restore veya kurulmasının gerektiği düşük maliyetli DR modelidir.

#### RPO ve RTO arasındaki fark nedir?

RPO kabul edilebilir veri kaybını, RTO ise kabul edilebilir sistem kesinti süresini ifade eder.

#### DR ortamı ne sıklıkla test edilmelidir?

Test sıklığı kurumun kritikliği ve risk seviyesine göre belirlenmelidir. Kritik sistemlerde düzenli teknik DR tatbikatları yapılması önerilir.

#### Ransomware saldırısında DR işe yarar mı?

Evet, ancak yalnızca replication kullanılıyorsa şifrelenmiş veri DR'a da taşınabilir. Bu nedenle immutable ve izole backup katmanları önemlidir.

#### DR merkezi Kırmızı Ağ mimarisini destekleyebilir mi?

Evet. Production ortamındaki izole güvenlik zonları DR merkezinde de aynı güvenlik modeliyle oluşturulabilir.

#### DR sistemleri SOC tarafından izlenebilir mi?

Evet. DR firewall, sunucu, Active Directory ve diğer sistem logları SIEM/SOC altyapısına aktarılabilir.

#### Cloud üzerinde Disaster Recovery kurulabilir mi?

Evet. On-premise production sistemleri cloud üzerinde DR ortamına replike edilebilir veya cloud-to-cloud DR mimarisi kurulabilir.

### Kritik İş Sistemlerinizi SecureSys Disaster Recovery ile Kesintilere Hazırlayın

Backup almak kurumun verisini korur; ancak kritik sistemlerin gerçek bir felaket sonrasında hangi sırayla, hangi network üzerinde, hangi database ile ve ne kadar sürede tekrar çalışacağı önceden planlanmamışsa iş sürekliliği garanti altına alınmış olmaz.

SecureSys ile mevcut altyapınızı analiz edebilir, kritik sistemleriniz için RPO/RTO hedefleri oluşturabilir, Secondary Data Center veya Cloud DR mimarinizi kurabilir ve Disaster Recovery planınızı gerçek teknik testlerle doğrulayabilirsiniz.

Ransomware ve gelişmiş siber olaylar için Disaster Recovery yapınızı **Immutable Backup, Cold Backup, izole Recovery Network ve Clean Room** yaklaşımlarıyla güçlendirebilirsiniz.

**Felaket Kurtarma Merkezi, Disaster Recovery as a Service, Cloud DR, Secondary Data Center veya DR Test Hizmetleri hakkında detaylı bilgi almak için SecureSys ile iletişime geçin.**

**Felaket planınızı yalnızca dokümanda bırakmayın; test edilmiş, ölçülmüş ve gerçekten devreye alınabilir bir Disaster Recovery mimarisine dönüştürün.**