Veri Yedekleme ve Felaket Kurtarma Planı

Kısa cevap: yedekleme bir dosya kopyalama işi değil, geri dönüş süresi taahhüdüdür. Bir sistemin gerçekten yedeği var demek için üç şeyin yazılı olması gerekir: ne sıklıkla yedek alınıyor (yani en fazla kaç saatlik veriyi kaybedebilirsiniz), geri yükleme ne kadar sürüyor ve yedeğin açıldığı en son ne zaman test edildi. Bu üçü belirlenmemişse elinizde yedek değil, yedek olduğunu sandığınız dosyalar vardır.

İki soru: RPO ve RTO

Felaket kurtarma planı iki sayı üzerine kurulur ve bu sayılar teknik değil, iş kararıdır. Sizin belirlemeniz, geliştirici ekibin de ona göre altyapı kurması gerekir.

• RPO (kabul edilebilir veri kaybı): Sistem çöktüğünde en fazla kaç saatlik veriyi kaybetmeye razısınız? Kurumsal tanıtım sitesinde 24 saat sorun değildir; sipariş alan bir e-ticarette 15 dakika bile fazladır.
• RTO (kabul edilebilir kesinti süresi): Sistem ne kadar süre kapalı kalabilir? Bu süre yedeklerin nerede durduğunu belirler; başka bir sunucuda hazır bekleyen kopya ile arşivden indirilecek dosya arasındaki fark saatlerle ölçülür.
• Kapsam: Veritabanı, kullanıcıların yüklediği dosyalar, yapılandırma ve ortam değişkenleri, e-posta kayıtları. En sık unutulan kalem yüklenen dosyalardır: veritabanı geri gelir, ürün görselleri gelmez.

RPO ve RTO yazılmadan alınan her yedekleme kararı tahmindir. Bu iki sayı belirlendiğinde hangi çözümün gerektiği ve maliyeti kendiliğinden ortaya çıkar.

3-2-1 kuralı ve neden hâlâ geçerli

Yedekleme dünyasının en eski kuralı hâlâ en işe yarayanı: 3 kopya, 2 farklı ortam, 1 tanesi başka bir lokasyonda. Bunun sebebi felsefi değil pratik; yedek çoğunlukla sunucu yandığı için değil, aynı hesap içinde bir şey silindiği ya da şifrelendiği için işe yaramaz hâle geliyor.

• Aynı sunucuda duran yedek yedek değildir. Sunucu erişilemez olduğunda yedeğe de erişemezsiniz.
• Aynı hesapta duran yedek yarım yedektir. Hesap ele geçirilirse ya da fatura sebebiyle kapanırsa iki kopya birden gider.
• Fidye yazılımına karşı değiştirilemez (immutable) kopya: Belirlenen süre boyunca silinemeyen bir kopya, saldırının yedekleri de şifrelediği senaryonun tek çözümüdür.
• Saklama süresi: Yalnızca son yedeği tutmak yetmez; bozulma fark edilmeden bir hafta geçebilir. Günlük yedeği bir ay, haftalıkları birkaç ay tutmak yaygın kurgudur.

Test edilmemiş yedek, yedek değildir

Sahada gördüğümüz en pahalı hata bu: yedekleme işi her gece çalışıyor, log yeşil görünüyor, ama dosya boş ya da bozuk. Bu ancak gerçekten ihtiyaç duyulduğu gün anlaşılıyor. Çözüm basit; yedekleme betiğinin son adımı, aldığı yedeği boş bir veritabanına geri yükleyip içinde veri olduğunu doğrulamaktır.

#!/usr/bin/env bash
set -euo pipefail

# Gece yedegi: veritabani dokumu + dosyalar, sonra GERI YUKLEME TESTI.
STAMP=$(date +%F)
DUMP="/backup/db-$STAMP.sql.gz"

pg_dump "$DATABASE_URL" | gzip > "$DUMP"
tar -czf "/backup/uploads-$STAMP.tar.gz" /var/www/uploads

# Bos bir test veritabanina geri yukle: yedegin okunabildigini kanitlar.
createdb restore_check
gunzip -c "$DUMP" | psql restore_check >/dev/null
ROWS=$(psql -tA restore_check -c 'select count(*) from orders;')
dropdb restore_check

if [ "$ROWS" -lt 1 ]; then
  echo "YEDEK BOZUK: siparis tablosu bos" >&2
  exit 1
fi

# Kopyayi ikinci bir konuma (farkli saglayici) tasi.
rclone copy /backup remote-offsite:backup --max-age 24h
echo "Yedek dogrulandi: $ROWS kayit"

Bu betikteki asıl değer pg_dump satırı değil, geri yükleme kontrolüdür: yedek açılamıyorsa iş başarısız sayılır ve size bildirim gider. Ayrıca çeyrekte bir elle tatbikat yapın: yedekten yepyeni bir ortam ayağa kaldırıp kaç dakika sürdüğünü ölçün. Ölçmediğiniz RTO, tahmin edilmiş RTO demektir.

Yedekleme bakım anlaşmasının neresinde?

Yedekleme genelde bakım hizmetinin içindedir ama kapsamı çoğu sözleşmede muğlaktır. Anlaşmaya şu dört maddenin yazılı olması gerekir; nelerin yıllık maliyet kalemi olduğunu web sitesi bakım ücreti yazısında ayrıntılandırdık.

• Sıklık ve saklama süresi: Günlük mü saatlik mi, kaç gün geriye dönülebiliyor?
• Yedeğin bulunduğu yer: Aynı sağlayıcı mı, farklı sağlayıcı mı? Verinin bulunduğu ülke KVKK açısından da önemlidir; ilkeler için KVKK uyumlu web sitesi yazısına bakın.
• Geri yükleme taahhüdü: Talep geldikten kaç saat içinde sistem ayağa kaldırılıyor ve bu mesai saati dışında da geçerli mi?
• Yedeğin size teslimi: İlişki biterse yedekleri hangi formatta ve ne kadar sürede alırsınız? Bu madde yoksa veriniz sağlayıcıda kilitli kalır.

Felaket senaryosunda ilk bir saat

Plan, olay anında okunacak kadar kısa olmalı. Kriz sırasında kimse otuz sayfalık doküman açmıyor; tek sayfalık bir sıra listesi işe yarıyor.

• Önce durdurun: Saldırı ya da veri bozulması şüphesi varsa yazma işlemlerini durdurun. Çalışmaya devam eden sistem, bozuk veriyi yedeklere de yayar.
• Sonra sınıflandırın: Sunucu mu gitti, veri mi bozuldu, yoksa yalnızca bir dağıtım mı hatalı? Üçünün çözümü farklıdır ve yanlış teşhis en çok zamanı burada kaybettirir.
• Geri yüklemeyi kopya ortama yapın: Canlının üstüne yazmak, sorunun ikinci kez yaşanmasına yol açar.
• Haber verin: Kesinti müşteriyi etkiliyorsa iletişim planı teknik çözümden önce devreye girer.
• Sonrasında yazın: Neden oldu, hangi adım eksikti? Güvenlik tarafındaki önlemler için web sitesi güvenliği yazısı iyi bir kontrol listesi.

Sonuç

Yedekleme sorusu "yedek alıyor muyuz" değil, "en son ne zaman geri yükleyebildik" sorusudur. RPO ve RTO belirlenmiş, 3-2-1 kuralına uygun kurulmuş ve düzenli test edilen bir yapı, veri kaybını olağanüstü bir kriz olmaktan çıkarıp planlı bir işleme dönüştürür. Mevcut altyapınızda bu üç maddeyi kontrol etmemizi isterseniz kurumsal çözümler hizmetimize bakabilir ya da teklif alabilirsiniz.