KOBİ'ler için Felaket Kurtarma Planlaması: İşletmenizi Kaçınılmazdan Koruyun

Verilerini kaybeden küçük işletmelerin %60'ı 6 ay içinde kapanıyor. Ancak KOBİ'lerin yalnızca %23'ünün belgelenmiş, test edilmiş bir felaket kurtarma planı var. Felaketlerden kurtulan işletmeler, onlardan kaçınan değil, onlara hazırlık yapanlardır.

Bu kılavuz, küçük ve orta ölçekli işletmeler için temel yedekleme stratejilerinden çok bölgeli yük devretme mimarilerine kadar her şeyi kapsayan pratik bir felaket kurtarma çerçevesi sağlar.

Önemli Çıkarımlar

• Bir DR stratejisi seçmeden önce RPO ve RTO'yu tanımlayın --- bu sayılar mimarinizi ve bütçenizi belirler
• 3-2-1 yedekleme kuralı (3 kopya, 2 ortam türü, 1 tesis dışı) kabul edilebilir minimum yedekleme stratejisidir
• Test edilmemiş yedeklemeler yedekleme değildir --- üç ayda bir kurtarma tatbikatları planlayın
• DR maliyetleri RTO gereksinimleriyle doğrusal olarak ölçeklenir: 24 saatlik RTO maliyeti, 1 saatlik RTO'nun %10'udur

---

Kurtarma Hedeflerini Tanımlama

RPO (Kurtarma Noktası Hedefi)

Zaman cinsinden ölçülen kabul edilebilir maksimum veri kaybı. RPO'nuz 1 saat ise 1 saate kadar veri kaybını tolere edebilirsiniz.

RTO (Kurtarma Süresi Hedefi)

Kabul edilebilir maksimum kesinti süresi. RTO'nuz 4 saat ise işletmeniz 4 saate kadar çevrimdışı kalarak hayatta kalabilir.

Hedefleri İş Etkisiyle Eşleştirme

---

Yedekleme Stratejileri

3-2-1 Kuralı

• Her kritik veri kümesinin 3 kopyası
• 2 farklı depolama türü (örneğin yerel disk + bulut)
• 1 coğrafi olarak ayrı bir yere kopyalayın

Otomatik PostgreSQL Yedekleme

#!/bin/bash
# /opt/scripts/backup-database.sh
# Run via cron: 0 */6 * * * /opt/scripts/backup-database.sh

set -euo pipefail

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/opt/backups/database"
S3_BUCKET="s3://ecosire-backups/database"
DB_NAME="ecosire"
DB_USER="app"
RETENTION_DAYS=30

mkdir -p "$BACKUP_DIR"

# Create backup with compression
echo "Starting backup at $(date)"
pg_dump -h localhost -U "$DB_USER" -Fc "$DB_NAME" > "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump"

# Verify backup integrity
pg_restore --list "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" > /dev/null 2>&1
if [ $? -ne 0 ]; then
  echo "ERROR: Backup verification failed"
  exit 1
fi

BACKUP_SIZE=$(du -h "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" | cut -f1)
echo "Backup created: ${BACKUP_SIZE}"

# Upload to S3 with server-side encryption
aws s3 cp "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" \
  "$S3_BUCKET/${DB_NAME}_${TIMESTAMP}.dump" \
  --sse AES256

# Upload to secondary region
aws s3 cp "$BACKUP_DIR/${DB_NAME}_${TIMESTAMP}.dump" \
  "s3://ecosire-backups-dr/database/${DB_NAME}_${TIMESTAMP}.dump" \
  --sse AES256 \
  --region eu-west-1

# Clean up local backups older than retention period
find "$BACKUP_DIR" -name "*.dump" -mtime +$RETENTION_DAYS -delete

echo "Backup complete at $(date)"

Uygulama Dosyası Yedekleme

#!/bin/bash
# Backup application files, uploads, and configuration

TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# Backup Odoo filestore
tar czf "/opt/backups/files/filestore_${TIMESTAMP}.tar.gz" /opt/odoo/data/filestore/

# Backup uploaded documents
tar czf "/opt/backups/files/uploads_${TIMESTAMP}.tar.gz" /opt/app/uploads/

# Backup configuration (secrets excluded)
tar czf "/opt/backups/config/config_${TIMESTAMP}.tar.gz" \
  --exclude='*.env*' \
  --exclude='*.pem' \
  /opt/app/infrastructure/

# Upload all to S3
aws s3 sync /opt/backups/ s3://ecosire-backups/ --sse AES256

---

Yük Devretme Mimarileri

1. Katman: Soğuk Bekleme (RTO: 4-24 saat)

• Bulut depolama alanında saklanan yedeklemeler
• Kurtarma, yeni altyapının sağlanmasını ve yedeklemeden geri yüklemeyi içerir
• En ucuz seçenek: yalnızca depolama için ödeme yapın
• Kritik olmayan dahili uygulamalar için uygundur

2. Katman: Hazır Bekleme (RTO: 1-4 saat)

• Bekleme sunucusu çalışıyor ancak trafik almıyor
• Veritabanı çoğaltma, beklemedeki verileri güncel tutar
• Kurtarma, bekleme modunun teşvik edilmesini ve DNS'nin güncellenmesini içerir
• Orta maliyet: yedek sunucu için azaltılmış boyutta ödeme yapın

Primary (active) ----replication----> Standby (warm)
                                         |
                   On failure: promote + DNS update

3. Katman: Otomatik Bekleme (RTO: <30 dakika)

• Aktif-pasif veya aktif-aktif konfigürasyonu
• Durum kontrolleri yoluyla otomatik yük devretme
• Senkronize çoğaltmalı veritabanı
• Daha yüksek maliyet: tam kopya altyapı için ödeme yapın

                     Health Check
                         |
