Felaket Kurtarma Stratejileri: Yedek Site Türleri ve Seçim Kriterleri

Tarafındankomut
0 Comments

Bir felaketle karşılaştığınızda, o ana kadar ne kadar hazır olduğunuz her şeyi belirler. Sunucular çöker, veri merkezleri yanar, doğal afetler olur ve siz o an “keşke planımız olsaydı” demek istemezsiniz. Felaket kurtarma (Disaster Recovery – DR) stratejileri, tam da bu noktada devreye girer. Bu yazıda yedek site türlerini, hangisinin hangi senaryoya uygun olduğunu ve bunları nasıl uygulayacağınızı gerçek dünya örnekleriyle ele alacağız.

Felaket Kurtarma’nın Temel Kavramları

Yedek site türlerine geçmeden önce iki kritik kavramı netleştirmemiz gerekiyor. Bunlar olmadan herhangi bir DR planı eksik kalır.

RTO (Recovery Time Objective): Bir felaket sonrasında sistemlerin ne kadar sürede ayağa kalkması gerektiğini tanımlar. “Maksimum 4 saat içinde sistemler çalışmalı” diyorsanız, RTO’nuz 4 saattir.

RPO (Recovery Point Objective): Veri kaybını ne kadar tolere edebileceğinizi belirtir. “Son 1 saatlik veri kaybı kabul edilebilir” diyorsanız, RPO’nuz 1 saattir.

Bu iki değer, hangi yedek site türünü seçeceğinizi doğrudan etkiler. RTO ve RPO’nuz ne kadar düşükse, o kadar fazla yatırım yapmanız gerekir. Bu basit bir denklem ama çoğu zaman görmezden gelinen bir gerçek.

# RTO ve RPO değerlerinizi bir konfigürasyon dosyasında tutmak iyi bir alışkanlıktır
cat /etc/dr-config/sla-requirements.conf
# RTO_HOURS=4
# RPO_HOURS=1
# CRITICALITY_LEVEL=HIGH
# PRIMARY_SITE=datacenter-istanbul
# DR_SITE=datacenter-ankara

Yedek Site Türleri

Yedek siteler genel olarak üç ana kategoriye ayrılır: Cold Site, Warm Site ve Hot Site. Bunlara ek olarak günümüzde Cloud DR ve Active-Active gibi modern yaklaşımlar da var. Her birini ayrıntılı inceleyelim.

Cold Site (Soğuk Site)

Cold site, en temel ve en ucuz DR seçeneğidir. Temelde sadece fiziksel bir mekandan ibarettir. Elektrik var, internet bağlantısı var, belki biraz network altyapısı var, ama çalışır durumda sunucu yok.

Bir felakette önce donanım temin etmeniz, sonra kurulum yapmanız, ardından yedeklerden restore etmeniz gerekir. Bu süreç günler, hatta haftalar alabilir.

Cold Site’ın avantajları:

  • Maliyet son derece düşük
  • Bakım neredeyse yok
  • Küçük işletmeler için makul bir başlangıç noktası

Cold Site’ın dezavantajları:

  • RTO genellikle 24-72 saat veya daha uzun
  • RPO yedek sıklığınıza bağlı
  • Manuel süreçler hata riskini artırır
  • Felaket anında donanım bulmak zorlaşabilir

Cold site için kritik olan nokta, yedeklerinizin düzenli ve erişilebilir olmasıdır. Bantlardan restore yapıyorsanız, bantların gerçekten okunabilir olduğundan emin olmalısınız.

#!/bin/bash
# Cold site için offline yedek doğrulama scripti
# Bu scripti her hafta çalıştırın

BACKUP_DIR="/mnt/backup-tapes"
LOG_FILE="/var/log/backup-verification.log"
DATE=$(date +%Y%m%d)

echo "[$DATE] Yedek doğrulama başlıyor..." >> $LOG_FILE

