Bulut Uygulamalarında Disaster Recovery Planı Hazırlama
Bulut uygulamalarında veri kaybı, hizmet kesintisi veya siber saldırılar yaşanabilir. Disaster Recovery (DR) planı, bu durumlardan hızlı kurtulmayı sağlar. İki önemli metrik vardır:
- RTO (Recovery Time Objective): Sistemi ne kadar sürede geri açacaksın?
- RPO (Recovery Point Objective): Maksimum kaç dakikalık veri kaybını tolere edebilirsin?
Önce hangi uygulamalar ve veriler en kritik olduğunu belirle. Bir e-ticaret sitesinin veritabanı, web sunucusu ve ödeme sistemi birinci önceliktir.
1# AWS'de kritik kaynakları etiketleme2aws ec2 create-tags \3--resources i-0123456789abcdef0 \4--tags Key=Criticality,Value=High Key=DR-Priority,Value=1Çıktı: Başarıyla etiketlenir, sonra bu etiketlere göre yedekleme politikası oluşturabilirsin.
Üç yaygın strateji vardır:
- Sıcak Yedek: Backup bölgede her zaman açık (pahalı, RTO = dakikalar)
- Ilık Yedek: Kaynaklar kapalı ama hızlı başlatılabilir (orta maliyet, RTO = saatler)
- Soğuk Yedek: Sadece snapshot/backup (ucuz, RTO = günler)
AWS Route 53 veya Azure Traffic Manager kullanarak sağlık kontrolü ve otomatik yönlendirme yap:
1# AWS Route 53'te failover kuralı2aws route53 change-resource-record-sets \3--hosted-zone-id Z1234567890ABC \4--change-batch '{5"Changes": [{6"Action": "CREATE",7"ResourceRecordSet": {8"Name": "app.example.com",9"Type": "A",10"SetIdentifier": "Primary",11"Failover": "PRIMARY",12"TTL": 60,13"ResourceRecords": [{"Value": "10.0.1.100"}],14"HealthCheckId": "abc123def456"15}16}]17}'Çıktı: Primary sunucu sağlıksızsa, Route 53 otomatik olarak Secondary'ye yönlendirir.
DR planı kağıt üzerinde kalırsa işe yaramaz. Ayda bir kez failover testi yap:
1# AWS'de snapshot'tan test ortamı oluştur2aws ec2 create-image \3--instance-id i-0123456789abcdef0 \4--name "dr-test-$(date +%Y%m%d)"DR planı = Kritik kaynakları tanımla Yedekleme stratejisi seç Failover otomatikleştir Düzenli test et.
Bu döngü sayesinde felaket anında hizmetini dakikalar içinde geri açarsın. (IAM Politikasında En Az Yetki Prensibi: Adım Adım Uygulama)
5 yorum
RTO ve RPO kavramları iyi açıklanmış ama e ticaret örneğinde ödeme sistemi aslında banka tarafında çalışıyor senin veritabanında tutman gereken şey
doğru ama e ticaret sitesinin kendi tarafında işlem logları sipariş geçmişi vs tutması gerekiyor bunlar kaybolursa müşteri şikayet eder banka yanında da yedek tutmak lazım tabi
evet ama işlem logları tutmak bir şey onları gerçekten KAC dakikada geri açabilmek başka
işte bu yüzden RTOyu gerçekçi belirlemeye yarar logları tutmak kolay ama bir saldırı olsa mesela bütün sunucular down gelirse o backupı aktif etmek 2 saate çıkabiliyor o zaman 5 dakikalık RPOnun anlamı kalmıyor
aynen işte bu tam da problem kağıt üzerinde 5 dakika yazıyor ama pratikte backupı açmak veritabanı senkronize etmek DNS güncelleme filan 2 saat tutuyor sonra o 5 dakikalık RPO ne işe yarar ki