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
evet ama işlem logları tutmak bir şey onları gerçekten KAC dakikada geri açabilmek başka
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
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
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
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