Felaket Kurtarma ve İş Sürekliliği (DR/BC) Rehberi [2026]

Felaket Kurtarma ve Is Surekliligi Neden Kritik?

Yazilim sistemlerinde kesinti, veri kaybi veya buyuk olcekli arizalar kacinilamaz risklerdir. Dogal afetler, donanim arizalari, siber saldirilar, insan hatalari ve yazilim hatalari her zaman bir felaket senaryosunu tetikleyebilir. Felaket kurtarma (Disaster Recovery, DR) ve is surekliligi (Business Continuity, BC) planlari bu risklere karsi kurumlarin dayanikliligini saglar.

2026 yilinda dijital donusum hizlanirken, sistemlerin kesintisiz calisma beklentisi de artmistir. Bir e-ticaret platformunda bir saatlik kesinti yuz binlerce liralik gelir kaybina, bir fintech uygulamasinda dakikalik bir kesinti yasal yaptirimlara yol acabilir. Saglik sektoru, bankacilik ve kamu hizmetleri gibi kritik alanlarda kesintinin sonuclari cok daha agir olabilir.

Is surekliligi plani olmayan sirketlerin buyuk bir felaket sonrasinda faaliyetlerini surmede ciddi guclukler yasadigi bilinmektedir. Arastirmalar, kapsamli bir DR plani olmayan isletmelerin buyuk olcekli bir kesinti sonrasinda onemli gelir kaybi yasadigini gostermektedir. Bu nedenle DR/BC planlamasi, teknik bir gereklilik olmanin otesinde kurumsal bir zorunluluktur.

RTO ve RPO Kavramlari

Recovery Time Objective (RTO)

RTO, bir felaket sonrasinda sistemlerin yeniden calisir hale gelmesi icin kabul edilebilir maksimum sureyi tanimlar. Ornegin dort saatlik bir RTO hedefi, felaket sonrasinda sistemlerin en gec dort saat icinde hizmete donmesi gerektigini ifade eder. RTO suresi ne kadar kisa ise, gereken altyapi yatirimi o kadar yuksek olur.

RTO hedeflerini belirlerken is birimlerinin gereksinimleri, gelir etkisi, yasal yukumlulukler ve musteri beklentileri dikkate alinmalidir. Her sistem icin farkli RTO degerleri tanimlanabilir. Kritik odeme sistemleri icin dakikalar mertebesinde RTO gerekirken, raporlama sistemleri icin saatler kabul edilebilir olabilir. Is etki analizi (BIA) yapilarak her sistemin kesinti maliyeti hesaplanmali ve RTO hedefleri buna gore belirlenmeli.

Recovery Point Objective (RPO)

RPO, kabul edilebilir maksimum veri kaybi suresini tanimlar. Bir saatlik RPO hedefi, felaket aninda en fazla son bir saatlik verinin kaybolabilecegini ifade eder. RPO degeri yedekleme sikligini dogrudan belirler. Bir saatlik RPO icin en az saatte bir yedekleme yapilmalidir.

Sifir RPO hedefi, hicbir veri kaybinin kabul edilemeyecegi anlamina gelir ve senkron replikasyon gerektirir. Bu hedef maliyet ve performans acisindan en pahali secenektir ancak finansal islemler, saglik kayitlari ve yasal belgeler gibi kritik veriler icin zorunlu olabilir. RPO ve RTO arasindaki iliski, DR stratejisinin secimini dogrudan etkiler.

DR Stratejileri

Yedekleme ve Geri Yukleme (Backup and Restore)

En temel ve en dusuk maliyetli DR stratejisidir. Veriler duzenli araliklarla yedeklenir ve felaket durumunda bu yedeklerden geri yuklenir. RTO ve RPO degerleri yuksektir; geri yukleme sureci saatler hatta gunler alabilir.

Bu strateji, dusuk kritiklik seviyesine sahip sistemler icin uygundur. Yedeklerin farkli bir bolgede veya bulut saglayicida saklanmasi onemlidir. Ayni veri merkezinde saklanan yedekler, veri merkezi capinda bir felaket durumunda islevsiz kalir. Duzenli geri yukleme testleri yapilarak yedeklerin butunlugu dogrulanmalidir. Kullanilmayan yedeklere guvenmek, yanlis bir guvenlik hissi yaratir.

Yedekleme stratejisi olustururken tam yedek (full backup), artimli yedek (incremental backup) ve farksal yedek (differential backup) yaklasimlarinin kombinasyonu degerlendirilmelidir. Ornegin haftalik tam yedek ve gunluk artimli yedek kombinasyonu yaygin bir yaklasimdir.

Pilot Light

Pilot light stratejisinde, kritik altyapi bilesenleri (veritabani replikasi gibi) hedef bolgede surekli calisir durumda tutulur, ancak uygulama sunuculari kapalidir. Felaket durumunda uygulama sunuculari hizla baslatilir ve trafik yonlendirilir. Bir pilotun uretim ortamina gecisi tipik olarak on ile otuz dakika arasinda gerceklesir.

Bu yaklasim, yedekleme ve geri yuklemeye kiyasla daha dusuk RTO saglar. Veritabani replikasyonu sayesinde RPO degeri de dusuktur, genellikle saniyeler mertebesindedir. Maliyet, yalnizca minimum altyapi bilesenlerinin surekli calismasi nedeniyle makul seviyededir. Infrastructure as Code (IaC) kullanarak uygulama katmaninin hizla ayaga kaldirilmasi bu stratejinin basarisi icin kritiktir.

Warm Standby

Warm standby stratejisinde, hedef bolgede uygulamanin kucultulmus bir kopyasi surekli calisir. Felaket durumunda kapasite arttirilir (olceklenir) ve trafik yonlendirilir. RTO dakikalar mertebesindedir cunku uygulama zaten calismaktadir; yalnizca olceklendirme gerekir.

Bu yaklasim, kritik uygulamalar icin iyi bir maliyet-performans dengesi sunar. Hedef bolgedeki sistem dusuk kapasitede calistigi icin maliyet tam bir kopya kadar yuksek degildir. Warm standby sistemi ayni zamanda okuma trafigini yonlendirmek icin de kullanilabilir, bu sayede normal zamanlarda da deger uretir.

Hot Standby ve Active-Active

En yuksek kullanilabilirlik seviyesini saglayan stratejidir. Uygulama birden fazla bolgede tam kapasite ile esanli olarak calisir. Trafik tum bolgeler arasinda dagitilir ve her bolge hem okuma hem yazma islemlerini isler. Bir bolge devre disi kaldiginda diger bolgeler otomatik olarak yuku devralir.

Active-active yaklasim, neredeyse sifir RTO ve sifir RPO saglar. Ancak en yuksek maliyetli secenektir ve veri tutarliligi yonetimi (ozellikle cok bolgeli yazma islemleri) karmasiktir. CAP teoremi cercevesinde tutarlilik ve kullanilabilirlik arasindaki denge dikkatle yonetilmelidir. Coklu bolge yazma islemlerinde catisma cozum stratejileri (conflict resolution) onceden belirlenmis olmalidir.

Bulut Tabanli DR Cozumleri

AWS DR Hizmetleri

AWS Elastic Disaster Recovery (DRS), surekli veri replikasyonu ile sunucularin baska bir bolgeye kurtarilmasini saglar. Blok duzeyinde replikasyon yaparak RPO'yu saniyeler mertebesine dusurur. Amazon S3 cross-region replication, RDS Multi-AZ ve Aurora Global Database gibi hizmetler DR altyapisinin temelini olusturur.

AWS Route 53 saglik kontrolleri ve otomatik failover yonlendirmesi ile DNS bazli trafik yonetimi saglanir. AWS Backup merkezi yedekleme yonetimi sunarak farkli hizmetlerin yedeklerini tek bir noktadan yonetmeye olanak tanir. AWS CloudFormation veya Terraform ile DR altyapisi kod olarak tanimlanmali ve otomatik kurulum saglanmalidir.

Azure DR Hizmetleri

Azure Site Recovery, sanal makinelerin bolgeler arasi replikasyonunu ve otomatik failover'ini saglar. Replikasyon surekli olarak yapilir ve failover tek tiklama ile gerceklestirilebilir. Azure SQL Database geo-replikasyon ve Azure Cosmos DB coklu bolge yazma destegi sunar. Azure Traffic Manager DNS bazli trafik yonlendirmesi ile kullanilabilirlik saglar.

Azure'un Availability Zones yapisi, ayni bolge icinde yuksek kullanilabilirlik saglarken, bolgeler arasi replikasyon felaket kurtarma icin kullanilir. Azure Backup ve Azure Archive Storage maliyet etkin yedekleme cozumleri sunar.

GCP DR Hizmetleri

Google Cloud, Cloud SQL replikasi, Cloud Spanner ile global olcekte guclu tutarlilik garantisi sunan veritabani ve Cloud Storage dual-region secenekleri sunar. Google Cloud Load Balancing global trafik yonlendirmesi saglar ve saglik kontrollerine gore otomatik failover gerceklestirir.

GCP'nin anycast IP adresleme yaklasimi, DNS TTL bekleme suresini ortadan kaldirarak daha hizli failover saglar. Cloud Functions ve Cloud Run gibi sunucusuz hizmetler, DR senaryolarinda hizli olceklendirme avantaji sunar.

Veritabani Yedekleme ve Zaman Noktasi Kurtarma

Veritabani katmani DR planinin en kritik bilesendir. Veri kaybi, diger tum altyapi bilesenlerinin kaybindan daha ciddi sonuclara yol acar. Duzenli tam yedeklemeler, artimli yedeklemeler ve transaction log yedeklemeleri planlanmalidir.

Point-in-time recovery (PITR) ozelligi, veritabanini belirli bir zaman noktasina geri yukleme imkani saglar. Bu ozellik ozellikle insan hatasi veya hatali veri guncellemesi durumlarinda kritik oneme sahiptir. Ornegin, yanlis bir DELETE sorgusu calistirildiginda PITR ile veritabani o sorgunun hemen oncesine geri yuklenebilir.

-- PostgreSQL PITR icin WAL arsivleme yapilandirmasi
-- postgresql.conf
-- archive_mode = on
-- archive_command = 'aws s3 cp %p s3://wal-archive/%f'
-- Kurtarma ornegi:
-- recovery_target_time = '2026-03-06 14:30:00'

Veritabani replikasyonu icin senkron ve asenkron secenekler mevcuttur. Senkron replikasyon sifir veri kaybi saglar ancak yazma performansini etkiler cunku her yazma islemi replika tarafindan onaylanana kadar beklenir. Asenkron replikasyon daha iyi performans sunar ancak az miktarda veri kaybi riski tasir. Yari senkron (semi-synchronous) replikasyon ise bu iki yaklasim arasinda bir denge sunar.

Bolgeler Arasi Replikasyon

Cross-region replikasyon, verilerin farkli cografi bolgelere kopyalanmasini saglar. Bu yaklasim hem DR hem de dusuk gecikmeli okuma islemleri icin kullanilir. Bolgeler arasi mesafe arttikca replikasyon gecikmesi de artar; bu durum RPO hesaplamalarinda dikkate alinmalidir.

Nesne depolama (S3, Azure Blob, GCS) icin cross-region replikasyon yapilandirilmalidir. Veritabani replikasyonu icin yonetilen hizmetlerin sundugu cok bolgeli cozumler tercih edilmelidir. Manuel replikasyon yapilandirmasi operasyonel karmasiklik yaratir ve hata riski tasir.

Replikasyon gecikmesi (replication lag) izlenmeli ve RPO hedefleriyle uyumlu olmasi saglanmalidir. Gecikme artislarinda alarm mekanizmalari devreye girmelidir. Smart Maple olarak DR projelerinde replikasyon gecikmesinin surekli izlenmesini ve alarm esik degerlerinin RPO hedefinin altinda tutulmasini onemsiyoruz.

Otomatik Failover ve Failback

Failover Sureci

Otomatik failover, birincil bolgenin devre disi kalmasi durumunda trafigi ikincil bolgeye otomatik olarak yonlendirir. Saglik kontrolleri (health checks) belirli araliklarla calisarak birincil bolgenin durumunu izler. Birden fazla saglik kontrol noktasi kullanilarak karar dogrulugu arttirilir.

DNS bazli failover en yaygin yontemdir. DNS TTL degerleri dusuk tutularak gecis suresi kisaltilir. Global load balancer kullanan cozumler DNS'e gore daha hizli failover saglar cunku DNS onbellekleme gecikmesinden etkilenmez.

Otomatik failover yapilandirilirken yanlis pozitif alarmlar onlenmelidir. Birden fazla saglik kontrolu noktasi kullanilarak, gecici ag sorunlarinin gereksiz failover tetiklemesi engellenir. Failover kararinin otomatik mi yoksa yari otomatik mi (insan onayi ile) alinacagi onceden belirlenmeli ve dokumante edilmelidir.

Failback Sureci

Birincil bolge onarildiktan sonra trafigi geri yonlendirme sureci olan failback, failover kadar kritiktir ve genellikle daha karmasiktir. Veri senkronizasyonunun tamamlanmasi, birincil bolgenin saglik kontrollerinin basarili olmasi ve kademeli trafik geri yonlendirmesi adimlarini icerir.

Failback sirasinda veri catismalarinin cozulme stratejisi onceden belirlenmis olmalidir. Felaket surecinde ikincil bolgede yeni veriler olusmus olabilir; bu verilerin birincil bolge ile senkronize edilmesi gerekir. "Son yazan kazanir", "birlestirme kurallari" veya "cakisma kaydi olusturma" gibi yaklasimlar is gereksinimlerine gore secilmelidir.

DR Testi ve Kaos Muhendisligi Entegrasyonu

DR plani duzenli olarak test edilmelidir. Test edilmeyen bir DR plani, guvence saglamaz ve yanlis bir guvenlik hissi yaratir. Farkli test seviyeleri uygulanmalidir.

Masa basi egitimler (tabletop exercises), ekibin felaket senaryolarini teorik olarak tartismasi ve plani gozden gecirmesidir. Dusuk maliyetli ve sik yapilabilir. Teknik testler, yedekleme geri yukleme, failover ve failback islemlerinin teknik olarak dogrulanmasidir. Belirli bilesenlerin izole olarak test edilmesini icerir. Tam olcekli DR testleri ise gercek bir felaket senaryosunun simule edilmesidir. Yilda en az bir kez yapilmali ve tum ekiplerin katilimiyla gerceklestirilmelidir.

Kaos muhendisligi prensipleri DR testlerine entegre edilmelidir. Plansiz kesintiler simule edilerek sistemlerin gercek dayanikliligi olculmelidir. Netflix'in Chaos Monkey araci ve AWS Fault Injection Simulator gibi araclari bu amacla kullanilabilir.

Runbook Olusturma

DR runbook'lari, felaket durumunda izlenecek adim adim prosedurler icerir. Her runbook acik, anlasilir ve teknik bilgi seviyesinden bagimsiz olarak uygulanabilir olmalidir. Stres altindaki bir muhendis, runbook'u takip ederek kurtarma islemini basariyla tamamlayabilmelidir.

Bir DR runbook'u su bolumleri icermelidir: Felaket tespiti ve siniflandirmasi (ciddiyet seviyeleri ve tetikleyiciler), bildirim ve eskalasyon proseduru (kim, ne zaman, nasil bilgilendirilecek), karar verme matrisi (hangi durumda hangi DR stratejisi uygulanacak), adim adim kurtarma islemleri (ekran goruntuleri ve komut ornekleri ile), dogrulama ve test kontrol listesi (kurtarma sonrasi dogrulama adimlari) ve iletisim sablonlari (ic ve dis paylasim bildirim metinleri).

Runbook'lar surekli guncellenmeli ve her DR testinden sonra gozden gecirilmelidir. Otomasyon araclari ile runbook adimlarinin mumkun oldugunca otomatiklestirilmesi insan hatasi riskini azaltir. Ansible, Terraform ve AWS Systems Manager gibi araclar runbook otomasyonu icin kullanilabilir.

Felaket Sirasinda Iletisim

Felaket durumunda etkili iletisim, teknik kurtarma kadar onemlidir. Iletisim bozuklugu, teknik sorunun ustune operasyonel kaos ekler. Ic iletisim planinda kimlerin bilgilendirilecegi, hangi kanallarin kullanilacagi ve eskalasyon zinciri tanimlanmalidir. Birincil iletisim kanali devre disi kalirsa yedek kanallar hazir olmalidir.

Dis iletisim planinda musterilere, is ortaklarina ve gerektiginde duzenleyici kurumlara bilgilendirme yapilmalidir. Durum sayfasi (status page) guncelleme proseduru belirlenmeli ve iletisim sablonlari onceden hazirlanmalidir. Seffaf ve duzenli iletisim, musteri guvenini korumak icin esastir.

Uyumluluk Gereksinimleri

KVKK Veri Yerlesimi

Turkiye'de KVKK kapsaminda kisisel verilerin yurt disina aktariminda belirli sartlarin saglanmasi gerekmektedir. DR planlari olusturulurken veri yerlesim gereksinimleri dikkate alinmalidir. Yedekleme ve replikasyon hedef bolgeleri KVKK uyumlu olmalidir. Yurt disindaki bir DR bolgesine kisisel veri replike edilmesi, KVKK cercevesinde acik riza veya yeterli koruma kosullarini gerektirir.

Finansal Sektor Duzenlemeleri

BDDK duzenlemeleri kapsaminda bankacilik ve finansal kuruluslar icin belirli DR gereksinimleri mevcuttur. Maksimum RTO ve RPO degerleri, DR test sikligi ve raporlama yukumlulukleri yasal cerceve ile belirlenmistir. Finansal kuruluslar yilda en az bir kez kapsamli DR testi yapmak ve sonuclarini duzenleyiciye raporlamak zorundadir.

Sektorel Standartlar

ISO 22301 Is Surekliligi Yonetim Sistemi standardina uyum, kurumsal olgunlugun bir gostergesidir. Bu standart, is surekliligi politikasi, risk degerlendirmesi, strateji belirleme, plan olusturma, test ve iyilestirme dongulerini kapsar. Sertifikasyon surecinin yaninda, standardin en iyi uygulamalarinin benimsenmesi kurumsal dayanikliligi arttirir.

DR Maliyet Optimizasyonu

DR maliyetini optimize etmek icin katmanli bir yaklasim benimsenmelidir. Kritik sistemler icin hot standby, orta oncelikli sistemler icin warm standby veya pilot light, dusuk oncelikli sistemler icin yedekleme ve geri yukleme stratejisi uygulanmalidir. Bu katmanli yaklasim, sinirli butceyi en etkili sekilde kullanmayi saglar.

Multi-cloud ve hibrit bulut stratejileri, DR maliyetini optimize etmek ve tek bir saglayiciya bagimlilik riskini azaltmak icin degerlendirilmelidir. Farkli bulut saglayicilari DR hedefi olarak kullanmak, saglayici bazli kesintilere karsi ek koruma saglar.

Bulut saglayicilarin sundugu reserve instance ve spot instance secenekleri, DR altyapi maliyetini dusurur. Ayrica Infrastructure as Code (IaC) ile DR altyapisinin otomatik olarak kurulup kaldirilmasi maliyet tasarrufu saglar. Pilot light stratejisinde uygulama sunuculari yalnizca ihtiyac duyuldugunda baslatilarak maliyet minimumda tutulur.

Is Surekliligi Plani (BCP) Cercevesi

Bir BCP su temel bilesenleri icermelidir: Is etki analizi (BIA) ile kritik is sureclerinin ve bagimliliklarin belirlenmesi, risk degerlendirmesi ile olasi tehditlerin ve olasiklarinin analizi, strateji belirleme ile her kritik sistem icin uygun DR stratejisinin secimi, plan dokumantasyonu ile detayli kurtarma prosedurlerinin yazilmasi, test ve egitim ile duzenli DR testleri ve personel egitimlerinin planlanmasi ve surekli iyilestirme ile test sonuclarindan ogrenilen derslerin plana yansitilmasi.

BCP, yalnizca teknolojiyi degil, insanlari ve surecleri de kapsamalidir. Ofis erisilemez oldugunda uzaktan calisma plani, anahtar personelin devamsizliginda yedek sorumluluklar ve tedarik zinciri kesintilerinde alternatif planlar BCP'nin parcasidir.

Sonuc

Felaket kurtarma ve is surekliligi planlamasi, modern yazilim sistemlerinin vazgecilmez bir bilesenidir. RTO ve RPO hedeflerinin dogru belirlenmesi, uygun DR stratejisinin secilmesi ve duzenli testler ile planin dogrulanmasi basarili bir DR/BC programinin temelini olusturur.

Her kurum kendi risk profili, butcesi ve yasal yukumlulukleri cercevesinde DR/BC stratejisini olusturmalidir. Onemli olan, bir felaket durumunda ne yapilacaginin onceden planlanmis ve test edilmis olmasi, ekiplerin rolleri ve sorumluluklari konusunda net olmasi ve iletisim planinin hazir olmasidir. Felaket kurtarma, bir sigorta policesi gibidir; hicbir zaman kullanilmamasi en iyi senaryo olsa da, ihtiyac duyuldugunda hazir olmasi hayati onem tasir.