Bulut Tabanlı Olağanüstü Durum Kurtarma (Disaster Recovery)

Bir sistemin yedeğini almak önemlidir, ancak gerçek bir kesinti başladığında asıl soru şudur: Hizmeti ne kadar sürede yeniden çalışır hâle getirebilirsiniz ve bu sırada ne kadar veri kaybetmeyi göze alabilirsiniz? Bulut Tabanlı Olağanüstü Durum Kurtarma (Disaster Recovery), bu sorulara ölçülebilir ve test edilebilir yanıtlar üretmek için kullanılan teknik ve operasyonel yaklaşımı ifade eder. İyi tasarlanmış bir yapı yalnızca sunucuların kopyasını tutmaz; kimlik servislerinden DNS'e, veritabanından ağ kurallarına, sertifikalardan uygulama bağımlılıklarına kadar hizmetin gerçekten çalışması için gereken bütün parçaları hesaba katar. Yaklaşık on yıllık altyapı ve iş sürekliliği çalışmalarında sık gördüğüm temel hata, kurumların yedekleme sistemi kurduktan sonra kurtarma planının da tamamlandığını düşünmesidir. Oysa test edilmemiş bir kurtarma planı, kritik anda çalışıp çalışmayacağı bilinmeyen bir varsayımdan fazlası değildir.

Bu rehberde bulut tabanlı disaster recovery planı nasıl hazırlanır, cloud disaster recovery RPO ve RTO değerleri nasıl belirlenir, bulut ortamında backup failover replikasyon ve felaket kurtarma testi nasıl yapılır gibi pratik soruları adım adım ele alacağız. Ayrıca kurumsal bulut disaster recovery ve iş sürekliliği hizmeti seçerken hangi teknik kriterlere bakılması gerektiğini, bulut disaster recovery danışmanlığı yakınımda aramasının ötesinde gerçekten hangi uzmanlıkların sorgulanması gerektiğini açıklayacağız. Altyapı değişikliklerinin kurtarma ortamına yansıtılması özellikle önemli olduğu için geliştirme, staging ve production ortamlarının uyumu konusunda https://www.diyarbakiryazilim.com.tr/posts/gelistirme-staging-ve-production-ortamlarinin-senkronizasyonu içeriği de tamamlayıcı bir bakış sunar. Buradaki amaç teorik terimleri sıralamak değil, gerçek bir kesinti sırasında uygulanabilecek bir karar modeli oluşturmaktır. Rehberin sonunda elinizde varlık envanterinden failback testine kadar uzanan uygulanabilir bir yol haritası bulunacaktır.

Bulut Tabanlı Olağanüstü Durum Kurtarma Nedir?

Bulut tabanlı kurtarma, birincil sistemlerin çalışamaz hâle gelmesi durumunda iş yüklerinin önceden tanımlanmış başka bir ortamda yeniden erişilebilir olmasını sağlayan süreçlerin bütünüdür. Bu ortam başka bir bölge, farklı bir veri merkezi, ayrı bir hesap veya bağımsız bir bulut altyapısı olabilir. Temel amaç yalnızca veriyi saklamak değil, iş hizmetini kabul edilebilir sürede yeniden kullanıma açmaktır. Bu nedenle kurtarma stratejisi teknik ekiplerin tek başına verdiği bir altyapı kararı değildir. İş birimleri, güvenlik, finans, hukuk ve operasyon ekipleri de hedefleri birlikte belirlemelidir.

Disaster Recovery Ne Anlama Gelir?

Disaster Recovery, beklenmeyen bir olay sonrasında bilgi sistemlerini ve bunlara bağlı iş süreçlerini kontrollü biçimde yeniden çalıştırma yaklaşımıdır. Felaket sözcüğü yalnızca deprem veya yangın gibi fiziksel olayları ifade etmez. Yanlış bir yapılandırma, fidye yazılımı, kimlik sisteminin ele geçirilmesi veya bölgesel servis kesintisi de aynı kapsama girebilir. Planın başarılı sayılması için sistemin yalnızca açılması yeterli değildir; kullanıcıların oturum açabilmesi, uygulamanın veritabanına erişebilmesi ve gerekli işlevlerin doğrulanması gerekir. Bu nedenle kurtarma teknik olduğu kadar operasyonel bir disiplindir.

Cloud Disaster Recovery Nasıl Çalışır?

Cloud Disaster Recovery yaklaşımında veriler, yapılandırmalar ve gerekli altyapı bileşenleri kurtarma ortamına önceden hazırlanır veya ihtiyaç anında otomatik olarak oluşturulabilecek biçimde tanımlanır. Kritik veriler belirlenen RPO hedeflerine göre kopyalanırken, compute kaynakları seçilen stratejiye bağlı olarak kapalı, küçültülmüş veya tamamen aktif durumda tutulabilir. Bir felaket ilan edildiğinde önce veri bütünlüğü kontrol edilir, ardından uygulama bağımlılıkları doğru sırayla başlatılır. Son aşamada trafik kurtarma ortamına yönlendirilir ve iş birimleri kabul testi yapar. Başarılı bir yapı, bu süreci mümkün olduğunca tekrarlanabilir ve ölçülebilir hâle getirir.

İş Sürekliliği ile Disaster Recovery Arasındaki Fark

İş sürekliliği, şirketin kritik faaliyetlerini bir kesinti sırasında nasıl sürdüreceğini ele alan daha geniş bir yönetim çerçevesidir. Disaster Recovery ise bu çerçevenin bilgi teknolojileri sistemlerinin kurtarılmasına odaklanan bölümüdür. Örneğin müşteri destek ekibinin alternatif iletişim kanalına geçmesi iş sürekliliği planının parçasıdır. Destek yazılımının başka bir ortamda yeniden çalıştırılması ise kurtarma planının teknik tarafına girer. İki alan birlikte tasarlanmadığında teknik olarak ayağa kaldırılmış bir sistem, iş açısından hâlâ kullanılamaz durumda kalabilir.

Disaster Recovery Plan (DRP) Nedir?

Disaster Recovery Plan, bir kesinti sırasında kimlerin hangi kararı vereceğini, hangi sistemlerin hangi sırayla kurtarılacağını ve başarının nasıl ölçüleceğini tanımlayan belgedir. İyi bir DRP yalnızca teknik komutlardan oluşmaz. Aktivasyon kriterleri, iletişim akışı, sorumluluklar, RTO ve RPO hedefleri, doğrulama adımları ve geri dönüş prosedürleri de planın içinde yer almalıdır. Planın her önemli altyapı değişikliğinden sonra güncellenmesi gerekir. En önemlisi, belge belirli aralıklarla uygulamalı testlerden geçirilmelidir.

Backup, High Availability ve Disaster Recovery Arasındaki Fark

Backup, replication, high availability ve disaster recovery kavramları birbirine yakın görünse de farklı riskleri çözer. Yedekleme verinin geçmiş bir kopyasını saklamaya odaklanırken yüksek erişilebilirlik kısa süreli bileşen arızalarında hizmetin devam etmesini hedefler. Replikasyon veriyi başka bir konuma taşıyabilir, fakat hatalı veya zararlı veriyi de aynı hızla çoğaltabilir. Disaster Recovery ise bütün bu teknikleri belirli iş hedefleri altında bir araya getirir. Bu ayrımı doğru yapmak yatırım kararlarının da daha sağlıklı verilmesini sağlar.

Backup Nedir?

Backup, veri veya sistem durumunun belirli zamanlardaki kopyalarının bağımsız bir saklama alanında tutulmasıdır. Bir dosya yanlışlıkla silindiğinde veya veritabanında istenmeyen bir değişiklik yapıldığında geçmiş bir sürüme dönebilmek için kullanılır. Yedeklerin değerli olabilmesi için düzenli alınması kadar geri yükleme testlerinin de yapılması gerekir. Şifrelenmiş fakat anahtarı kaybolmuş bir yedek teknik olarak mevcut olsa bile pratikte kullanılamaz. Bu nedenle yedekleme politikası bütünlük kontrolü, saklama süresi ve erişim yetkilerini de kapsamalıdır.

Replication Nedir?

Replication, verinin veya sistem durumunun başka bir konuma sürekli ya da belirli aralıklarla kopyalanmasıdır. Replikasyon, düşük RPO hedefleri için önemli bir araçtır çünkü değişikliklerin kısa sürede ikincil ortama taşınmasını sağlar. Bununla birlikte kaynak tarafta yapılan yanlışlıkların da kopyalanabileceği unutulmamalıdır. Özellikle veri bozulması ve fidye yazılımı senaryolarında yalnızca replika kullanmak güvenli bir geri dönüş noktası sağlamayabilir. Bu nedenle replikasyon çoğu zaman bağımsız, değiştirilemez yedeklerle birlikte kullanılmalıdır.

High Availability Nedir?

High Availability, tek bir bileşen arızasının hizmet kesintisine dönüşmesini engellemek için yedekli sistemler kullanır. Örneğin iki uygulama sunucusunun bir yük dengeleyici arkasında çalışması, sunuculardan biri kapandığında hizmetin devam etmesini sağlayabilir. Bu yaklaşım genellikle aynı bölge veya aynı operasyon alanındaki kısa süreli arızalara karşı etkilidir. Fakat bütün bir bölgenin kullanılamaması veya kimlik altyapısının bozulması gibi olayları tek başına çözmez. Bu nedenle yüksek erişilebilirlik ile felaket kurtarma birbirinin alternatifi değil, tamamlayıcısıdır.

Disaster Recovery Nedir?

Disaster Recovery, normal yüksek erişilebilirlik önlemlerinin aşamadığı daha geniş çaplı olaylardan sonra hizmetin yeniden kurulmasına odaklanır. Buradaki temel soru, sistemin başka bir konumda veya yapılandırmada ne kadar hızlı çalıştırılabileceğidir. Bu hedef RTO ile, kabul edilebilir veri kaybı ise RPO ile ifade edilir. Plan; veri, uygulama, ağ, kimlik, güvenlik ve operasyon süreçlerinin birlikte ele alınmasını gerektirir. Dolayısıyla yalnızca bir altyapı ürünü satın almak etkili bir kurtarma programı kurmak anlamına gelmez.

Neden Yedek Sahibi Olmak DR Planı Sahibi Olmak Anlamına Gelmez?

Bir yedek dosyasının bulunması hizmetin ne kadar sürede geri döneceğini söylemez. Büyük bir veritabanının geri yüklenmesi saatler sürebilir ve uygulama sunucuları hazır olsa bile DNS veya kimlik servisi çalışmıyorsa kullanıcılar sisteme erişemez. Ayrıca yedeklerin gerçekten okunabilir olduğu, gerekli anahtarların erişilebilir kaldığı ve doğru sırada restore edildiği test edilmelidir. DR planı bu bağımlılıkları, sorumlulukları ve zaman hedeflerini birlikte yönetir. Bu yüzden “yedek alıyoruz” ifadesi, “kesinti durumunda çalışmayı sürdürebiliriz” anlamına gelmez.

Hangi Olaylar Disaster Recovery Senaryosudur?

Kurtarma planı yalnızca fiziksel felaketlere göre hazırlanırsa gerçek risklerin önemli bir bölümü gözden kaçar. Modern altyapılarda bölgesel servis kesintileri, yanlış yapılandırmalar, kimlik ihlalleri ve tedarikçi sorunları fiziksel olaylar kadar etkili olabilir. Senaryo kataloğu hazırlanırken hem teknik hem organizasyon kaynaklı riskler değerlendirilmelidir. Her senaryonun aynı kurtarma yöntemine sahip olması gerekmez. Önemli olan olay türüne göre doğru tetikleyici, doğrulama ve geri dönüş adımlarının önceden belirlenmesidir.

Veri Merkezi Kesintisi

Elektrik, soğutma, ağ veya fiziksel altyapı sorunları bir veri merkezinin tamamen kullanılamamasına neden olabilir. Bu durumda aynı lokasyon içinde bulunan yedek sistemler de etkilenebilir. Kurtarma planının farklı bir hata alanında çalışabilecek kapasiteyi hazır tutması gerekir. Uygulamaların yalnızca sunucu düzeyinde değil, bağımlılıklarıyla birlikte taşınması önemlidir. Veri merkezi kesintisi senaryosu, fiziksel konum bağımlılıklarının net biçimde görülmesini sağlar.

Cloud Region Kesintisi

Bir bulut bölgesinin tamamını etkileyen olaylar seyrek olsa da kritik sistemler için planlanması gereken riskler arasındadır. Multi-AZ mimarisi aynı bölge içindeki hata alanlarını ayırabilir fakat bölge seviyesindeki sorunu tek başına aşamaz. Bu nedenle çok düşük RTO isteyen kritik iş yüklerinde farklı bir recovery region değerlendirilebilir. Verinin ne şekilde taşınacağı ve trafik yönlendirmesinin nasıl yapılacağı önceden belirlenmelidir. Bölgesel kurtarma test edilmeden yalnızca mimari diyagram üzerinde bırakılmamalıdır.

Donanım Arızası

Disk, sunucu, depolama kontrolcüsü veya ağ ekipmanı gibi donanımlar her ortamda arızalanabilir. Sanallaştırılmış ve bulut tabanlı sistemler bu riski büyük ölçüde soyutlasa da veri kaybı ihtimalini tamamen ortadan kaldırmaz. Birden fazla arızanın aynı anda gerçekleşmesi veya yönetilen hizmetin beklenmedik davranması daha geniş bir kesintiye yol açabilir. Kurtarma tasarımı tekil donanım bileşenlerine bağımlılığı azaltmalıdır. Ayrıca arıza sonrası veri tutarlılığının nasıl doğrulanacağı da plana eklenmelidir.

Network Kesintisi

Uygulama sunucuları çalışıyor olsa bile ağ erişimi yoksa hizmet kullanıcı açısından kesilmiş sayılır. Routing hataları, VPN problemleri, firewall değişiklikleri ve sağlayıcı bağlantı sorunları sık karşılaşılan nedenlerdir. Kurtarma ortamına geçişte aynı ağ bağımlılığının yeniden kullanılmaması özellikle önemlidir. Alternatif erişim yolları ve yönetim bağlantıları önceden test edilmelidir. Network kurtarma adımları uygulama runbook'undan ayrı düşünülmemelidir.

İnsan Hatası

Yanlış komut, hatalı silme işlemi veya plansız yapılandırma değişikliği büyük kesintilere neden olabilir. İnsan hatasının tehlikeli tarafı çoğu zaman mevcut replikasyon sistemleri tarafından otomatik olarak diğer ortama taşınmasıdır. Bu nedenle sürümleme, onay mekanizmaları ve geri dönüş noktaları önem kazanır. Infrastructure as Code kullanımı değişikliklerin izlenebilirliğini artırabilir. Bununla birlikte otomasyon da yanlış yapılandırılmışsa hatayı daha geniş ölçekte uygulayabileceği için güvenlik kontrolleri korunmalıdır.

Yazılım ve Database Corruption

Uygulama hataları veya depolama sorunları verinin mantıksal olarak bozulmasına yol açabilir. Bu durum çoğu zaman sunucular çalışırken gerçekleştiği için klasik availability kontrolleri olayı hemen fark etmeyebilir. Bozulmuş veri replikasyonla ikincil ortama da taşınabilir. Point-in-time recovery ve doğrulanmış yedekler bu nedenle önemlidir. Kurtarma planında temiz verinin hangi zamandan alınacağına karar verecek teknik ve iş sorumluları belirlenmelidir.

Ransomware

Ransomware senaryosu sıradan bir sistem arızasından farklı ele alınmalıdır çünkü üretim verisi ile birlikte yedekler ve yönetim hesapları da hedef alınabilir. Replikasyon şifrelenmiş dosyaları hızla başka ortama taşıyabilir. Bu nedenle değiştirilemez veya izole yedekler kurtarma stratejisinin önemli parçalarıdır. Kurtarmadan önce kullanılacak geri dönüş noktasının temiz olduğuna dair kontrol yapılmalıdır. Ayrıca ayrıcalıklı hesapların güvenilir biçimde yeniden kurulması planın başlangıç aşamalarından biri olmalıdır.

Cloud Account Compromise

Bulut hesabının ele geçirilmesi, saldırganın kaynakları silmesine veya güvenlik politikalarını değiştirmesine yol açabilir. Kurtarma ortamının aynı yönetim hesabına tamamen bağımlı olması bu riski büyütür. Kritik yedeklerin ayrı yetkilendirme sınırlarında korunması güçlü bir savunma katmanı oluşturur. Break-glass hesaplarının güvenli biçimde saklanması ve düzenli test edilmesi gerekir. Hesap ihlali senaryosunda teknik kurtarma kadar kimlik ve erişim kontrolünün yeniden güvenilir hâle getirilmesi de önemlidir.

Tedarikçi ve SaaS Kesintileri

Kurumsal iş süreçleri çoğu zaman harici SaaS hizmetlerine bağımlıdır. Sağlayıcı kesintisi sırasında şirket kendi altyapısını kontrol edemediği için alternatif süreçler önceden planlanmalıdır. Verilerin düzenli dışa aktarılabilmesi ve kritik kayıtların bağımsız kopyalarının bulunması iş sürekliliğini destekler. Entegrasyonların geçici olarak devre dışı bırakılması veya kuyruklanması gerekebilir. Tedarikçi kesintisi senaryoları sözleşme ve SLA incelemeleriyle birlikte değerlendirilmelidir.

Deprem, Sel ve Yangın

Fiziksel felaketler yalnızca sunucuları değil, personelin ofise erişimini ve yerel iletişim altyapısını da etkileyebilir. Bu nedenle farklı coğrafi hata alanları kullanmak önemli bir risk azaltma yöntemidir. Kurtarma planının uzaktan yönetim imkânlarını ve alternatif iletişim kanallarını da kapsaması gerekir. Personelin görevlerini farklı lokasyonlardan sürdürebilmesi teknik altyapının çalışması kadar önemlidir. Fiziksel olay senaryosu gerçek iş sürekliliği planının teknoloji dışındaki parçalarını da görünür hâle getirir.

Business Impact Analysis (BIA) Nasıl Yapılır?

BIA, hangi sistemin ne kadar kritik olduğunu iş etkisi üzerinden belirlemeye yarar. Teknik ekiplerin “bu uygulama önemli” değerlendirmesi tek başına yeterli değildir. Kesinti süresinin gelir, müşteri, sözleşme, operasyon ve mevzuat üzerindeki etkileri ölçülmelidir. Bu çalışma RTO ve RPO hedeflerinin ekonomik gerekçesini oluşturur. İyi yapılmış BIA, gereksiz pahalı kurtarma mimarilerinin de önüne geçer.

Kritik İş Süreçlerini Belirleme

İlk adım, şirketin gelir üretmesi veya temel yükümlülüklerini yerine getirmesi için gerekli iş süreçlerini listelemektir. Her süreç hangi uygulamalara, veri kaynaklarına ve dış hizmetlere bağımlı olduğu açısından incelenmelidir. Süreç sahibinin teknik ekipten farklı olabileceği unutulmamalıdır. İş birimi, kesintinin ne zaman kabul edilemez hâle geldiğini açıklamalıdır. Bu bilgi daha sonra sistemlerin kurtarma önceliğine dönüştürülür.

Kesintinin Saatlik Maliyetini Hesaplama

Kesinti maliyeti yalnızca kaybedilen satış miktarı değildir. Çalışamayan personel, geciken siparişler, SLA cezaları, destek yükü ve müşteri kaybı da hesaba katılmalıdır. Saatlik maliyet yaklaşık olarak ölçüldüğünde kurtarma yatırımının ekonomik sınırı daha net görülür. Örneğin bir saatlik kesinti çok düşük maliyet oluşturuyorsa pahalı active/active mimari gereksiz olabilir. Buna karşılık kısa bir kesinti bile yüksek kayıp yaratıyorsa daha hızlı kurtarma stratejileri anlamlı hâle gelir.

Gelir Kaybı

Satış veya işlem üreten sistemlerde kesinti doğrudan gelir kaybına dönüşebilir. Hesaplama yapılırken ortalama saatlik işlem hacmi başlangıç noktası olarak alınabilir. Kampanya, sezon veya günün belirli saatleri gibi değişkenler ayrıca değerlendirilmelidir. Kesinti sonrası bütün işlemlerin geri kazanılacağı varsayılmamalıdır. Bu değer kurtarma yatırımı için en anlaşılır ekonomik göstergelerden biridir.

SLA Cezaları

Müşterilerle yapılan sözleşmeler belirli erişilebilirlik hedefleri içeriyorsa kesintiler finansal cezalara yol açabilir. Bu cezalar yalnızca doğrudan ödeme olmayabilir. Hizmet kredileri, sözleşme indirimleri veya yenileme riskleri de maliyete eklenebilir. DR hedefleri belirlenirken SLA maddeleri teknik ekiple birlikte incelenmelidir. Böylece kurtarma süresi gerçek sözleşme yükümlülükleriyle uyumlu olur.

Çalışan Verimlilik Kaybı

İç sistemlerin kesintisi çalışanların iş yapmasını durdurabilir veya ciddi biçimde yavaşlatabilir. Saatlik çalışan maliyeti ve etkilenen kişi sayısı üzerinden yaklaşık bir hesap yapılabilir. Özellikle ERP, kimlik veya iletişim hizmetleri geniş kullanıcı gruplarını aynı anda etkileyebilir. Bu maliyet dışarıdan görünmese de uzun kesintilerde hızla büyür. BIA çalışmasında iç uygulamaların etkisi bu nedenle düşük değerlendirilmemelidir.

Müşteri Kaybı

Uzun veya tekrarlayan kesintiler müşterilerin alternatif çözümlere yönelmesine neden olabilir. Bu etki tek bir günün gelirinden daha uzun vadeli sonuçlar yaratır. Müşteri yaşam boyu değeri ve yenileme oranları yaklaşık risk hesabına dahil edilebilir. Destek taleplerindeki artış da ek operasyon maliyeti oluşturur. Kritik müşteri süreçleri için RTO belirlenirken bu dolaylı kayıp dikkate alınmalıdır.

İtibar ve Mevzuat Riski

Bazı kesintiler doğrudan gelir kaybından daha büyük itibar veya uyum riski yaratabilir. Özellikle kişisel veri, finansal kayıt veya kritik hizmet sağlayan sistemlerde olay bildirimi gereksinimleri oluşabilir. İtibar etkisini sayısallaştırmak zor olsa da risk sınıflandırmasına dahil etmek gerekir. Yönetim ekipleri kabul edilebilir risk seviyesini açık biçimde tanımlamalıdır. Böylece teknik kararlar yalnızca altyapı maliyetine göre verilmez.

İş Yüklerini Kritiklik Seviyesine Ayırma

Bütün uygulamalara aynı kurtarma hedefini vermek hem pahalı hem verimsizdir. İş yüklerini katmanlara ayırmak, yatırımın kesinti etkisine göre dağıtılmasını sağlar. Her katman için örnek RTO, RPO, test sıklığı ve sorumlu ekip tanımlanabilir. Bu sınıflandırma zaman içinde iş gereksinimleri değiştikçe güncellenmelidir. Tier modeli teknik öncelik listesini iş etkisiyle ilişkilendiren pratik bir yöntemdir.

Tier 0 / Mission Critical

Tier 0 sistemler kesintisi doğrudan ana iş faaliyetini durduran veya çok yüksek risk oluşturan bileşenlerdir. Kimlik altyapısı, ödeme sistemleri veya temel işlem motorları bu sınıfa girebilir. Bu sistemlerde RTO ve RPO hedefleri genellikle en düşüktür. Kurtarma ortamı daha hazır tutulur ve test sıklığı daha yüksek olur. Maliyet de diğer katmanlara göre doğal olarak artar.

Tier 1

