Özet: Felaket kurtarma merkezi (DR site), birincil veri merkezi devre dışı kaldığında üretim iş yüklerini devralacak şekilde önceden hazırlanmış ikincil bir altyapıdır. RTO ve RPO hedefleri üzerinden seçilen hot, warm veya cold site modeli, mimari karmaşıklığı ve maliyeti doğrudan belirler. Türkiye'de bankacılık, sigorta ve regüle sektörler için BDDK Bilgi Sistemleri Yönetmeliği ve ISO 22301 standartları DR mimarisini yasal bir zorunluluk haline getirir.
Ana noktalar:
- Hot site dakikalar içinde, warm site saatler içinde, cold site günler içinde devreye girer.
- RTO hedefini düşürmek mimari karmaşıklığı ve maliyeti üstel olarak artırır.
- Modern ransomware saldırıları yedekleri de hedef aldığından immutable backup ve air-gap katmanı zorunludur.
- Bulut tabanlı DRaaS, çoğu senaryoda kendi DR merkezini kurmaktan %40-60 daha ekonomik bir TCO sağlar.
- BDDK ikincil veri merkezini ve yıllık failover tatbikatlarını yasal zorunluluk olarak tanımlar.
Bir veri merkezi yangını, bir fiber kesintisi ya da bir ransomware saldırısı, üretimin durduğu o ilk saatte tüm sorumluluğu BT yönetiminin üzerine yıkar. Yedeklerin var olması yetmez; bunların başka bir lokasyondan, denenmiş bir prosedürle, kabul edilebilir bir süre içinde ayağa kalkması gerekir. Felaket kurtarma merkezi tam olarak bu boşluğu doldurur: birincil sistemler kullanılamaz hale geldiğinde iş yüklerinin çalışmaya devam ettiği fiziksel veya bulut tabanlı ikinci konum.
Bu rehber, Türkiye'deki orta ve büyük ölçekli işletmelerin BT yöneticileri, altyapı mimarları ve risk yönetimi sorumluları için yazıldı. Hot, warm ve cold site arasındaki gerçek farkları, RTO/RPO hedeflerinin nasıl belirlendiğini, kendi DR merkezini kurmakla DRaaS satın almak arasındaki TCO denklemini ve BDDK, KVKK gibi yerel yasal gereklilikleri tek bir çatı altında ele alıyoruz.
Hedef şu: bu rehberi okuduktan sonra "bizim için doğru DR modeli nedir, hangi sistem hangi kritiklikte olmalı, kurulum ve test planı nasıl yazılır" sorularına net cevap verebilmeniz.
Felaket kurtarma merkezi nedir?
Felaket kurtarma merkezi (DR center, DR site), birincil veri merkezi devre dışı kaldığında üretim iş yüklerini devralacak şekilde önceden hazırlanmış ikincil bir altyapıdır. Sunucu donanımı, ağ bağlantısı, depolama, replike edilmiş veri ve devreye alma prosedürleri tek bir yerde bir araya gelir. Klasik anlamda fiziksel bir bina olabileceği gibi, modern senaryoda bir bulut bölgesi de bu rolü üstlenebilir.
Tanım: DR site, DR center ve ikincil veri merkezi
DR site, DR center ve ikincil veri merkezi terimleri çoğunlukla birbirinin yerine kullanılır. Tümünün ortak noktası: birincil konumdan bağımsız bir altyapı bulundurmak. Aralarındaki ince ayrım daha çok rol bazlıdır. "DR site" terimi, sadece felaket anında devreye giren pasif bir konumu çağrıştırır. "İkincil veri merkezi" ise active/active mimarilerde sürekli yük taşıyan, eşit kapasiteli bir kardeş konumu da kapsayabilir.
Pratikte mimar için önemli olan terim değil, mimari karardır: bu konum aktif mi pasif mi olacak, hangi RTO/RPO'yu karşılayacak, kim tarafından işletilecek? Bu soruların cevapları ürünün adından çok daha belirleyicidir.
Birincil veri merkezi ile farkı
Birincil veri merkezi, gündelik üretim yükünü taşır. DR merkezi, normal koşullarda boştadır veya sadece replikasyon ve test trafiği görür. İki konum arasında fiziksel mesafe esastır; aynı bina hatta aynı şehirdeki iki tesis, bölgesel bir felaketten birlikte etkilenebilir. Endüstri standardı, en az 50–100 km arasında bir mesafe ve farklı elektrik/fiber besleme öner.
Bir diğer fark işletme felsefesinde: birincil veri merkezinde değişiklikler dinamiktir, sürekli deployment'lar olur. DR merkezi ise sıkı sürüm kontrolü ister; replikasyon dışında manuel değişiklik yasaktır, aksi halde failover anında farklı bir sistem ayağa kalkar.
Felaket kurtarma planı (DRP) ile ilişkisi
DR merkezi, felaket kurtarma planının (Disaster Recovery Plan) fiziksel/altyapısal ayağıdır. DRP ise bu altyapıyı ne zaman, nasıl, kim tarafından devreye alınacağını anlatan dokümandır. Sadece DR merkezi kurmak yetmez; devreye alma adımları, iletişim akışı, yetki matrisleri, roll-back kriterleri yazılı olmalı ve düzenli tatbikat edilmelidir.
İyi yazılmış bir DRP, gece 03:00'te tatildeki BT müdürü ulaşılamadığında bile nöbetçi mühendisin tek başına failover'ı başlatabilmesini sağlar. Aksi halde milyonlarca liralık DR yatırımı, "kim çalıştıracak?" sorusunda takılır.
Neden bir felaket kurtarma merkezine ihtiyaç var?
Bir DR merkezinin maliyeti, "neden olmasın?" sorusu değil; "olmazsa kaç saatlik kesinti, kaç müşteri ve kaç sözleşme kaybedersiniz?" sorusu üzerinden değerlendirilir.
Doğal afet, yangın ve donanım arızası senaryoları
Türkiye, deprem riski yüksek bir coğrafyada bulunuyor. 1999 Marmara depremi bölgedeki birçok BT operasyonunu doğrudan etkiledi; 2023 Kahramanmaraş depreminden sonra da bölge ekonomisinin BT bileşeni saatlerce-günlerce kesintiye uğradı. Bunun dışında yangın, sel, fiber hattının inşaat sırasında kesilmesi ve UPS/jeneratör arızaları gibi "daha yerel" olaylar da tek başına bir veri merkezini saatlerce işlemez hale getirebilir.
Donanım arızası tarafında klasik tek sunucu çökmeleri, RAID kontrolcüsünün veriyi bozması, storage kontrolcüsünün firmware bug'ı gibi durumlar yedeklemeyle çözülür ama veri merkezi seviyesinde bir SAN ya da omurga switch arızası, ancak ayrı konumdaki bir DR site ile telafi edilebilir.
Siber saldırılar ve ransomware
2026 itibarıyla ransomware artık tekil dosyaları değil; yedeklerle birlikte production storage ve yedek storage'ı eş zamanlı şifreleyen, hatta vSphere hipervizörünü hedefleyen saldırılara dönüştü — ENISA Tehdit Görünümü raporları bu eğilimi son yıllarda kurumsal ortamlardaki başlıca tehdit olarak değerlendiriyor. Bu nedenle aynı yönetim düzleminde duran yedekler ve aynı bölgedeki DR site bile yetersiz kalabiliyor.
Modern DR mimarisi, immutable (değiştirilemez) yedekleri ayrı bir hesap/kimlik düzleminde, mümkünse coğrafi olarak ayrı bir konumda tutar. Air-gap yaklaşımı ve düzenli "temiz odadan restore" testleri bu tür saldırılara karşı tek gerçek savunmadır.
İş sürekliliği (BCP) ve marka itibarı
Bir bankanın internet şubesinin 4 saatlik kesintisi sadece teknik bir olay değil, regülatör bildirimi, basın açıklaması, müşteri kaybı ve uzun vadeli itibar zararıdır. E-ticarette aynı 4 saat, üst düzey kampanya gününde milyonlarca liralık satış kaybı demektir. DR merkezi yatırımı, BCP (Business Continuity Plan) çerçevesinde sigorta benzeri bir kalemdir.
DR merkezi türleri: Hot, Warm ve Cold Site
DR site sınıflandırması, ne kadar hızlı devreye alınabildiğine ve ne kadar maliyetli olduğuna göre üç ana modele oturur. Doğru model, sistem kritikliğine göre seçilir; hatta tek bir kuruluş içinde farklı sistemler farklı modelde çalıştırılır.
Hot site: gerçek zamanlı replikasyon, dakikalar içinde devreye alma
Hot site, birincil veri merkeziyle sürekli senkronizasyon halinde olan, çoğunlukla "hazır" durumda bekleyen tam ölçekli ikinci konumdur. Veri replikasyonu çoğu zaman senkron veya yakın senkrondur. Failover dakikalar, hatta saniyeler içinde gerçekleşebilir. RTO genellikle 15 dakika altı, RPO ise sıfıra yakın hedeflenir.
Maliyet yüksektir: ikinci konumda sürekli açık donanım, lisans, ağ ve operasyon ekibi gerekir. Bankacılık core sistemleri, ödeme ağ geçitleri, kritik üretim hatları için tercih edilir.
Warm site: kısmi hazır altyapı, saatler içinde devreye alma
Warm site'ta donanım ve ağ hazırdır ama uygulamalar tam çalışır durumda değildir. Veri replikasyonu genelde asenkrondur; son yedek ya da son birkaç saatin replike edilmiş hali bulunur. Failover sırasında işletim sistemi başlatılır, yedekler geri yüklenir, DNS değiştirilir. Süre tipik olarak 2–8 saattir.
Maliyet hot site'ın yarısı veya daha azıdır. ERP, CRM, e-ticaret gibi kritik ama dakikalık RTO gerektirmeyen sistemler için yaygın bir tercihtir.
Cold site: yalnızca temel altyapı, günler içinde devreye alma
Cold site, sadece elektrik, soğutma, ağ omurgası gibi temel altyapı bulunduran bir konumdur. Donanım ve veri felaket anında getirilip kurulur. Devreye alma süresi günlerle ölçülür.
Maliyet en düşüktür. Sadece arşiv sistemleri, geliştirme/test ortamları veya çok düşük öncelikli iş yükleri için anlamlıdır. 2026'da pek çok kuruluş cold site yerine bulut tabanlı DRaaS modelini tercih ediyor; çünkü bulut, cold site'ın düşük maliyetini warm/hot site'ın hızıyla birleştirebiliyor.
Maliyet ve RTO karşılaştırması
| Model | RTO | RPO | Maliyet endeksi | Uygun iş yükü |
|---|---|---|---|---|
| Hot site | < 15 dk | ~0 | 100 | Core banking, ödeme, üretim hattı |
| Warm site | 1–8 saat | 15 dk–4 saat | 40 | ERP, CRM, e-ticaret |
| Cold site | 24–72 saat | 4–24 saat | 10 | Arşiv, test ortamları |
| Bulut DRaaS (warm) | 30 dk–2 saat | 1 dk–1 saat | 25 | Genel kurumsal |
RTO ve RPO: hedeflerinizi nasıl belirlersiniz?
RTO ve RPO, DR yatırımının iki ana ekseni. Bütün karar matrisi bu iki sayıdan türetilir.
RTO (Recovery Time Objective) tanımı
RTO, bir kesinti başladıktan sonra sistemin tekrar çalışır hale gelmesi için izin verilen maksimum süredir. 15 dakika RTO demek, "kesintiden 15 dakika sonra kullanıcı yeniden işlem yapabilmeli" demektir. RTO ne kadar düşükse, gerekli yatırım ve mimari karmaşıklık o kadar yüksektir.
RTO sadece teknik bir hedef değil, iş kararıdır. CFO, ürün ve operasyon birlikte oturup "1 saatlik kesinti bize ne kaybettirir" sorusunu cevaplamalı, RTO bu cevaba göre belirlenmelidir.
RPO (Recovery Point Objective) tanımı
RPO, kaybedilebilecek maksimum veri miktarını zamanla ifade eder. 15 dakika RPO demek, "felaket öncesi son 15 dakikalık veriyi kaybedebiliriz" demektir. Bunu sıfıra yaklaştırmak senkron replikasyon ve genelde yüksek bant genişliği ister, dolayısıyla maliyet katlanır.
RPO ile birlikte sıkça kullanılan bir kavram MTPD'dir (Maximum Tolerable Period of Disruption): kuruluşun ayakta kalması için kesintinin asla aşmaması gereken üst sınır. RTO + ek tolerans, MTPD'yi aşmamalıdır.
Sistem kritikliğine göre hedef tablosu (ERP, CRM, e-posta)
| Sistem | Kritiklik | Önerilen RTO | Önerilen RPO |
|---|---|---|---|
| Core banking / ödeme | Tier-0 | < 15 dk | ~0 |
| ERP üretim ortamı | Tier-1 | 1–2 saat | 15 dk |
| E-ticaret platformu | Tier-1 | 30 dk–1 saat | 5–15 dk |
| CRM | Tier-2 | 2–4 saat | 1 saat |
| Kurumsal e-posta | Tier-2 | 4 saat | 1 saat |
| Dosya sunucusu | Tier-3 | 8–24 saat | 4–24 saat |
| Geliştirme/test | Tier-4 | 24–72 saat | 24 saat |
Bu tablo başlangıç noktasıdır; her kuruluş kendi iş etki analizine (BIA) göre uyarlamalıdır.
DR merkezi mimarisi: temel bileşenler
DR merkezi mimarisi dört ana bileşen etrafında şekillenir.
Veri replikasyonu (senkron / asenkron)
Senkron replikasyon, her yazma işleminin birincil ve ikincil konuma aynı anda yazılıp onaylanmasını ister. RPO sıfırdır ama yazma gecikmesi iki konum arası fiziksel mesafeyle doğrudan artar. Pratik kullanım için iki konum arası mesafe genelde 50–100 km altıdır.
Asenkron replikasyon, yazma işleminin birincil tarafta hızlıca onaylandıktan sonra arka planda ikincil tarafa kopyalandığı modeldir. Gecikme uygulamayı yavaşlatmaz, mesafe sınırı yumuşar; ama RPO sıfır olamaz. Kıtalararası DR genelde asenkron yapılır.
Ağ ve DNS failover
Failover sırasında trafiğin yeni konuma yönlendirilmesi gerekir. Yaygın yöntemler: DNS TTL'lerini düşük tutup A kayıtlarını değiştirmek, anycast IP kullanmak, küresel yük dengeleyiciler ile sağlık kontrolüne göre otomatik yönlendirme. DNS değişiklikleri caching nedeniyle her zaman istenen hızda yayılmaz; bu yüzden DNS bazlı failover, dakikalar mertebesinde RTO için uygundur, saniyeler için yetersizdir.
VPN ve site-to-site bağlantıların failover sonrası da çalışacak şekilde yapılandırılması, sıklıkla atlanan ama operasyonel olarak kritik bir kalemdir.
Yedek depolama ve immutable backup
DR site'ın replike ettiği veri, ransomware ile birlikte şifrelenmiş veri olabilir. Bu nedenle DR mimarisi mutlaka immutable yedekleme katmanı içermelidir. S3 Object Lock, WORM özelliği aktif tape veya ayrı kimlik düzlemindeki yedek hesap, bu katmanın klasik uygulamalarıdır.
3-2-1-1-0 kuralı sektörde standart: 3 kopya, 2 farklı medya, 1 offsite, 1 immutable, 0 doğrulanmamış geri yükleme.
Runbook ve otomasyon
Failover prosedürü adım adım yazılmalı (runbook) ve mümkün olan adımlar otomasyona alınmalıdır. Manuel adımlar gece 03:00 baskısında hata yapar. Terraform, Ansible, vSphere SRM veya Veeam Orchestrator gibi araçlar, failover'ı tek komuta indirgeyebilir.
Runbook her değişiklikte güncellenmeli; aksi halde 6 ay sonra failover anında "bu IP nereden geliyor?" anı yaşanır.
Kendi DR merkezini kurmak mı, DRaaS mi?
DR kararı klasik bir CAPEX/OPEX seçimidir, ama 2026'da denklem büyük ölçüde DRaaS lehine kayıyor.
Sermaye yatırımı (CAPEX) ile bulut tabanlı (OPEX) karşılaştırması
Kendi DR merkezini kurmak, fiziksel veya kira alan, donanım, lisans, ağ, güvenlik, soğutma, elektrik ve operasyon ekibi yatırımı demektir. Tipik orta ölçekli bir kuruluş için kurulum maliyeti milyonlarca TL'yi bulur, üzerine yıllık işletme gideri eklenir.
DRaaS modeli ise iş yükü başına aylık abonelik mantığı sunar. Atıl kapasite ödenmez; replikasyon ve standby kaynaklar kullanıldıkça veya rezerve edildikçe faturalanır. 3 yıllık TCO hesabında çoğu senaryoda DRaaS, kendi merkezini kurmaktan yüzde 40–60 daha ekonomik çıkar.
DRaaS modelinin avantajları
DRaaS, mimari kararların büyük kısmını sağlayıcı tarafa devreder. Replikasyon yazılımı, hipervizör uyumluluğu, ağ failover, runbook çatısı önceden hazırdır. Müşteri sadece kendi iş yüklerini koruma kapsamına alır ve test takvimini belirler.
Bir diğer avantaj coğrafi seçeneklerin genişlemesidir: kendi DR merkezi için ikinci şehre fiziksel bir tesis kurmak çok büyük yatırımdır; DRaaS sağlayıcısı zaten farklı şehirlerde bölgelere sahiptir, müşteri bir tıkla bunu kullanabilir.
Hibrit senaryolar
Bütün iş yüklerini DRaaS'a taşımak zorunlu değildir. Yaygın bir hibrit yaklaşım: Tier-0 sistemler kendi ikinci veri merkezinde hot site olarak, Tier-1 ve Tier-2 sistemler bulutta DRaaS warm site olarak, Tier-3 sistemler bulutta immutable backup ile pasif olarak korunur. Bu yaklaşım hem maliyeti optimize eder hem de kritik sistemler için tam kontrol sağlar.
Türkiye'de yasal gereklilikler
DR mimarisi, regülasyon altındaki sektörlerde teknik tercih değil yasal zorunluluktur.
BDDK Bilgi Sistemleri Yönetmeliği (finans sektörü)
BDDK Bilgi Sistemleri ve Elektronik Bankacılık Hizmetleri Yönetmeliği, bankalar ve finansal kuruluşlar için ikincil veri merkezi ve düzenli iş sürekliliği testleri zorunluluğu getirir. Coğrafi ayrım, RTO/RPO hedefleri, yıllık tatbikat raporları ve regülatöre bildirim yükümlülükleri belirlenmiştir. Uyumsuzluk para cezası ve faaliyet kısıtlamasına kadar varabilir.
KVKK kapsamında veri erişilebilirliği
KVKK, kişisel verinin korunmasını sadece gizlilik (confidentiality) ile değil, erişilebilirlik (availability) ile de tanımlar. Veri sahibinin haklarını kullanabilmesi için kişisel veriler erişilebilir tutulmalıdır. Ciddi bir veri merkezi kesintisinde verinin haftalarca erişilemez kalması, KVKK uyumsuzluğu yorumlanabilir.
ISO 22301 iş sürekliliği yönetimi
ISO 22301 sertifikası, iş sürekliliği yönetim sisteminin uluslararası standardıdır. Pek çok kurumsal müşteri ve ihale tedarikçilerinden bu sertifikayı talep eder. Sertifika sürecinde DR mimarisi ve test sıklığı denetlenir.
Coğrafi mesafe gereksinimleri
BDDK ve birçok kurumsal politika, birincil ve ikincil veri merkezi arasında "aynı doğal afet bölgesinde olmama" şartı arar. Pratikte bu, en az 50–100 km mesafe ve farklı fay hatları/elektrik şebekesi demektir. Türkiye'de İstanbul–Ankara, İstanbul–İzmir, İstanbul–Bursa eksenleri yaygın tercihtir.
DR testleri ve düzenli tatbikatlar
Test edilmemiş DR planı, plan değildir.
Tabletop testler
Tabletop test, ekibin masa başında "şu an birincil veri merkezimiz çöktü, sırasıyla ne yapıyoruz?" sorusunu canlandırdığı düşünce tatbikatıdır. Çeyrekte bir yapılması yaygındır. Doküman tutarsızlıkları, kontak listelerinin eskimişliği, runbook'taki belirsizlikler burada ortaya çıkar.
Failover ve failback tatbikatları
Asıl test, gerçek failover'dır. Yılda en az bir kez, kontrollü bir pencere içinde DR site'a tam geçiş yapılmalı, kullanıcı kabul testi koşulmalı ve sonra failback yapılarak birincil konuma dönülmelidir. BDDK gibi regülatörler bu testin raporlanmasını talep eder.
Test sonuçlarının raporlanması
Her test bir rapora dönüşmeli: süreler ölçülmüş (RTO hedefe ulaşıldı mı?), kaybedilen veri ölçülmüş (RPO hedefe ulaşıldı mı?), sorunlar listelenmiş ve aksiyon planı atanmış olmalı. Bu raporlar denetimlerde belge olarak kullanılır ve mimarinin sürekli iyileştirilmesini sağlar.
Sıkça sorulan sorular (SSS)
DR merkezi ile yedekleme aynı şey midir?
Hayır; yedekleme yalnızca verinin kopyasını saklarken DR merkezi hesaplama, ağ, kimlik ve uygulama altyapısını da yedek konumda hazır tutar. Yedekleme, DR'nin gerekli ama tek başına yetersiz bir bileşenidir; felaket anında veriden çok daha fazlasına ihtiyaç duyulur.
Küçük işletmeler için DR merkezi gerekli mi?
Evet, ancak kendi DR merkezi yerine bulut tabanlı DRaaS modeli küçük işletmeler için doğru tercihtir. Aylık birkaç bin TL'den başlayan paketler erişilebilir; küçük işletmelerde bir kesintinin etkisi orantısal olarak büyük işletmelere göre çok daha yıkıcı olabilir.
DRaaS hizmetinin fiyatı nasıl hesaplanır?
DRaaS fiyatı korunan VM sayısı, replike edilen veri miktarı (TB), hedeflenen RTO/RPO ve standby kaynaklarına göre belirlenir. Düşük RTO ve yüksek veri hacmi maliyeti artırır; test sıklığı ve runbook karmaşıklığı profesyonel hizmet kalemi olarak ayrıca faturalandırılabilir.
Cloud4U Türkiye DRaaS ile felaket kurtarma merkezinizi bulutta kurun
Felaket kurtarma merkezi kurmak için artık ikinci bir bina kiralamak, donanım almak ve 7/24 vardiyalı ekip kurmak zorunda değilsiniz. Cloud4U Türkiye DRaaS hizmeti, ikincil veri merkezinizi bulutta hazır şekilde sunar; sadece koruma kapsamını ve hedef RTO/RPO'yu belirlemeniz yeterlidir.
- Türkiye veri merkezi ve KVKK uyumlu DR mimarisi: Verileriniz Türkiye sınırlarında, ikincil bölge ayrımı ile saklanır; KVKK, BDDK ve ISO 22301 uyum süreçlerinizde belgelenebilir bir DR mimarisi sunar.
- 7/24 Türkçe destek ve düzenli failover testleri: Her aşamada Türkçe konuşan kıdemli mühendislerle çalışır, yılda en az bir kez planlı failover/failback tatbikatı yaparsınız.
- Esnek RTO/RPO seçenekleri: Tier-0 sistemler için dakikalar mertebesinde hot DR'dan, Tier-3 sistemler için ekonomik immutable backup modeline kadar tek bir sağlayıcıda hibrit mimari kurabilirsiniz.
İş sürekliliğinizi şansa bırakmamak için Cloud4U Türkiye DRaaS sayfasını ziyaret edin, ücretsiz mimari danışmanlığı ve fiyat teklifi alın. Mevcut sistemlerinizin kritiklik analizini birlikte yaparak size uygun RTO/RPO hedeflerine dayalı bir DR planı çıkarıyoruz.
