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ı etiketleme
2aws 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:

Reklam · TEST
AdSense Test ReklamıYazı arası (gönderi içi) · Yazı arası
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ştur
2aws 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)

Reklam · TEST
AdSense Test ReklamıGönderi altı · Görüntülü
konu hakkında tepkinizi verebilirsiniz
  • adlı kullanıcıya yanıt verdi
    ordinarybiri

    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

  • adlı kullanıcıya yanıt verdi
    kodkafasi

    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

  • adlı kullanıcıya yanıt verdi
    ordinarybiri

    evet ama işlem logları tutmak bir şey onları gerçekten KAC dakikada geri açabilmek başka

  • adlı kullanıcıya yanıt verdi
    kodkafasi

    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

  • ordinarybiri

    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