Pilot Light DR Stratejisi: Minimum Kaynakla Yedeklilik

Felaket kurtarma planlarından bahsederken çoğu sysadmin ya “her şeyi yedekle, her şeyi çalışır tut” aşırılığına ya da “nasılsa başımıza gelmez” rehavetine düşüyor. Pilot Light stratejisi tam bu ikisi arasında duruyor: minimum maliyet, maksimum hazırlık. Adı uçak motorlarındaki pilot alevi kavramından geliyor; küçük bir alev her zaman yanıyor, gerektiğinde tüm sistemi tutuşturuyor. Biz de bu yazıda bu stratejiyi gerçek dünya senaryolarıyla, elle tutulur komutlarla ve uygulanabilir bir çerçeveyle ele alacağız.

Pilot Light Nedir, Neden Tercih Edilir

DR stratejileri genellikle dört kategoride incelenir: Backup & Restore, Pilot Light, Warm Standby ve Active-Active. Her biri farklı RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) hedefleri sunar, buna bağlı olarak maliyetleri de ciddi ölçüde değişir.

Pilot Light’ta fikir şu: production ortamının kritik çekirdeği her zaman ayakta ve senkronize halde tutulur, ama tam kapasite çalışmaz. Örneğin veritabanı sunucusu canlıdır ve replikasyon aktiftir; ancak uygulama sunucuları kapalıdır ya da çok küçük instance boyutlarında beklemektedir. Felaket anında bu “pilot alevi” büyütürsün, uygulama katmanını ayağa kaldırırsın ve trafik yeni ortama yönlenir.

Neden tercih edilir:

Warm Standby veya Active-Active’e kıyasla %60-80 daha düşük DR maliyeti
Backup & Restore’a kıyasla çok daha kısa RTO (saatler yerine dakikalar)
Kritik verilerin gerçek zamanlı veya yakın gerçek zamanlı senkronizasyonu
Altyapı otomasyonuyla birleşince neredeyse tam otomatik failover mümkün

Tipik RTO hedefi 1-4 saat arası, RPO ise replikasyon gecikmesine göre dakikalar mertebesinde olur.

Mimariyi Anlamak: Neyi Açık Tutarsın, Neyi Kapalı

Pilot Light mimarisinin temeli “her zaman çalışması gereken minimum bileşenleri” doğru belirlemektir. Bunu yanlış yaparsan ya çok fazla kaynak harcarsın ya da failover sırasında sürprizlerle karşılaşırsın.

Her zaman çalışır halde tutulması gerekenler:

Veritabanı katmanı (replikasyon aktif, veriler güncel)
DNS ve load balancer konfigürasyonları (hazır ama pasif)
Kimlik doğrulama servisleri (LDAP, Active Directory replikası)
Temel network altyapısı (VPN, peering bağlantıları)
İzleme ve alerting sistemi

Felaket anında ayağa kaldırılacaklar:

Uygulama sunucuları
Web/proxy katmanı
Cache servisleri
Batch işlem sunucuları

Bu ayrımı net yapabilmek için önce bir bileşen haritası çıkarman gerekiyor. Aşağıdaki basit script, çalışan servislerin bağımlılıklarını listelemenize yardımcı olur:

#!/bin/bash
# Servis bağımlılık haritası çıkarma
# /usr/local/bin/service-dependency-map.sh

OUTPUT_FILE="/var/log/dr/service-map-$(date +%Y%m%d).txt"
mkdir -p /var/log/dr

echo "=== Servis Bağımlılık Haritası ===" > "$OUTPUT_FILE"
echo "Tarih: $(date)" >> "$OUTPUT_FILE"
echo "" >> "$OUTPUT_FILE"

# Aktif servisleri listele
echo "--- Aktif Sistemd Servisleri ---" >> "$OUTPUT_FILE"
systemctl list-units --type=service --state=running 
  --no-legend --plain | awk '{print $1}' | while read service; do
    echo "" >> "$OUTPUT_FILE"
    echo "Servis: $service" >> "$OUTPUT_FILE"
    systemctl show "$service" --property=After,Requires,Wants 
      --no-pager >> "$OUTPUT_FILE"
done

