Yedekleme, kimsenin ilgilenmediği ama bir gün her şeyin ona bağlı olduğu iştir. Kötü haber şu: yedeği olduğunu sanan pek çok kişinin aslında yoktur — çünkü hiç denememişlerdir.
3-2-1 kuralı
Sektörde kabul görmüş en basit ölçüt budur:
- 3 kopya veri (aslı + iki yedek)
- 2 farklı ortam/sistem üzerinde
- 1 kopya fiziksel olarak başka bir konumda
Bu kuralın amacı, tek bir olayın tüm kopyaları birden yok etmesini engellemektir. Yedeği aynı sunucunun aynı diskinde tutmak, diskle birlikte yedeği de kaybetmek demektir. Aynı veri merkezinde tutmak, o merkezi etkileyen bir olayda aynı sonucu verir.
Neyi yedekliyorsunuz?
"Siteyi yedekledim" cümlesi çoğu zaman eksiktir. Listeleyin:
- Web dosyaları — uygulama kodu ve kullanıcı yüklemeleri
- Veritabanı — dosya kopyası yetmez, tutarlı bir döküm gerekir
- Yapılandırma — web sunucusu, PHP, cron görevleri, güvenlik duvarı kuralları
- E-posta — posta kutuları ayrı bir veri kümesidir
- SSL sertifikaları ve anahtarlar
- Sunucudaki gizli değerler — API anahtarları, ortam değişkenleri
Yapılandırmayı yedeklemek, felaket sonrası kurtarma süresini günlerden saatlere indirir.
Ne sıklıkta?
Bu sorunun cevabı tek bir soruya bağlıdır: Kaç saatlik veriyi kaybetmeyi göze alabilirsiniz?
- Günde birkaç sipariş alan bir kurumsal site için günlük yedek yeterlidir.
- Aktif bir e-ticaret sitesi için günlük yedek, en kötü senaryoda 24 saatlik sipariş kaybı demektir. Saatlik veritabanı yedeği gerekir.
- Blog gibi seyrek güncellenen içeriklerde haftalık yedek makul olabilir.
Saklama süresini de belirleyin. Yaygın bir düzen: 7 günlük, 4 haftalık, 12 aylık kopya.
Otomasyon
Elle alınan yedek, alınmayan yedektir. Zamanlanmış görevle otomatikleştirin.
Basit bir yaklaşım — veritabanı dökümü ve dosyaların uzak sunucuya kopyalanması:
bash#!/bin/bash
set -euo pipefail
TARIH=$(date +%F)
HEDEF=/var/backups/$TARIH
mkdir -p "$HEDEF"
mysqldump --single-transaction --routines --triggers \
-u yedek -p"$DB_PAROLA" veritabani | gzip > "$HEDEF/db.sql.gz"
tar czf "$HEDEF/dosyalar.tar.gz" /var/www/siteniz
rsync -az "$HEDEF/" yedek@UZAK-SUNUCU:/yedekler/$TARIH/
find /var/backups -maxdepth 1 -type d -mtime +7 -exec rm -rf {} +Daha ciddi ihtiyaçlar için restic veya BorgBackup kullanın. İkisi de artımlı yedek alır (yalnızca değişeni gönderir), tekilleştirme yapar ve şifrelemeyi kendiliğinden halleder:
bashrestic -r sftp:yedek@UZAK-SUNUCU:/yedekler init
restic -r sftp:yedek@UZAK-SUNUCU:/yedekler backup /var/www /etc
restic -r sftp:yedek@UZAK-SUNUCU:/yedekler forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --pruneŞifreleme
Yedekleriniz sunucunun dışına çıkıyorsa şifrelenmiş olmalıdır. Bir yedek dosyası, sunucunun tamamının kopyasıdır: veritabanı, kullanıcı bilgileri, yapılandırmadaki parolalar.
Şifreleme anahtarını yedeklerin durduğu yerde saklamayın. Anahtarı kaybederseniz yedek de kullanılamaz hâle gelir — anahtar yönetimini yazılı bir sürece bağlayın.
En çok atlanan adım: geri yükleme testi
Bu bölüm, yazının en önemli kısmıdır.
Yedek almak yarısıdır; geri yükleyebildiğinizi doğrulamak diğer yarısıdır. Sık karşılaşılan senaryo şudur: yedek görevleri aylardır sorunsuz çalışıyor görünür, felaket anında dosyaların boş ya da bozuk olduğu anlaşılır.
Ayda bir şunu yapın:
- Rastgele bir yedek seçin (en yenisini değil).
- Boş bir test sunucusuna ya da yerel bir sanal makineye geri yükleyin.
- Uygulamayı çalıştırın ve verinin bütün olduğunu doğrulayın.
- Geri yüklemenin ne kadar sürdüğünü not edin.
Dördüncü madde önemlidir: gerçek bir kesintide "yedeğimiz var" demek yetmez, "ne kadar sürede ayağa kalkarız" sorusunun cevabını bilmeniz gerekir.
İzleme
Yedekleme görevinin sessizce başarısız olması yaygındır. Şunları izleyin:
- Yedek görevinin çıkış kodu — başarısızlıkta bildirim gitmeli
- Yedek dosyasının boyutu — ani düşüş, bozuk yedeğin ilk işaretidir
- Son başarılı yedeğin tarihi
Yedekleme kurgunuzu birlikte gözden geçirmek isterseniz bize yazın.