# Son yedeğin bütünlüğünü kontrol et
for backup_file in $BACKUP_DIR/*.tar.gz; do
    if tar -tzf "$backup_file" > /dev/null 2>&1; then
        echo "[$DATE] OK: $backup_file" >> $LOG_FILE
    else
        echo "[$DATE] HATA: $backup_file bozuk!" >> $LOG_FILE
        # Uyarı gönder
        mail -s "KRITIK: Yedek dosyasi bozuk - $backup_file" [email protected] < /dev/null
    fi
done

echo "[$DATE] Doğrulama tamamlandı." >> $LOG_FILE

Warm Site (Ilık Site)

Warm site, cold ve hot site arasında denge kuran en yaygın tercih edilen seçenektir. Donanım hazır ve çalışır durumda, yazılımlar kurulu, ama veriler güncel değil. Verilerinizi periyodik olarak senkronize edersiniz, genellikle saatlik veya günlük bazda.

Bir felakette sistemi ayağa kaldırmak için son yedeği restore etmeniz ve bazı manuel adımlar atmanız gerekir. Bu süreç genellikle 4-24 saat arasında tamamlanır.

Warm Site için tipik bir senaryo: İstanbul’daki birincil veri merkeziniz sel nedeniyle devre dışı kaldı. Ankara’daki warm site’ınıza bağlanıyorsunuz, dün gece saat 02:00’deki yedekten restore yapıyorsunuz ve 8 saat içinde sistemler ayakta. Bu süreçte dün gece 02:00’den bu yana olan veriler kayboluyor. RPO’nuz 24 saat ise bu kabul edilebilir.

#!/bin/bash
# Warm site'a periyodik veri senkronizasyonu
# Crontab: 0 */4 * * * /usr/local/bin/warm-site-sync.sh

PRIMARY_DB="mysql-primary.istanbul.sirket.com"
WARM_DB="mysql-warm.ankara.sirket.com"
BACKUP_PATH="/var/backups/mysql"
DATE=$(date +%Y%m%d_%H%M)
LOG="/var/log/dr-sync.log"

echo "[$DATE] Warm site senkronizasyonu başlıyor..." >> $LOG

# MySQL dump al
mysqldump --all-databases 
    --single-transaction 
    --flush-logs 
    --master-data=2 
    -u backup_user 
    -p$(cat /etc/mysql/backup.passwd) > $BACKUP_PATH/full_backup_$DATE.sql

if [ $? -eq 0 ]; then
    echo "[$DATE] MySQL dump alındı." >> $LOG
    
    # Warm site'a transfer et
    rsync -avz --progress 
        $BACKUP_PATH/full_backup_$DATE.sql 
        backup@$WARM_DB:/var/backups/incoming/
    
    echo "[$DATE] Transfer tamamlandı." >> $LOG
else
    echo "[$DATE] HATA: MySQL dump başarısız!" >> $LOG
    exit 1
fi

# Eski yedekleri temizle (7 günden eskiler)
find $BACKUP_PATH -name "full_backup_*.sql" -mtime +7 -delete

Hot Site (Sıcak Site)

Hot site, neredeyse gerçek zamanlı veri senkronizasyonuyla çalışan yedek sitedir. Birincil sitenizle sürekli senkron haldedir, tüm sistemler ayakta ve devreye almak için dakikalar yeterlidir.

Bu en pahalı seçenek, ama kritik sistemler için kaçınılmaz. Bankalar, hastaneler, e-ticaret platformları genellikle hot site kullanır.

Hot site özellikleri:

  • RTO: Genellikle 15 dakika ile 2 saat
  • RPO: Sıfır ya da birkaç saniye
  • Sürekli replikasyon
  • Düzenli failover testleri zorunlu
#!/bin/bash
# Hot site için MySQL Master-Slave replikasyon durumu kontrolü
# Crontab: */5 * * * * /usr/local/bin/check-replication.sh

SLAVE_HOST="mysql-hot.ankara.sirket.com"
ALERT_EMAIL="[email protected]"
MAX_LAG_SECONDS=30

# Slave replikasyon durumunu kontrol et
SLAVE_STATUS=$(mysql -h $SLAVE_HOST -u monitor 
    -p$(cat /etc/mysql/monitor.passwd) 
    -e "SHOW SLAVE STATUSG" 2>/dev/null)

IO_RUNNING=$(echo "$SLAVE_STATUS" | grep "Slave_IO_Running" | awk '{print $2}')
SQL_RUNNING=$(echo "$SLAVE_STATUS" | grep "Slave_SQL_Running" | awk '{print $2}')
LAG=$(echo "$SLAVE_STATUS" | grep "Seconds_Behind_Master" | awk '{print $2}')

if [ "$IO_RUNNING" != "Yes" ] || [ "$SQL_RUNNING" != "Yes" ]; then
    echo "KRITIK: Replikasyon durdu! IO: $IO_RUNNING, SQL: $SQL_RUNNING" | 
        mail -s "DR ALARM: Replikasyon hatası" $ALERT_EMAIL
elif [ "$LAG" -gt "$MAX_LAG_SECONDS" ]; then
    echo "UYARI: Replikasyon gecikmesi ${LAG} saniye!" | 
        mail -s "DR UYARI: Replikasyon gecikmesi" $ALERT_EMAIL