Tier 1 iş yükleri yüksek öneme sahiptir fakat çok kısa süreli kesinti sınırlı ölçüde tolere edilebilir. Warm standby veya benzeri orta düzey hazır bekleme yöntemleri bu sınıfta sık kullanılabilir. RTO birkaç dakika ile birkaç saat arasında iş ihtiyacına göre belirlenebilir. Veri kaybı toleransı süreç sahipleriyle birlikte tanımlanmalıdır. Testlerin düzenli biçimde yapılması yine zorunludur.

Tier 2

Tier 2 sistemler belirli süre devre dışı kalabilen destek hizmetlerini kapsar. Backup and restore veya pilot light yaklaşımı çoğu zaman yeterli olabilir. Daha uzun RTO kabul edildiği için sürekli çalışan ek compute kaynaklarına ihtiyaç azalabilir. Böylece maliyet düşerken kurtarma süresi uzar. Kritik bağımlılıkları bulunuyorsa daha üst seviye sistemlerle ilişkisi ayrıca haritalanmalıdır.

Tier 3

Tier 3 iş yükleri kesinti durumunda iş faaliyetini doğrudan durdurmayan düşük öncelikli sistemlerdir. Raporlama, test veya arşiv uygulamalarının bazıları bu sınıfa girebilir. Bu sistemlerde uzun RTO ve daha geniş RPO kabul edilebilir. Basit yedekleme ve gerektiğinde yeniden kurulum ekonomik bir tercih olabilir. Ancak düşük öncelik, verinin korunmasına gerek olmadığı anlamına gelmez.

Uygulama Bağımlılıklarını Haritalama

Bir uygulamayı tek başına kurtarmak çoğu zaman yeterli değildir çünkü modern sistemler çok sayıda dış bileşene bağlıdır. Veritabanı, DNS, kimlik, mesaj kuyruğu, sertifika, üçüncü taraf API ve network erişimleri haritada görünür olmalıdır. Dependency map, kurtarma sırasının doğru oluşturulmasını sağlar. Ayrıca unutulan küçük bir servisin büyük bir kesintiye neden olmasını önler. Harita her major değişiklikten sonra güncellenmelidir.

RTO ve RPO Nedir?

RTO ve RPO, kurtarma stratejisinin ölçülebilir iki temel hedefidir. Cloud disaster recovery RPO ve RTO değerleri nasıl belirlenir sorusunun yanıtı teknik kapasiteden önce iş etkisiyle başlar. RTO sistemin ne kadar sürede yeniden çalışması gerektiğini, RPO ise ne kadar geçmiş verinin kaybedilebileceğini tanımlar. Bu değerler ne kadar düşük tutulursa altyapı maliyeti ve operasyon yükü genellikle o kadar yükselir. Bu yüzden hedefler gerçek iş ihtiyacına göre belirlenmelidir.

Recovery Time Objective (RTO)

RTO, kesinti başladıktan sonra hizmetin kabul edilebilir biçimde yeniden kullanılabilir olması için hedeflenen maksimum süredir. Örneğin iki saat RTO belirlenmiş bir sistemin iki saat içinde işlevsel hâle gelmesi beklenir. Süre yalnızca sunucunun açılmasını değil, doğrulama ve trafik yönlendirmesini de kapsamalıdır. Kullanıcıların gerçek hizmete erişebildiği nokta ölçüm açısından daha anlamlıdır. RTO testlerde düzenli olarak doğrulanmalıdır.

Recovery Point Objective (RPO)

RPO, bir kesinti sonrasında kabul edilebilecek maksimum veri kaybı aralığını ifade eder. On beş dakikalık RPO, son on beş dakikaya kadar olan verinin kaybedilebileceği anlamına gelir. Daha düşük RPO daha sık yedekleme veya sürekli replikasyon gerektirebilir. Ancak her sistemde sıfıra yakın veri kaybı ekonomik olmayabilir. İşlem değerinin ve verinin yeniden üretilebilir olup olmadığının değerlendirilmesi gerekir.

RTO ile RPO Arasındaki Fark

RTO zaman odaklıdır, RPO ise veri kaybı odaklıdır. Bir sistem çok hızlı açılabilir fakat birkaç saatlik veri kaybı yaşayabilir. Bunun tersi de mümkündür; veri neredeyse güncel olabilir fakat uygulamanın yeniden çalıştırılması uzun sürebilir. Bu nedenle iki hedef ayrı ayrı belirlenmelidir. İyi bir DR tasarımı ikisini birlikte karşılayan teknik yöntemi seçer.

RTO ve RPO Nasıl Belirlenir?

Belirleme süreci BIA çıktılarıyla başlamalıdır. İş birimleri kesintinin ne kadar süre sonra kabul edilemez hâle geldiğini ve ne kadar verinin yeniden oluşturulabileceğini belirtmelidir. Teknik ekip bu hedeflerin uygulanabilirliğini ve maliyetini hesaplar. Ardından iş, finans ve teknoloji ekipleri ortak bir karar verir. Hedefler dokümante edilmeli ve gerçek test sonuçlarıyla karşılaştırılmalıdır.

Her Sistem İçin Aynı RTO/RPO Neden Yanlıştır?

Her uygulamanın iş üzerindeki etkisi aynı değildir. Kritik ödeme sistemi ile aylık raporlama aracına aynı RTO vermek gereksiz maliyet yaratabilir. Aynı şekilde bazı veriler tekrar üretilebilirken bazı işlemler geri getirilemez olabilir. Bu nedenle hedefler uygulama veya iş süreci bazında tanımlanmalıdır. Katmanlı yaklaşım bütçeyi en kritik alanlara yönlendirir.

RTO/RPO ile Maliyet Arasındaki İlişki

Daha düşük RTO genellikle daha fazla hazır compute kapasitesi gerektirir. Daha düşük RPO ise daha sık replikasyon, daha yüksek ağ kullanımı ve ek depolama maliyeti oluşturabilir. Active/active gibi yaklaşımlar hızlı kurtarma sunarken sürekli çalışan ikinci altyapı maliyetini yükseltir. Backup and restore daha ucuz olabilir ancak kurtarma süresi uzar. Doğru karar kesinti maliyeti ile kurtarma altyapısı maliyetini birlikte değerlendirmektir.

Hedef RTO ile Gerçek Kurtarma Süresi Arasındaki Fark

Dokümana yazılmış RTO bir hedeftir, gerçek performans değildir. Gerçek kurtarma sırasında beklenmeyen bağımlılıklar, insan onayları ve veri doğrulama adımları süreyi uzatabilir. Bu nedenle planın başarısı drill sonuçlarıyla ölçülmelidir. Hedef ve gerçek değer arasındaki fark yönetim raporlarında açıkça gösterilmelidir. Sürekli iyileştirme ancak bu fark görünür olduğunda yapılabilir.

RTA — Recovery Time Actual

RTA, gerçek bir test veya olay sırasında ölçülen fiilî kurtarma süresidir. RTO hedefi iki saat olup RTA dört saat çıkıyorsa plan hedefini karşılamıyor demektir. Bu sonuç bir başarısızlık olarak saklanmak yerine iyileştirme girdisi olarak kullanılmalıdır. En fazla süre alan adımlar ayrıca ölçülmelidir. Böylece otomasyon veya mimari değişiklik için doğru öncelik belirlenebilir.

Drill Sırasında RTO Nasıl Ölçülür?

Ölçüm başlangıç noktası felaket deklarasyonu veya plan tarafından tanımlanan resmi tetikleyici olmalıdır. Bitiş noktası ise kullanıcıların kritik hizmeti kabul edilebilir seviyede kullanabildiği an olmalıdır. Yalnızca sanal makinelerin açıldığı zamanı bitiş kabul etmek yanıltıcıdır. DNS yayılımı, doğrulama, güvenlik kontrolleri ve kullanıcı kabul testi hesaba katılmalıdır. Test zaman çizelgesi mümkün olduğunca otomatik kayıt altına alınmalıdır.

Teorik RTO Neden Production'da Tutmayabilir?

Laboratuvar ortamında çalışmış bir prosedür production koşullarında farklı davranabilir. Veri hacmi büyümüş, servis kotası değişmiş veya yeni bir dependency eklenmiş olabilir. İnsan onayı gereken adımlar da beklenenden uzun sürebilir. Configuration drift, kurtarma ortamının güncel üretim yapısından uzaklaşmasına yol açabilir. Bu yüzden yalnızca plan dokümanına değil, düzenli full failover sonuçlarına güvenilmelidir.

Recovery KPI Dashboard

Recovery KPI dashboard, kurtarma hazırlığını tek noktadan izlemeyi kolaylaştırır. RTA, gerçek RPO, replication lag, son başarılı backup ve son drill tarihi temel göstergeler arasında yer alabilir. Açık riskler ve yapılandırma farkları da aynı görünümde takip edilmelidir. Yönetim ekipleri için teknik metriklerin iş etkisiyle ilişkisi açıklanmalıdır. Dashboard yalnızca gözlem ekranı değil, aksiyon üreten bir yönetim aracı olmalıdır.

Cloud Disaster Recovery Stratejileri

Tek bir DR stratejisi bütün iş yükleri için doğru değildir. Seçim; RTO, RPO, bütçe, veri hacmi, operasyon kapasitesi ve iş kritikliği üzerinden yapılmalıdır. En yaygın yaklaşımlar backup and restore, pilot light, warm standby, hot standby ve active/active modelidir. Her yöntem farklı hazır olma seviyesi sunar. En iyi tasarım çoğu zaman kurum içinde birden fazla stratejinin birlikte kullanıldığı katmanlı yapıdır.

Backup and Restore

Backup and restore yaklaşımında üretim verileri düzenli olarak yedeklenir ve felaket sırasında gerekli altyapı yeniden oluşturularak veriler geri yüklenir. Sürekli çalışan ikinci ortam gerektirmediği için maliyet açısından avantajlıdır. Buna karşılık restore süresi veri büyüklüğüne göre uzun olabilir. Infrastructure as Code kullanımı yeniden kurulum süresini önemli ölçüde azaltabilir. Bu yöntem daha geniş RTO kabul eden sistemler için uygundur.

Avantajları

En önemli avantaj düşük sürekli altyapı maliyetidir. Kurtarma bölgesinde büyük compute kapasitesi sürekli açık tutulmak zorunda değildir. Saklama maliyeti çoğunlukla yedek kapasitesi ve veri transferinden oluşur. Basit sistemlerde operasyon yönetimi de daha kolay olabilir. Test otomasyonu ile güvenilirliği önemli ölçüde artırılabilir.

Dezavantajları

Başlıca dezavantaj, geri yükleme işleminin zaman almasıdır. Büyük veri setlerinde restore süresi hedeflenen RTO'nun aşılmasına neden olabilir. Ayrıca altyapı şablonları güncel değilse yeniden kurulum sırasında ek sorunlar çıkabilir. Sistem bağımlılıklarının manuel hazırlanması süreyi daha da uzatır. Bu nedenle gerçek veri hacmiyle test yapılmalıdır.

Uygun RTO/RPO Profili

Backup and restore genellikle dakikalar yerine saatler seviyesinde RTO kabul edebilen iş yükleri için daha uygundur. RPO kullanılan yedekleme sıklığına göre belirlenir. Saatlik yedekleme varsa teorik RPO yaklaşık bir saate kadar çıkabilir. Daha sık snapshot veya log backup ile bu değer düşürülebilir. Ancak hedefler mutlaka restore testleriyle doğrulanmalıdır.

Pilot Light

Pilot light modelinde sistemin veri ve çekirdek bileşenleri sürekli hazır tutulurken tam uygulama kapasitesi yalnızca felaket sırasında oluşturulur. Bu yaklaşım backup and restore'a göre daha hızlı, warm standby'a göre daha düşük maliyetli olabilir. Veritabanı replikası veya temel ağ yapısı sürekli açık kalabilir. Compute katmanı gerektiğinde otomasyonla genişletilir. İyi bir IaC yapısı bu modelin başarısını ciddi biçimde etkiler.

Sürekli Çalışan Bileşenler

Genellikle veri replikasyonu, temel network yapısı ve kritik güvenlik servisleri sürekli çalışır. Bu parçalar kurtarma sırasında zaman kaybını azaltır. Hangi servislerin sürekli hazır tutulacağı RTO hedefiyle ilişkilendirilmelidir. Kimlik ve anahtar servisleri gözden kaçırılmamalıdır. Hazır bileşenlerin sağlığı sürekli izlenmelidir.

Felakette Ayağa Kaldırılan Bileşenler

Uygulama sunucuları ve ölçeklenebilir compute kaynakları felaket deklarasyonundan sonra oluşturulabilir. Otomatik deployment bu sürenin tutarlı kalmasını sağlar. Kapasite kotaları önceden kontrol edilmelidir. Gerekli imaj ve paketlerin kurtarma bölgesinden erişilebilir olması gerekir. Gerçek bir drill, hazırlığın ne kadar sürede tamamlandığını gösterir.

Warm Standby

Warm standby yaklaşımında production ortamının daha küçük fakat çalışır bir kopyası sürekli tutulur. Kesinti sırasında bu ortam hızla ölçeklendirilerek tam kapasiteye çıkarılır. Sürekli açık kaynaklar nedeniyle pilot light modelinden daha pahalıdır. Buna karşılık daha düşük RTO sağlar. Kritik fakat active/active maliyetini gerektirmeyen uygulamalar için güçlü bir orta yol olabilir.

Küçültülmüş Production Ortamı

Kurtarma ortamı temel fonksiyonları çalıştıracak kadar kapasiteye sahip olur. Normal koşullarda daha az instance veya daha küçük kaynak boyutları kullanılabilir. Yapılandırmaların production ile uyumlu kalması çok önemlidir. Uygulama sürümü, firewall kuralları ve secret'lar düzenli kontrol edilmelidir. Aksi hâlde ortam açık olsa bile failover sırasında beklenmeyen hatalar ortaya çıkabilir.

Failover Sırasında Scale-Up

Felaket ilan edildiğinde compute kapasitesi önceden tanımlanan seviyeye çıkarılır. Autoscaling veya Infrastructure as Code bu işlemi hızlandırabilir. Bununla birlikte servis kotası veya kaynak bulunabilirliği sorunları göz önünde bulundurulmalıdır. Kapasite artırımı gerçek yük testleriyle doğrulanmalıdır. Sadece instance sayısını yükseltmek, veritabanı veya network dar boğazlarını otomatik olarak çözmez.

Hot Standby

Hot standby modelinde ikincil ortam production kapasitesine yakın seviyede sürekli çalışır. Veri replikasyonu neredeyse sürekli devam eder ve failover için sınırlı ölçeklendirme gerekir. Bu yöntem düşük RTO hedefleri için güçlüdür. Sürekli kaynak maliyeti diğer pasif stratejilere göre daha yüksektir. Testlerin düzenli yapılması bu yatırımın gerçekten beklenen süre avantajını sağlayıp sağlamadığını gösterir.

Multi-Site Active/Active

Active/active mimaride birden fazla ortam aynı anda kullanıcı trafiği taşır. Bir taraf kullanılamaz olduğunda diğer taraf mevcut trafiğin daha büyük bölümünü karşılar. Bu yaklaşım çok düşük RTO sağlayabilir fakat veri tutarlılığı, yönlendirme ve kapasite planlaması daha zordur. Stateful uygulamalarda eşzamanlı yazma modeli dikkatle tasarlanmalıdır. İş ihtiyacı bu maliyeti ve operasyon yükünü haklı çıkarmıyorsa daha basit stratejiler tercih edilebilir.

Doğru Strateji Nasıl Seçilir?

Doğru strateji teknik eğilimlere göre değil, BIA sonuçlarına göre seçilmelidir. Kesinti maliyeti, hedef RTO, hedef RPO ve yıllık DR bütçesi birlikte değerlendirilir. Uygulamanın stateful veya stateless yapısı da kararı etkiler. Operasyon ekibinin yönetebileceğinden daha karmaşık bir mimari güvenilirliği azaltabilir. En doğru çözüm ölçülebilir, test edilebilir ve sürdürülebilir olandır.

Multi-AZ ile Multi-Region Disaster Recovery Arasındaki Fark

Multi-AZ ve multi-region aynı şey değildir. Multi-AZ yapısı tek bir bölge içindeki farklı hata alanlarını kullanarak yerel arızalara karşı dayanıklılık sağlar. Multi-region ise daha geniş coğrafi veya bölgesel kesintiler için ikinci bir bölgeyi devreye alır. Her sistemin multi-region olması gerekmez. Karar iş etkisi, regülasyon, maliyet ve operasyon kapasitesine göre verilmelidir.

Availability Zone Arızası

Bir Availability Zone erişilemez olduğunda aynı region içindeki diğer zone'lar hizmeti sürdürebilir. Bunun çalışması için uygulama, veritabanı ve load balancer katmanlarının zone bağımsız tasarlanması gerekir. Tek bir zone'a bağlı depolama veya network bileşeni gizli risk oluşturabilir. Failover süreci mümkünse otomatik ve düzenli test edilmiş olmalıdır. Multi-AZ, yaygın altyapı arızalarının önemli bölümünü azaltabilir.

Region Seviyesinde Arıza

Region düzeyindeki bir kesintide aynı bölgenin birden fazla zone'u etkilenebilir. Böyle bir olay için farklı region üzerinde hazır veya yeniden oluşturulabilir altyapı gerekir. Veri replikasyonu, DNS yönlendirmesi ve erişim politikaları önceden hazırlanmalıdır. Uygulamaların bölgeye özel bağımlılıkları ayrıca kontrol edilmelidir. Bu senaryo multi-region planının gerçek değerini ortaya koyar.

Multi-AZ Ne Zaman Yeterlidir?

İş yükü kısa süreli bölgesel riskleri kabul edebiliyorsa multi-AZ yeterli olabilir. Uygulamanın kesinti maliyeti multi-region yatırımını haklı çıkarmıyorsa daha basit yapı tercih edilebilir. Aynı region içindeki yüksek erişilebilirlik birçok standart iş yükü için güçlü koruma sağlar. Yine de yedeklerin farklı hata alanlarında tutulması gerekir. Karar mutlaka BIA ve risk değerlendirmesine dayanmalıdır.

Multi-Region Ne Zaman Gereklidir?

Bölgesel kesintinin kabul edilemez olduğu kritik hizmetlerde multi-region değerlendirilebilir. Çok düşük RTO hedefi veya yasal gereksinimler bu kararı destekleyebilir. Büyük müşteri tabanı ve yüksek kesinti maliyeti de yatırım gerekçesi oluşturabilir. Ancak ikinci region yalnızca kaynak kopyalamakla bitmez; identity, network, secrets ve operasyon süreçleri de hazırlanmalıdır. Gerçek region failover drill'i yapılmadan hedeflerin karşılandığı varsayılmamalıdır.

Maliyet ve Operasyon Karmaşıklığı

Multi-region yapılar ek depolama, veri transferi, compute ve yönetim maliyeti oluşturur. Daha fazla bölge daha fazla yapılandırma farkı riski anlamına da gelebilir. Otomasyon bu yükü azaltabilir fakat tamamen ortadan kaldırmaz. Ekiplerin her iki ortamı da aynı güvenlik ve gözlem standartlarıyla yönetebilmesi gerekir. Maliyet, olası kesinti kaybı ile birlikte değerlendirilmelidir.

DRaaS Nedir?

DRaaS, Disaster Recovery as a Service ifadesinin kısaltmasıdır ve kurtarma altyapısının bir hizmet modeliyle sunulmasını ifade eder. Hizmet; replikasyon, failover orchestration, test, monitoring ve operasyon desteğinin farklı kombinasyonlarını içerebilir. Kurumların kendi başına ikinci veri merkezi kurma ihtiyacını azaltabilir. Ancak servis alınması sorumluluğun tamamen ortadan kalktığı anlamına gelmez. RTO, RPO, güvenlik, veri konumu ve exit planı sözleşmede açık biçimde tanımlanmalıdır.

Disaster Recovery as a Service Nasıl Çalışır?

DRaaS modelinde üretim iş yükleri belirlenen kurtarma ortamına replike edilir veya yedeklenir. Sağlayıcı, felaket sırasında kaynakların açılması ve trafiğin yönlendirilmesi için orchestration mekanizmaları sunabilir. Bazı hizmetlerde ekipler süreci kendileri yönetirken bazılarında operasyon desteği sağlanır. Test sıklığı ve kapsamı hizmet seviyesine göre değişebilir. Seçim yapılırken sadece fiyat değil, gerçek drill sonuçları ve failback yetenekleri de değerlendirilmelidir.

Managed DRaaS

Managed modelde planlama ve operasyon sorumluluğunun önemli kısmı hizmet ekibi tarafından yürütülür. Runbook hazırlığı, test koordinasyonu ve incident desteği paketin parçası olabilir. İç kaynakları sınırlı kurumlar için yararlı olabilir. Bununla birlikte iş kararları ve kritik sistem öncelikleri yine kurum tarafından belirlenmelidir. Yetki sınırları ve sorumluluk matrisi sözleşmede açık olmalıdır.

Assisted DRaaS

Assisted modelde kurum ve hizmet ekibi süreci birlikte yönetir. Teknik platform servis tarafından sağlanırken failover kararları ve uygulama doğrulaması kurum ekiplerinde kalabilir. Bu model, içeride teknik yetkinliği bulunan fakat bazı operasyon adımlarında destek isteyen ekipler için uygundur. Sorumlulukların gri alanda kalmaması önemlidir. Tatbikatlar bu görev paylaşımının gerçekten çalışıp çalışmadığını gösterir.

Self-Service DRaaS

Self-service modelde platform sağlanır fakat planlama ve işletim çoğunlukla kurumun kendi ekibi tarafından yapılır. Maliyet avantajı olabilir ancak daha fazla iç uzmanlık gerektirir. Runbook, test ve incident yönetiminin kurum tarafından düzenli yürütülmesi gerekir. Platform otomasyonu iyi olsa bile yanlış yapılandırma riski devam eder. Bu seçenek ekip kapasitesi güçlü kurumlar için uygun olabilir.

DRaaS ile Geleneksel İkinci Veri Merkezi Karşılaştırması

Geleneksel ikinci veri merkezi yüksek başlangıç yatırımı ve fiziksel operasyon gerektirebilir. DRaaS modeli kaynakların ihtiyaca göre ölçeklenmesini ve bazı yönetim görevlerinin hizmet olarak alınmasını sağlar. Buna karşılık sağlayıcı bağımlılığı ve veri taşınabilirliği yeni riskler oluşturabilir. İkinci veri merkezinde kurum daha fazla fiziksel kontrol sahibidir. Doğru seçim maliyet, regülasyon, ekip kapasitesi ve hedef kurtarma süresine bağlıdır.

DRaaS Kimler İçin Uygundur?

DRaaS, kendi kurtarma altyapısını sürekli işletmek istemeyen kurumlar için cazip olabilir. Özellikle sınırlı altyapı ekibi olan şirketlerde operasyon yükünü azaltabilir. Çok sayıda sanal iş yükünü merkezi olarak korumak isteyen yapılar da fayda görebilir. Ancak yüksek derecede özel uygulamalar için ek uyarlama gerekebilir. Hizmet seçimi öncesinde uygulama bağımlılıklarının ve güvenlik gereksinimlerinin detaylı analizi yapılmalıdır.

Cloud Disaster Recovery Referans Mimarisi

Referans mimari, kurtarma ortamının yalnızca compute ve storage'dan ibaret olmadığını görünür hâle getirir. Primary environment, recovery region, backup, replication, orchestration, traffic, identity, monitoring ve güvenlik katmanları birlikte tasarlanmalıdır. Bir katmanın eksik olması bütün kurtarma zincirini durdurabilir. Mimari çizim ile runbook arasında doğrudan ilişki kurulmalıdır. Her bileşenin sahibi ve doğrulama yöntemi ayrıca belirtilmelidir.

Primary Environment

Primary environment normal kullanıcı trafiğini taşıyan ana ortamdır. Varlık envanteri bu ortamdan çıkarılır ve hangi kaynakların DR kapsamına gireceği belirlenir. Production değişiklikleri kurtarma tasarımına düzenli olarak yansıtılmalıdır. Yeni sunucu, servis veya entegrasyonların otomatik keşfi faydalı olabilir. Kaynak ortam bilinmeden doğru kurtarma ortamı tasarlanamaz.

Recovery Region

Recovery region, birincil ortam kullanılamadığında iş yüklerinin çalışacağı bölgedir. Seçim yapılırken coğrafi risk, veri aktarım gecikmesi, mevzuat ve servis kullanılabilirliği değerlendirilmelidir. Gerekli servislerin ve kapasite kotalarının bölgede hazır olduğundan emin olunmalıdır. İmajlar, container registry kopyaları ve anahtar erişimleri kontrol edilmelidir. Bölge yalnızca kâğıt üzerinde değil, gerçek testlerle doğrulanmalıdır.

Backup Katmanı

Backup katmanı geçmişe dönülebilir bağımsız veri kopyalarını sağlar. Saklama süreleri ve immutable özellikler iş riskine göre belirlenmelidir. Yedeklerin farklı hata alanlarında tutulması fiziksel ve mantıksal riskleri azaltır. Restore testleri olmadan backup başarısı yalnızca job status üzerinden değerlendirilmemelidir. Yedek bütünlüğü düzenli olarak ölçülmelidir.

Replication Katmanı

Replication katmanı düşük RPO için veriyi ikincil ortama taşır. Senkron veya asenkron yöntem iş yükünün gecikme toleransına göre seçilir. Replication lag sürekli izlenmelidir. Kaynak hatalarının da kopyalanabileceği unutulmamalıdır. Bu nedenle replikasyon geçmişe dönülebilir yedeklerin yerine geçmez.

Recovery Orchestration

Orchestration, kurtarma adımlarının doğru sırada ve tekrarlanabilir biçimde uygulanmasını sağlar. Veritabanı başlamadan uygulama servislerinin devreye alınması gibi hatalar böylece azaltılabilir. Otomatik adımların yanında insan onayı gereken noktalar da tanımlanmalıdır. Her adımın başarısızlık durumunda geri dönüş yöntemi bulunmalıdır. Runbook ile orchestration akışı aynı mantığı takip etmelidir.

Traffic Management

Traffic management, kullanıcı isteklerinin hangi ortama gideceğini kontrol eder. DNS, global routing ve load balancer katmanları bu sürecin parçalarıdır. Failover sırasında TTL değerleri ve cache davranışı dikkate alınmalıdır. Trafik bir anda veya kontrollü oranlarla taşınabilir. Cutover öncesi recovery ortamının sağlık kontrollerinden geçmesi gerekir.

Identity

Kimlik altyapısı kurtarma ortamının en kritik bağımlılıklarından biridir. Kullanıcılar oturum açamıyorsa uygulama teknik olarak açık olsa bile hizmet verilmiş sayılmaz. Yönetici hesaplarının da felaket sırasında kullanılabilir olması gerekir. MFA ve break-glass erişimi güvenli biçimde planlanmalıdır. Kimlik kurtarma Wave 0 seviyesinde ele alınmalıdır.

Monitoring ve Alerting

Monitoring yalnızca production ortamı için değil, recovery bileşenleri için de kurulmalıdır. Replication lag, backup başarısı, sertifika süresi ve DR ortam sağlığı sürekli izlenebilir. Alarm mekanizması gerçek olayla test edilmelidir. Alarm alan kişinin ne yapacağı runbook içinde tanımlanmalıdır. İzleme sistemi de kesinti sırasında erişilebilir kalmalıdır.

Security ve Audit

Recovery ortamının güvenlik seviyesi production ortamından düşük olmamalıdır. Şifreleme, erişim kontrolü ve loglama aynı güvenlik hedeflerini karşılamalıdır. Özellikle uzun süre kullanılmayan DR hesapları gözden kaçan ayrıcalıklar barındırabilir. Düzenli audit bu farkları ortaya çıkarır. Felaket anındaki acil erişimler de sonradan incelenebilir biçimde loglanmalıdır.

Senkron ve Asenkron Replikasyon Arasındaki Fark

Replikasyon yöntemi RPO hedefini ve uygulama performansını doğrudan etkiler. Senkron replikasyon yazma işleminin birden fazla noktada doğrulanmasını bekleyebilir. Asenkron modelde kaynak işlem tamamlandıktan sonra veri diğer tarafa taşınır. Bu nedenle ağ gecikmesi ve coğrafi mesafe önemli karar faktörleridir. Seçim yapılırken sıfır veri kaybı isteği ile performans maliyeti birlikte değerlendirilmelidir.

Synchronous Replication

Synchronous replication, yazma işlemini tamamlamadan önce verinin ikincil hedefte de doğrulanmasını bekleyebilir. Bu yaklaşım çok düşük veya teorik olarak sıfıra yakın RPO sağlayabilir. Fakat uzak bölgelerde network latency uygulama yanıt sürelerini artırabilir. Ağ kesintisi durumunda yazma davranışının nasıl olacağı ayrıca tasarlanmalıdır. Bu yöntem genellikle gecikmeye duyarlı olmayan ve veri kaybı toleransı çok düşük iş yüklerinde değerlendirilir.

Asynchronous Replication

Asenkron replikasyonda ana sistem işlemi tamamlar ve değişiklikler daha sonra replica'ya gönderilir. Kullanıcı işlemi uzak hedefin onayını beklemediği için performans açısından avantajlıdır. Buna karşılık kesinti anında henüz taşınmamış değişiklikler kaybedilebilir. Bu fark replication lag olarak ölçülür. Çoğu coğrafi DR senaryosunda pratikliği nedeniyle asenkron yöntem yaygındır.

Network Latency'nin Etkisi

Fiziksel mesafe arttıkça ağ gecikmesi de genellikle yükselir. Senkron işlemlerde bu gecikme doğrudan uygulama yanıt süresine yansıyabilir. Bu yüzden uzak bölgeler arasında sıfır RPO hedefi performans sorunları yaratabilir. Ağ kalitesi sadece ortalama gecikmeyle değil, jitter ve paket kaybıyla da değerlendirilmelidir. Gerçek üretim yüküyle yapılan testler doğru sonucu verir.

Replication Lag

Replication lag, kaynak ile replica arasındaki veri gecikmesini gösterir. RPO hedefinin sürekli karşılanıp karşılanmadığını anlamak için önemli bir metriktir. Lag artışı network sorunu, yoğun yazma trafiği veya hedef kapasite eksikliği gösterebilir. Alarm eşikleri iş yükünün RPO hedefiyle ilişkilendirilmelidir. Sadece ortalama değil, en kötü değerler de izlenmelidir.

RPO 0'ın Teknik Bedeli

RPO 0 hedefi hiçbir onaylanmış işlemin kaybedilmemesini amaçlar. Bu hedef çoğu senaryoda senkron veri çoğaltma ve yüksek erişilebilir altyapı gerektirir. Ağ gecikmesi, uygulama performansı ve altyapı maliyeti yükselir. Ayrıca mantıksal bozulma veya kullanıcı hatası yine iki tarafa birden taşınabilir. Bu nedenle RPO 0 hedefi yalnızca gerçek iş gerekçesi varsa seçilmelidir.

Hangi İş Yükünde Hangisi Kullanılmalı?

Finansal işlem gibi veri kaybına toleransı çok düşük sistemlerde senkron yöntem değerlendirilebilir. Büyük coğrafi mesafelerde veya yüksek yazma performansı isteyen sistemlerde asenkron yöntem daha uygulanabilir olabilir. Bazı mimariler her iki modeli farklı veri katmanlarında birlikte kullanabilir. Karar uygulamanın gecikme toleransına, veri değerine ve kurtarma hedeflerine bağlıdır. Test sonuçları teorik beklentilerden daha belirleyici olmalıdır.

Database Disaster Recovery Nasıl Tasarlanır?

Veritabanı çoğu uygulamanın en kritik stateful bileşenidir. Uygulama sunucularını yeniden oluşturmak kolay olabilir, fakat güncel ve tutarlı veri olmadan hizmet çalışmaz. Database DR tasarımında replikasyon, point-in-time recovery, log saklama ve replica promotion birlikte ele alınmalıdır. Split-brain gibi veri bütünlüğü riskleri önceden değerlendirilmelidir. Failback aşamasında iki taraftaki verinin nasıl uzlaştırılacağı da planın parçasıdır.

Database Replication

Database replication veritabanı değişikliklerini ikincil kopyaya taşır. Fiziksel veya mantıksal replikasyon yöntemleri kullanılabilir. Seçim kullanılan veritabanı motoruna ve RPO hedefine bağlıdır. Replikanın sadece çalışıyor görünmesi yeterli değildir; lag ve veri tutarlılığı da izlenmelidir. Replikanın promotion sonrası uygulama trafiğini taşıyabileceği kapasite testiyle doğrulanmalıdır.

Point-in-Time Recovery

Point-in-time recovery, veritabanını belirli bir zamandaki duruma geri döndürmeyi sağlar. Yanlış silme veya mantıksal corruption senaryolarında özellikle değerlidir. Tam backup ile transaction log'lar birlikte kullanılabilir. Geri dönülecek zaman iş birimi ve teknik ekip tarafından belirlenmelidir. Restore süresi gerçek veri büyüklüğüyle düzenli test edilmelidir.

Transaction Log / WAL / Binlog

Transaction log, WAL veya binlog veritabanındaki değişikliklerin sıralı kaydını tutar. Bu kayıtlar daha ince RPO hedefleri ve point-in-time recovery için kullanılabilir. Log zincirinde boşluk oluşması kurtarma yeteneğini zayıflatabilir. Bu nedenle log arşivleme ve saklama durumu sürekli izlenmelidir. Kurtarma testi yalnızca full backup değil log replay sürecini de kapsamalıdır.

Application-Consistent Backup

Application-consistent backup, uygulama işlemleriyle uyumlu ve kurtarıldığında tutarlı bir veri durumu sağlamayı amaçlar. Yalnızca disk seviyesinde snapshot almak aktif transaction'lar nedeniyle tutarsız sonuç verebilir. Veritabanının flush veya quiesce mekanizmaları gerektiğinde kullanılmalıdır. Backup yöntemi kullanılan uygulama ve veritabanı motoruna uygun olmalıdır. Restore testleri bu tutarlılığın gerçekten sağlandığını gösterir.

Replica Promotion

Replica promotion, ikincil veritabanının yeni primary olarak devreye alınması işlemidir. Bu adım failover sırasında kritik bir karar noktasıdır. Eski primary'nin hâlâ yazma kabul etmesi split-brain riskini artırabilir. Promotion öncesinde kaynak tarafın izole edildiğinden emin olmak gerekir. Uygulamaların yeni endpoint'e nasıl yönleneceği de runbook içinde yer almalıdır.

Split-Brain Riski

Split-brain, iki veritabanı düğümünün aynı anda kendisini primary sanarak yazma kabul etmesi durumudur. Bu durum çelişen veriler ve zor bir uzlaştırma süreci oluşturabilir. Quorum ve fencing mekanizmaları riski azaltabilir. Failover prosedürü eski primary'nin erişimini güvenli biçimde kesmelidir. Testlerde ağ bölünmesi senaryosu özellikle denenmelidir.

Failback ve Data Reconciliation

Failback sırasında primary ortam geri getirildiğinde recovery tarafında oluşan yeni veriler geri taşınmalıdır. Bu işlem reverse replication veya kontrollü veri senkronizasyonuyla yapılabilir. İki tarafta farklı kayıtlar oluşmuşsa reconciliation gerekir. Veri bütünlüğü doğrulanmadan trafik geri taşınmamalıdır. Failback için ayrıca RTO ve risk penceresi belirlenmesi faydalıdır.

Object Storage ve Dosya Sistemlerinin Kurtarılması

Object storage ve dosya sistemleri çok sayıda uygulamanın belge, medya ve arşiv verisini taşır. Yanlış silme, overwrite ve ransomware bu katmanı doğrudan etkileyebilir. Versioning, snapshot ve cross-region replication birlikte kullanılabilir. Immutable saklama, geçmiş kopyaların değiştirilmesini zorlaştırır. Kurtarma politikası veri yaşam döngüsü ve saklama gereksinimleriyle birlikte tanımlanmalıdır.

Object Versioning

Object versioning aynı nesnenin önceki sürümlerini saklamayı sağlar. Yanlışlıkla overwrite edilen veya silinen dosyalar eski sürümden geri getirilebilir. Ancak versioning tek başına bağımsız backup değildir. Yetkili bir saldırgan bütün sürümleri silme yetkisine sahip olabilir. Erişim politikaları ve immutable seçenekleriyle birlikte kullanılmalıdır.

Cross-Region Replication

Cross-region replication nesnelerin başka bir bölgeye kopyalanmasını sağlar. Bölgesel erişim sorunlarında veri kullanılabilirliğini artırabilir. Yanlış silme davranışının hedefe nasıl yansıtıldığı politika bazında kontrol edilmelidir. Replikasyon gecikmesi RPO açısından izlenmelidir. Yasal veri konumu gereksinimleri bölge seçimini etkileyebilir.

Snapshot

Snapshot belirli bir andaki veri durumunun hızlı kopyasını sağlar. Dosya sistemi ve block storage kurtarmasında yaygın biçimde kullanılabilir. Snapshot'ların aynı hesap veya aynı hata alanında kalması ek risk oluşturabilir. Kritik snapshot'lar farklı koruma sınırlarına kopyalanabilir. Restore performansı gerçek veri hacmiyle test edilmelidir.

Immutable Storage

Immutable storage belirlenen süre boyunca verinin silinmesini veya değiştirilmesini engelleyen koruma modelidir. Ransomware ve kötü niyetli yönetici senaryolarında güçlü bir savunma katmanı oluşturur. Retention süresi iş ve mevzuat gereksinimlerine göre belirlenmelidir. Yetki modelinin korumayı aşamayacak şekilde tasarlanması gerekir. Immutable kopyaların restore edilebilirliği yine düzenli test edilmelidir.

Accidental Delete Recovery

Yanlış silme en yaygın veri kaybı nedenlerinden biridir. Versioning, recycle mekanizması veya snapshot kısa sürede geri dönüş sağlayabilir. Silinen verinin fark edilme süresi saklama politikasını etkiler. Kullanıcıların kurtarma talebi açabileceği net süreç oluşturulmalıdır. Hassas veriler geri yüklenirken erişim yetkileri de doğru biçimde yeniden uygulanmalıdır.

Ransomware İçin Disaster Recovery

Ransomware için kurtarma planı klasik arıza senaryosundan farklı güvenlik varsayımlarıyla hazırlanmalıdır. Saldırganın yönetici yetkilerini elde etmiş olabileceği düşünülmelidir. Üretim ile recovery arasında sürekli replikasyon yapılması, şifrelenmiş verinin hızla ikinci ortama taşınmasına neden olabilir. Bu yüzden temiz recovery point, immutable backup ve izole kurtarma ortamı önemlidir. Kurtarma başlamadan önce saldırı vektörünün kapatılması gerekir.

Replikasyon Neden Tek Başına Yeterli Değildir?

Replikasyon verinin güncel kopyasını tutar fakat iyi ve kötü değişiklik arasında ayrım yapmaz. Bir dosya şifrelenirse aynı değişiklik replica'ya da aktarılabilir. Bu durumda iki ortam da aynı anda kullanılamaz hâle gelebilir. Geçmişe dönülebilen yedekler bu nedenle gereklidir. Replikasyon düşük RPO için güçlüdür, fakat bağımsız recovery point sağlamaz.

Ransomware'in Replica'ya Taşınması Riski

Şifreleme işlemi normal dosya değişikliği gibi görünebilir. Replikasyon sistemi bu değişiklikleri hedefe hızla kopyalayabilir. Bu durum temiz replica beklentisini bozar. Anomali algılama ve replikasyonu durdurma prosedürü ek koruma sağlayabilir. En güvenli yaklaşım geçmişe dönülebilen immutable kopyaları da ayrı tutmaktır.

Immutable Backup

Immutable backup belirli süre boyunca değiştirilemeyen yedek kopyasıdır. Saldırgan üretim hesabını ele geçirse bile yedeklerin silinmesini zorlaştırabilir. Koruma politikalarının bağımsız yetkilerle yönetilmesi önemlidir. Retention süresi saldırının fark edilme süresinden daha uzun olacak biçimde planlanabilir. Restore testleri kopyaların gerçekten kullanılabilir olduğunu doğrular.

Air-Gapped Backup

Air-gapped backup üretim ortamından fiziksel veya mantıksal olarak ayrılmış kopyayı ifade eder. Tam fiziksel ayrım her ortamda gerekli olmayabilir, fakat ayrı hesap ve erişim sınırları ciddi koruma sağlar. Yönetim kimliklerinin production ile aynı olmaması tercih edilebilir. Kopyanın otomatik silme yetkilerine karşı korunması gerekir. Kurtarma prosedürü bu izole alana güvenli erişimi önceden tanımlamalıdır.

Clean Recovery Point

Clean recovery point, saldırgan faaliyetinin başlamasından önceki güvenilir veri durumudur. En yeni backup her zaman en güvenli backup olmayabilir. Güvenlik ekibi loglar üzerinden tahmini başlangıç zamanını belirlemelidir. Gerekirse daha eski bir noktaya dönmek veri kaybını artırsa da tekrar enfekte olma riskini azaltabilir. Karar iş ve güvenlik ekipleri tarafından birlikte verilmelidir.

Clean-Room Recovery

Clean-room recovery, verinin izole ve güvenilir bir ortamda doğrulanarak geri yüklenmesini amaçlar. Bu ortam üretim ağından ayrı tutulabilir. Restore edilen sistemlerde malware taraması ve güvenlik kontrolleri uygulanır. Kimlik bilgileri ve secret'lar gerektiğinde yenilenir. Doğrulama tamamlandıktan sonra sistem kontrollü biçimde hizmete alınır.

Malware Scanning

Yedeklerin doğrudan production'a restore edilmesi yeniden enfeksiyon riski yaratabilir. Dosyalar ve sistem imajları güvenli ortamda taranmalıdır. Tarama sonuçları recovery validation sürecinin parçası hâline getirilmelidir. Güvenlik araçlarının imza ve politika güncelliği kontrol edilmelidir. Kritik uygulamalarda manuel analiz de gerekebilir.

Privileged Account Recovery

Ransomware olaylarında ayrıcalıklı hesapların ele geçirilmiş olabileceği varsayılmalıdır. Kurtarma sürecine başlamadan önce güvenilir yönetim hesapları oluşturulmalıdır. MFA ve break-glass erişimleri yeniden doğrulanmalıdır. Eski secret ve token'lar rotasyona alınabilir. Kimlik güvenliği sağlanmadan teknik sistemleri ayağa kaldırmak tekrar ele geçirilme riskini artırır.

Ransomware DR Drill

Ransomware drill yalnızca backup restore testi değildir. Senaryo, kimlik ihlali, production izolasyonu, temiz nokta seçimi ve güvenli restore adımlarını birlikte içermelidir. Güvenlik ve altyapı ekipleri aynı tatbikatta rol almalıdır. Gerçek süreler ve manuel adımlar ölçülmelidir. Tatbikat sonunda bulgular runbook'a işlenmelidir.

3-2-1 ve 3-2-1-1-0 Backup Stratejileri

3-2-1 yaklaşımı veri koruma için uzun süredir kullanılan pratik bir çerçevedir. 3-2-1-1-0 modeli bu yapıya immutable veya offline kopya ve doğrulama hedefi ekler. Amaç tek bir hata veya saldırının bütün kopyaları aynı anda etkilemesini zorlaştırmaktır. Sayılar bir ürün değil, risk dağıtım mantığını ifade eder. Kurumun altyapısına göre teknik uygulama şekli değişebilir.

Üç Veri Kopyası

Üç kopya yaklaşımı bir üretim verisi ve en az iki ek kopya düşüncesine dayanır. Kopyaların aynı altyapı sınırı içinde tutulması beklenen korumayı azaltabilir. Farklı erişim yetkileri kullanmak riski dağıtır. Her kopyanın yaşam döngüsü ve saklama süresi tanımlanmalıdır. Gereksiz kopyalar ise veri güvenliği ve maliyet açısından ayrıca yönetilmelidir.

İki Farklı Medya

İki farklı medya veya teknoloji yaklaşımı aynı tür arızanın bütün kopyaları etkilemesini azaltmayı hedefler. Modern bulut ortamlarında bu kavram fiziksel medyadan daha geniş yorumlanabilir. Örneğin farklı depolama sınıfları veya bağımsız koruma katmanları kullanılabilir. Temel hedef ortak hata noktasını azaltmaktır. Seçilen yöntemin gerçekten bağımsızlığı artırıp artırmadığı analiz edilmelidir.

Bir Off-Site Kopya

Off-site kopya ana lokasyon dışındaki veri kopyasını ifade eder. Fiziksel felaket veya bölgesel kesinti sırasında önemli koruma sağlar. Bulut ortamında farklı bölge veya ayrı hesap kullanılabilir. Veri aktarımı ve saklama regülasyonları göz önünde bulundurulmalıdır. Restore süresi de RTO açısından test edilmelidir.

Bir Immutable veya Offline Kopya

Immutable veya offline kopya özellikle saldırı senaryolarına karşı ek güvenlik sağlar. Üretim yöneticisinin yedekleri kolayca silememesi önemli bir tasarım prensibidir. Saklama süresi iş ihtiyacına göre belirlenmelidir. Erişim prosedürü acil durumda bilinir olmalıdır. Koruma seviyesi düzenli audit ile doğrulanmalıdır.

Sıfır Doğrulama Hatası

Sıfır doğrulama hatası hedefi, yedeklerin test ve bütünlük kontrollerinden başarıyla geçmesini amaçlar. Backup job'ın tamamlanması tek başına bu sonucu garanti etmez. Dosya checksum, restore testi ve uygulama açılış kontrolü birlikte yapılabilir. Hatalı kopyalar hızlı biçimde yeniden oluşturulmalıdır. Dashboard üzerinde doğrulama durumu görünür tutulmalıdır.

Backup Integrity Testleri

Backup integrity testi yedek verinin gerçekten okunabilir olduğunu doğrular. Testler küçük örnekler yerine zaman zaman tam restore içermelidir. Veritabanı tutarlılık kontrolleri ayrıca uygulanabilir. Şifreleme anahtarlarının erişilebilirliği de test edilmelidir. Test sonuçları RPO ve risk raporlarına eklenmelidir.

Identity Disaster Recovery Neden Kritik?

Kimlik servisi çalışmıyorsa kullanıcıların ve yöneticilerin diğer sistemlere erişimi kesilebilir. Bu nedenle identity recovery, çoğu DR planında en erken başlatılması gereken alanlardan biridir. Sadece kullanıcı hesapları değil, service account, MFA, yetkilendirme politikaları ve privileged access de değerlendirilmelidir. Kimlik altyapısının yedeği bulunmasına rağmen geri dönüş prosedürü bilinmiyorsa kurtarma uzayabilir. Wave 0 yaklaşımı bu yüzden identity ve network bileşenlerine öncelik verir.

Active Directory

Active Directory birçok kurumda kimlik, policy ve uygulama erişimi için merkezi bağımlılıktır. Domain controller yedekleri uygun yöntemlerle alınmalıdır. Restore senaryosu izole ortamda test edilmelidir. DNS bağımlılığı ayrıca değerlendirilmelidir. Yetkili hesapların recovery sırasında erişilebilir olması gerekir.

Entra ID / Identity Provider

Bulut tabanlı identity provider hizmetleri de kritik erişim bağımlılıklarıdır. Kullanıcı senkronizasyonu, federation ve conditional access politikaları dokümante edilmelidir. Acil erişim hesapları normal federation bağımlılığından ayrı tutulabilir. Yönetim erişimi kaybolduğunda uygulanacak eskalasyon yöntemi bilinmelidir. SaaS servislerine erişim de bu katmana bağlı olabilir.

MFA

MFA güvenlik açısından vazgeçilmezdir fakat recovery sürecinde erişim bağımlılığı oluşturabilir. Kimlik sağlayıcısı veya telefon altyapısı kullanılamadığında alternatif doğrulama yöntemi gerekebilir. Bu alternatif mekanizma güvenliği zayıflatmamalıdır. Break-glass hesapları sıkı kontroller altında tutulmalıdır. Tatbikatlarda MFA başarısızlığı senaryosu da denenmelidir.

Break-Glass Accounts

Break-glass hesapları normal kimlik mekanizması çalışmadığında acil yönetim erişimi sağlar. Bu hesaplar günlük operasyon için kullanılmamalıdır. Güçlü kimlik bilgileri ve bağımsız saklama yöntemi uygulanmalıdır. Kullanımı alarm ve audit kaydı üretmelidir. Düzenli test yapılırken gereksiz erişim açılmamasına dikkat edilmelidir.

Privileged Access

Felaket sırasında hızlı hareket ihtiyacı ayrıcalıklı erişim riskini artırabilir. Yetkilerin kimde olduğu önceden belirlenmelidir. Least privilege ilkesi acil durumda da mümkün olduğunca korunmalıdır. Geçici yetkiler olay sonrasında kaldırılmalıdır. Bütün privileged işlemler merkezi log sistemine aktarılmalıdır.

Kullanıcı Authenticate Olamıyorsa Sistem Kurtarılmış Sayılır mı?

Hayır, gerçek hizmet kullanıcı tarafından erişilebilir olmalıdır. Uygulama sunucusunun çalışması tek başına recovery tamamlandı anlamına gelmez. Kullanıcı kimliği doğrulanamıyorsa iş süreci hâlâ kesintidedir. Bu nedenle RTO ölçümünün son noktası gerçek kullanıcı deneyimine dayanmalıdır. Identity validation her recovery testinin zorunlu adımlarından biri olmalıdır.

DNS ve Network Disaster Recovery

DNS ve network katmanı birçok DR planında sonradan hatırlanan fakat kurtarmayı doğrudan belirleyen bileşenlerdir. Recovery ortamı çalışsa bile trafik doğru yere yönlenmiyorsa hizmet erişilemez kalır. VPN, firewall, route ve IP allowlist yapılandırmaları birlikte değerlendirilmelidir. DNS TTL değerleri failover hızını etkileyebilir. Ağ bileşenleri Wave 0 içinde hazırlanmalıdır.

DNS Failover

DNS failover kullanıcı trafiğini recovery endpoint'e yönlendirmek için yaygın yöntemdir. Otomatik veya manuel tetiklenebilir. Health check'lerin yanlış pozitif üretmesi istenmeyen geçişe neden olabilir. DNS kaydı değişse bile istemci ve ara resolver cache'leri eski değeri tutabilir. Bu nedenle gerçek trafik davranışı test edilmelidir.

DNS TTL

TTL, DNS kaydının istemci veya resolver tarafından ne kadar süre cache'lenebileceğini belirler. Düşük TTL daha hızlı yön değişikliğine yardımcı olabilir. Fakat daha fazla DNS sorgusu oluşturabilir. Felaket anında TTL düşürmek için geç olabilir çünkü eski değer hâlâ cache'lerde bulunabilir. Kritik kayıtlar için TTL stratejisi önceden planlanmalıdır.

Global Traffic Management

Global traffic management farklı bölgelerdeki endpoint'ler arasında kullanıcı trafiğini yönetir. Sağlık, coğrafya veya latency gibi kriterlerle yönlendirme yapılabilir. Failover politikaları iş kurallarıyla uyumlu olmalıdır. Recovery bölgesinin kapasitesi yeni trafik yükünü karşılayabilmelidir. Trafik geçişi kontrollü testlerle doğrulanmalıdır.

Load Balancer

Load balancer uygulama instance'ları arasında trafiği dağıtır. Recovery ortamındaki konfigürasyonun production ile uyumlu olması gerekir. Health check path'leri yanlışsa sağlıklı sunucular devre dışı kalabilir veya hatalı sunucular trafik alabilir. Sertifika ve listener yapılandırmaları da yedeklenmelidir. Failover testinde gerçek kullanıcı trafiğine yakın yük uygulanması faydalıdır.

VPN ve Remote Access

Felaket sırasında teknik ekiplerin recovery ortamına uzaktan erişmesi gerekebilir. Birincil VPN altyapısı aynı olaydan etkilenmişse alternatif erişim yöntemi bulunmalıdır. Yönetim ağı ve kullanıcı ağı için ayrı senaryolar değerlendirilebilir. MFA ve cihaz güvenliği acil erişimde de korunmalıdır. Remote access kapasitesi toplu çalışma durumları için test edilmelidir.

Firewall Kuralları

Firewall kuralları recovery ortamında unutulan dependency'lerin sık nedenlerinden biridir. Production'da sonradan açılmış bir port DR'a aktarılmamış olabilir. Kurallar kod olarak yönetildiğinde karşılaştırma kolaylaşır. Gereksiz geniş erişim açmak ise güvenlik riskini büyütür. Her drill sonrasında başarısız bağlantılar firewall politikası açısından incelenmelidir.

Network Route'ları

Route tabloları servislerin birbirine ve dış sistemlere erişimini belirler. Recovery ortamında aynı network topolojisinin birebir kopyalanması her zaman gerekli olmayabilir. Ancak kritik subnet ve gateway bağımlılıkları korunmalıdır. Yanlış route sessiz bağlantı sorunları yaratabilir. Otomatik validation testleri temel endpoint'lere erişimi doğrulayabilir.

IP Allowlist Problemleri

Harici servisler production çıkış IP'sini allowlist'e eklemiş olabilir. Recovery bölgesine geçildiğinde çıkış IP'si değişirse entegrasyon başarısız olur. Bu bağımlılık dependency map içinde açıkça kayıt altına alınmalıdır. Mümkünse önceden alternatif recovery IP'leri tanımlanmalıdır. Failover testleri gerçek dış servis bağlantılarını da kapsamalıdır.

Certificate, Secret ve Key Recovery

Sertifika, secret ve şifreleme anahtarları olmadan recovery ortamındaki veriler ve servisler kullanılamaz hâle gelebilir. Bu bileşenler genellikle küçük görünür fakat kritik bağımlılık oluşturur. Anahtarların aynı hata alanında tutulması yedekleri anlamsız hâle getirebilir. Secret rotation ve erişim politikaları recovery senaryosuna dahil edilmelidir. Özellikle KMS bağımlılıkları düzenli test edilmelidir.

TLS Sertifikaları

TLS sertifikaları kullanıcı ve servis bağlantılarının güvenli kurulmasını sağlar. Recovery endpoint'lerinin doğru hostname ve sertifikaya sahip olması gerekir. Sertifika yenileme mekanizması yalnızca primary ortama bağlıysa DR sırasında sorun yaşanabilir. Private key erişimi güvenli biçimde hazırlanmalıdır. Süre dolumu monitoring sistemine eklenmelidir.

Private Keys

Private key kaybı şifreli servislerin çalışmamasına neden olabilir. Anahtarların güvenli yedekleme ve erişim politikası olmalıdır. Düz metin olarak runbook içinde saklanmamalıdır. Recovery ekibinin hangi koşulda erişebileceği belirlenmelidir. Anahtar rotasyonu sonrasında DR kopyalarının güncel kaldığı doğrulanmalıdır.

Secrets Manager / Vault

Merkezi secret yönetimi uygulama kimlik bilgilerinin kontrollü saklanmasını sağlar. Recovery ortamının bu sisteme nasıl erişeceği önceden tasarlanmalıdır. Ana secret servisi unavailable ise bağımsız recovery yolu gerekebilir. Yetkiler en az ayrıcalık ilkesiyle sınırlandırılmalıdır. Restore sonrasında kritik secret'lar gerektiğinde rotasyona alınmalıdır.

KMS Anahtarları

KMS anahtarları disk, obje ve backup şifrelemesinin temel bağımlılığı olabilir. Anahtar silinirse veri kopyaları mevcut olsa bile okunamaz hâle gelebilir. Anahtar yaşam döngüsü ve bölgesel erişim politikası DR tasarımının parçası olmalıdır. Silme koruması ve yetki ayrımı değerlendirilebilir. Recovery drill sırasında şifreli yedeklerin gerçekten açılabildiği test edilmelidir.

Recovery Ortamında Secret Rotation

Güvenlik olayı sonrasında eski secret'lara güvenmek doğru olmayabilir. Recovery ortamı açılırken belirli kimlik bilgilerinin otomatik rotasyonu planlanabilir. Uygulama config'lerinin yeni değerleri kullanabildiği doğrulanmalıdır. Bağımlı entegrasyonlarda credential güncellemesi gerekebilir. Rotasyon adımları runbook içinde sıra ile tanımlanmalıdır.

KMS Kaybolursa Yedeklerin Kullanılabilirliği

Şifreli backup, doğru anahtar olmadan kullanılamaz. Bu nedenle backup koruması ile anahtar koruması birlikte tasarlanmalıdır. Aynı yönetim hatası hem backup'ı hem anahtarı silebiliyorsa gerçek bağımsızlık zayıftır. Anahtar recovery prosedürü ayrıca test edilmelidir. Veri koruma tasarımında “kopya var mı?” kadar “kopya çözülebiliyor mu?” sorusu da sorulmalıdır.

Infrastructure as Code ile Disaster Recovery

Infrastructure as Code, recovery ortamının tekrarlanabilir biçimde oluşturulmasını sağlar. Manuel kurulumlara göre hata oranını ve yeniden oluşturma süresini azaltabilir. Network, compute, erişim ve bazı policy bileşenleri kod olarak yönetilebilir. Ancak IaC deposu ve state dosyaları da kritik recovery varlıklarıdır. Kodun gerçekten yeni bir bölgede çalışabildiği düzenli test edilmelidir.

Terraform

Terraform çoklu altyapı bileşenlerini kodla tanımlamak için yaygın kullanılan bir yaklaşımdır. DR ortamının network, compute ve servis yapılandırmaları modüller hâlinde hazırlanabilir. State dosyasının güvenli saklanması kritik önemdedir. Provider sürümü ve modül değişiklikleri test edilmelidir. Recovery bölgesinde quota ve servis farklılıkları ayrıca kontrol edilmelidir.

CloudFormation

CloudFormation altyapı kaynaklarını deklaratif şablonlarla yönetmeye olanak verir. Kurtarma kaynakları önceden tanımlanarak tekrar kurulabilir. Şablonların güncel production değişikliklerini içermesi gerekir. Parametre ve secret yönetimi ayrı güvenlik kontrolleriyle korunmalıdır. Drill sırasında gerçek deployment süresi ölçülmelidir.

Bicep

Bicep kaynak tanımlarını daha okunabilir biçimde kodlaştırmak için kullanılabilir. DR altyapısının modüler şekilde hazırlanmasına yardımcı olur. Region'a bağlı parametrelerin ayrı tutulması geçişi kolaylaştırır. Kod review süreçleri yanlış değişiklik riskini azaltır. Deployment çıktıları recovery validation içinde kontrol edilmelidir.

Recovery Region'ın Otomatik Oluşturulması

Recovery region kaynaklarının otomatik kurulması pilot light ve backup restore stratejilerinde büyük hız kazandırır. Network ve security bileşenleri şablonlardan oluşturulabilir. Fakat servis kotaları deployment öncesinde kontrol edilmelidir. Region'a özgü olmayan kaynakların davranışı ayrıca incelenmelidir. Tam ortam kurma testi düzenli aralıklarla yapılmalıdır.

IaC State Backup

IaC state altyapı kaynaklarının mevcut durumunu takip etmek için kritik olabilir. State kaybı yeniden yönetim ve import işlemlerini zorlaştırabilir. Dosya şifrelenmiş ve versioning açık bir depoda tutulabilir. Erişim yetkileri sınırlandırılmalıdır. State restore prosedürü de DR planının parçası olmalıdır.

Git Repository Recovery

IaC kodu ve uygulama deployment tanımları çoğu zaman Git repository içinde tutulur. Repository hizmeti unavailable olduğunda recovery süreci durmamalıdır. Kritik repoların bağımsız kopyaları veya export yöntemleri değerlendirilebilir. Access token ve signing key'lerin de kurtarılması gerekir. Kod kaynağı recovery dependency map içinde açıkça gösterilmelidir.

Infrastructure Drift Detection

Drift detection production ortamı ile tanımlı altyapı kodu arasındaki farkları bulur. Manuel değişiklikler DR şablonuna yansımadığında failover sırasında hata oluşabilir. Otomatik taramalar bu riski erken gösterebilir. Kritik farklar değişiklik yönetimi sürecine bağlanmalıdır. Her major release sonrası drift kontrolü yapmak iyi bir pratiktir.

Configuration Drift DR Planını Nasıl Bozar?

Configuration drift production ve recovery ortamlarının zaman içinde farklılaşmasıdır. Bu farklar küçük görünebilir, fakat failover sırasında kritik bağlantıların çalışmamasına neden olabilir. Yeni firewall kuralı, servis hesabı veya application dependency DR ortamına aktarılmamış olabilir. Drift izleme bu görünmeyen riskleri azaltır. Kurtarma planı değişiklik yönetimiyle doğrudan bağlanmalıdır.

Production ve DR Arasındaki Farklar

Production sürekli değişirken recovery ortamı uzun süre kullanılmayabilir. Bu nedenle paket sürümleri, network kuralları ve uygulama ayarları zamanla farklılaşabilir. Farkların manuel listelerle takip edilmesi zordur. Otomatik karşılaştırma araçları daha güvenilir sonuç verir. Drill öncesi fark analizi zorunlu kontrol hâline getirilebilir.

Yeni Firewall Kurallarının DR'a Aktarılmaması

Production'da açılan yeni bir bağlantı uygulamanın çalışması için kritik olabilir. Aynı kural recovery ortamına eklenmezse failover sonrasında servis bağımlılığı kesilir. Firewall politikalarının kod olarak yönetilmesi bu riski azaltır. Değişiklik taleplerinde DR etkisi ayrı alan olarak değerlendirilmelidir. Testler yalnızca port kontrolü değil gerçek uygulama akışını doğrulamalıdır.

Yeni Sunucuların DR Scope'una Eklenmemesi

Yeni bir sunucu veya servis production'a alınırken DR kapsamına otomatik girmeyebilir. Bu durum envanterin zaman içinde eksik kalmasına yol açar. CMDB veya cloud inventory ile otomatik kontrol faydalıdır. Yeni kaynakların backup ve replication politikaları da doğrulanmalıdır. Release sürecinde DR scope kontrolü yapılması riski azaltır.

Değişen Application Dependencies

Uygulamalar zaman içinde yeni veritabanı, API veya mesajlaşma servislerine bağlanabilir. Dependency map güncellenmezse runbook eski kalır. Yeni bağımlılığın recovery ortamında erişilebilirliği test edilmelidir. Sertifika ve secret gereksinimleri ayrıca kaydedilmelidir. Her büyük mimari değişiklik sonrası DR validation yapılması güçlü bir kontrol yöntemidir.

Automated Drift Detection

Automated drift detection düzenli taramalarla üretim ve DR tanımlarını karşılaştırır. Fark bulunduğunda ilgili ekibe alarm üretilebilir. Kritik ve düşük riskli farklar ayrı sınıflandırılmalıdır. Otomatik düzeltme uygulanacaksa yanlış değişiklik riskine karşı onay mekanizması düşünülmelidir. Raporlar recovery dashboard'a dahil edilebilir.

Her Major Change Sonrası DR Validation

Büyük altyapı veya uygulama değişiklikleri recovery davranışını etkileyebilir. Bu nedenle major release sonrasında kısa bir DR validation yapılması yararlıdır. Tam failover her değişiklikte gerekli olmayabilir. Ancak dependency, backup, IaC ve network kontrolleri otomatik çalıştırılabilir. Riskli değişikliklerde daha kapsamlı drill planlanabilir.

Kubernetes Disaster Recovery

Kubernetes ortamlarında DR yalnızca cluster kaynaklarını yeniden oluşturmakla bitmez. etcd state, persistent volume, registry, secret ve stateful workload verileri ayrı ayrı korunmalıdır. GitOps cluster reconstruction süresini azaltabilir. Ancak dış veri servisleri ve cloud bağımlılıkları yine bağımsız plan gerektirir. Kurtarma testleri gerçek stateful uygulamaları içermelidir.

Kubernetes Cluster State

Cluster state deployment, service, config ve policy gibi kaynak tanımlarını içerir. Bu kaynakların kod deposunda tutulması yeniden kurulum sürecini hızlandırır. Manuel oluşturulmuş kaynaklar görünmez risk oluşturabilir. Cluster state ile gerçek altyapı arasındaki fark düzenli kontrol edilmelidir. Recovery testi boş cluster'dan yeniden oluşturmayı da içerebilir.

etcd Backup

etcd Kubernetes kontrol düzleminin kritik state verisini saklar. Backup yöntemi cluster kurulum modeline göre değişebilir. Snapshot'ların güvenli ve ayrı bir konuma kopyalanması önemlidir. Restore prosedürü aynı sürüm ve sertifika gereksinimleriyle test edilmelidir. Yönetilen cluster hizmetlerinde sağlayıcı sorumluluğu ile kurum sorumluluğu ayrıştırılmalıdır.

Persistent Volumes

Stateful uygulamaların verisi persistent volume üzerinde bulunabilir. Volume snapshot ve replication politikaları uygulamanın veri tutarlılığına uygun olmalıdır. Yalnızca volume kopyası almak her zaman application-consistent sonuç vermez. Recovery bölgesinde storage class eşleşmesi kontrol edilmelidir. Büyük veri setlerinde restore süresi RTO'yu belirleyebilir.

Container Registry

Recovery cluster'ın gerekli image'lara erişebilmesi gerekir. Registry yalnızca primary region'da bulunuyorsa bölgesel kesinti deployment'ı durdurabilir. Kritik image'lar recovery bölgesine replike edilebilir. Image tag yerine değişmez digest kullanımı sürüm doğruluğunu artırır. Registry kimlik bilgileri ve erişim politikaları da plana dahil edilmelidir.

Secrets

Kubernetes secret'ları uygulama bağlantıları için kritik olabilir. Düz manifest dosyalarında saklanmaları güvenlik riski yaratır. Harici secret yönetimi veya şifrelenmiş kaynaklar kullanılabilir. Recovery cluster'ın secret kaynağına erişimi test edilmelidir. Güvenlik olayı sonrasında rotasyon prosedürü uygulanmalıdır.

GitOps ile Cluster Reconstruction

GitOps yaklaşımı hedef cluster durumunun kod deposundan yeniden uygulanmasını kolaylaştırır. Yeni recovery cluster açıldıktan sonra kaynaklar kontrollü biçimde senkronize edilebilir. Kod deposunun ve GitOps controller kimlik bilgilerinin de kurtarılabilir olması gerekir. Yanlış manifest değişikliği iki ortama birden yayılabileceği için review süreçleri önemlidir. Reconstruction süresi drill sırasında ölçülmelidir.

Stateful Workload Recovery

Stateful workload kurtarması uygulama ile verinin doğru sırada birleştirilmesini gerektirir. Önce storage ve database recovery tamamlanabilir, ardından pod'lar devreye alınır. Uygulama lock mekanizmaları ve leader election davranışı test edilmelidir. İki cluster'ın aynı veriye aynı anda yazması önlenmelidir. Kullanıcı kabul testi stateful fonksiyonları kapsamalıdır.

SaaS Uygulamaları İçin Disaster Recovery

SaaS kullanmak kurumun bütün veri koruma sorumluluğunu ortadan kaldırmaz. Sağlayıcı erişilebilirliği, yanlış kullanıcı işlemleri, hesap ihlali ve veri saklama politikaları ayrı risklerdir. Kritik SaaS verilerinin export edilebilirliği önceden değerlendirilmelidir. Entegrasyonların kesinti sırasında nasıl davranacağı planlanmalıdır. İş sürekliliği prosedürleri teknik backup kadar önemli olabilir.

Microsoft 365

Kurumsal e-posta ve doküman hizmetleri iş sürekliliği açısından kritik olabilir. Saklama, versioning ve geri dönüş yeteneklerinin kurum ihtiyacını karşılayıp karşılamadığı değerlendirilmelidir. Kullanıcı yanlış silmeleri ile hesap ihlali farklı senaryolardır. Alternatif iletişim kanalı DR planında tanımlanmalıdır. Kritik veriler için bağımsız kopya gereksinimi risk analizine göre belirlenmelidir.

Google Workspace

Bulut ofis hizmetlerinde e-posta, dosya ve kullanıcı kimliği aynı sağlayıcıya bağlı olabilir. Bu bağımlılık kesinti senaryosunda geniş etki yaratabilir. Veri export ve saklama seçenekleri önceden incelenmelidir. Yönetici erişimi için alternatif yöntemler hazırlanmalıdır. İş birimleri servis erişilemediğinde hangi geçici süreci kullanacağını bilmelidir.

CRM ve SaaS Platformları

CRM ve benzeri SaaS sistemleri müşteri süreçlerinin merkezinde olabilir. Sağlayıcının kendi DR yetenekleri kurumun özel RTO beklentisini karşılamayabilir. Veri export, API erişimi ve entegrasyon bağımlılıkları analiz edilmelidir. Kritik kayıtların bağımsız rapor veya kopyaları yararlı olabilir. Sözleşmedeki veri geri alma ve hizmet sonlandırma koşulları da incelenmelidir.

SaaS Backup Neden Gerekebilir?

SaaS sağlayıcısı platform erişilebilirliğini korusa bile kullanıcı kaynaklı veri silme her zaman aynı kapsamda olmayabilir. Retention süreleri kurum ihtiyacından kısa olabilir. Fidye yazılımı senaryosu senkronize dosyaları etkileyebilir. Bağımsız backup daha uzun geçmişe dönüş veya farklı güvenlik sınırı sağlayabilir. Gereksinim veri kritikliği ve sağlayıcı özelliklerine göre belirlenmelidir.

SaaS Provider Outage Senaryosu

Sağlayıcı kesintisinde kurum altyapıyı doğrudan onaramaz. Bu nedenle geçici manuel süreçler veya alternatif iletişim kanalları planlanmalıdır. Entegrasyonların hata üretmek yerine kuyruklama yapması mümkünse tercih edilebilir. Status bilgisinin nereden takip edileceği runbook'a eklenmelidir. Uzun kesintiler için yönetim eskalasyonu tanımlanmalıdır.

SaaS Verisinin Export Edilebilirliği

Verinin dışa aktarılabilir olması provider lock-in ve recovery açısından önemlidir. Export formatının gerçekten kullanılabilir ve yeterli metadata içeriyor olması gerekir. Büyük veri setlerinin çıkarılma süresi test edilmelidir. API limitleri ve egress maliyeti dikkate alınmalıdır. Düzenli export gerekiyorsa süreç otomatikleştirilebilir.

Hybrid Cloud Disaster Recovery

Hybrid ortamlarda on-premise ve cloud bağımlılıkları birlikte ele alınmalıdır. Uygulama bir yerde, veritabanı başka yerde bulunabilir. Ağ bağlantısı kesildiğinde iki taraf ayrı ayrı çalışıyor olsa bile hizmet durabilir. Recovery stratejisi fiziksel sunucu, cloud servisleri, DNS ve kimlik katmanlarını ortak plana dahil etmelidir. Hybrid kullanıcı erişimi ayrıca test edilmelidir.

On-Premise → Cloud

On-premise iş yüklerinin cloud ortamına kurtarılması ikinci fiziksel veri merkezi ihtiyacını azaltabilir. Veriler önceden replike edilebilir veya backup üzerinden geri yüklenebilir. Network ve kimlik bağlantıları recovery öncesinde hazırlanmalıdır. VM formatı ve lisans koşulları değerlendirilmelidir. Gerçek failover testi performans ve kapasiteyi doğrular.

Cloud → On-Premise

Bazı kurumlar cloud kesintisinde kritik iş yüklerini yerel altyapıya döndürmek isteyebilir. Bunun için yeterli fiziksel kapasite sürekli hazır olmalıdır. Cloud'a özel servislerin yerel karşılığı bulunmayabilir. Veri transfer süresi ve egress maliyeti önemli olabilir. Bu yaklaşım yalnızca açık bir iş gerekçesi varsa anlamlıdır.

Cloud → Cloud

Bir cloud ortamından başka bir bağımsız ortama recovery teknik olarak mümkündür. Ancak servis API'leri ve yönetilen platform özellikleri birebir aynı olmayabilir. Taşınabilir uygulama katmanı işleri kolaylaştırabilir. Veri kopyalama ve ağ yönlendirme süreçleri önceden test edilmelidir. Operasyon ekibinin iki ortamı da yönetebilmesi gerekir.

Physical Server Recovery

Legacy uygulamalar fiziksel sunuculara bağlı olabilir. Bu sistemlerin image tabanlı yedeği veya sanallaştırma yöntemi değerlendirilebilir. Donanım bağımlı lisans ve sürücüler kurtarmayı zorlaştırabilir. Uygulamanın modernleştirilmesi uzun vadede DR süresini azaltabilir. Kısa vadede ise gerçek donanım arızası senaryosu test edilmelidir.

Network Dependency'leri

Hybrid yapıda VPN, özel hat veya gateway bağlantısı kritik bağımlılık hâline gelir. Tek bağlantı noktası yüksek risk oluşturabilir. Alternatif route ve internet tabanlı güvenli erişim yöntemi değerlendirilebilir. DNS çözümleme iki ortam arasında doğru çalışmalıdır. Ağ kesintisi drill'i hybrid DR planının önemli parçalarından biridir.

Hybrid Kullanıcıların Erişimi

Kullanıcılar şirket içi ağdan veya uzaktan sisteme erişebilir. Recovery ortamına geçildiğinde aynı erişim yöntemi çalışmayabilir. VPN, SSO ve cihaz politikaları test edilmelidir. Lokasyon bazlı IP allowlist'ler gözden geçirilmelidir. Kullanıcı kabul testi farklı erişim profillerini kapsamalıdır.

Multi-Cloud Disaster Recovery Mantıklı mı?

Multi-cloud DR bazı riskleri dağıtabilir, ancak önemli bir operasyon yükü de getirir. Farklı platformların network, identity, database ve yönetim servisleri aynı davranışı göstermeyebilir. Bu nedenle yalnızca tek sağlayıcı kesintisinden kaçınmak için ikinci platform kurmak her zaman ekonomik değildir. Uygulamanın taşınabilirliği ve veri hareketi dikkatle analiz edilmelidir. Gerçek iş gerekçesi olmadan eklenen çoklu platform yapısı yönetim riskini büyütebilir.

Cloud Provider Outage Riskini Azaltmak

Bağımsız bir ikinci ortam tek sağlayıcıya bağlı bölgesel veya yönetimsel riskleri azaltabilir. Ancak çoğu kurum için aynı platform içinde ayrı region kullanmak daha basit bir çözüm olabilir. Hangi riskin azaltılmak istendiği açık biçimde tanımlanmalıdır. Provider seviyesindeki tam kesinti olasılığı, uygulamanın kesinti maliyetiyle birlikte değerlendirilmelidir. Daha fazla platform her zaman daha yüksek güvenilirlik anlamına gelmez.

AWS → Azure / GCP

Farklı bulut platformları arasında kurtarma tasarlarken servis eşdeğerliği temel konulardan biridir. Sanal makineler nispeten taşınabilir olabilir, fakat yönetilen veritabanı veya mesajlaşma servisleri daha fazla uyarlama gerektirebilir. Identity, network ve güvenlik modelleri de farklılaşabilir. Bu nedenle AWS Azure ve Google Cloud disaster recovery çözümleri karşılaştırması yapılırken yalnızca servis listesine değil, uygulamanın gerçek bağımlılıklarına bakılmalıdır. En iyi seçenek, kurumun teknik kapasitesi ve iş hedefleriyle sürdürülebilir olan modeldir.

Platform Servislerinin Uyumsuzluğu

Yönetilen servislerin API ve özellikleri farklı olabilir. Bir veritabanı veya queue hizmetinin diğer platformda birebir karşılığı bulunmayabilir. Bu durumda uygulama kodunda uyarlama gerekebilir. Taşınabilirlik katmanları bu bağımlılığı azaltabilir fakat ek bakım getirir. DR testi gerçek platform değişimini içermelidir.

Data Portability

Verinin standart formatlarda dışa aktarılabilmesi çoklu platform recovery için önemlidir. Proprietary formatlar geçiş süresini uzatabilir. Büyük veri setlerinde transfer süresi RTO'yu aşabilir. Düzenli replika veya export mekanizması gerekebilir. Veri bütünlüğü hedef tarafta ayrıca doğrulanmalıdır.

Egress Maliyeti

Buluttan büyük miktarda veri çıkarmak maliyet oluşturabilir. Normal koşullarda düşük olan bu gider gerçek failover sırasında ciddi seviyeye ulaşabilir. Drill maliyeti de bütçeye dahil edilmelidir. Veri hacmi büyüdükçe fiziksel veya alternatif transfer yöntemleri değerlendirilebilir. TCO hesabı yalnızca bekleme altyapısını içermemelidir.

Operasyonel Karmaşıklık

İki farklı platform iki farklı yetkinlik seti gerektirir. Monitoring, security, IaC ve incident süreçleri her iki ortamda da yönetilmelidir. Ekip yalnızca bir platformu iyi biliyorsa gerçek felaket sırasında hata riski artabilir. Eğitim ve düzenli drill bu farkı azaltır. Operasyon kapasitesi mimari seçim kadar önemlidir.

Multi-Cloud DR Ne Zaman Gereksizdir?

İş yükünün bölgesel kesinti toleransı yüksekse aynı platform içinde multi-region yeterli olabilir. Kesinti maliyeti ikinci platform yatırımından düşükse multi-cloud ekonomik değildir. Platform bağımlılığı çok yüksek uygulamalarda geçiş süreleri de hedef RTO'yu aşabilir. Operasyon ekibi iki ortamı sürdüremiyorsa ek yapı güvenilirliği düşürebilir. Karar moda veya algıya değil, somut risk analizine dayanmalıdır.

Failover Nasıl Çalışır?

Failover, üretim hizmetinin kurtarma ortamına kontrollü biçimde geçirilmesidir. Süreç felaket deklarasyonu, veri doğrulama, recovery sistemlerinin başlatılması ve trafik cutover adımlarını içerir. Otomatik veya manuel yapılabilir. Her iki yöntemde de yanlış geçiş riskini azaltacak kontroller gerekir. Kullanıcı kabul testi tamamlanmadan recovery başarılı sayılmamalıdır.

Felaket Deklarasyonu

Felaket deklarasyonu resmi recovery sürecini başlatan karardır. Hangi olaylarda deklarasyon yapılacağı önceden tanımlanmalıdır. Kısa süreli arıza ile gerçek DR olayı birbirinden ayrılmalıdır. Karar yetkisi belirli kişilere veya role atanmalıdır. Başlangıç zamanı RTO ölçümü için kayıt altına alınmalıdır.

Failover Yetkisi Kimde Olmalı?

Failover kararı teknik ekibin tek taraflı kararı olmak zorunda değildir. İş etkisi, güvenlik durumu ve tahmini onarım süresi birlikte değerlendirilir. Incident Commander süreci koordine edebilir. Kritik sistemlerde iki aşamalı onay uygulanabilir. Yetki matrisi runbook içinde açık biçimde yazılmalıdır.

Manuel Failover

Manuel failover insan kontrolü sayesinde yanlış geçiş riskini azaltabilir. Ancak çok sayıda adım varsa süreç uzayabilir ve hata ihtimali artabilir. Checklist ve otomatik doğrulamalar manuel yöntemi güçlendirebilir. Kritik komutlar önceden test edilmelidir. İnsan bağımlılığı actual RTO ölçümünde görünür olmalıdır.

Otomatik Failover

Otomatik failover sağlık kontrollerine göre hızlı geçiş sağlayabilir. Düşük RTO hedeflerinde önemli avantaj sunar. Fakat yanlış pozitif health check gereksiz bölge değişimine neden olabilir. Özellikle stateful sistemlerde otomatik promotion dikkatle tasarlanmalıdır. Human approval gate bazı kritik aşamalarda güvenli denge sağlar.

False Positive Failover Riski

Geçici network sorunu gerçek sistem arızası gibi algılanabilir. Otomatik sistem hemen failover yaparsa iki ortam aynı anda aktif hâle gelebilir. Birden fazla sağlık sinyalini birlikte değerlendirmek riski azaltır. Bekleme süresi ve quorum mantığı kullanılabilir. Testlerde yanlış alarm senaryosu ayrıca denenmelidir.

Traffic Cutover

Traffic cutover kullanıcı trafiğinin recovery ortamına yönlendirilmesidir. DNS, route veya global load balancing ile yapılabilir. Recovery kapasitesi cutover öncesinde doğrulanmalıdır. Trafik kademeli taşınabiliyorsa risk daha kontrollü yönetilir. İlk kullanıcı işlemleri yakından izlenmelidir.

Recovery Validation

Recovery validation teknik servislerin gerçekten işlevsel olduğunu doğrular. Health endpoint'in 200 dönmesi tek başına yeterli değildir. Kritik kullanıcı yolculukları ve veri yazma işlemleri test edilmelidir. Monitoring, log ve güvenlik kontrolleri gözden geçirilmelidir. Başarısız validation varsa trafik tamamen açılmadan sorun giderilmelidir.

Kullanıcı Kabul Testi

Kullanıcı kabul testi iş biriminin sistemin gerçekten kullanılabilir olduğunu onaylamasını sağlar. Teknik ekip her iş akışını bilemeyebilir. Kritik sipariş, ödeme veya raporlama senaryoları süreç sahipleri tarafından test edilmelidir. Sonuçlar zaman damgasıyla kaydedilmelidir. RTO'nun bitiş noktası bu onaya bağlanabilir.

Recovery Wave ve Başlatma Sırası

Recovery wave yaklaşımı sistemleri bağımlılık sırasına göre gruplandırır. Her şeyi aynı anda açmak hataların kaynağını bulmayı zorlaştırabilir. Önce temel identity ve network servisleri, ardından veri katmanı ve uygulamalar devreye alınır. Bu sıra dependency map ile uyumlu olmalıdır. Orchestration otomasyonu wave'leri tekrarlanabilir hâle getirir.

Wave 0 — Identity ve Network

Wave 0 temel erişim servislerini kapsar. DNS, routing, identity, VPN ve gerekli güvenlik bileşenleri bu aşamada hazırlanır. Bu servisler olmadan diğer katmanlar ayağa kalksa bile erişilemez kalabilir. Sağlık kontrolleri tamamlandıktan sonra sonraki wave başlatılır. Wave 0 genellikle recovery süresinin en kritik başlangıç bölümüdür.

Wave 1 — Database

Database katmanı uygulama servislerinden önce hazırlanmalıdır. Replikasyon durumu ve veri tutarlılığı kontrol edilir. Gerekirse replica promotion yapılır. Connection endpoint'leri doğrulanır. Veri katmanı hazır olmadan backend servisleri başlatılmamalıdır.

Wave 2 — Backend Services

Backend servisleri veri ve identity katmanları hazır olduktan sonra devreye alınır. Mesaj kuyrukları ve entegrasyon servisleri de bu grupta olabilir. Health check'ler yalnızca process durumunu değil dependency erişimini test etmelidir. Hata veren servisler diğer wave'i engelleyebilir. Sıralama uygulama dependency map üzerinden belirlenmelidir.

Wave 3 — Frontend

Frontend katmanı backend doğrulandıktan sonra açılır. CDN, load balancer ve TLS sertifikaları kontrol edilir. Kullanıcı oturum açma akışı test edilir. İlk trafik küçük oranda yönlendirilebilir. Kullanıcı kabul testi bu aşamada başlar.

Wave 4 — Reporting ve Non-Critical Systems

Raporlama ve düşük öncelikli sistemler ana hizmet çalışmaya başladıktan sonra kurtarılabilir. Bu yaklaşım kritik kaynakların önce önemli iş süreçlerine ayrılmasını sağlar. Tier 2 ve Tier 3 iş yüklerinin çoğu bu wave'e yerleştirilebilir. Bazı raporların veri güncelliği daha geniş RPO kabul edebilir. Kurtarma tamamlandıktan sonra bu sistemler ayrıca doğrulanmalıdır.

Dependency-Aware Orchestration

Dependency-aware orchestration servislerin gerçek bağımlılık sırasını otomatik uygular. Bir veritabanı hazır olmadan onu kullanan servis başlatılmaz. Başarısız adım sonraki wave'i durdurabilir. Manuel override gerekiyorsa yetki ve koşullar önceden tanımlanmalıdır. Bu yaklaşım büyük ortamlarda insan hatasını önemli ölçüde azaltır.

Failback Nedir ve Neden Failover Kadar Önemlidir?

Failback, geçici recovery ortamından onarılmış primary ortama geri dönüş sürecidir. Pek çok plan failover'a odaklanır fakat geri dönüşün nasıl yapılacağını yeterince test etmez. Recovery ortamında olay sırasında yeni veriler üretildiği için primary'ye dönüş basit bir DNS değişikliği değildir. Reverse replication ve data reconciliation gerekir. Failback de kontrollü bir değişiklik olarak planlanmalıdır.

Primary Ortamın Yeniden Hazırlanması

Primary ortam teknik olarak açılmış olsa bile hemen trafiğe verilmemelidir. Olayın kök nedeni giderilmiş olmalıdır. Güvenlik ihlali varsa credential ve secret'lar yenilenebilir. Altyapı production standardına göre yeniden doğrulanmalıdır. Data sync başlamadan önce hedef ortamın temizliği kontrol edilmelidir.

Reverse Replication

Failover sonrasında yazmalar recovery ortamında devam eder. Geri dönüş için bu değişikliklerin primary tarafa taşınması gerekir. Reverse replication uygun veri araçlarıyla kurulabilir. Lag sıfıra yakın seviyeye gelmeden trafik taşınmamalıdır. İşlem sırasında iki yönlü yazma riski dikkatle yönetilmelidir.

Data Reconciliation

İki ortamda farklı kayıtlar oluşmuşsa data reconciliation gerekir. Hangi kaydın doğru kabul edileceği iş kurallarıyla belirlenmelidir. Otomatik karşılaştırma araçları farkları tespit edebilir. Kritik finansal veya müşteri verilerinde manuel onay gerekebilir. Reconciliation tamamlanmadan failback yapmak veri kaybı yaratabilir.

Kullanıcı Trafiğinin Geri Taşınması

Primary ortam doğrulandıktan sonra kullanıcı trafiği kontrollü biçimde geri taşınır. Kademeli cutover hata riskini azaltabilir. Monitoring metrikleri her aşamada izlenmelidir. DNS cache davranışı hesaba katılmalıdır. Trafik tamamen döndükten sonra recovery ortamı hemen kapatılmamalıdır.

Failback Sırasında Veri Kaybı Riski

Yanlış sırada yapılan geri dönüş yeni işlemlerin kaybolmasına neden olabilir. Son replication checkpoint doğrulanmalıdır. İki tarafa aynı anda yazma engellenmelidir. Uygulama bakım modu gerekebilir. Failback penceresi iş birimiyle birlikte planlanmalıdır.

Failback Testi

Failback testi recovery stratejisinin tam döngüsünü doğrular. Sadece failover yapan drill eksik kalır. Reverse replication, traffic return ve veri doğrulama adımları ölçülmelidir. Failback RTA ayrıca raporlanmalıdır. Test sonuçları runbook güncellemesine dönüşmelidir.

Disaster Recovery Runbook Nasıl Hazırlanır?

Runbook, kriz anında ekiplerin yorum yapmak yerine belirlenmiş adımları uygulamasını sağlar. Belge kısa, açık ve operasyon sırasında kullanılabilir olmalıdır. Her adımın sahibi, beklenen sonucu ve hata durumunda yapılacak işlem yazılmalıdır. Otomasyon bulunan yerlerde komut veya workflow referansı eklenebilir. Runbook düzenli drill ile yaşayan belge hâline gelmelidir.

Aktivasyon Kriterleri

Hangi olayın DR planını başlatacağı açık biçimde tanımlanmalıdır. Kısa servis kesintisi ile bölgesel felaket aynı şekilde yönetilmemelidir. Süre, etki ve onarım tahmini karar kriterleri olabilir. Güvenlik olayları için ayrı tetikleyiciler tanımlanabilir. Karar kaydı olay zaman çizelgesine eklenmelidir.

Incident Commander

Incident Commander karar ve iletişim akışını koordine eder. Bu kişi her teknik komutu vermek zorunda değildir. Ekipler arası öncelik ve eskalasyon yönetimini sağlar. Yedek kişi önceden belirlenmelidir. Tatbikatlarda rolün uygulanması gerçek olayda hazırlığı artırır.

Teknik Adımlar

Teknik adımlar açık, sıralı ve doğrulanabilir biçimde yazılmalıdır. “Veritabanını kurtarın” gibi genel ifadeler yerine gerçek işlemler tanımlanmalıdır. Her komutun hangi ortamda çalıştırılacağı belirtilmelidir. Geri alınması zor işlemler için onay adımı eklenebilir. Otomatik adımların çıktıları kaydedilmelidir.

Recovery Sequence

Recovery sequence dependency map ile uyumlu olmalıdır. Identity ve network servisleri veri ve uygulama katmanından önce hazırlanabilir. Her aşamada sağlık kontrolü yapılmalıdır. Başarısız dependency varken sonraki wave'e geçilmemelidir. Sıralama düzenli drill ile doğrulanmalıdır.

Validation

Her adım için beklenen başarı kriteri belirlenmelidir. Sunucunun açık olması tek başına yeterli validation değildir. Port erişimi, veri sorgusu ve kullanıcı akışı gibi gerçek kontroller kullanılabilir. Validation sonuçları otomatik kaydedilebilir. Başarısız kontrol için eskalasyon yolu tanımlanmalıdır.

Escalation

Bir adım belirlenen sürede tamamlanamazsa kime haber verileceği bilinmelidir. Teknik, yönetim ve tedarikçi eskalasyonları ayrı olabilir. İletişim bilgileri güncel tutulmalıdır. Normal iletişim kanalı çalışmıyorsa alternatif yöntem belirtilmelidir. Eskalasyon süresi RTO'yu doğrudan etkileyebilir.

Rollback

Failover sırasında yapılan değişiklik başarısız olursa rollback seçeneği gerekebilir. Hangi noktaya kadar geri dönüşün güvenli olduğu önceden belirlenmelidir. Stateful değişikliklerde rollback daha dikkatli yapılmalıdır. DNS ve traffic ayarlarının eski hâle döndürülmesi planlanabilir. Rollback kararı Incident Commander tarafından koordine edilebilir.

Failback

Runbook failback adımlarını da içermelidir. Primary ortamın doğrulanması ve reverse replication sırası açıkça yazılmalıdır. Veri eşitleme tamamlanmadan trafik taşınmamalıdır. Geri dönüş sonrası recovery ortamının ne zaman kapatılacağı belirtilmelidir. Failback testi planın kabul kriterlerinden biri olmalıdır.

İletişim Adımları

Teknik olay yönetimi kadar doğru iletişim de önemlidir. Çalışanlara, müşterilere ve yönetime hangi aralıklarla bilgi verileceği tanımlanmalıdır. Mesajlarda doğrulanmamış tahminlerden kaçınılmalıdır. Status page ve alternatif kanal kullanımı önceden planlanabilir. İletişim sorumlusu teknik ekipten ayrı olabilir.

DR Planında İnsan ve Organizasyon Faktörü

En iyi teknoloji bile roller belirsizse kriz sırasında yeterli olmayabilir. Kim karar verecek, kim veritabanını yönetecek, kim müşteri iletişimi yapacak ve kim güvenlik onayı verecek önceden bilinmelidir. Görevlerin tek kişiye bağlı olması risk oluşturur. Yedek sorumlular ve iletişim bilgileri güncel tutulmalıdır. Tatbikatlar teknik araçlardan çok ekip koordinasyonunu da test eder.

Incident Commander

Incident Commander genel olay koordinasyonundan sorumludur. Teknik detayların tamamını kendisinin çözmesi beklenmez. Öncelik, karar ve eskalasyon akışını yönetir. Durum toplantılarının sıklığını belirler. Olay sonunda postmortem sürecini başlatabilir.

Infrastructure Team

Infrastructure Team compute, network ve temel platform katmanlarını yönetir. Recovery region kaynaklarının açılması bu ekibin sorumluluğunda olabilir. IaC deployment ve kapasite kontrolü yapar. Diğer ekiplerin ihtiyaç duyduğu bağlantıları hazırlar. Teknik ilerleme durumunu Incident Commander'a bildirir.

Database Team

Database Team veri bütünlüğü ve database promotion kararlarında kritik rol oynar. Replication lag ve restore point kontrolü yapar. Split-brain riskini yönetir. Data reconciliation gerekip gerekmediğini belirler. Uygulama ekibiyle birlikte bağlantı doğrulaması gerçekleştirir.

Security Team

Security Team olayın saldırı kaynaklı olup olmadığını değerlendirir. Recovery ortamının temizliğini doğrular. Credential rotation ve malware scanning süreçlerini yönetebilir. Güvenlik ihlali kapatılmadan production trafiğinin açılmasını engelleyebilir. Audit kayıtlarını korur.

Business Owner

Business Owner sistemin iş açısından kullanılabilir olup olmadığını değerlendirir. RTO ve RPO hedeflerinin belirlenmesine katkı verir. Kullanıcı kabul testini onaylar. Kesinti süresinin iş etkisini yönetime aktarır. Teknik ekiplerin bilmediği kritik iş akışlarını görünür hâle getirir.

Hukuk ve Compliance

Hukuk ve compliance ekipleri olayın bildirim yükümlülüklerini değerlendirir. Kişisel veri veya sözleşme ihlali varsa gerekli süreçleri koordine eder. Veri konumu ve saklama gereksinimleri recovery kararını etkileyebilir. İletişim metinlerinin uygunluğunu kontrol edebilir. Olay kayıtlarının mevzuata uygun tutulmasını sağlar.

Corporate Communications

Corporate Communications müşteri ve kamu iletişimini yönetir. Teknik detayları anlaşılır ve doğrulanmış mesajlara dönüştürür. Güncelleme sıklığını Incident Commander ile koordine eder. Yanlış bilgi veya erken tahmin paylaşılmasını engeller. Normal kanal çalışmıyorsa alternatif yöntemleri kullanır.

Tedarikçi Eskalasyonu

Dış servis sağlayıcılar recovery sürecinin kritik parçası olabilir. Destek sözleşmelerindeki acil durum kanalları önceden bilinmelidir. Ticket yerine doğrudan incident hattı gerekebilir. Hesap ve sözleşme bilgileri erişilebilir tutulmalıdır. Tatbikatlarda en azından eskalasyon prosedürü masa başı olarak doğrulanabilir.

Kriz İletişimi Nasıl Planlanır?

Kriz iletişimi teknik çözümden ayrı düşünülmemelidir. Çalışanlar ne olduğunu bilmiyorsa yanlış işlemler yapabilir veya destek ekiplerine gereksiz yük oluşturabilir. Müşterilere zamanında ve doğru bilgi vermek güven açısından önemlidir. Normal e-posta sisteminin çalışmadığı senaryolar da hesaba katılmalıdır. İletişim planı farklı kitleler için önceden şablonlar içerebilir.

Normal E-posta Çalışmıyorsa Ne Olur?

E-posta sistemi kesintiyle aynı anda etkilenebilir. Bu durumda ekiplerin alternatif kanal üzerinden haberleşmesi gerekir. Telefon, güvenli mesajlaşma veya ayrı bir status kanalı kullanılabilir. İletişim bilgilerinin sadece şirket e-postasında saklanması risk oluşturur. Tatbikatlarda ana e-posta servisi kapalı varsayılabilir.

Alternatif İletişim Kanalı

Alternatif kanal ana kimlik veya network sisteminden bağımsız olmalıdır. Ekip üyeleri erişim yöntemini önceden bilmelidir. Hassas teknik detayların hangi kanalda paylaşılabileceği güvenlik politikasıyla uyumlu olmalıdır. Kanalın düzenli test edilmesi gerekir. Acil durumda yeni araç öğrenmek zaman kaybettirir.

Çalışan Bilgilendirmesi

Çalışanlara hizmet durumu ve beklenen davranış açık biçimde aktarılmalıdır. Hangi sistemlerin kullanılmaması gerektiği belirtilmelidir. Geçici manuel süreçler varsa adımlar paylaşılmalıdır. Güncelleme zamanı verilmesi gereksiz soru trafiğini azaltır. Mesajlar doğrulanmış bilgiye dayanmalıdır.

Müşteri İletişimi

Müşterilere kesintinin etkisi anlaşılır dille anlatılmalıdır. Teknik ayrıntı yerine hizmetin hangi fonksiyonlarının etkilendiği açıklanabilir. Kesin olmayan çözüm süreleri verilmemelidir. Düzenli güncellemeler güven oluşturur. Olay kapandıktan sonra gerekli durumlarda neden ve alınan önlemler paylaşılabilir.

Status Page

Status page ana uygulamadan bağımsız barındırılmalıdır. Aksi hâlde aynı kesintide durum sayfası da erişilemez olabilir. Servis bazlı etki bilgisi paylaşılabilir. Güncellemelerin kim tarafından girileceği belirlenmelidir. Geçmiş olay kayıtları şeffaflık ve analiz açısından yararlı olabilir.

Yönetim Raporlaması

Yönetim ekibi teknik ayrıntıdan çok iş etkisi ve tahmini riskle ilgilenir. Etkilenen süreçler, mevcut RTA ve açık engeller kısa biçimde raporlanmalıdır. Kritik kararlar için maliyet ve risk seçenekleri sunulabilir. Düzenli durum toplantıları belirli aralıklarla yapılabilir. Olay sonrası rapor kalıcı iyileştirmeleri takip etmek için kullanılır.

Disaster Recovery Planı Nasıl Test Edilir?

Test edilmemiş bir DR planının gerçek performansı bilinmez. Testler basit belge incelemesinden tam region evacuation senaryosuna kadar farklı seviyelerde yapılabilir. Her kurum yalnızca en ağır testi yapmak zorunda değildir, fakat test kapsamı zaman içinde genişletilmelidir. Bulut ortamında backup failover replikasyon ve felaket kurtarma testi nasıl yapılır sorusunun yanıtı, düşük riskli kontrollerden gerçek traffic cutover'a kadar kademeli bir yaklaşım kurmaktır. Test sonuçları actual RTO ve actual RPO ile ölçülmelidir.

Checklist Review

Checklist review en düşük riskli test seviyesidir. Runbook adımları ekiplerle birlikte gözden geçirilir. İletişim bilgileri, komutlar ve sahiplikler kontrol edilir. Gerçek failover yapılmaz. Buna rağmen eski belgeleri ve eksik bağımlılıkları bulmak için faydalıdır.

Tabletop Exercise

Tabletop exercise kurgusal bir olay üzerinden ekiplerin karar sürecini test eder. Teknik sistemler kapatılmadan senaryo adım adım ilerletilir. Kim karar verecek, kim iletişim kuracak ve hangi verinin kullanılacağı tartışılır. Organizasyonel boşluklar kolayca görünür hâle gelir. Gerçek failover öncesinde iyi bir hazırlık aşamasıdır.

Backup Restore Test

Backup restore testi yedeklerin gerçekten kullanılabilir olduğunu doğrular. Seçilen sistem bağımsız ortamda geri yüklenebilir. Restore süresi ölçülür. Veri bütünlüğü ve uygulama açılışı kontrol edilir. Sonuçlar RTO ve RPO hedefleriyle karşılaştırılır.

Partial Failover

Partial failover yalnızca seçilen servis veya kullanıcı grubunu recovery ortamına taşır. Tam kesinti riski daha düşüktür. Network ve identity bağımlılıkları gerçek koşullarda test edilebilir. Trafiğin küçük oranı ikinci ortama yönlendirilebilir. Başarılı sonuçlar full failover için güven oluşturur.

Full Failover

Full failover bütün kritik hizmetin recovery ortamına taşınmasını test eder. Gerçek RTO ölçümü için en güçlü yöntemlerden biridir. Production kullanıcıları kontrollü bakım penceresinde recovery ortamını kullanabilir. Bütün dependency'ler ve kullanıcı akışları doğrulanır. Sonrasında failback de test edilmelidir.

Region Evacuation Test

Region evacuation test birincil bölgenin tamamen kullanılamadığı varsayımıyla yapılır. Ekiplerin primary bölgeye hiçbir işlem için güvenmemesi sağlanır. Recovery region tek başına hizmet vermelidir. DNS, identity, data ve monitoring birlikte sınanır. Multi-region yatırımının gerçek değeri bu testte görülür.

Ransomware Recovery Test

Ransomware testi temiz recovery point seçimi ve izole restore adımlarını kapsar. Replica'nın da etkilenmiş olduğu varsayılabilir. Immutable backup kullanımı doğrulanır. Credential rotation ve malware scanning sürece eklenir. Güvenlik ekibi tatbikatın aktif katılımcısı olmalıdır.

Failback Test

Failback testi primary ortama güvenli geri dönüşü doğrular. Reverse replication ve data reconciliation süreçleri ölçülür. Traffic return sırasında veri kaybı olmadığı kontrol edilir. Kullanıcı kabul testi tekrar yapılır. Tam DR döngüsü ancak failback test edildiğinde tamamlanmış olur.

DR Drill Sırasında Neler Ölçülmeli?

Test yalnızca “başarılı” veya “başarısız” olarak kaydedilmemelidir. Süre, veri kaybı, hata oranı ve manuel işlem sayısı gibi ölçümler sonraki iyileştirmeleri yönlendirir. Actual RTO ve RPO temel performans göstergeleridir. Dependency hataları ve failback süresi ayrıca izlenmelidir. Zaman içindeki trend hazırlık seviyesinin gelişip gelişmediğini gösterir.

Actual RTO

Actual RTO gerçek recovery süresidir. Deklarasyon anından kullanıcıya hizmet verildiği ana kadar ölçülmelidir. Hedef RTO ile arasındaki fark raporlanır. En uzun alt adımlar ayrıca işaretlenir. Sürekli drill verisi kapasite ve otomasyon yatırımını yönlendirebilir.

Actual RPO

Actual RPO gerçekten kaybedilen veri aralığını gösterir. Replikasyon veya backup teorik olarak belirli RPO vaat edebilir. Testte recovery point'in zamanı doğrulanmalıdır. Hedef aşılmışsa neden araştırılmalıdır. Lag ve backup scheduling bu analizde önemli veriler sağlar.

Replication Lag

Replication lag kaynak ile hedef arasındaki güncellik farkıdır. Drill öncesi ve failover anındaki değer kaydedilmelidir. Yüksek lag actual RPO'yu büyütebilir. Network veya hedef kapasite sorunları neden olabilir. Alarm eşikleri hedef RPO'ya göre ayarlanmalıdır.

Recovery Error Rate

Recovery error rate otomatik veya manuel adımların kaçının hata verdiğini gösterir. Çok sayıda küçük hata RTO'yu ciddi biçimde uzatabilir. Hatalar kategori bazında sınıflandırılabilir. Tekrarlayan sorunlar otomasyon veya dokümantasyonla azaltılmalıdır. Oranın zaman içinde düşmesi olgunlaşma göstergesidir.

Manual Step Sayısı

Manuel adım sayısı insan bağımlılığını ölçmek için yararlı bir metriktir. Her manuel işlem hata ve gecikme riski taşır. Tekrarlanan adımlar otomasyona aday olabilir. Bununla birlikte kritik karar noktalarında insan onayı bilinçli olarak korunabilir. Amaç bütün insanları kaldırmak değil, gereksiz manuel işi azaltmaktır.

Kullanıcıya Hizmet Verme Süresi

Teknik sistemlerin ayağa kalkması ile kullanıcının hizmet alması arasında fark olabilir. Bu nedenle gerçek hizmet verme zamanı ayrıca ölçülmelidir. Login, temel işlem ve veri yazma gibi fonksiyonlar test edilmelidir. Business Owner onayı ölçümün son noktası olabilir. Bu değer yönetim için teknik RTA'dan daha anlamlı olabilir.

Başarısız Dependency'ler

Her drill hangi bağımlılıkların sorun çıkardığını görünür hâle getirir. DNS, secret, firewall veya dış API gibi alanlar sık hata kaynağı olabilir. Dependency listesi test sonrası güncellenmelidir. Tekrarlayan sorunlar risk backlog'una eklenmelidir. Böylece bir sonraki drill daha gerçekçi ve hızlı olur.

Failback Süresi

Failback süresi recovery ortamından primary ortama dönüş için geçen toplam zamandır. Bu değer çoğu programda yeterince takip edilmez. Reverse replication ve veri doğrulama genellikle sürenin büyük bölümünü oluşturur. İş kesintisi gerekip gerekmediği ayrıca kaydedilmelidir. Failback performansı DR programının tam olgunluğunu gösterir.

Chaos Engineering ile Disaster Recovery Testi

Chaos Engineering kontrollü hata enjeksiyonu ile sistemin gerçek dayanıklılığını ölçmeye yardımcı olur. Amaç rastgele sistemi bozmak değildir. Belirli hipotez oluşturulur, güvenlik sınırları tanımlanır ve beklenen davranış gözlemlenir. Küçük sunucu arızasından daha geniş network veya region senaryolarına kademeli geçiş yapılabilir. DR testleriyle birlikte kullanıldığında gizli bağımlılıkları görünür kılar.

Server Failure

Tek sunucu kapatılarak yüksek erişilebilirlik davranışı gözlemlenebilir. Trafik diğer instance'lara geçiyor mu kontrol edilir. Autoscaling tepki süresi ölçülebilir. Kullanıcı hatası oluşup oluşmadığı izlenir. Bu test daha geniş senaryolara geçmeden önce temel dayanıklılığı doğrular.

Network Partition

Network partition servislerin birbirini göremediği fakat tamamen kapalı olmadığı durumdur. Özellikle dağıtık veritabanlarında split-brain riskini ortaya çıkarabilir. Timeout ve retry davranışları test edilir. Monitoring sisteminin olayı doğru algılayıp algılamadığı kontrol edilir. Ağ geri geldiğinde sistemin otomatik toparlanması ayrıca gözlemlenir.

Availability Zone Failure

Bir zone unavailable kabul edilerek uygulamanın diğer zone'lardaki kapasitesi test edilir. Load balancer ve database failover davranışı gözlemlenir. Tek zone'da kalan bağımlılıklar ortaya çıkabilir. Kapasite planının N-1 koşulunu karşılayıp karşılamadığı ölçülür. Kullanıcı etkisi kayıt altına alınır.

Database Failure

Primary database erişimi kesilerek replica promotion süreci test edilebilir. Uygulama connection retry davranışı önemlidir. Promotion sırasında veri kaybı ölçülür. Eski primary'nin izolasyonu doğrulanır. Sonrasında failback ve veri eşitleme süreci uygulanabilir.

Identity Failure

Identity service unavailable senaryosu çoğu sistemin gizli bağımlılığını gösterir. Mevcut session'ların ne kadar süre çalıştığı izlenebilir. Yeni login işlemlerinin davranışı kontrol edilir. Break-glass yönetim erişimi test edilir. Uygulamanın graceful degradation yeteneği varsa doğrulanır.

Region Failure Simulation

Region failure simulation birincil bölgeye erişimin kesildiği varsayımıyla yapılır. İkinci ortamın bağımsızlığı sınanır. Veri, identity, DNS ve monitoring birlikte çalışmalıdır. Primary'den hiçbir gizli bağımlılık kalmaması beklenir. Bu test gerçek multi-region hazırlığının en güçlü göstergelerindendir.

GameDay Yaklaşımı

GameDay planlı süre içinde gerçekçi arıza senaryolarının ekiplerle uygulanmasıdır. Katılımcılar önceden genel hedefi bilir fakat bazı olay detayları sürpriz bırakılabilir. Gözlemciler karar ve teknik süreleri kaydeder. Amaç ekipleri cezalandırmak değil, sistem ve süreç açıklarını bulmaktır. Çıktılar somut iyileştirme aksiyonlarına dönüştürülmelidir.

Disaster Recovery Güvenliği

Recovery ortamı daha az kullanıldığı için güvenlik açısından ihmal edilmemelidir. Saldırganlar DR hesaplarını ve yedekleri hedef alabilir. Least privilege, MFA, encryption ve audit logging production ile benzer seviyede uygulanmalıdır. Acil erişim yöntemleri ayrı kontrollere sahip olmalıdır. Güvenli olmayan recovery ortamı felaket anında ikinci bir olay yaratabilir.

Recovery Plane İzolasyonu

Recovery yönetim düzlemini production'dan belirli ölçüde ayırmak saldırı yayılımını azaltabilir. Ayrı hesap veya yönetim sınırı kullanılabilir. Backup silme yetkilerinin production yöneticilerinde bulunmaması tercih edilebilir. İzolasyon operasyonu tamamen imkânsız hâle getirmemelidir. Acil erişim yolu önceden test edilmelidir.

Least Privilege

Kullanıcı ve servis hesaplarına yalnızca gerekli yetkiler verilmelidir. DR ortamında “acil durumda lazım olur” düşüncesiyle geniş haklar bırakmak risklidir. Geçici elevation mekanizmaları kullanılabilir. Yetki incelemeleri periyodik yapılmalıdır. Drill sırasında hangi rollerin gerçekten gerekli olduğu görülebilir.

MFA

Yönetim hesaplarında MFA recovery sırasında da korunmalıdır. Ancak ana MFA sistemi unavailable olduğunda kontrollü alternatif gerekir. Break-glass hesapları bu amaçla tasarlanabilir. Kullanımları alarm üretmelidir. Tatbikatlar normal MFA servisinin çalışmadığı durumu da kapsayabilir.

Break-Glass Access

Break-glass access normal kontrol yolları çalışmadığında kullanılacak acil mekanizmadır. Kimlik bilgileri güvenli ve bağımsız saklanmalıdır. Erişim yalnızca belirli olay kriterlerinde kullanılmalıdır. Kullanım sonrasında credential rotasyonu yapılabilir. Audit kayıtları olay incelemesine dahil edilmelidir.

Encryption at Rest

Backup ve recovery storage üzerindeki veriler at-rest şifreleme ile korunmalıdır. Anahtar yönetimi veri şifrelemesi kadar önemlidir. Recovery region'ın anahtara erişebildiği doğrulanmalıdır. Anahtar kaybı bütün yedekleri kullanılamaz hâle getirebilir. Bu nedenle key recovery ayrı test edilmelidir.

Encryption in Transit

Replication ve restore trafiği ağ üzerinde şifrelenmelidir. Özellikle region'lar arası veri transferinde güvenli bağlantı kullanılmalıdır. Sertifika yaşam döngüsü izlenmelidir. Eski protokol ve cipher kullanımından kaçınılmalıdır. Performans etkisi gerçek yükle ölçülebilir.

Audit Logging

Recovery işlemleri denetlenebilir log bırakmalıdır. Kim hangi kaynağı açtı, hangi yedeği restore etti ve hangi yetkiyi kullandı kayıt altına alınmalıdır. Log sistemi primary ortamdan bağımsız olmalıdır. Güvenlik olayında logların değiştirilmesi engellenmelidir. Olay sonrası analiz bu kayıtlar üzerinden yapılır.

Separation of Duties

Tek kişinin hem backup'ı silme hem güvenlik politikasını değiştirme yetkisine sahip olması risk oluşturabilir. Görev ayrılığı kritik işlemlerde ikinci kontrol sağlar. Özellikle immutable retention değişiklikleri daha sıkı yetkilendirilebilir. Acil durumda süreç tamamen kilitlenmeyecek biçimde tasarlanmalıdır. Yetki modeli düzenli audit ile doğrulanmalıdır.

KVKK ve Bulut Disaster Recovery

Kişisel veri içeren recovery kopyaları da veri koruma yükümlülüklerinden ayrı değildir. Yedeklerin nerede tutulduğu, kimlerin eriştiği ve ne kadar süre saklandığı açık biçimde yönetilmelidir. DR testi yapılırken gerçek kişisel verinin gereksiz yere çoğaltılmaması önemlidir. Yurt dışı veri aktarımı gibi konular güncel mevzuata göre ayrıca değerlendirilmelidir. Hukuki kararlar alınırken resmi kaynak ve yetkili uzman görüşü esas alınmalıdır.

DR Ortamında Kişisel Veri

Recovery ortamındaki kişisel veriler production verisiyle aynı koruma seviyesini gerektirir. Ortam pasif olsa bile erişim ve şifreleme kontrolleri uygulanmalıdır. Test amacıyla açılan kaynakların sonradan kapatılması gerekir. Yetkisiz personelin test sırasında veriye erişmesi engellenmelidir. Veri envanteri recovery kopyalarını da kapsamalıdır.

Yedek Verilerin Güvenliği

Yedekler kişisel verinin uzun süre saklandığı kritik alanlardır. Şifreleme ve erişim sınırları güçlü olmalıdır. Backup admin yetkileri ayrı değerlendirilebilir. Loglama ve restore yetkisi düzenli gözden geçirilmelidir. Saklama süresi gereksiz veri tutmayı önleyecek biçimde tanımlanmalıdır.

Ağ Dışı / İzole Backup

İzole backup üretim hesabındaki saldırı veya yanlışlığın yedekleri etkilemesini azaltabilir. Ayrı kimlik ve yönetim sınırı kullanılabilir. Fiziksel offline kopya her kurum için gerekli olmayabilir. Risk seviyesi ve kurtarma hedefi üzerinden karar verilmelidir. İzole kopyanın yine erişilebilir ve test edilmiş olması gerekir.

DR Test Verilerinin Anonimleştirilmesi

Test ortamında gerçek kişisel veri kullanımı her zaman gerekli değildir. Mümkün olduğunda anonimleştirilmiş veya maskelemiş veri kullanılabilir. Full recovery testinde gerçek veri gerekiyorsa erişim sınırları sıkı tutulmalıdır. Test bittikten sonra geçici kopyalar güvenli biçimde silinmelidir. Veri kullanım amacı ve süresi kayıt altına alınmalıdır.

Saklama ve İmha

Backup retention teknik alışkanlığa göre değil, iş ve yasal gereksinime göre belirlenmelidir. Süresi dolan verinin güvenli imhası planlanmalıdır. Immutable retention nedeniyle silinemeyen süreler baştan dikkatle seçilmelidir. Farklı veri sınıfları için farklı politikalar gerekebilir. Saklama politikası düzenli olarak gözden geçirilmelidir.

Yurt Dışı Replikasyon ve Veri Aktarımı

Farklı region'a veri replikasyonu yurt dışı veri aktarımı sonucunu doğurabilir. Bu konu teknik karardan önce hukuk ve compliance ekipleriyle değerlendirilmelidir. Veri sınıfı ve işleme amacı göz önünde bulundurulmalıdır. Bölge seçimi yalnızca latency ve maliyet üzerinden yapılmamalıdır. Güncel yasal koşullar resmi kaynaklardan doğrulanmalıdır.

Access Log ve Audit Trail

Kişisel veriye recovery ortamından erişim de loglanmalıdır. Kim, ne zaman ve hangi işlem için erişti bilgisi saklanabilir. Logların bütünlüğü ayrıca korunmalıdır. Olay ve test kayıtları farklı saklama politikasına sahip olabilir. Audit trail uyum kontrollerinde önemli kanıt sağlar.

Güncel Mevzuatın Resmi Kaynaktan Doğrulanması

Mevzuat ve uygulama rehberleri zaman içinde değişebilir. Bu nedenle teknik ekip yalnızca eski proje dokümanlarına dayanarak karar vermemelidir. Güncel resmi metinler kontrol edilmelidir. Gerekli durumlarda hukuk uzmanından görüş alınmalıdır. DR mimarisi hukuki gereksinim değiştikçe güncellenebilmelidir.

İş Sürekliliği Standartları ve Governance

DR programının kalıcı olması için teknik projeden yönetim sürecine dönüşmesi gerekir. Politika, sorumluluk, test sıklığı ve risk kabul mekanizması yazılı olmalıdır. Yönetim düzenli olarak sonuçları gözden geçirmelidir. Standartlar ortak dil ve denetim çerçevesi sağlar. Ancak standart belgesine sahip olmak tek başına gerçek kurtarma yeteneğini kanıtlamaz.

ISO 22301

ISO 22301 iş sürekliliği yönetim sistemleri için kullanılan önemli standartlardan biridir. İş etkisi analizi, risk değerlendirmesi ve süreklilik planlamasına sistematik yaklaşım sunar. Disaster Recovery bu geniş çerçevenin teknik bölümünü destekleyebilir. Kurumların görev, test ve iyileştirme süreçlerini düzenlemesine yardımcı olur. Uygulamada gerçek iş ihtiyaçlarıyla birlikte değerlendirilmelidir.

ISO 27001 ile DR İlişkisi

ISO 27001 bilgi güvenliği yönetimini ele alır ve erişilebilirlik de bilgi güvenliğinin temel boyutlarından biridir. Backup, erişim kontrolü, olay yönetimi ve süreklilik kontrolleri DR ile ilişkilidir. Güvenlik ve recovery planlarının ayrı ekiplerde tamamen kopuk yürütülmesi risk oluşturabilir. Özellikle ransomware senaryolarında iki alan doğrudan kesişir. Ortak risk kayıtları yönetimi kolaylaştırır.

Sektörel Düzenlemeler

Finans, sağlık veya kritik altyapı gibi sektörlerde ek süreklilik gereksinimleri olabilir. RTO, veri konumu ve test sıklığı sektörel kurallardan etkilenebilir. Teknik ekip ilgili mevzuatı hukuk ve compliance ile birlikte değerlendirmelidir. Sözleşmesel yükümlülükler de benzer şekilde önemlidir. Politika güncel düzenlemelere göre yenilenmelidir.

DR Policy

DR Policy kurumun recovery yaklaşımını üst düzeyde tanımlar. Hangi sistemlerin kapsama girdiği ve sorumlulukların kimde olduğu belirtilir. RTO ve RPO onay süreci açıklanır. Test sıklığı ve raporlama beklentileri yazılır. Politika yönetim tarafından sahiplenildiğinde programın sürekliliği artar.