# Açık portları ve bağlantıları listele
echo "" >> "$OUTPUT_FILE"
echo "--- Aktif Dinleme Portları ---" >> "$OUTPUT_FILE"
ss -tlnp >> "$OUTPUT_FILE"

echo "Harita oluşturuldu: $OUTPUT_FILE"

Veritabanı Replikasyonu: DR’nin Kalbi

Pilot Light’ın en kritik parçası veritabanı replikasyonudur. Burada senkronizasyon kırılırsa tüm strateji çöker. MySQL/MariaDB için binary log tabanlı replikasyon kurulumunu adım adım görelim.

Primary sunucuda (production):

#!/bin/bash
# MySQL replikasyon hazırlık scripti - Primary taraf
# /usr/local/bin/setup-mysql-primary.sh

MYSQL_ROOT_PASS="your_secure_password"
REPL_USER="replicator"
REPL_PASS="repl_secure_pass_2024"
DR_SERVER_IP="10.20.0.50"  # DR datacenter IP

# my.cnf'e replikasyon parametreleri ekle
cat >> /etc/mysql/mysql.conf.d/mysqld.cnf << 'EOF'
[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = production_db
binlog_format = ROW
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
EOF

# MySQL'i yeniden başlat
systemctl restart mysql
sleep 5

# Replikasyon kullanıcısı oluştur
mysql -u root -p"$MYSQL_ROOT_PASS" << SQL
CREATE USER '${REPL_USER}'@'${DR_SERVER_IP}' 
  IDENTIFIED WITH mysql_native_password BY '${REPL_PASS}';
GRANT REPLICATION SLAVE ON *.* TO '${REPL_USER}'@'${DR_SERVER_IP}';
FLUSH PRIVILEGES;
SHOW MASTER STATUS;
SQL

echo "Primary kurulumu tamamlandı. Yukarıdaki MASTER STATUS değerlerini not alın."

DR sunucusunda (replica):

#!/bin/bash
# MySQL replikasyon kurulum scripti - Replica taraf
# /usr/local/bin/setup-mysql-replica.sh

MYSQL_ROOT_PASS="your_secure_password"
PRIMARY_HOST="10.10.0.50"    # Production IP
REPL_USER="replicator"
REPL_PASS="repl_secure_pass_2024"

# Dikkat: Bu değerleri primary'deki SHOW MASTER STATUS çıktısından alın
MASTER_LOG_FILE="mysql-bin.000001"
MASTER_LOG_POS=157

cat >> /etc/mysql/mysql.conf.d/mysqld.cnf << 'EOF'
[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
read_only = 1
EOF

systemctl restart mysql
sleep 5

mysql -u root -p"$MYSQL_ROOT_PASS" << SQL
CHANGE MASTER TO
  MASTER_HOST='${PRIMARY_HOST}',
  MASTER_USER='${REPL_USER}',
  MASTER_PASSWORD='${REPL_PASS}',
  MASTER_LOG_FILE='${MASTER_LOG_FILE}',
  MASTER_LOG_POS=${MASTER_LOG_POS};
START SLAVE;
SHOW SLAVE STATUSG
SQL

Replikasyon sağlıklı çalışıyor mu diye düzenli kontrol etmek zorundasın. “Kurdum, oldu” deyip bırakırsan felaket günü sürprizle karşılaşırsın.

#!/bin/bash
# Replikasyon sağlık kontrolü ve alerting
# /usr/local/bin/check-replication.sh
# Cron: */5 * * * * /usr/local/bin/check-replication.sh

ALERT_EMAIL="[email protected]"
MAX_LAG_SECONDS=30
MYSQL_ROOT_PASS="your_secure_password"

# Slave durumunu al
SLAVE_STATUS=$(mysql -u root -p"$MYSQL_ROOT_PASS" 
  -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}')

ALERT_MSG=""

if [ "$IO_RUNNING" != "Yes" ]; then
    ALERT_MSG+="KRITIK: Slave IO thread çalışmıyor!n"
fi

if [ "$SQL_RUNNING" != "Yes" ]; then
    ALERT_MSG+="KRITIK: Slave SQL thread çalışmıyor!n"
fi

if [ -n "$LAG" ] && [ "$LAG" != "NULL" ] && [ "$LAG" -gt "$MAX_LAG_SECONDS" ]; then
    ALERT_MSG+="UYARI: Replikasyon gecikmesi ${LAG} saniye (max: ${MAX_LAG_SECONDS}s)n"
fi

if [ -n "$ALERT_MSG" ]; then
    echo -e "DR Replikasyon Alarmınn$ALERT_MSGnZaman: $(date)" | 
      mail -s "[DR-ALARM] MySQL Replikasyon Sorunu" "$ALERT_EMAIL"
    logger -t dr-check "ALARM: $ALERT_MSG"
    exit 1
fi

logger -t dr-check "OK: Replikasyon sağlıklı, gecikme: ${LAG}s"
exit 0

Uygulama Sunucularını Hızlı Ayağa Kaldırma

Pilot Light’ta uygulama sunucuları ya tamamen kapalıdır ya da minimal bir snapshot/image olarak beklemektedir. Felaket anında bu sunucuları hızlıca ayağa kaldıracak otomasyona ihtiyacın var. Aşağıdaki örnek, KVM/libvirt ortamında hazırda bekleyen VM’leri başlatıp yapılandıran bir senaryoyu gösteriyor.

#!/bin/bash
# DR Failover - Uygulama sunucularını başlatma scripti
# /usr/local/bin/dr-failover-start.sh
# KULLANIM: ./dr-failover-start.sh [--confirm]

set -euo pipefail

LOG_FILE="/var/log/dr/failover-$(date +%Y%m%d-%H%M%S).log"
mkdir -p /var/log/dr

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a "$LOG_FILE"
}

# Onay kontrolü
if [ "${1:-}" != "--confirm" ]; then
    echo "UYARI: Bu script DR failover işlemini başlatır!"
    echo "Devam etmek için: $0 --confirm"
    exit 1
fi

log "DR Failover başlatılıyor..."

# Adım 1: DB replica'yı read-write moduna al
log "Adım 1: MySQL replica'yı primary'e promote ediyorum..."
mysql -u root -p"$MYSQL_ROOT_PASS" << 'SQL'
STOP SLAVE;
RESET SLAVE ALL;
SET GLOBAL read_only = 0;
SQL
log "MySQL promote tamamlandı."

# Adım 2: Uygulama VM'lerini başlat
APP_VMS=("app-server-01" "app-server-02" "app-server-03")

for vm in "${APP_VMS[@]}"; do
    log "VM başlatılıyor: $vm"
    if virsh domstate "$vm" | grep -q "shut off"; then
        virsh start "$vm"
        log "$vm başlatıldı."
    else
        log "$vm zaten çalışıyor veya farklı durumda: $(virsh domstate $vm)"
    fi
done

# Adım 3: VM'lerin ayağa kalkmasını bekle
log "VM'lerin hazır olması bekleniyor (120 saniye timeout)..."
for vm in "${APP_VMS[@]}"; do
    TIMEOUT=120
    ELAPSED=0
    while ! virsh domstate "$vm" | grep -q "running"; do
        sleep 5
        ELAPSED=$((ELAPSED + 5))
        if [ "$ELAPSED" -ge "$TIMEOUT" ]; then
            log "HATA: $vm $TIMEOUT saniyede başlamadı!"
            exit 1
        fi
    done
    log "$vm çalışıyor."
done

# Adım 4: DNS güncellemesi
log "Adım 4: DNS failover kaydı güncelleniyor..."
# Örnek: nsupdate ile DNS güncelleme
nsupdate -k /etc/dr/dns-update.key << EOF
server 10.20.0.1
zone sirket.com.
update delete app.sirket.com A
update add app.sirket.com 60 A 10.20.0.100
send
EOF

log "Failover tamamlandı. Log: $LOG_FILE"

Dosya Sistemi Senkronizasyonu

Veritabanı dışında dosya sistemi (uygulama dosyaları, konfigürasyonlar, kullanıcı yüklemeleri) de senkronize tutulmalı. Rsync tabanlı çözüm burada oldukça işe yarıyor.

#!/bin/bash
# Sürekli dosya senkronizasyon scripti
# /usr/local/bin/dr-file-sync.sh
# Cron: */15 * * * * /usr/local/bin/dr-file-sync.sh

DR_HOST="10.20.0.50"
DR_USER="dr-sync"
SSH_KEY="/etc/dr/dr-sync-key"
LOG_FILE="/var/log/dr/file-sync.log"

SYNC_PATHS=(
    "/var/www/uygulama"
    "/etc/nginx"
    "/etc/ssl/certs"
    "/opt/uygulama/config"
)

EXCLUDE_PATTERNS=(
    "--exclude=*.tmp"
    "--exclude=*.log"
    "--exclude=cache/"
    "--exclude=sessions/"
)

for path in "${SYNC_PATHS[@]}"; do
    if [ ! -d "$path" ]; then
        echo "$(date): UYARI - Dizin bulunamadı: $path" >> "$LOG_FILE"
        continue
    fi

    rsync -avz --delete 
        "${EXCLUDE_PATTERNS[@]}" 
        -e "ssh -i $SSH_KEY -o StrictHostKeyChecking=no -o ConnectTimeout=10" 
        "$path" 
        "${DR_USER}@${DR_HOST}:${path}" 
        >> "$LOG_FILE" 2>&1

    if [ $? -eq 0 ]; then
        echo "$(date): OK - $path senkronize edildi." >> "$LOG_FILE"
    else
        echo "$(date): HATA - $path senkronizasyonu başarısız!" >> "$LOG_FILE"
        # Alert gönder
        echo "DR dosya sync hatası: $path" | 
          mail -s "[DR-ALARM] Dosya Sync Hatası" [email protected]
    fi
done

DR Test Senaryosu: Yılda En Az İki Kez

“Test etmediğin DR planı yok hükmündedir.” Bu cümleyi bir yere yazıp ekranına yapıştır. Çoğu şirketin DR planı kağıt üzerinde mükemmeldir, ilk gerçek failover denemesinde çöker. Düzenli test yapmak için structured bir senaryo izlemek gerekiyor.

Test öncesi hazırlık kontrol listesi:

Replikasyon lag değerinin kabul edilebilir seviyede olduğunu doğrula
Tüm DR sunucularına SSH erişiminin çalıştığını test et
Failover scriptlerinin son versiyonunun DR sunucusunda mevcut olduğunu kontrol et
Paydaşlara planlı DR testi bildirimi gönder
Geri dönüş (failback) prosedürünü de hazırda tut

Test akışı – tipik senaryo:

T+0: Test başlangıcı, production’ı salt okunur moda al veya simüle et
T+5: Replikasyon durumunu son kez kontrol et, lag değerini kayıt altına al
T+10: Failover scriptini çalıştır
T+20: Uygulama sağlık kontrollerini yap, kritik fonksiyonları test et
T+30: RTO hedefini karşılayıp karşılamadığını değerlendir
T+45: Failback prosedürünü uygula
T+60: Sistemin normal haline döndüğünü doğrula, test raporunu hazırla

Test sonrasında mutlaka bir post-mortem raporu yaz. Neyin iyi çalıştığını, neyin beklediğin gibi olmadığını, bir sonraki teste kadar ne geliştireceğini kayıt altına al.

Maliyet Optimizasyonu: Pilot Light’ı Gerçekten Ucuz Tutmak

Pilot Light’ın avantajını yaşamak için kaynakları doğru boyutlandırmak şart. Birkaç pratik yol:

Her zaman açık bileşenler için minimum boyut kullanmak:

Veritabanı replica’sını production’la aynı boyutta tutmak zorunda değilsin. Replikasyon read-only yapıda olduğu sürece, yazma yoğunluğu olmadığından daha küçük bir sunucu yeterli olur. Failover anında sunucuyu büyütürsün.

Zamanlanmış boyut değiştirme:

#!/bin/bash
# DR veritabanı sunucusunu test günü büyütme / sonra küçültme
# Bulut ortamı için örnek (AWS CLI benzeri)
# /usr/local/bin/dr-resize.sh

ACTION="${1:-status}"
DR_INSTANCE_ID="i-0123456789abcdef0"

case "$ACTION" in
    "upgrade")
        echo "DR instance'ı failover moduna büyütülüyor..."
        # AWS örneği - kendi bulut sağlayıcınıza göre uyarlayın
        aws ec2 stop-instances --instance-ids "$DR_INSTANCE_ID"
        aws ec2 wait instance-stopped --instance-ids "$DR_INSTANCE_ID"
        aws ec2 modify-instance-attribute 
            --instance-id "$DR_INSTANCE_ID" 
            --instance-type '{"Value": "m5.2xlarge"}'
        aws ec2 start-instances --instance-ids "$DR_INSTANCE_ID"
        echo "Instance büyütüldü ve başlatıldı."
        ;;
    "downgrade")
        echo "DR instance'ı pilot light moduna küçültülüyor..."
        aws ec2 stop-instances --instance-ids "$DR_INSTANCE_ID"
        aws ec2 wait instance-stopped --instance-ids "$DR_INSTANCE_ID"
        aws ec2 modify-instance-attribute 
            --instance-id "$DR_INSTANCE_ID" 
            --instance-type '{"Value": "t3.medium"}'
        aws ec2 start-instances --instance-ids "$DR_INSTANCE_ID"
        echo "Instance küçültüldü ve başlatıldı."
        ;;
    "status")
        aws ec2 describe-instances 
            --instance-ids "$DR_INSTANCE_ID" 
            --query 'Reservations[0].Instances[0].{State:State.Name,Type:InstanceType}' 
            --output table
        ;;
esac

Pilot Light maliyet bileşenleri:

Veritabanı replica sunucusu: Production’ın %30-40’ı boyutunda, sürekli çalışır
Network/VPN bağlantısı: Sabit maliyet, kaçınılmaz
Depolama: Full replica, maliyet kaçınılmaz ama makul
Uygulama sunucuları: Kapalı veya minimum boyut, neredeyse sıfır maliyet
Toplam: Production maliyetinin yaklaşık %25-35’i

Gerçek Dünya Senaryosu: E-ticaret Sitesi Failover

Somutlaştıralım. Orta ölçekli bir e-ticaret sitesi düşün; günlük 50.000 işlem, anlık 500 eş zamanlı kullanıcı. Production ortamı: 3 uygulama sunucusu, 1 MySQL primary, 1 Redis, Nginx load balancer.

Pilot Light DR ortamı:

1 MySQL replica (küçük boyut, sürekli çalışır, replikasyon aktif)
1 Redis replica (minimal, sürekli çalışır, replikasyon aktif)
Uygulama sunucuları: Kapalı, hazır snapshot mevcut
Nginx konfigürasyonu: Hazır ama pasif

Felaket senaryosu: Production datacenter’ı güç arızası geçiriyor. Saat gece 02:30.

02:30: Monitoring alarm, otomatik alert geldi, nöbetçi sysadmin uyarıldı
02:35: Durum değerlendirmesi yapıldı, production erişilemez durumda, DR kararı verildi
02:36: dr-failover-start.sh --confirm komutu çalıştırıldı
02:38: MySQL promote tamamlandı, uygulama VM’leri başlatılıyor
02:45: Uygulama sunucuları ayağa kalktı, sağlık kontrolleri başladı
02:50: DNS failover tamamlandı, trafik DR’a yönlendi
02:52: İlk başarılı kullanıcı işlemi DR üzerinden geçti
Toplam süre: 22 dakika (RTO hedefi 60 dakikaydı, fazlasıyla karşılandı)

RPO değerlendirmesi: Replikasyon lag değeri 47 saniyeydi, yani en fazla 47 saniyelik işlem kaybı yaşandı. Ödeme sisteminin kendi idempotency mekanizması olduğu için çift işlem riski de minimaldi.

İzleme ve Uyarı Altyapısı

Pilot Light’ın hayatta kalması için güçlü bir izleme altyapısına ihtiyacın var. Sadece replikasyonu değil, DR ortamının genel sağlığını da takip etmelisin.

#!/bin/bash
# DR genel sağlık kontrol scripti
# /usr/local/bin/dr-health-check.sh
# Cron: */10 * * * * /usr/local/bin/dr-health-check.sh

ALERT_EMAIL="[email protected]"
DR_HOST="10.20.0.50"
CHECKS_PASSED=0
CHECKS_FAILED=0
REPORT=""

check() {
    local NAME="$1"
    local CMD="$2"
    
    if eval "$CMD" > /dev/null 2>&1; then
        CHECKS_PASSED=$((CHECKS_PASSED + 1))
        REPORT+="[OK] $NAMEn"
    else
        CHECKS_FAILED=$((CHECKS_FAILED + 1))
        REPORT+="[FAIL] $NAMEn"
    fi
}

# Temel bağlantı kontrolü
check "DR Host Ping" "ping -c 2 -W 3 $DR_HOST"
check "DR SSH Erişimi" "ssh -i /etc/dr/key -o ConnectTimeout=5 dr-user@$DR_HOST 'echo ok'"
check "DR MySQL Çalışıyor" "ssh -i /etc/dr/key dr-user@$DR_HOST 'systemctl is-active mysql'"
check "DR Redis Çalışıyor" "ssh -i /etc/dr/key dr-user@$DR_HOST 'systemctl is-active redis'"