else
    echo "$(date): Replikasyon sağlıklı. Gecikme: ${LAG}s" >> /var/log/replication-check.log
fi

Active-Active Yapı

Active-Active, hot site’ın bir adım ötesidir. Artık “birincil” ve “yedek” kavramı yoktur. Her iki site de eş zamanlı olarak üretim trafiği alır. Bir site düşerse, diğeri tüm yükü üstlenir.

Bu yapı genellikle load balancer ve DNS tabanlı trafik yönetimiyle kurulur.

# Keepalived ile Active-Active benzeri yapı için örnek kontrol scripti
# /etc/keepalived/check_service.sh

#!/bin/bash
SERVICE_URL="http://localhost:8080/health"
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" $SERVICE_URL --max-time 5)

if [ "$HTTP_CODE" -eq 200 ]; then
    exit 0
else
    echo "$(date): Servis sağlıksız, HTTP kodu: $HTTP_CODE" >> /var/log/keepalived-check.log
    exit 1
fi
# DNS tabanlı failover için basit bir kontrol ve güncelleme scripti
#!/bin/bash
# /usr/local/bin/dns-failover.sh

PRIMARY_IP="1.2.3.4"
SECONDARY_IP="5.6.7.8"
DOMAIN="app.sirket.com"
CLOUDFLARE_TOKEN=$(cat /etc/cloudflare/token)
ZONE_ID=$(cat /etc/cloudflare/zone_id)
RECORD_ID=$(cat /etc/cloudflare/record_id)

# Primary site'ı kontrol et
if ! curl -sf --max-time 10 "http://$PRIMARY_IP/health" > /dev/null; then
    echo "$(date): Primary site down! Failover başlatılıyor..." >> /var/log/dns-failover.log
    
    # Cloudflare DNS'i güncelle
    curl -s -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" 
        -H "Authorization: Bearer $CLOUDFLARE_TOKEN" 
        -H "Content-Type: application/json" 
        --data "{"type":"A","name":"$DOMAIN","content":"$SECONDARY_IP","ttl":60}" 
        >> /var/log/dns-failover.log
    
    # Uyarı gönder
    echo "Failover tamamlandı. $DOMAIN -> $SECONDARY_IP" | 
        mail -s "KRITIK: DNS Failover gerçekleşti" [email protected]
fi

Cloud DR (Bulut Tabanlı Felaket Kurtarma)

Günümüzde birçok işletme on-premises birincil sitesi için cloud’u DR platformu olarak kullanıyor. Bu yaklaşım, warm site benzeri bir koruma sağlarken sermaye harcamasını minimize eder. AWS, Azure ve GCP’nin hepsi bu senaryoya yönelik çözümler sunuyor.

Cloud DR’ın avantajları:

  • Sermaye yatırımı yok, operasyonel gider modeli
  • Coğrafi esneklik
  • Ölçeklenebilirlik
  • Otomatik failover imkanı

Cloud DR’ın dezavantajları:

  • Sürekli bant genişliği maliyeti
  • Veri egemenliği soruları
  • Karmaşık ağ yapılandırması
  • Cloud lock-in riski
#!/bin/bash
# AWS S3'e düzenli yedek ve lifecycle yönetimi
# Bu script kritik dosyaları S3'e gönderir ve lifecycle politikasını uygular

AWS_BUCKET="sirket-dr-yedekler"
AWS_REGION="eu-central-1"
SOURCE_DIR="/var/data/kritik"
DATE=$(date +%Y/%m/%d)
LOG="/var/log/cloud-dr-backup.log"

echo "$(date): Cloud DR yedekleme başlıyor..." >> $LOG

# Artımlı yedek al ve S3'e gönder
aws s3 sync $SOURCE_DIR 
    s3://$AWS_BUCKET/on-premises/$DATE/ 
    --region $AWS_REGION 
    --storage-class STANDARD_IA 
    --sse AES256 
    --delete 
    --exclude "*.tmp" 
    --exclude "*.log" >> $LOG 2>&1

if [ $? -eq 0 ]; then
    echo "$(date): S3 sync başarılı." >> $LOG
    
    # Yedek boyutunu raporla
    BACKUP_SIZE=$(aws s3 ls s3://$AWS_BUCKET/on-premises/$DATE/ 
        --recursive --human-readable --summarize 2>/dev/null | 
        grep "Total Size" | awk '{print $3, $4}')
    
    echo "$(date): Toplam yedek boyutu: $BACKUP_SIZE" >> $LOG
