Disaster Recovery
Recovery Site, Topoloji ve Bağımlı Altyapılar
Recovery stratejisini iş hedefine eşleştir
Ön koşul: senaryo bazlı BIA, MTD/MTPD, RTO/RPO, minimum iş hizmeti, declaration ve recovery dalgalarını çıkarabilmelisin. Bu dersin sonunda backup/restore, pilot light, warm standby ve active-active yaklaşımlarını ürün etiketi yerine hazır tutulan state, recovery işi, maliyet ve riskle ayıracak; recovery site’ın coğrafi, tesis, platform, identity ve yönetim sınırlarını doğrulayacak; network, DNS, key, security, observability ve dış servis bağımlılıklarını topolojiye yerleştirecek; normal ve adverse kapasite zarfı kuracak; Arven için varsayım, test, risk, TBD ve koşul taşıyan recovery topolojisi önerebileceksin.
DR stratejisi RTO/RPO etiketinden ürün seçmeye sıçramaz. Her yaklaşım hangi data, configuration, infrastructure ve application state’inin önceden hazır olduğunu; olay anında hangi işin kaldığını; hangi insan, kontrol düzlemi ve tedarikçiye bağımlı olduğunu açıklar. Aynı kuruluş farklı hizmetler için farklı yaklaşım kullanabilir. Bir desen diğerinden mutlak üstün değildir; iş etkisi, senaryo, güven sınırı, test sonucu ve maliyetle eşleşir. Backup and restore en az sürekli çalışma kaynağı tutabilir; alternatif ortam, configuration ve application olayda kurulup data geri getirilir. Maliyet düşük olabilir, fakat media recall, provisioning, configuration drift ve veri hacmi RTO’yu uzatır. Pilot light kritik data ve temel çekirdeği sürekli hazır tutar; application katmanının bir bölümü olayda ölçeklenir. Warm standby, azaltılmış fakat çalışan uçtan uca ortamı büyütür ve trafiğe açar. Active-active birden fazla site/region’ın aynı anda hizmet vermesini hedefler; data consistency, trafik, hata izolasyonu ve operasyon karmaşıklığı artar. İsimler kesin mimari değildir. Bir ekip “warm” derken yalnız çalışan database’i, diğeri az kapasitede tüm zinciri kastedebilir. Bu nedenle compute instance, image/IaC, network, data replica, identity, key, DNS, security policy, monitoring, licence, external allowlist ve personel hazırlığı bileşen bazında kaydedilir. Normal zamanda ne çalışır, declaration sonrası ne oluşturulur veya büyütülür, ne kadar sürer ve hangi kanıtla doğrulanır sorulur. RTO kısaldıkça önceden hazır state ve otomasyon genellikle artar; maliyet kadar değişiklik senkronizasyonu ve yanlış failover riski de büyür. RPO veri replication/backup mekanizması ile consistency modeline bağlıdır. Active-active etiketi sıfır RPO/RTO garantisi değildir; ortak identity, DNS, control plane veya hatalı değişiklik iki tarafı da etkileyebilir. Strateji, hedef dışında kalan senaryoları ve residual riski de yazar.
| Yaklaşım | Önceden hazır state | Olay anındaki ana iş |
|---|---|---|
| Backup/restore | Kopya ve yeniden kurma artefact’ları | Altyapı kur, data restore et, doğrula |
| Pilot light | Data ve kritik çekirdek | Uygulamayı kur/ölçekle ve bağla |
| Warm standby | Azaltılmış uçtan uca hizmet | Kapasiteyi büyüt, point’i doğrula, trafik aç |
| Active-active | Birden çok çalışan hizmet | Sağlam tarafı izole et, data/trafiği uzlaştır |
| Hybrid | Hizmete göre farklı desen | Portföy sırası ve ortak kaynakları yönet |
ÖRNEK
Warm standby adı, cold bağımlılık gerçeği
Arven’in ikincil lokasyonunda ERP database ve iki application VM çalışır; ekip bunu warm standby sayar. Fakat DNS değişikliği manuel bilete, key service ve domain controller birincil site’a, lisans sunucusu dış sağlayıcının eski IP allowlist’ine bağlıdır. Compute warm görünse de uçtan uca hizmetin kritik yolları cold’dur. Strateji adı yerine her bağımlılığın hazır state’i kaydedilir.
MÜŞTERİYE SOR
Her DR seçeneğinde data, infrastructure, configuration, application ve bağımlı servislerden hangisi sürekli hazır; declaration sonrası hangisi kim tarafından ne kadar sürede kurulacak, ölçeklenecek veya doğrulanacak?
Pazarlama desenini gerçek kalan iş, süre bütçesi ve kabul kanıtına dönüştürür.
BİLGİNİ KONTROL ET
Warm standby yaklaşımını en iyi hangi kanıt tanımlar?
Site, failure ve trust domain sınırlarını doğrula
Recovery site bağımsızlığı kilometre ile tek başına ölçülmez. Aynı floodplain, deprem/yangın bölgesi, enerji şebekesi, telecom santrali, metro fiberi, bina erişimi, personel havuzu veya tedarik zinciri iki lokasyonu birlikte etkileyebilir. Çok uzak site ise latency, data sovereignty, operasyon, maliyet ve personel erişimi riski getirebilir. Tehdit ve BIA senaryosu hangi korelasyonun kabul edilemez olduğunu belirler. Cloud availability zone veya region da otomatik bağımsızlık garantisi değildir. Account/tenant, organization policy, identity provider, DNS zone, key vault, CI/CD, image registry, observability, support ve quota ortak control/trust domain olabilir. Tek privileged credential iki ortamı değiştirebiliyorsa fiziksel ayrılık cyber bağımsızlık sağlamaz. Provider dokümanı hizmet sınırını açıklayabilir; müşteri configuration ve shared responsibility’si ayrıca kanıtlanır. Network topolojisi data replication, yönetim, kullanıcı erişimi ve dış entegrasyon yollarını ayırır. İki site aynı carrier, last-mile, firewall manager veya route controller’a bağlı olabilir. DR anında bandwidth yalnız steady replication’ı değil backlog catch-up, restore, image/config dağıtımı ve kullanıcı trafiğini birlikte taşımalıdır. DNS TTL tek başına trafik geçiş süresi değildir; resolver cache, health decision, certificate, load balancer, route advertisement, WAF ve external allowlist zinciri ölçülür. Data yazma otoritesi ve partition davranışı açık olmalıdır. Synchronous yaklaşım latency ve ortak kesinti riski; asynchronous yaklaşım lag ve veri kaybı riski taşır. İki taraf bağlantıyı kaybettiğinde hangisi yazabilir, quorum/witness nerede, split-brain nasıl engellenir, geri birleşmede hangi kaynak doğru kabul edilir? Cyber senaryoda bozukluk veya silme replike olabilir. Replication, bağımsız backup ve temiz point stratejisinin yerine geçmez.
| Domain | Ortak neden sorusu | Negatif kanıt |
|---|---|---|
| Fiziksel | Tesis, güç, çevresel risk ortak mı? | Tanımlı site olayı diğerini etkilemez |
| Network | Carrier, yol, firewall/DNS ortak mı? | Bir yol/control kaybında erişim sürer |
| Identity/control | Account, admin, CI/CD ortak mı? | Birincil credential olmadan recovery yönetilir |
| Data | Yazma otoritesi ve partition davranışı ne? | Split-brain reddedilir, doğru point seçilir |
| Tedarik/personel | Support, licence ve ekip ortak mı? | Ana sağlayıcı/ekip yokken plan yürür |
ÖRNEK
Farklı şehir, aynı kontrol düzlemi
Arven’in siteleri farklı şehirlerdedir ve farklı enerji şebekeleri kullanır. Yine de iki firewall aynı merkezi manager’dan, iki cloud hesabı aynı identity tenant’dan, DNS aynı registrar hesabından yönetilir. Privileged hesabın ele geçirilmesi iki site yönlendirmesini ve erişimini bozabilir. Ekip coğrafi failure domain yanında ayrı recovery admin, break-glass, policy ve yönetim yolunu tasarlar.
MÜŞTERİYE SOR
Tanımlı site, region, network partition ve privileged-account senaryolarında hangi güç, carrier, route/DNS, account, identity, key, yönetim ve personel bağımlılığı diğer tarafta güvenilir kalır; bunu hangi negatif test gösterir?
Mesafe veya provider etiketini senaryoya bağlı failure ve trust domain kanıtına dönüştürür.
ŞİMDİ SEN DENE
Failure ve trust domain haritası çiz
Arven’in iki lokasyonu için fiziksel risk, güç, carrier/last-mile, firewall, DNS, identity, key, cloud account/control plane, CI/CD, observability, support ve personel yollarını çiz. Üç ortak nedeni işaretle; her biri için ayırma, alternatif yol, owner ve negatif test yaz. Partition halinde data yazma otoritesini belirt.
BİLGİNİ KONTROL ET
İki sitenin farklı şehirlerde olması neyi tek başına kanıtlamaz?
Bağımlı altyapı ve kapasite zarfını kur
Recovery ortamı yalnız application compute ve data’dan oluşmaz. Network address plan, subnet/VLAN, route, firewall/WAF, load balancer, DNS, DHCP/IPAM; identity, PKI, certificate, key/secrets, privileged workstation; time, logging, SIEM/EDR, monitoring, alerting; image/artifact registry, CI/CD, configuration/IaC, licence ve external provider bağlantıları ilk sınıf DR bileşenidir. Her birinin data/config kaynağı, RPO/RTO’su, bootstrap sırası, sahibi ve test yöntemi bulunur. Configuration parity kör kopyalama değildir. İkincil ortam planlı olarak daha küçük veya farklı endpoint’li olabilir; farklar kod/IaC ve karar kaydında yönetilir. Manuel değişiklik drift üretir. IaC yeniden kurmayı hızlandırabilir fakat state, secret, provider quota, image erişimi ve hatalı kod ortak nedeni devam eder. Artefact ve configuration sürümü recovery point ile uyumlu olmalıdır; eski database ile yeni schema veya yeni certificate ile eski hostname hizmeti bozabilir. Kapasite minimum iş hizmeti üzerinden base ve adverse modellenir. Compute/RAM, storage capacity/IOPS/throughput, network, load balancer, database connection, queue, key/DNS request, logging ingest ve external limitler aynı senaryoda ele alınır. Ay sonu tepesinde failover, replication backlog ve restore aynı kaynakları kullanabilir. Birden çok hizmet ortak DR ortamına geçerse resource contention ve portföy recovery sırası görünür olmalıdır. Warm veya active ortamın boş kapasitesi normal kullanım metriğinden çıkarılmaz. Bir node/AZ/network yolu kaybı, bakım, rebuild, data convergence ve güvenlik taraması sırasında hizmet eşiği korunmalıdır. Cloud quota ve capacity reservation, on-prem tedarik lead time, licence entitlement ve support erişimi önceden doğrulanır. Observability DR tarafında hazır değilse performans ve güvenlik kabulü yapılamaz. Sağlamlık, dashboard yeşilinden iş işlemi ve adverse test sonucuna kadar kanıtlanır.
| Katman | Hazır tutulacak kanıt | Adverse doğrulama |
|---|---|---|
| Erişim | Route, DNS, LB, firewall/WAF, certificate | Birincil control yolu olmadan trafik |
| Trust | Identity, PKI, key/secret, break-glass | Compromised primary credential reddi |
| Kurulum | IaC, image, artefact, config/state | Doğru point ile sürüm uyumu |
| Gözlem | Log, metric, EDR/SIEM ve alarm | DR tarafında kabul ve olay görünürlüğü |
| Kapasite | Compute, data, network, quota/licence | Tepe + backlog + kayıp/rebuild |
MÜŞTERİYE SOR
Minimum hizmeti birincil control plane olmadan açmak için hangi network/DNS, identity/PKI/key, artefact/config, licence, dış bağlantı ve gözlem bileşeni hazır; tepe + backlog + bir kaynak kaybında kalan kapasite nedir?
Uygulama topolojisini bootstrap, güven, kabul ve adverse kapasite gereksinimleriyle tamamlar.
ŞİMDİ SEN DENE
DR altyapı readiness ve kapasite kartı kur
Arven için erişim, trust, kurulum, gözlem ve kapasite katmanlarını doldur. Her bileşene normal state, declaration işi, config/data kaynağı, RTO payı, owner ve test ekle. Compute, storage, network ve ortak servisleri tepe yük, replication backlog, restore ve bir kaynak kaybında hesapla; üç quota/licence riskini yaz.
BİLGİNİ KONTROL ET
Infrastructure as Code DR readiness için neyi tek başına garanti etmez?
Arven recovery topolojisi kararını üret
Arven üç yaklaşımı karşılaştırır. A Ankara’da backup/restore ile altyapıyı IaC’den kurar; düşük sürekli maliyet karşılığında provisioning, restore ve doğrulama üç saatlik hedefi zorlayabilir. B Ankara’da minimum sipariş zincirini warm standby tutar; database replica, identity/DNS recovery yolu, güvenlik ve observability sürekli çalışır, declaration sonrası application kapasitesi büyür. C iki lokasyonda active-active hizmet sunar; kısa geçiş potansiyeline karşı data consistency, global traffic, ortak değişiklik ve split-brain karmaşıklığı taşır. BIA minimum sipariş hizmeti için üç saat RTO ve senaryoya göre 15 dakika RPO hedeflemiştir. Ön elemede A’nın son testteki media recall, provisioning ve 12 TB restore süresi hedefi aşar; ancak düşük öncelikli raporlama için uygundur. C, sipariş uygulamasının tek-writer database ve dış ödeme sağlayıcısı nedeniyle büyük yeniden tasarım ister. B mevcut uygulama sınırlarıyla daha uygulanabilir görünür; yine de karar POC ve dependency kanıtına bağlıdır. Warm topoloji iki siteyi fiziksel ve network olarak ayırır; ayrı recovery admin/break-glass yolu, Ankara’da DNS resolver/authoritative değişim yolu, identity/key bootstrap, EDR/SIEM ve monitoring tutar. Asynchronous replication lag’i gerçek transaction zamanı ile izlenir; bağımsız backup temiz point sağlar. Ankara minimum kapasitesi yoğun saatte siparişin yüzde 60’ını, replication catch-up ve log ingest’i bir altyapı yolu kaybında taşımalıdır. Raporlama sonraki dalgaya bırakılır. POC İstanbul control plane erişilemezken başlar. Declaration, Ankara yönetim erişimi, write authority fencing, data consistency, application scale-out, DNS/traffic, external allowlist, security ve sipariş işlemi zamanlanır. Risk register ortak registrar, identity compromise, quota, replication lag, configuration drift, licence ve personel açığını izler. Koşullu öneri ancak üç senaryonun kabul ölçüleri ve adverse kapasitesi geçtiğinde karar olur.
| Kapı | Eleme kanıtı | Karşılaştırma |
|---|---|---|
| Hedef | Minimum hizmet, RTO/RPO, consistency | BIA ve portföy önceliği |
| Bağımsızlık | Site/network/identity/control negatif testi | Residual ortak neden |
| Hazır state | Data, config, app ve bağımlılıklar | Declaration sonrası kalan iş |
| Kapasite | Tepe, backlog, kayıp/rebuild | Büyüme ve quota/licence |
| Kabul | Teknik, security ve sipariş işlemi | Test yaşı, operasyon ve maliyet |
MÜŞTERİYE SOR
A, B ve C yaklaşımında hangi state önceden hazır; üç olay senaryosunda hangi failure/trust domain güvenilir; minimum sipariş zinciri tepe, backlog ve bir kaynak kaybında hangi kanıtla üç saat içinde kabul edilir?
Strateji adlarını ölçülebilir hazır state, ortak neden, kapasite ve iş sonucu üzerinden eleyen karar kapısına dönüştürür.
ŞİMDİ SEN DENE
Arven recovery topolojisi karar paketini tamamla
A, B ve C yaklaşımını minimum hizmet, üç senaryo, hazır/kalan state, site-network-trust sınırı, data consistency, ortak altyapı ve adverse kapasiteyle karşılaştır. Sekiz risk/TBD’ye owner/tarih ver; POC adımı, stop/go, iş kabulü ve dört yeniden açma koşulu yaz. Koşullu önerini tek paragrafta savun.
BU DERSTEN AL
Bu dersten taşıyacağın düşünceler
- DR deseni hangi state’in hazır, hangi işin olay anına kaldığını açıklar.
- Backup/restore, pilot light, warm standby ve active-active iş hedefine göre seçilir.
- Coğrafi ayrılık network, identity, control plane ve operasyon bağımsızlığını garanti etmez.
- Yazma otoritesi, quorum/partition ve consistency split-brain riskini yönetir.
- DNS, key, security, observability, licence ve dış servisler topolojinin parçasıdır.
- Arven kararı minimum hizmet, üç senaryo, adverse kapasite, POC, risk ve TBD ile koşulludur.