Load Balancer ------> Primary (active)
       |
       +-------------> Secondary (hot standby, auto-promote)

Katman 4: Çok Bölgeli Aktif-Aktif (RTO: <5 dakika)

• Birden fazla bölge trafiğe aynı anda hizmet veriyor
• Coğrafyaya göre küresel yük dengeleyici rotaları
• Çoklu ana yazmaçlar için veritabanı çakışması çözümü
• En yüksek maliyet ve karmaşıklık

Maliyet Karşılaştırması

---

Kurtarma Testi

Üç Aylık Kurtarma Tatbikatı

Her üç ayda bir tam bir kurtarma testi gerçekleştirin:

1. Son 30 günden rastgele bir yedekleme seçin
2. Tedarik kurtarma altyapısı (üretimden ayrı)
3. Veritabanını yedekten geri yükleyin
4. Uygulama dosyalarını yedekten geri yükleyin
5. Uygulama kodunu Git'ten dağıtın
6. Yenilenen ortama karşı duman testleri yapın
7. Gerçek iyileşme süresini RTO hedefine göre ölçün
8. Bulguları belgeleyin ve DR planını güncelleyin

Kurtarma Tatbikatı Kontrol Listesi

• Veritabanı yedeklemeden başarıyla geri yüklendi
• Uygulama başlar ve istekleri yerine getirir
• Kullanıcı kimlik doğrulaması çalışıyor
• Kritik iş akışları tamamlandı (sipariş verin, fatura oluşturun)
• Entegrasyon uç noktaları yanıt verir (ödeme ağ geçidi, e-posta)
• Gerçek iyileşme süresi RTO hedefine ulaşıyor
• Ekip, belgelere başvurmadan rollerini biliyor
• İletişim kanalları çalışıyor (paydaşları nasıl bilgilendiriyorsunuz?)

---

Olay Müdahalesi Başucu Kitabı

Önem Düzeyleri

SEV1 Yanıt Adımları

1. Olayı 15 dakika içinde kabul edin
2. Kapsamını değerlendirin: Neler etkilendi, kaç kullanıcı etkilendi?
3. Paydaşlarla iletişim kurun: durum sayfası güncellemesi, müşteri bildirimi
4. **Mevcut en hızlı seçeneği (geri alma, yük devretme, ölçeklendirme) kullanarak azaltın
5. Temel nedeni çözün
6. Opsitasyon sonrası 48 saat içinde: zaman çizelgesi, temel neden, eylem öğeleri

---

Sıkça Sorulan Sorular

How much should we budget for disaster recovery?

Makul bir DR bütçesi, üretim altyapısı maliyetinizin %10-25'idir. Altyapıya ayda 500$ harcayan bir şirket için, DR için ayda 50-125$ bütçe ayırın. Bu, bulut yedekleme depolamasını, sıcak bir bekleme sunucusunu ve izlemeyi kapsar. ROI hesaplaması: işletmeniz saatte 5.000 ABD Doları kesinti kaybederse ve DR, olası 24 saatlik kesintiyi 4 saate düşürürse, DR yatırımı 100.000 ABD Doları tasarruf etti.

Yönetilen bir bulut sağlayıcısı kullanırsak DR'ye ihtiyacımız var mı?

Evet. Bulut sağlayıcıları donanım arızalarına ve veri merkezi kesintilerine karşı koruma sağlar ancak uygulama hatalarına, yanlışlıkla silinmeye, fidye yazılımlarına veya hesabın ele geçirilmesine karşı koruma sağlamaz. DR planınız, bulut sağlayıcının kapsamadığı senaryoları kapsamalıdır: bozuk veriler, silinmiş kaynaklar, güvenlik ihlalleri ve satıcıya bağlı kalma riski.

Odoo ERP sistemimiz için DR'yi nasıl ele alıyoruz?

Odoo DR üç bileşen gerektirir: (1) PostgreSQL veritabanı yedeklemeleri (otomatik, şifreli, tesis dışı), (2) dosya deposu yedeklemeleri (yüklenen ekler, rapor şablonları), (3) özel modül kodu (Git'te). Kurtarma şunları içerir: bir sunucunun sağlanması, Odoo'nun kurulması, veritabanının geri yüklenmesi, dosya deposunun geri yüklenmesi, özel modüllerin dağıtılması. ECOSIRE, otomatik yedeklemeler ve test edilmiş kurtarma prosedürleri ile yönetilen Odoo DR sağlar.

En yaygın DR hatası nedir?

Test edilmemiş yedeklemeler. Yedekleme geri yüklemelerinin %30'undan fazlası yolsuzluk, eksik yedeklemeler, eksik bağımlılıklar veya değiştirilmiş şifreler nedeniyle başarısız oluyor. İkinci en yaygın hata ise güncel olmayan belgelerdir; DR planı artık var olmayan sunuculara, kimlik bilgilerine veya prosedürlere referans verir. Üç aylık testler her iki sorunu da yakalar.

---

Sırada Ne Var?

Felaket kurtarma, operasyonel dayanıklılığın temel taşlarından biridir. Erken tespit için izleme ve uyarı, güvenli değişiklikler için sıfır kesinti süreli dağıtımlar ve tehditleri önlemek için güvenliği güçlendirme ile birleştirin.

Felaket kurtarma planlaması ve uygulaması için ECOSIRE ile iletişime geçin veya altyapı yol haritasının tamamı için DevOps kılavuzumuzu inceleyin.

---

ECOSIRE tarafından yayınlandı -- işletmelerin kaçınılmaz olana hazırlanmasına yardımcı oluyor.