else
    echo "$(date): HATA: S3 sync başarısız!" >> $LOG
    exit 1
fi

# 90 günden eski yedekleri Glacier'a taşı (lifecycle policy ile otomatik yapılır)
# Ama manuel kontrol olarak eski tarihleri listele
aws s3 ls s3://$AWS_BUCKET/on-premises/ --recursive | 
    awk '{print $1}' | sort -u | head -5 >> $LOG

DR Planı Test Senaryoları

Bir DR planının sadece kağıt üzerinde iyi görünmesi yetmez. Test edilmemiş bir DR planı, hiç planın olmadığından farklı değildir. Bunu çok sayıda kişi acı tecrübeyle öğrendi.

Masa Başı Testleri (Tabletop Exercise)

Gerçek bir failover yapmadan, ekibin bir araya gelip felaket senaryosunu adım adım konuştuğu tatbikat türüdür. Ucuz ve risksizdir. Her 6 ayda bir yapılmalıdır.

Tipik sorular:

  • “Veri merkeziyle tüm iletişim kesildi. İlk 15 dakikada ne yapıyoruz?”
  • “DR sorumlusu tatilde. Kim devreye giriyor?”
  • “Yedekler bozuk çıkarsa alternatif planımız ne?”

Kısmi Failover Testi

Üretim ortamını etkilemeden belirli sistemlerin DR’a geçirilip geçirilemediğini test edersiniz. Örneğin, sadece raporlama sunucusunu DR site’a taşıyıp test edebilirsiniz.

#!/bin/bash
# DR test ortamı hazırlık scripti
# Üretim verilerini anonimleştirilmiş şekilde test ortamına kopyalar

SOURCE_DB="production-db.istanbul.sirket.com"
DR_TEST_DB="dr-test.ankara.sirket.com"
LOG="/var/log/dr-test-prep.log"

echo "$(date): DR test ortamı hazırlanıyor..." >> $LOG

# Üretim veritabanından dump al
mysqldump -h $SOURCE_DB 
    -u readonly_user 
    -p$(cat /etc/mysql/readonly.passwd) 
    --single-transaction 
    production_db > /tmp/prod_snapshot.sql

# Hassas verileri anonimleştir
sed -i "s/'[0-9]{10,16}'/'XXXX-XXXX-XXXX-XXXX'/g" /tmp/prod_snapshot.sql
sed -i "s/[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}/[email protected]/g" /tmp/prod_snapshot.sql

# DR test sunucusuna yükle
mysql -h $DR_TEST_DB 
    -u dr_admin 
    -p$(cat /etc/mysql/dr_admin.passwd) 
    dr_test_db < /tmp/prod_snapshot.sql

echo "$(date): DR test ortamı hazır." >> $LOG

# Temizlik
rm -f /tmp/prod_snapshot.sql

Tam Failover Testi

En gerçekçi test türüdür. Tüm sistemleri DR site’a geçirip bir süre oradan çalışırsınız, ardından geri dönersiniz. Bu test yılda bir kez yapılmalı, bakım penceresi planlanmalı ve üst yönetim onayı alınmalıdır.

Tam failover testinde kontrol etmeniz gerekenler:

  • RTO hedefine ulaşıldı mı?
  • RPO hedefine ulaşıldı mı?
  • Hangi servisler beklenmedik sorun çıkardı?
  • Failback süreci ne kadar sürdü?
  • Dokümantasyon güncel miydi?

DR Planınızda Olması Gerekenler

Teknik altyapı kadar önemli olan DR dokümantasyonudur. Aşağıdaki bileşenler her DR planında bulunmalıdır.

İletişim planı:

  • Kimin kimi aradığı, hangi sırayla
  • Yönetim, müşteriler ve iş ortaklarına bildirim prosedürleri
  • Telefon listelerinin offline kopyası

Teknik prosedürler:

  • Her sistem için adım adım failover talimatları
  • Şifre ve erişim bilgilerinin güvenli yeri
  • Vendor destek numaraları

Önceliklendirme:

  • Hangi sistemler önce ayağa kalkar?
  • Hangi uygulamalar kritik, hangileri ertelenebilir?

Geri dönüş planı (Failback):

  • Birincil siteye nasıl dönülür?
  • Veri tutarlılığı nasıl sağlanır?
#!/bin/bash
# Sistem önceliklendirme ve failover sırası kontrolü
# Bu script, DR sırasında hangi servislerin hangi sırada ayağa kalkacağını yönetir