# Disk doluluk kontrolü
check "DR Disk Alanı (<%85)" 
    "ssh -i /etc/dr/key dr-user@$DR_HOST 
    'df /var/lib/mysql | awk NR==2{print $5}' | tr -d '%' | awk '$1 < 85'"

# Replikasyon lag kontrolü (ayrı script'ten durum oku)
REPL_OK=$(ssh -i /etc/dr/key dr-user@"$DR_HOST" 
    "mysql -u root -p'$MYSQL_ROOT_PASS' 
    -e 'SHOW SLAVE STATUSG' 2>/dev/null | 
    grep 'Slave_IO_Running: Yes'" | wc -l)

if [ "$REPL_OK" -gt 0 ]; then
    CHECKS_PASSED=$((CHECKS_PASSED + 1))
    REPORT+="[OK] MySQL Replikasyon Aktifn"
else
    CHECKS_FAILED=$((CHECKS_FAILED + 1))
    REPORT+="[FAIL] MySQL Replikasyon PROBLEMn"
fi

# Özet rapor
TOTAL=$((CHECKS_PASSED + CHECKS_FAILED))
echo -e "DR Sağlık Kontrolü - $(date)n$REPORTnPassed: $CHECKS_PASSED/$TOTAL" 
    >> /var/log/dr/health-check.log

# Eğer herhangi bir kontrol başarısız olduysa alert gönder
if [ "$CHECKS_FAILED" -gt 0 ]; then
    echo -e "DR Sağlık Kontrolü BAŞARISIZ!nn$REPORT" | 
        mail -s "[DR-ALARM] $CHECKS_FAILED Kontrol Başarısız" "$ALERT_EMAIL"
fi

Failback: Production’a Geri Dönüş

Felaket sonrası production ortamı düzeldiğinde geri dönüş (failback) yapmak gerekir. Bu adım çoğu zaman göz ardı edilir ve aynı derecede dikkatli planlanmalıdır. Temelde süreç şu işler:

Production ortamının tamamen sağlıklı olduğundan emin ol
DR’dan production’a ters replikasyon kur, DR üzerinde biriken değişiklikleri production’a aktar
Veri tutarlılığını doğrula
Trafiki tekrar production’a yönlendir
DR’ı tekrar pilot light moduna döndür

Failback sırasında en büyük risk, DR’da biriken ve production’a henüz geçmemiş yazma işlemlerinin kaybedilmesidir. Bu yüzden failback’i asla aceleye getirme. Veriler production’a tam olarak aktarılmadan trafik yönlendirmesini değiştirme.

Sonuç

Pilot Light stratejisi, “ne çok pahalı ne de yetersiz” diyenlerin DR çözümüdür. Doğru yapılandırıldığında aylık maliyeti ciddi ölçüde düşürürken RTO ve RPO hedeflerini tatmin edici seviyede tutabilir. Ama şunu asla unutma: strateji ne kadar iyi olursa olsun, test edilmedikçe değeri yoktur.

Bugün başlayabileceğin adımlar:

Veritabanı replikasyonunu kur ve replikasyon lag monitoring’ini aktif hale getir
Kritik bileşen listeni çıkar, hangisi her zaman açık olacak hangisi kapalı duracak kararını ver
Failover scriptlerini yaz ve bir lab ortamında test et
Takvime altı ayda bir DR testi ekle ve bu testlere gerçekten katıl

Felaket planı yapmak korkudan değil, sorumluluktan yapılan bir iştir. Pilot ışığını yak, küçük tut ama daima hazır halde beklet.

Pilot Light Stratejisi: Minimum Kaynak Kullanarak Felaket Kurtarma