Risk Acceptance

Bütün riskleri sıfırlamak ekonomik değildir. Bazı sistemlerde daha uzun RTO bilinçli olarak kabul edilebilir. Bu karar teknik ekip tarafından tek başına verilmemelidir. İş sahibi ve yönetim riskin etkisini bilerek onaylamalıdır. Kabul edilen riskler belirli aralıklarla yeniden değerlendirilmelidir.

Periyodik Yönetim Gözden Geçirmesi

Yönetim toplantılarında DR hazırlığı ölçülebilir göstergelerle sunulmalıdır. Son drill tarihi, actual RTO, açık risk ve kritik drift bilgileri paylaşılabilir. Bütçe ihtiyacı somut risklerle ilişkilendirilmelidir. Eski kabul kararları yeniden gözden geçirilmelidir. Böylece DR yılda bir hatırlanan belge olmaktan çıkar.

DRaaS Sağlayıcısı Nasıl Seçilir?

DRaaS seçimi yalnızca fiyat teklifi karşılaştırması değildir. Sağlayıcının RTO ve RPO hedeflerini nasıl kanıtladığı, ne sıklıkla drill yaptığı ve failback'i kapsayıp kapsamadığı sorgulanmalıdır. Ransomware clean recovery ve configuration drift yönetimi de kritik kriterlerdir. Veri konumu, SLA ve exit strategy sözleşmenin önemli parçalarıdır. Kurumsal bulut disaster recovery ve iş sürekliliği hizmeti alırken teknik kanıt istenmesi doğru yaklaşımdır.

RTO/RPO Nasıl Kanıtlanıyor?

Sözleşmeye yazılan hedeflerin gerçek test sonuçlarıyla desteklenmesi gerekir. Sağlayıcı geçmiş drill raporlarını veya ölçüm yöntemini açıklayabilmelidir. RTO'nun hangi başlangıç ve bitiş noktaları arasında ölçüldüğü sorulmalıdır. RPO'nun gerçek replication lag ile nasıl doğrulandığı incelenmelidir. Teorik ürün değeri ile operasyonel sonuç birbirinden ayrılmalıdır.

Ne Sıklıkla DR Drill Yapılıyor?

Test sıklığı sistem kritikliğiyle uyumlu olmalıdır. Yılda bir masa başı test kritik sistem için yeterli olmayabilir. Partial ve full failover seçenekleri değerlendirilmelidir. Testlerin müşteri katılımıyla yapılıp yapılamadığı sorulmalıdır. Her drill sonrası iyileştirme raporu beklenmelidir.

Failback Dahil mi?

Bazı hizmetler failover'ı kapsarken failback sürecini ayrıca ücretlendirebilir veya kurum sorumluluğunda bırakabilir. Bu ayrım sözleşmede açık olmalıdır. Reverse replication ve data reconciliation desteği sorgulanmalıdır. Failback testinin yapılıp yapılmadığı sorulmalıdır. Gerçek olayın sona ermesi için primary ortama güvenli dönüş gerekir.

Configuration Drift Nasıl Yönetiliyor?

Production ortamı değiştikçe DR yapılandırmasının güncel kalması gerekir. Sağlayıcının otomatik discovery ve drift detection yetenekleri incelenmelidir. Yeni sistemlerin scope'a eklenme süreci açıklanmalıdır. Manuel değişikliklerin nasıl izlendiği sorulmalıdır. Drift raporlarının müşteri tarafından görüntülenebilmesi faydalıdır.

Ransomware Clean Recovery Var mı?

Ransomware senaryosunda yalnızca replica failover yeterli değildir. Immutable backup ve clean recovery point desteği sorgulanmalıdır. İzole clean-room restore imkânı önemli olabilir. Malware scanning ve privileged access reset süreçleri değerlendirilmelidir. Tatbikatın güvenlik ekibiyle birlikte yapılabilmesi tercih edilir.

Veri Nerede Tutuluyor?

Backup ve replica verilerinin hangi bölgelerde tutulduğu bilinmelidir. Veri konumu mevzuat ve sözleşme gereksinimlerini etkileyebilir. Şifreleme ve anahtar yönetimi detayları açıklanmalıdır. Alt hizmet sağlayıcı kullanımı varsa bu bilgi de incelenmelidir. Veri silme ve sözleşme sonu prosedürü net olmalıdır.

SLA

SLA hizmetin hangi performans ve erişilebilirlik hedeflerini taahhüt ettiğini açıklar. DR hizmetinde response time ile recovery time birbirine karıştırılmamalıdır. Destek ekibinin ne kadar sürede yanıt vereceği farklı, sistemin ne kadar sürede ayağa kalkacağı farklı metriktir. İhlal durumundaki yaptırımlar değerlendirilmelidir. Ölçüm yöntemi sözleşmede net olmalıdır.

Support ve Incident Response

Gerçek felaket normal ticket akışından farklı destek gerektirir. 7/24 kritik incident kanalı olup olmadığı sorgulanmalıdır. Hangi seviyede teknik uzman sağlandığı bilinmelidir. Tedarikçi eskalasyon zinciri önceden test edilmelidir. Dil ve iletişim beklentileri de operasyonel açıdan önemlidir.

Exit Strategy

Hizmetten ayrılmak gerektiğinde verilerin ve recovery artifact'ların nasıl alınacağı baştan bilinmelidir. Proprietary format bağımlılığı çıkışı zorlaştırabilir. Export süresi ve egress maliyeti hesaba katılmalıdır. Sözleşme bittikten sonra verilerin ne zaman silineceği açıklanmalıdır. Exit plan sağlayıcı seçiminden önce hazırlanmalıdır.

DRaaS Provider Lock-In Riski

DRaaS rahat operasyon sunarken sağlayıcı bağımlılığı yaratabilir. Replikasyon formatı, orchestration ve yedek metadata'sı farklı platformlara kolay taşınamayabilir. Bu nedenle portability baştan değerlendirilmelidir. Sözleşme sonu veri export ve migration koşulları incelenmelidir. Lock-in tamamen kötü değildir, fakat bilinçli kabul edilmesi gereken bir risktir.

Proprietary Replication Formatları

Bazı replikasyon sistemleri veriyi yalnızca kendi platformunda kullanabilecek formatta tutabilir. Bu durum sağlayıcı değişikliğini zorlaştırır. Standart export seçeneği olup olmadığı sorulmalıdır. Büyük veri setlerinin dışa aktarım süresi test edilebilir. Alternatif bağımsız backup katmanı riski azaltabilir.

Yedeklerin Başka Platforma Taşınması

Yedeklerin başka ortamda restore edilebilir olması gerçek taşınabilirlik göstergesidir. Sadece dosyanın export edilmesi yeterli olmayabilir. Metadata, encryption key ve uygulama tutarlılığı da korunmalıdır. Düzenli portability testi yapılabilir. Exit strategy bu sürecin maliyetini içermelidir.

Provider Değiştirme

Provider değiştirme planı sözleşme imzalanmadan önce düşünülmelidir. Yeni platforma veri aktarımı ve paralel çalışma süresi gerekebilir. RPO hedefinin migration sırasında nasıl korunacağı belirlenmelidir. Eski sağlayıcıdaki verinin güvenli silinmesi doğrulanmalıdır. Geçiş projesi ayrı risk planı gerektirir.

Contract Exit Plan

Contract exit plan veri teslimi, erişim sonlandırma ve silme adımlarını tanımlar. Notice period ve ek ücretler gözden geçirilmelidir. Backup export formatı sözleşmeye yazılabilir. Geçiş sırasında teknik destek düzeyi önemlidir. Planın hukuk ve teknik ekipler tarafından birlikte incelenmesi faydalıdır.

Recovery Artifact Portability

Recovery artifact yalnızca veri değildir. IaC şablonları, runbook, network tanımları ve automation script'leri de taşınabilir olmalıdır. Proprietary orchestration kullanılıyorsa alternatif prosedür hazırlanabilir. Kod depolarının kurum kontrolünde tutulması avantaj sağlar. Portability testi belirli aralıklarla yapılabilir.

Cloud Disaster Recovery Maliyeti Nasıl Hesaplanır?

DR maliyeti yalnızca yedek depolama ücretinden oluşmaz. Replication trafiği, warm compute, database replica, lisans, test ve insan emeği toplam maliyeti oluşturur. Ayrıca gerçek failover sırasında ortaya çıkabilecek egress ve ölçeklenme giderleri de hesaba katılmalıdır. TCO hesabı yıllık bazda yapılabilir. Bu maliyet beklenen kesinti zararıyla birlikte değerlendirilmelidir.

Storage

Backup, snapshot ve replica verileri depolama maliyeti yaratır. Retention süresi arttıkça kapasite büyür. Incremental yöntemler maliyeti azaltabilir. Immutable kopyalar ayrı sınıfta tutulabilir. Restore performansı için seçilen storage tier de önemlidir.

Replication Trafiği

Region'lar arası replikasyon veri transfer ücreti oluşturabilir. Yoğun yazma yapan sistemlerde bu gider yüksek olabilir. Sıkıştırma ve değişiklik bazlı transfer maliyeti azaltabilir. Trafik miktarı gerçek metriklerden hesaplanmalıdır. RPO hedefi ile transfer maliyeti arasında denge kurulmalıdır.

Egress

Felaket veya migration sırasında veriyi platform dışına taşımak egress maliyeti doğurabilir. Normal aylarda görünmeyen bu gider kriz sırasında büyüyebilir. Full drill'ler de benzer ücret yaratabilir. TCO modelinde test ve gerçek olay senaryoları ayrı hesaplanmalıdır. Çok büyük veri setlerinde alternatif transfer yöntemi değerlendirilebilir.

Warm Compute

Warm standby ortamında küçültülmüş compute kaynakları sürekli çalışır. Bu nedenle backup restore yaklaşımına göre düzenli aylık maliyet daha yüksektir. Reserved kapasite veya uygun fiyat modeli değerlendirilebilir. Ancak recovery sırasında hızlı scale-up için quota hazır tutulmalıdır. Maliyet karşılığında daha düşük RTO elde edilir.

Database Replicas

Sürekli çalışan database replica maliyetin önemli bölümünü oluşturabilir. Yüksek performanslı sistemlerde storage ve IOPS giderleri de eklenir. Replica boyutu production ile aynı olmak zorunda olmayabilir. Fakat failover sırasında yeterli kapasiteye çıkabilmelidir. Ölçeklendirme süresi RTO hesabına dahil edilmelidir.

Lisans

İşletim sistemi, database ve ticari yazılımlar ikinci ortam için ek lisans isteyebilir. Pasif standby için özel lisans koşulları bulunabilir. Sözleşmeler önceden incelenmelidir. Felaket anında ani lisans eksikliği hizmeti durdurabilir. Lisans maliyeti DR TCO'suna eklenmelidir.

DRaaS Yönetim Ücreti

DRaaS hizmetleri platform kullanımına ek yönetim ücreti içerebilir. Bu ücret monitoring, test ve incident desteğini kapsayabilir. Hangi hizmetlerin dahil olduğu tekliflerde netleştirilmelidir. Full drill veya failover için ayrı ücret olup olmadığı sorulmalıdır. İç operasyon maliyetiyle karşılaştırma yapılmalıdır.

Drill Maliyeti

DR testi compute, veri transferi ve insan zamanı gerektirir. Ancak test maliyetinden kaçınmak daha büyük operasyon riskine yol açar. Yıllık bütçede drill için ayrı pay ayrılmalıdır. Otomasyon tekrar eden test maliyetini düşürebilir. Test harcaması recovery yatırımının ayrılmaz parçasıdır.

Operasyonel İnsan Maliyeti

Mühendislerin planlama, test, monitoring ve olay yönetimi için harcadığı zaman da maliyettir. Çok karmaşık mimari sürekli uzmanlık ister. Otomasyon bakımının da insan emeği gerektirdiği unutulmamalıdır. Managed hizmet bu maliyetin bir bölümünü dışarı aktarabilir. TCO karşılaştırması yalnızca altyapı faturasına göre yapılmamalıdır.

Backup & Restore, Pilot Light, Warm Standby ve Active/Active Maliyet Karşılaştırması

Stratejiler arasında temel denge maliyet ve kurtarma hızıdır. Backup restore en düşük sürekli maliyeti sağlayabilir fakat RTO uzundur. Pilot light orta seviyede hazırlık sunar. Warm standby daha fazla sürekli kaynak karşılığında daha hızlı geçiş sağlar. Active/active ise en düşük RTO hedefleri için güçlüdür fakat operasyon ve altyapı gideri en yüksek yaklaşımlardan biridir.

En Düşük Maliyetli Yaklaşım

Genellikle backup and restore en düşük sürekli compute maliyetine sahiptir. Yedek depolama ve test maliyeti yine devam eder. Büyük restore süreleri kritik sistemler için uygun olmayabilir. IaC kullanımı maliyet artışı olmadan RTO'yu bir miktar iyileştirebilir. Karar iş yükünün toleransına göre verilmelidir.

En Düşük RTO

Active/active veya tam hot standby modelleri çok düşük RTO sağlayabilir. Kaynaklar sürekli çalıştığı için geçiş süresi azalır. Ancak veri tutarlılığı ve operasyon yönetimi daha zordur. Aynı kapasitenin iki yerde tutulması maliyeti artırır. Bu seviye yalnızca kesinti maliyeti çok yüksek sistemlerde anlamlı olabilir.

Maliyet–RTO Trade-Off

RTO düştükçe ikinci ortamın hazır olma seviyesi artar. Bu da compute, database ve operasyon maliyetini yükseltir. Her iş yükünde birkaç dakikalık RTO hedeflemek ekonomik değildir. BIA bu dengeyi ölçülebilir hâle getirir. Teknik ekip seçenekleri maliyet ve süre tablosuyla iş sahibine sunmalıdır.

Kesinti Maliyetine Göre Yatırım Kararı

Bir saatlik kesintinin maliyeti ile hızlı recovery altyapısının yıllık maliyeti karşılaştırılabilir. Bu değerlendirme yalnızca doğrudan gelir kaybını değil müşteri ve mevzuat riskini de içermelidir. Bazı sistemlerde yüksek DR yatırımı kendini açık biçimde haklı çıkarır. Bazılarında daha uzun RTO kabul etmek daha doğru olabilir. Karar risk kabul süreciyle belgelenmelidir.

Disaster Recovery Monitoring Dashboard'ında Neler Olmalı?

DR hazırlığı yalnızca drill günü kontrol edilmemelidir. Dashboard backup, replication, recovery environment ve açık risklerin sürekli görünürlüğünü sağlar. Kritik metrikler RTO ve RPO hedefleriyle ilişkilendirilmelidir. Alarm üreten değerlerin sahipleri belli olmalıdır. Yönetim görünümü teknik detaylardan daha sade olabilir.

Replication Health

Replication health veri akışının çalışıp çalışmadığını gösterir. Bağlantı kesilmiş veya replica error durumunda olabilir. Başarı durumu tek başına yeterli değildir. Lag ile birlikte izlenmelidir. Uzun süreli hata hedef RPO'yu doğrudan bozar.

Replication Lag

Lag kaynağın hedefe göre ne kadar geride olduğunu gösterir. RPO hedefinden büyük değer alarm üretmelidir. Ortalama ve maksimum değer ayrı izlenebilir. Yoğun yük dönemlerindeki artış kapasite ihtiyacını gösterebilir. Trend analizi kalıcı sorunları ortaya çıkarır.

Son Başarılı Backup

Son başarılı backup zamanı kolay anlaşılır temel göstergedir. Hedeflenen backup periyodundan daha eski ise risk oluşur. Ancak başarı etiketi restore edilebilirliği garanti etmez. Integrity sonucu ile birlikte gösterilmelidir. Kritik sistemlerde alarm gecikmeden üretilmelidir.

Backup Integrity

Backup integrity kopyanın okunabilir ve beklenen yapıda olduğunu doğrular. Checksum ve otomatik restore testleri kullanılabilir. Hatalı yedek hızlı biçimde yenilenmelidir. Son doğrulama tarihi dashboard'da görünmelidir. Sıfır doğrulama hatası hedefi burada takip edilebilir.

DR Environment Health

Warm veya hot ortamların servis sağlık durumu sürekli izlenmelidir. Kapalı pilot light kaynaklarında IaC validation çalıştırılabilir. Sertifika, network ve identity erişimleri ayrıca kontrol edilebilir. Kullanılmayan ortamların aylarca fark edilmeyen hatalar barındırması mümkündür. Basit synthetic testler riski azaltır.

RTO/RPO Compliance

Son testlerin actual değerleri hedeflerle karşılaştırılmalıdır. Hedef dışına çıkan sistemler açık risk olarak işaretlenebilir. Geçmiş trend yönetim kararları için faydalıdır. Tek seferlik iyi sonuç yerine süreklilik önemlidir. Compliance oranı tier bazında raporlanabilir.

Son Drill Tarihi

Uzun süredir test edilmeyen sistemin hazırlığı belirsizdir. Son drill tarihi görünür olmalıdır. Planlanan bir sonraki test de dashboard'a eklenebilir. Tier 0 sistemler daha sık test edilebilir. Geciken drill otomatik risk kaydı oluşturabilir.

Open DR Risks

DR sırasında bilinen eksikler ayrı risk listesinde tutulmalıdır. Örneğin failback testi yapılmamış veya ikinci region quota'sı düşük olabilir. Risk sahibi ve hedef kapanış tarihi belirlenmelidir. Yönetim kabul ettiği riskleri ayrıca işaretleyebilir. Dashboard teknik sorunları karar sürecine taşır.

Configuration Drift

Production ile DR arasındaki farklar dashboard'da görünür olmalıdır. Kritik firewall veya application değişiklikleri hızlı alarm üretmelidir. Drift kaynağı manuel değişiklik veya eksik deployment olabilir. Her fark aynı önem seviyesinde değildir. Risk bazlı sınıflandırma yapılmalıdır.

Cloud Disaster Recovery Otomasyonu

Otomasyon tekrar eden recovery adımlarını daha hızlı ve tutarlı hâle getirir. Runbook komutları, health check, scale-up ve traffic switching otomatikleştirilebilir. Ancak bütün kararların kontrolsüz biçimde makineye bırakılması yeni riskler yaratır. Özellikle stateful sistemlerde human approval gate faydalıdır. Otomasyon düzenli test edilmediğinde kendisi de drift yaşayabilir.

Runbook Automation

Tekrarlanan komutlar script veya workflow hâline getirilebilir. Her adım log üretmelidir. Başarısız işlem sonraki adımı güvenli biçimde durdurmalıdır. Manuel override yöntemi belirlenmelidir. Kod değişiklikleri review sürecinden geçmelidir.

Infrastructure as Code

IaC recovery altyapısını tekrarlanabilir biçimde oluşturur. Manuel kaynak açma süresini azaltır. Parametreler region ve environment bazında ayrılabilir. Kod repository ve state dosyası korunmalıdır. Deployment düzenli drill'de gerçek koşullarda çalıştırılmalıdır.

Automated Health Checks

Health check servislerin recovery sonrası gerçekten çalıştığını doğrulayabilir. Sadece port açık kontrolü yerine gerçek dependency sorgusu yapılabilir. Yanlış pozitif sonuçlar azaltılmalıdır. Business transaction seviyesinde synthetic testler yararlıdır. Sonuçlar orchestration'ın sonraki adımını kontrol edebilir.

Traffic Switching

DNS veya global routing değişiklikleri otomasyonla yapılabilir. Cutover öncesi recovery health kontrolü zorunlu olabilir. Kademeli trafik geçişi uygulanabilir. Rollback işlemi de aynı workflow içinde tanımlanmalıdır. Değişikliklerin audit kaydı tutulmalıdır.

Automated Scale-Up

Warm standby ortamı failover sırasında otomatik ölçeklendirilebilir. Hedef instance veya capacity değerleri önceden tanımlanır. Quota yetersizliği otomasyonun başarısız olmasına neden olabilir. Capacity testleri düzenli yapılmalıdır. Ölçek artışı database ve network gibi diğer darboğazlarla birlikte değerlendirilmelidir.

Otomatik Failover'ın Riskleri

Yanlış sağlık sinyali gereksiz failover başlatabilir. State değişikliği iki ortamın aynı anda aktif kalmasına yol açabilir. Otomasyon hatası büyük ölçekte hızlı değişiklik yapabilir. Guardrail ve quorum mekanizmaları riski azaltır. Kritik veri katmanında insan onayı tercih edilebilir.

Human Approval Gates

Human approval gate otomasyon ile kontrollü karar arasında denge sağlar. Sistem bütün ön kontrolleri otomatik yapabilir fakat son failover onayı yetkili kişiye bırakılabilir. Bu yöntem false positive riskini azaltır. Onay süresinin RTO üzerindeki etkisi ölçülmelidir. Yetkili kişi erişilemezse yedek onay mekanizması bulunmalıdır.

Açık Kaynak Disaster Recovery ve İşbirliği Ekosistemi

Açık kaynak araçlar backup, IaC, observability ve Kubernetes recovery süreçlerinde önemli seçenekler sunar. Bu araçların en büyük avantajlarından biri altyapı yaklaşımını tek bir özel formata bağlama riskini azaltabilmesidir. Ancak açık kaynak kullanmak operasyon ve bakım sorumluluğunu ortadan kaldırmaz. Sürüm, güvenlik güncellemesi ve test süreçleri düzenli yönetilmelidir. Kurumlar kullandıkları projelere dokümantasyon, hata bildirimi veya kod katkısıyla destek olabilir.

Açık Kaynak Backup Araçları

Açık kaynak backup araçları farklı depolama ve workload türleri için kullanılabilir. Seçim yapılırken restore yeteneği ve aktif bakım durumu değerlendirilmelidir. Yalnızca backup job çalıştırmak yeterli değildir. Encryption ve retention özellikleri kontrol edilmelidir. Kurum kendi destek modelini de planlamalıdır.

Kubernetes Backup Ekosistemi

Kubernetes ekosisteminde cluster resource ve persistent volume backup için çeşitli yaklaşımlar bulunur. Uygulama tutarlılığı kullanılan storage ve workload tipine göre değişir. Cluster manifest'leri ile stateful data ayrı planlanmalıdır. Restore başka cluster üzerinde test edilmelidir. CRD ve secret gibi kaynakların kapsamda olduğundan emin olunmalıdır.

Infrastructure as Code

Açık IaC yaklaşımı recovery altyapısının farklı ortamlarda tekrar kurulmasını kolaylaştırabilir. Kod review ve version control güvenilirliği artırır. Modüller recovery region için parametrik tasarlanabilir. Bağımlı provider sürümleri düzenli test edilmelidir. Kodun kendisi de güvenli backup politikasına dahil edilmelidir.

GitOps

GitOps hedef sistem durumunu repository üzerinden yönetir. Recovery ortamında uygulama kaynaklarını yeniden kurmayı hızlandırabilir. Repository'nin erişilebilirliği kritik bağımlılıktır. Yanlış commit iki ortama da zarar verebileceği için review şarttır. Rollback kabiliyeti recovery operasyonunda faydalıdır.

OpenTelemetry ile Recovery Observability

OpenTelemetry uygulama ve altyapı sinyallerini standart biçimde toplamak için kullanılabilir. Recovery sırasında trace, metric ve log verileri hatalı dependency'leri bulmayı kolaylaştırır. Telemetry backend'in primary ortamdan bağımsız olması tercih edilebilir. Synthetic transaction verileri RTA ölçümünü destekler. Observability kurtarma doğrulamasının önemli parçasıdır.

Vendor-Neutral DR Tasarımı

Vendor-neutral tasarım bütün servislerin tamamen genel teknoloji kullanması anlamına gelmez. Ama kritik veri ve deployment artifact'larının gerektiğinde taşınabilir olması hedeflenir. Standart veri formatları ve açık IaC tanımları yardımcı olabilir. Yönetilen servis avantajları ile taşınabilirlik arasında bilinçli denge kurulur. Exit testleri bu varsayımları doğrular.

Açık Kaynak Projelere Kurumsal Katkı

Kurumlar kullandıkları açık kaynak projelere yalnızca tüketici olarak yaklaşmak zorunda değildir. Hata raporu, dokümantasyon veya test katkısı ekosistemin gelişmesine yardımcı olur. Güvenlik açıklarının sorumlu bildirimi özellikle önemlidir. İç geliştirmeler uygun olduğunda upstream projeye aktarılabilir. Bu yaklaşım uzun vadeli sürdürülebilirliği destekler.

Cloud Disaster Recovery İçin Adım Adım Uygulama Yol Haritası

Bulut tabanlı disaster recovery planı nasıl hazırlanır sorusuna en pratik yanıt, işi ölçülebilir adımlara bölmektir. Önce hangi varlıkların ve iş süreçlerinin korunacağı belirlenir. Ardından RTO, RPO, dependency, teknik strateji, güvenlik ve test süreci planlanır. İlk tasarımın kusursuz olması gerekmez, fakat gerçek drill ile doğrulanması gerekir. Süreç sürekli monitoring ve drift detection ile yaşayan bir programa dönüşmelidir.

1. Varlık Envanteri Çıkarın

Bütün sunucu, database, storage, SaaS ve network bağımlılıklarını listeleyin. Kaynağın sahibi ve iş amacı belirtilmelidir. Otomatik cloud inventory araçları manuel liste hatalarını azaltır. DR kapsamı bu envanter üzerinden belirlenir. Yeni kaynakların otomatik eklenmesi için süreç kurulmalıdır.

2. BIA Yapın

Her iş sürecinin kesinti etkisini hesaplayın. Gelir, müşteri, personel ve mevzuat risklerini değerlendirin. İş birimleri bu çalışmaya aktif katılmalıdır. Kesintinin hangi süreden sonra kabul edilemez olduğunu belirleyin. Sonuçları tier sınıflandırmasına dönüştürün.

3. RTO ve RPO Belirleyin

Her kritik sistem için ayrı hedef tanımlayın. Hedefleri yalnızca teknik ekip belirlememelidir. İş ihtiyacı ve maliyet birlikte değerlendirilmelidir. Çok düşük hedeflerin altyapı bedelini açıkça gösterin. Değerleri yönetim onayıyla kayıt altına alın.

4. Dependency Map Oluşturun

Uygulamanın database, identity, DNS, secret ve dış servis bağımlılıklarını haritalayın. Başlatma sırası bu haritadan çıkarılmalıdır. IP allowlist ve sertifika gibi görünmeyen detayları ekleyin. Her major değişiklikten sonra haritayı güncelleyin. Drill bulgularını yeni dependency bilgisi olarak işleyin.

5. DR Stratejisini Seçin

Her tier için uygun recovery modelini belirleyin. Backup restore, pilot light, warm standby veya aktif mimari arasında seçim yapın. RTO, RPO ve yıllık maliyeti karşılaştırın. Ekip kapasitesini de hesaba katın. Gereksiz pahalı mimariden kaçının.

6. Recovery Region Seçin

Recovery region servis uygunluğu, gecikme ve veri konumu açısından değerlendirilmelidir. Gerekli quota'ların hazır olduğunu kontrol edin. Veri replikasyon maliyetini hesaplayın. Kimlik ve network erişimlerini planlayın. Region'ı gerçek testte kullanmadan güvenli kabul etmeyin.

7. Backup ve Replication Kurun

RPO hedeflerine göre backup sıklığı ve replikasyon yöntemini belirleyin. Immutable kopya gereksinimini risk bazında değerlendirin. Replication lag için alarm kurun. Backup integrity testleri ekleyin. Restore süresini gerçek veri boyutuyla ölçün.

8. Infrastructure as Code Ekleyin

Network ve compute kaynaklarını kodla tanımlayın. Recovery region parametrelerini ayrı tutun. Kod repository ve state dosyasını koruyun. Deployment süresini drill sırasında ölçün. Drift detection ile production farklarını takip edin.

9. Identity ve Network Recovery'yi Planlayın

Kimlik ve network bileşenlerini Wave 0 olarak ele alın. DNS, VPN, route ve firewall bağımlılıklarını doğrulayın. Break-glass erişimi hazırlayın. Recovery kullanıcılarının login testini yapın. Erişim olmadığında sistemin kurtarılmış sayılmayacağını unutmayın.

10. Runbook Yazın

Aktivasyon kriterlerini ve teknik adımları sırayla yazın. Her adımın sahibini belirtin. Validation ve rollback yöntemini ekleyin. İletişim ve eskalasyon bilgilerini güncel tutun. Runbook'u gerçek drill ile doğrulayın.

11. Security Kontrollerini Ekleyin

Recovery ortamında MFA, least privilege ve encryption uygulayın. Backup silme yetkilerini sınırlandırın. Immutable veya izole kopyaları değerlendirin. Audit logging'i etkinleştirin. Security Team'in recovery planındaki rolünü açıkça tanımlayın.

12. İlk Full DR Drill'i Yapın

Kontrollü bakım penceresinde full failover gerçekleştirin. Bütün dependency'leri gerçek sırayla çalıştırın. Kullanıcı kabul testi yapın. Actual RTO ve RPO'yu ölçün. Bulunan sorunları risk backlog'una ekleyin.

13. Actual RTO/RPO'yu Ölçün

Hedef ile gerçek değerleri karşılaştırın. RTO aşımına neden olan adımları ayırın. Replication lag ve restore süresini inceleyin. İş birimiyle sonuçları paylaşın. Gerekirse hedef veya mimariyi güncelleyin.

14. Failback Testini Yapın

Primary ortama geri dönüşü ayrı süreç olarak uygulayın. Reverse replication ve data reconciliation yapın. Trafiği kontrollü biçimde geri taşıyın. Veri kaybı oluşmadığını doğrulayın. Failback süresini de KPI olarak kaydedin.

15. Sürekli Monitoring ve Drift Detection Kurun

Backup, replication ve DR environment sağlığını sürekli izleyin. Configuration drift için alarm oluşturun. Son drill tarihini dashboard'a ekleyin. Major change sonrası validation çalıştırın. Programı yılda bir belge güncellemesi yerine sürekli işletilen süreç hâline getirin.

En Sık Yapılan Disaster Recovery Hataları

DR projelerinde sorun çoğu zaman teknoloji eksikliğinden değil, yanlış varsayımlardan kaynaklanır. En yaygın hata yedeklerin varlığını gerçek recovery kabiliyetiyle karıştırmaktır. Identity, DNS, failback ve gerçek RTO ölçümü sıklıkla gözden kaçar. Otomasyon da test edilmeden güvenli kabul edilmemelidir. Aşağıdaki hatalar program değerlendirmesinde kontrol listesi olarak kullanılabilir.

Backup'ı Disaster Recovery Sanmak

Yedek yalnızca veri kopyasıdır. Hizmetin çalışması için altyapı, network ve identity de gerekir. Restore süresi hedef RTO'yu aşabilir. Yedeklerin okunabilirliği test edilmelidir. DR planı bütün süreci birlikte yönetir.

RTO/RPO'yu İş Birimleri Olmadan Belirlemek

Teknik ekip iş kesintisinin gerçek maliyetini tek başına bilemez. Çok düşük hedef gereksiz maliyet yaratabilir. Çok yüksek hedef ise iş riskini artırabilir. Business Owner karar sürecine katılmalıdır. BIA bu ortak dili oluşturur.

Her Sisteme Aynı RTO Vermek

Uygulamaların iş etkisi farklıdır. Aynı hedef bütün sistemlerde bütçeyi verimsiz kullanır. Tier sınıflandırması daha doğru yaklaşım sağlar. Kritik sistemlere daha fazla yatırım yapılabilir. Düşük öncelikli sistemlerde daha uzun recovery kabul edilebilir.

Identity ve DNS'i Unutmak

Uygulama açılmış olsa bile kullanıcı login olamıyorsa hizmet çalışmaz. DNS yanlış endpoint'i gösteriyorsa aynı sorun oluşur. Bu bileşenler temel dependency olarak ele alınmalıdır. Wave 0 içinde test edilmelidir. Break-glass ve traffic failover süreçleri hazırlanmalıdır.

Yalnızca VM'leri Replike Etmek

Modern uygulamalar VM dışında çok sayıda yönetilen servise bağlıdır. Database, queue, object storage ve secret servisleri ayrıca korunmalıdır. Network policy ve identity bağımlılıkları da unutulmamalıdır. VM'nin açılması uygulamanın çalışacağını garanti etmez. Dependency map bu hatayı azaltır.

Ransomware'i Replica'ya Taşımak

Sürekli replikasyon kötü değişiklikleri de taşıyabilir. Şifrelenmiş dosyalar kısa sürede recovery ortama ulaşabilir. Immutable backup temiz geri dönüş noktası sağlar. Replikasyonu durdurma prosedürü tanımlanabilir. Güvenlik ekibi clean recovery point seçimine katılmalıdır.

Immutable Backup Kullanmamak

Normal backup yönetici yetkisiyle silinebiliyorsa saldırıda kaybedilebilir. Immutable kopya belirli süre değişiklik yapılmasını engeller. Kritik sistemlerde bu koruma ciddi fark yaratır. Retention politikası doğru seçilmelidir. Restore testi yine zorunludur.

Configuration Drift'i İzlememek

Production ve DR zamanla farklılaşır. Yeni firewall kuralı veya secret recovery tarafında eksik kalabilir. Drift detection bu farkları erken gösterir. Major change sonrası validation yapılmalıdır. Aynı IaC kodunu kullanmak riski azaltır.

Service Quota'yı Kontrol Etmemek

Recovery sırasında hızlı scale-up için yeterli quota gerekir. Normalde küçük warm ortamın çalışması bu kapasiteyi garanti etmez. Compute, IP ve managed service limitleri kontrol edilmelidir. Gerekirse önceden quota artırımı yapılmalıdır. Full drill gerçek kapasiteyi doğrular.

Failover'ı Test Edip Failback'i Test Etmemek

Recovery ortamına geçmek yalnızca sürecin yarısıdır. Primary geri geldiğinde yeni verilerin nasıl taşınacağı bilinmelidir. Reverse replication hata verebilir. Trafik geri dönüşünde veri kaybı riski vardır. Failback ayrı drill olarak ölçülmelidir.

Runbook'u Güncel Tutmamak

Eski runbook kriz sırasında yanlış yönlendirme yapabilir. Personel, IP, servis veya komutlar değişmiş olabilir. Her major release sonrası kontrol yapılmalıdır. Drill bulguları belgeye işlenmelidir. Version control kullanmak değişiklik geçmişini korur.

Gerçek RTO'yu Ölçmemek

Hedef RTO ile gerçek süre aynı değildir. Sunucunun açılma süresini RTO kabul etmek yanıltıcıdır. Kullanıcı hizmeti çalışana kadar süre ölçülmelidir. DNS, validation ve onay gecikmeleri dahil edilmelidir. RTA dashboard üzerinde takip edilmelidir.

Otomatik Failover'a Körü Körüne Güvenmek

Otomatik sistemler yanlış health signal nedeniyle gereksiz failover yapabilir. Network partition split-brain oluşturabilir. Guardrail ve human approval gate gerekebilir. Otomasyon da düzenli drill ile test edilmelidir. Hız ile kontrol arasında bilinçli denge kurulmalıdır.

DR Ortamının Güvenliğini İhmal Etmek

Pasif ortamlar uzun süre kullanılmadığı için güvenlik kontrolleri eskimeye açık olabilir. Eski hesaplar ve geniş yetkiler risk yaratır. Production ile benzer security baseline uygulanmalıdır. Log ve MFA kontrolleri düzenli gözden geçirilmelidir. Recovery planı saldırı sonrası kullanılacağı için güvenlik seviyesi özellikle önemlidir.

Sık Sorulan Sorular

Bu bölümde teknik ekiplerin ve iş yöneticilerinin en sık sorduğu temel DR sorularını kısa ama uygulanabilir yanıtlarla ele alıyoruz. Sorular RTO, RPO, backup, DRaaS, multi-region, ransomware ve Kubernetes gibi karar alanlarını kapsıyor. Yanıtlar tek bir ürün modeline bağlı değildir. Kurumların kendi BIA ve risk profillerine göre uyarlama yapması gerekir. Kritik kararlar her zaman gerçek drill sonuçlarıyla doğrulanmalıdır.

Bulut tabanlı Disaster Recovery nedir?

Bulut tabanlı Disaster Recovery, birincil sistem kullanılamadığında hizmeti alternatif bulut altyapısında yeniden çalıştırma yöntemidir. Veri, compute, network ve identity bileşenleri birlikte planlanır. Recovery hedefleri RTO ve RPO ile ölçülür. Strateji backup restore'dan active/active modele kadar değişebilir. Başarı düzenli failover ve failback testleriyle doğrulanır.

Disaster Recovery ile backup arasındaki fark nedir?

Backup veri kopyasını korur. Disaster Recovery ise bütün hizmetin yeniden çalışmasını hedefler. DNS, identity, network ve uygulama dependency'leri DR kapsamına girer. Yedek bulunması restore süresinin kabul edilebilir olduğu anlamına gelmez. Bu nedenle backup DR planının yalnızca bir katmanıdır.

RTO ve RPO nedir?

RTO kabul edilebilir maksimum kurtarma süresidir. RPO ise kabul edilebilir veri kaybı aralığını ifade eder. İki değer farklı iş hedeflerini ölçer. Daha düşük hedefler genellikle daha yüksek maliyet oluşturur. Her uygulama için ayrı belirlenmeleri gerekir.

DRaaS nedir?

DRaaS kurtarma altyapısı ve operasyonunun hizmet modeliyle sunulmasıdır. Replikasyon, orchestration, test ve incident desteği içerebilir. Managed, assisted ve self-service modeller bulunabilir. Sözleşmede RTO, RPO ve failback kapsamı açık olmalıdır. Provider lock-in ve exit strategy de değerlendirilmelidir.

Pilot Light nedir?

Pilot light modelinde kritik çekirdek bileşenler sürekli çalışır. Büyük compute kapasitesi yalnızca felaket anında oluşturulur. Backup restore'dan daha hızlı olabilir. Warm standby'dan daha düşük sürekli maliyet sunabilir. IaC ve otomasyon başarısını doğrudan etkiler.

Warm Standby nedir?

Warm standby production'ın küçültülmüş fakat çalışan bir kopyasını sürekli hazır tutar. Failover sırasında kapasite artırılır. Pilot light modelinden daha hızlı recovery sağlar. Sürekli compute maliyeti daha yüksektir. Configuration drift düzenli kontrol edilmelidir.

Multi-Region DR gerekli midir?

Her sistem için gerekli değildir. Region kesintisi iş açısından kabul edilemiyorsa değerlendirilebilir. Multi-AZ daha küçük hata alanlarını zaten koruyabilir. Multi-region ek maliyet ve operasyon yükü getirir. Karar BIA ve risk analizine dayanmalıdır.

Disaster Recovery ransomware'e karşı korur mu?

Doğru tasarlanırsa önemli koruma sağlar. Ancak replikasyon tek başına yeterli değildir. Immutable backup, clean recovery point ve izole restore gerekir. Credential rotation ve malware scanning de sürece eklenmelidir. Ransomware senaryosu ayrı drill ile test edilmelidir.

RPO 0 mümkün müdür?

Belirli mimarilerde teorik olarak sıfıra yakın veri kaybı hedeflenebilir. Senkron replikasyon bu amaçla kullanılabilir. Ancak network latency ve maliyet artar. Mantıksal corruption yine iki tarafa taşınabilir. Bu nedenle RPO 0 yalnızca güçlü iş gerekçesi varsa seçilmelidir.

DR planı ne sıklıkla test edilmelidir?

Test sıklığı sistem kritikliğine göre değişir. Kritik sistemler daha sık partial veya full drill gerektirebilir. Büyük değişikliklerden sonra ek validation yapılmalıdır. Yılda bir belge incelemesi tek başına yeterli olmayabilir. Organizasyon kendi risk ve mevzuat gereksinimine göre takvim oluşturmalıdır.

Failover ile failback arasındaki fark nedir?

Failover primary ortamdan recovery ortamına geçiştir. Failback ise onarılan primary ortama geri dönüştür. Failback sırasında recovery tarafındaki yeni verilerin geri taşınması gerekir. Reverse replication ve reconciliation önemli adımlardır. İki süreç de ayrı ayrı test edilmelidir.

Disaster Recovery için ikinci cloud provider gerekli midir?

Her durumda gerekli değildir. Aynı platformda farklı region kullanmak çoğu risk için yeterli olabilir. İkinci platform servis uyumsuzluğu ve operasyon yükü getirir. Kritik provider-level risk için anlamlı olabilir. Karar iş etkisi ve ekip kapasitesine göre verilmelidir.

DRaaS mı kendi DR altyapımız mı daha avantajlıdır?

İç ekip kapasitesi ve kontrol ihtiyacı kararı etkiler. DRaaS operasyon yükünü azaltabilir. Kendi altyapısı daha fazla kontrol sağlayabilir fakat sürekli uzmanlık gerektirir. TCO hesabında insan maliyeti de dahil edilmelidir. Her iki model gerçek test ve exit planı açısından değerlendirilmelidir.

Kubernetes için Disaster Recovery nasıl yapılır?

Kubernetes DR, cluster manifest'leri ve stateful verileri birlikte korumalıdır. etcd, persistent volume, registry ve secret'lar ayrı dependency'dir. GitOps yeniden kurulum süresini azaltabilir. Stateful workload recovery gerçek veriyle test edilmelidir. Cluster'ın açılması uygulamanın kurtarıldığı anlamına gelmez.

KVKK açısından bulut yedekleri nasıl korunmalıdır?

Kişisel veri içeren yedekler erişim kontrolü ve şifreleme ile korunmalıdır. Saklama ve imha süreleri tanımlanmalıdır. Recovery testlerinde gereksiz veri çoğaltılmamalıdır. Yurt dışı aktarım gereksinimleri güncel mevzuata göre incelenmelidir. Hukuki değerlendirme için resmi kaynak ve yetkili uzman görüşü esas alınmalıdır.

Bulut Tabanlı Olağanüstü Durum Kurtarma Hakkında Ek Sorular

Aşağıdaki sorular, kurumların uygulama aşamasına geçerken daha ayrıntılı yanıt aradığı başlıkları toplar. Teknik seçimler kurumun veri miktarı, iş kritikliği ve mevcut altyapısına göre değişir. Bu nedenle hazır bir şablonu aynen kullanmak yerine ölçülebilir hedeflerden başlamak gerekir. Bulut Tabanlı Olağanüstü Durum Kurtarma (Disaster Recovery) programı başarılı olduğunda yalnızca teknoloji değil, insanlar ve süreçler de aynı plana göre hareket eder. Gerçek güven seviyesi ise düzenli test sonuçlarıyla ortaya çıkar.

Bulut tabanlı olağanüstü durum kurtarma (Disaster Recovery) planı nasıl hazırlanır?

Önce varlık envanteri ve Business Impact Analysis hazırlanmalıdır. Ardından her kritik sistem için RTO ve RPO hedefleri belirlenir. Dependency map çıkarıldıktan sonra backup, replication ve recovery stratejisi seçilir. Identity, network, security, runbook ve failback adımları ayrıca planlanır. Son aşamada full DR drill yapılarak actual RTO ve RPO ölçülür ve plan test sonuçlarına göre güncellenir.

RTO ve RPO değerleri bulut tabanlı felaket kurtarma senaryolarında nasıl belirlenmelidir?

RTO ve RPO doğrudan iş etkisinden türetilmelidir. İş birimi kesintinin ne kadar süre tolere edilebileceğini ve hangi verinin yeniden üretilebileceğini açıklar. Teknik ekip bu hedeflerin maliyetini ve uygulanabilirliğini hesaplar. Her sisteme aynı hedef verilmemelidir. Son değerler gerçek drill sonuçlarıyla doğrulanmalıdır.

AWS Azure ve Google Cloud üzerinde yedekleme replikasyon ve failover süreçleri nasıl yapılandırılır?

Platformdan bağımsız olarak süreç aynı temel prensiple başlar: önce RPO hedefi, ardından veri çoğaltma yöntemi belirlenir. Backup kopyaları ayrı hata alanında tutulmalı ve restore testleri yapılmalıdır. Replikasyon lag sürekli izlenmeli, failover sırasında database promotion ve traffic cutover sırası runbook'ta tanımlanmalıdır. Servis isimleri ve teknik uygulama ayrıntıları kullanılan ortama göre değişebilir. En önemli nokta, tasarımın gerçek full failover testiyle doğrulanmasıdır.

Disaster Recovery planlarında çoklu bölge kullanımı otomatik geçiş testleri ve iş sürekliliği nasıl yönetilmelidir?

Çoklu bölge tasarımı region seviyesindeki kesintinin iş açısından kabul edilemez olduğu sistemlerde değerlendirilmelidir. Otomatik failover sağlık kontrolleri, quorum ve gerektiğinde human approval gate ile korunmalıdır. Region evacuation drill gerçek bağımsızlığı ölçmek için düzenli uygulanabilir. İş sürekliliği planı teknik failover'ın yanında çalışan ve müşteri iletişimini de kapsamalıdır. Failback testi yapılmadan tam recovery döngüsü tamamlanmış sayılmamalıdır.

Bulut tabanlı olağanüstü durum kurtarma kurulumu ve danışmanlığını yakınımda nerede bulabilirim?

Bulut disaster recovery danışmanlığı yakınımda şeklinde arama yaparken yalnızca fiziksel yakınlığa odaklanmak doğru seçim kriteri değildir. RTO ve RPO analizi, backup restore testi, replikasyon, network, identity, IaC, ransomware recovery ve failback deneyimi birlikte değerlendirilmelidir. Diyarbakır Yazılım Topluluğu'nun yaklaşımı ve topluluk yapısı hakkında https://www.diyarbakiryazilim.com.tr/about sayfasından bilgi alınabilir. Teknik çalışma ve proje yaklaşımını incelemek için https://www.diyarbakiryazilim.com.tr/projects adresi de değerlendirilebilir. Görüşme sırasında mutlaka gerçek drill, actual RTO/RPO, failback ve configuration drift yönetimi hakkında somut sorular sorulmalıdır.

Sonuç

Bulut Tabanlı Olağanüstü Durum Kurtarma (Disaster Recovery) iyi bir backup sisteminden çok daha geniş bir iş sürekliliği disiplinidir. Başarılı bir yapı; doğru BIA, gerçekçi RTO ve RPO hedefleri, güvenilir yedekler, kontrollü replikasyon, identity ve network recovery, Infrastructure as Code, güvenlik kontrolleri ve düzenli drill süreçlerini aynı çerçevede bir araya getirir. En önemli ölçüt dokümana yazılan hedef değil, test sırasında elde edilen actual RTO ve actual RPO değerleridir. Kurumunuzun mevcut altyapısını değerlendirmek, recovery bağımlılıklarını görünür hâle getirmek veya uygulanabilir bir DR yol haritası oluşturmak istiyorsanız Diyarbakır Yazılım Topluluğu ile https://www.diyarbakiryazilim.com.tr/about üzerinden iletişim ve topluluk bilgilerine ulaşabilirsiniz. İlk adım olarak bütün sistemleri değiştirmek yerine kritik iş yüklerinden başlayın, ölçülebilir hedefler belirleyin ve ilk gerçek kurtarma testinizi planlayın.