SERVICES_FILE="/etc/dr-config/service-priorities.conf"
DR_LOG="/var/log/dr-failover.log"

echo "$(date): DR Failover başlatıldı" >> $DR_LOG
echo "$(date): Operatör: $(whoami)" >> $DR_LOG

# Servis öncelik dosyasını oku (format: PRIORITY:SERVICE_NAME:START_COMMAND)
# Örnek içerik:
# 1:mysql:systemctl start mysql
# 2:redis:systemctl start redis
# 3:nginx:systemctl start nginx
# 4:app-server:systemctl start app-service

while IFS=':' read -r priority service command; do
    echo "$(date): [$priority] $service başlatılıyor..." >> $DR_LOG
    
    eval $command
    
    if [ $? -eq 0 ]; then
        echo "$(date): [$priority] $service başarıyla başlatıldı." >> $DR_LOG
    else
        echo "$(date): HATA: [$priority] $service başlatılamadı!" >> $DR_LOG
        echo "Kritik servis başlatılamadı: $service" | 
            mail -s "DR HATA: $service başlatılamadı" [email protected]
    fi
    
    # Her servis arasında kısa bekleme
    sleep 5
    
done < <(sort -t':' -k1 -n $SERVICES_FILE)

echo "$(date): Failover tamamlandı." >> $DR_LOG

Hangi Site Türünü Seçmeli?

Bu sorunun cevabı tamamen iş gereksinimlerinize bağlı.

Cold site seçin, eğer:

  • Bütçeniz çok kısıtlıysa
  • RTO’nuz 24 saat veya üzerindeyse
  • Kritik olmayan sistemleri koruyorsanız
  • Küçük ölçekli bir işletmeyseniz

Warm site seçin, eğer:

  • Makul bir bütçeniz varsa
  • RTO’nuz 4-24 saat arasındaysa
  • Çoğu kurumsal uygulama için bu yeterlidir
  • Hem maliyet hem koruma dengesini önemsiyorsanız

Hot site seçin, eğer:

  • Para ikincil öncelikte
  • RTO’nuz birkaç dakika ile 2 saat arasındaysa
  • RPO’nuz sıfıra yakınsa
  • Finans, sağlık, e-ticaret gibi kritik sektördeyseniz

Active-Active seçin, eğer:

  • Hem yüksek erişilebilirlik hem DR istiyorsanız
  • Yatırım yapmaya hazırsanız
  • Global ölçekte hizmet veriyorsanız

Sık Yapılan Hatalar

Yıllar içinde gördüğüm en yaygın DR hatalarını paylaşmadan geçemezdim.

Yedekleri test etmemek: “Yedekler alınıyor” deniyor ama restore hiç denenmemiş. Yedekler bozuk çıkıyor, DR anında fark ediliyor.

Dokümantasyonu güncel tutmamak: 6 ay önce yazılmış DR prosedürü artık geçersiz çünkü altyapı değişmiş.

Sadece veriyi düşünmek: Veritabanını yedekliyorsunuz ama uygulama konfigürasyonlarını, SSL sertifikalarını, lisans dosyalarını unutuyorsunuz.

İnsan faktörünü göz ardı etmek: Teknik plan mükemmel ama DR anında kimin ne yapacağı belli değil. İletişim planı yoksa teknik plan işe yaramaz.

Failback planı yapmamak: DR’a geçtiniz, güzel. Ama birincil siteye nasıl döneceksiniz? Bu da ayrı bir planlama gerektirir.

Sonuç

Felaket kurtarma stratejisi seçmek, salt teknik bir karar değil; iş sürekliliği, maliyet toleransı ve risk iştahını dengeleyen stratejik bir karardır. Cold site, warm site, hot site veya cloud DR, hepsinin doğru kullanım alanı var. Küçük bir muhasebe firması cold site ile hayatta kalabilir; ama online banka birkaç dakika bile downtime kaldıramaz.

En kötü DR planı, test edilmemiş DR planıdır. En iyi teknik çözüm bile düzenli tatbikatlar, güncel dokümantasyon ve eğitimli ekip olmadan kağıt üzerinde kalır. Bu yüzden planınızı yaptıktan sonra en az yılda bir kez gerçek failover testi yapın, masa başı tatbikatları düzenleyin ve her testten sonra öğrendiklerinizi dokümantasyona yansıtın.

Felaket anı, planı öğrenme zamanı değil; planı uygulama zamanıdır. O ana hazır olup olmadığınızı belirleyen şey, bugün yaptığınız çalışmalardır.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir