Bir sistemin çalışıyor olması tek başına yeterli değildir; ne zaman ve hangi koşullarda yeniden ayağa kaldırılacağını da bilmek gerekir. Tam bu noktada felaket kurtarma stratejisi devreye girer. Mesele yalnızca yedek almak değildir. Esas konu, bir kesinti anında hangi servislerin önce devreye alınacağı, ne kadar veri kaybının tolere edilebileceği ve bu sürecin nasıl bir teknik tasarımla yönetileceğidir.
Kurumsal yapılarda en sık yapılan hatalardan biri, yedekleme ile felaket kurtarmayı aynı şey sanmaktır. Oysa gece 02:00’de alınan bir veritabanı yedeği tek başına yeterli olmayabilir. Saat 14:00’te yaşanan bir olayda 12 saatlik veri kaybı kabul edilemezse mimarinin farklı kurgulanması gerekir. Bu yazıda, iş sürekliliğini koruyan bulut mimarisi için uygulanabilir bir çerçeveyi ele alacağız: hedeflerin belirlenmesi, yedekleme katmanları, replikasyon modeli, kurtarma senaryoları, test disiplini ve operasyonel sahiplik.
Felaket kurtarma stratejisi tam olarak neyi kapsar?
Felaket kurtarma stratejisi; uygulama, veritabanı, dosya depolama, ağ bileşenleri, kimlik doğrulama, izleme ve altyapı tanımlarının bir olay sonrasında yeniden devreye alınmasını planlayan teknik ve operasyonel çerçevedir. Buradaki amaç yalnızca veriyi geri getirmek değil, iş açısından kritik fonksiyonları kabul edilebilir süre içinde yeniden çalıştırmaktır.
Örneğin bir e-ticaret şirketinde ürün kataloğu 15 dakika içinde açılmalı, sipariş akışı 30 dakika içinde geri gelmeli, raporlama paneli ise 8 saat bekleyebilmelidir. Bu ayrım yapılmadığında tüm sistemlere aynı yatırım yapılır. Ortaya da yüksek maliyet ve düşük netlik çıkar.
Yedekleme ile felaket kurtarma arasındaki fark
- Yedekleme, verinin belirli aralıklarla kopyalanmasıdır.
- Felaket kurtarma, servislerin hangi sırayla, hangi ortamda, hangi veri noktasıyla ayağa kalkacağını tanımlar.
- İş sürekliliği ise bu planın insan, süreç ve iletişim tarafını da kapsar.
Basit bir senaryo düşünelim: Haftalık tam yedek ve günlük artımlı yedek alan bir sisteminiz var. Sunucu şifreleme saldırısına uğradıysa dosyaları geri yükleyebilirsiniz. Ancak DNS yönlendirmesi, uygulama sırları, container registry erişimi veya mesaj kuyruğu yapılandırması belgelenmemişse sistem saatler boyunca kapalı kalabilir.
İlk adım: RPO ve RTO hedeflerini sayıyla belirlemek
Sağlam bir plan, iki temel metrik olmadan kurulamaz: RPO ve RTO. RPO, kabul edilebilir veri kaybı penceresidir. RTO ise sistemin yeniden çalışır hale gelmesi için izin verilen süredir.
Somut bir örnek verelim:
- Müşteri siparişleri için RPO: 5 dakika
- Müşteri siparişleri için RTO: 30 dakika
- İç raporlama modülü için RPO: 24 saat
- İç raporlama modülü için RTO: 1 iş günü
Yalnızca bu iki satır bile mimari kararı değiştirir. RPO 5 dakika ise gece tek sefer yedek yeterli olmaz; sürekli ya da sık aralıklı replikasyon gerekir. RTO 30 dakika ise yedekten manuel kurulum yapmak yerine önceden hazır bir standby ortamına ihtiyaç duyabilirsiniz.
Pratikte her sistem için tek bir hedef belirlemek yerine servis bazlı tablo hazırlamak daha doğru olur. Ödeme, kimlik doğrulama, ERP entegrasyonu, dosya depolama ve log altyapısı aynı kritik seviyede değildir. Kritik servis sayısı 4 ise her biri için ayrı RPO/RTO tanımı yapılmalıdır.
Bulutta kullanılan felaket kurtarma mimarileri
Bulut platformları, felaket kurtarma için esnek modeller sunar. Doğru modeli seçmek çoğu zaman bütçe ile tolerans seviyesi arasındaki dengeyi kurmak anlamına gelir. Öne çıkan dört yaygın yaklaşım vardır.
1) Backup and Restore
En temel modeldir. Veriler obje depolamaya, veritabanı snapshot alanına ya da uzun süreli yedek kasasına alınır. Olay anında yeni altyapı kurulur ve yedek geri yüklenir. Maliyet görece düşüktür. RTO ise genellikle daha uzundur; birkaç saat hatta daha fazlası söz konusu olabilir.
Küçük ölçekli bir B2B portal için bu model yeterli olabilir. Örneğin günlük 20 bin kayıt üreten ve gece çalışmayan bir iç operasyon sistemi, 4-8 saatlik RTO ile yönetilebilir.
2) Pilot Light
Kritik bileşenlerin minimum çalışan kopyası ikinci bölgede veya ayrı hesapta hazır tutulur. Felaket anında uygulama katmanı ölçeklendirilir. Veritabanı replikasyonu devam eder, ancak tüm uygulama sunucuları sürekli tam kapasite açık tutulmaz.
Bu yaklaşım, maliyet ile hız arasında dengeli bir model sunar. Bir SaaS ürününde veritabanı ve kimlik altyapısı sürekli hazır kalırken, uygulama pod sayısı ihtiyaç anında 0’dan 6’ya çıkarılabilir.
3) Warm Standby
İkinci ortam aktiftir, ancak düşük kapasiteyle çalışır. Trafik yönlendirmesiyle hızlı geçiş yapılır. RTO genellikle dakikalar seviyesine iner. Örneğin 2 node’lu bir uygulama kümesi ana bölgede tam yük taşırken, yedek bölgede 1 node düşük trafik için hazır bekleyebilir.
4) Multi-site / Active-Active
En yüksek erişilebilirliği hedefleyen modeldir. Trafik aynı anda birden fazla bölgede işlenir. Karmaşıklık ise ciddi ölçüde artar. Veri tutarlılığı, oturum yönetimi, kuyruklar ve yazma çatışmaları dikkatli ele alınmalıdır. Her sistem için gerekli değildir. Çoğu işletme için active-active yerine iyi tasarlanmış warm standby daha gerçekçi bir seçenektir.
Yedekleme tasarımında sadece “kaç kopya” değil, “geri yükleme süresi” de önemlidir
Yedekleme politikasında sık geçen 3-2-1 prensibi faydalıdır: verinin en az 3 kopyası, 2 farklı ortam, 1 tanesi ana sistemden bağımsız bir lokasyonda. Ancak bu ilke tek başına yeterli değildir. Çünkü yedeğin var olması ile gerçekten işe yarar olması aynı şey değildir.
Dikkat edilmesi gereken teknik noktalar şunlardır:
- Sürümleme: Obje depolamada versioning açık olmalı.
- Immutable backup: Belirli süre silinemez yedek, fidye yazılımı riskini azaltır.
- Şifreleme: Hem aktarımda hem beklemede anahtar yönetimi net olmalı.
- Saklama politikası: 7 gün, 30 gün, 90 gün gibi katmanlı retention tanımlanmalı.
- Geri yükleme testi: En az ayda 1 kez örnek veri setiyle doğrulanmalı.
Örneğin 500 GB veritabanı snapshot’ını geri açmak 10 dakika sürebilir; uygulama indekslerinin yeniden oluşturulması ise 45 dakika alabilir. Kâğıt üzerinde kısa görünen bir plan, uygulamada RTO hedefini aşabilir. Bu yüzden testte yalnızca yedek dosyasının açılması değil, kullanıcı işleminin başarıyla tamamlanması esas alınmalıdır.
Bulut mimarisinde izole hesap ve çoklu bölge yaklaşımı
Felaket kurtarma yalnızca teknik arızalar için tasarlanmaz. Hatalı silme, yanlış deployment, kimlik bilgisi ele geçirilmesi ve hesap seviyesinde erişim kaybı gibi riskler de hesaba katılmalıdır. Bu noktada izole yapı öne çıkar.
İyi bir pratik, üretim ortamı ile yedek kasasını aynı hesapta tutmamaktır. Ayrı bulut hesabı, ayrı erişim politikası ve mümkünse ayrı kimlik sınırı kullanılmalıdır. Çünkü saldırgan ana hesaba eriştiğinde hem sistemleri hem de yedekleri silebiliyorsa plan yalnızca kâğıt üzerinde kalır.
Çoklu bölge kullanımı da benzer biçimde kritik olabilir. Tek bölgede çalışan bir uygulama için ikinci bölgede altyapı tanımlarının hazır bulunması, DNS failover sürelerini ciddi şekilde düşürür. Örneğin altyapıyı Infrastructure as Code ile tanımlayan ekipler, aynı stack’i yeni bölgede 20-30 dakika içinde oluşturabilir. El ile kurulum yapıldığında bu süre çok daha belirsiz hale gelir.
Basit bir IaC örneği
resource "aws_db_instance" "primary" {
identifier = "app-db-prod"
backup_retention_period = 7
multi_az = true
}
Bu kısa örnek tek başına felaket kurtarma sağlamaz. Yine de kritik bir noktayı gösterir: altyapı tanımı kod olarak tutulduğunda yeniden kurulum tekrarlanabilir hale gelir. Aynı mantık ağ, güvenlik grupları, container servisleri ve sır yönetimi için de geçerlidir.
Uygulama ve veri katmanında senaryo bazlı plan kurmak gerekir
Bir felaket kurtarma stratejisi, “olursa bakarız” yaklaşımıyla ayakta kalamaz. En az 4-5 net senaryo yazılmalıdır. Her senaryoda tetikleyici olay, etkilenen sistemler, karar verici kişi, failover adımı, doğrulama kontrolü ve geri dönüş planı yer almalıdır.
Örnek senaryolar:
- Veritabanında mantıksal veri silinmesi
- Bulut bölgesinde uzun süreli erişim kesintisi
- Yanlış uygulama dağıtımı sonrası servis çökmesi
- Ransomware nedeniyle dosya paylaşım alanının bozulması
- API sağlayıcısının 6 saatlik kesintisi
Bu senaryoların çözümü aynı değildir. Mantıksal veri silinmesinde point-in-time recovery gerekir. Bölgesel kesintide standby bölgeye trafik aktarımı gerekir. Üçüncü taraf API kesintisinde ise kuyruklama, retry ve degraded mode tasarımı öne çıkar. Yani felaket kurtarma yalnızca altyapı problemi değildir; uygulamanın nasıl davranacağı da planın parçasıdır.
Test edilmeyen plan, plan sayılmaz
Pek çok ekip dokümantasyon hazırlayıp işi tamamladığını sanır. Oysa gerçek kalite, test anında ortaya çıkar. Yılda 1 kez masa başı tatbikat yapmak başlangıç için faydalı olabilir, ancak üretim benzeri ortamda teknik prova yapılmadan ölçülebilir güven oluşmaz.
En azından şu disiplin kurulmalıdır:
- Her çeyrekte 1 kurtarma tatbikatı
- Her ay örnek geri yükleme doğrulaması
- Her büyük mimari değişiklikten sonra plan güncellemesi
- Her testte gerçekleşen RTO ve veri kaybı ölçümü
Örneğin hedef RTO 30 dakika ise tatbikatta 47 dakika çıkması değerlidir. Çünkü sorun canlı kesintide değil, kontrollü ortamda görülmüştür. Eksik IAM yetkisi, unutulmuş environment variable ya da manuel adım bağımlılığı gibi noktalar bu testlerde netleşir.
Operasyonel sahiplik ve dokümantasyon yapısı
Başarılı bir mimari, doğru sahiplikle işler. Kimin karar vereceği belli değilse teknik hazırlık da zayıf kalır. En az şu başlıklar tanımlanmalıdır: olay komutanı, altyapı sorumlusu, veritabanı sorumlusu, uygulama doğrulama sorumlusu, iş birimi onay kişisi.
Dokümanda 1 sayfalık hızlı aksiyon özeti bulunması da faydalıdır. Uzun runbook dosyaları değerli olsa da kriz anında ilk 10 dakikada kısa bir kontrol listesine ihtiyaç duyulur. Örnek olarak: “DNS TTL 60 saniye mi?”, “standby veritabanı replication lag kaç saniye?”, “son geri yükleme testi tarihi nedir?” gibi maddeler hızlı karar alınmasını sağlar.
Özetle, etkili bir felaket kurtarma stratejisi; yedekleme, replikasyon, otomasyon, erişim izolasyonu ve düzenli testin birleşimidir. Her işletmenin ihtiyacı aynı değildir. Kritik olan, hedefleri ölçülebilir biçimde tanımlamak ve bu hedefleri bulut mimarisine somut şekilde yansıtmaktır. İyi kurgulanmış bir plan, kriz anında panik yerine öngörü sağlar; iş sürekliliği de tam bu noktada korunur.
