Sunucu Yedekleme Stratejileri ve 3-2-1 Kuralı

Yedekleme stratejisi, “ara sıra bir kopya almak” değil; ne sıklıkla, neyi, nereye, kaç kopya halinde alacağınızı ve bunları nasıl test edeceğinizi önceden belirlemektir. Veri kaybının sebebi çoğu zaman donanım arızası bile değildir: yanlış çalıştırılmış bir rm -rf, hatalı bir güncelleme, fidye yazılımı ya da yanlış yapılmış bir göç işlemi çok daha sık karşımıza çıkar.

Bu rehberde 3-2-1 kuralını, yedek türlerini, RPO ve RTO kavramlarını, gerçek çalışan yedek betiklerini, rsync ve restic ile uzak kopyalamayı, cron zamanlamasını ve en önemlisi geri dönüş testini ele alıyoruz.

3-2-1 Kuralı#

Yedekleme dünyasının en kalıcı kuralı basit bir formülle özetlenir:

Verinin 3 kopyası olsun, 2 farklı ortamda saklansın, 1 kopya sunucudan uzakta dursun.

3 kopya

Bir asıl veri ve iki yedek. Tek yedek yeterli değildir; yedeğin kendisi de bozulabilir ya da eksik alınmış olabilir.

2 farklı ortam

Aynı diskin iki bölümü “iki ortam” sayılmaz. Sunucu diski + uzak depolama, ya da sunucu diski + ayrı bir yedek sunucusu.

1 kopya uzakta

Sunucunun bulunduğu fiziksel yerden bağımsız olmalı. Sunucu tamamen kaybolduğunda elinizde kalan kopya budur.

Modern bir ekleme daha vardır: 1 kopya değiştirilemez (immutable) olsun. Fidye yazılımı bulaştığında saldırganın ilk yaptığı iş, erişebildiği tüm yedekleri silmek ya da şifrelemektir. Yazma korumalı ya da saklama süresi kilitli bir kopya, bu senaryodaki tek kurtarıcıdır.

RPO ve RTO: İki Sayıyı Önce Belirleyin#

Yedekleme planı bu iki soruya verdiğiniz cevapla şekillenir:

Örneklerle somutlaştıralım:

Yedek Türleri#

Tam yedek (full)#

Her seferinde verinin tamamı alınır. Geri dönüş en basitidir: tek arşivi açarsınız. Dezavantajı yer ve süre tüketimidir.

Artımlı yedek (incremental)#

Bir önceki yedekten (tam ya da artımlı) sonra değişen dosyalar alınır. En az yer kaplayan ve en hızlı yöntemdir. Geri dönüşte tam yedek artı zincirdeki tüm artımlı yedekler gerekir; zincirin bir halkası bozuksa sonrası kurtarılamaz.

Fark yedeği (differential)#

Son tam yedekten sonra değişenler alınır. Dosya boyutu her gün biraz daha büyür ama geri dönüş için yalnızca iki dosya gerekir: son tam yedek ve son fark yedeği.

Pratikte en yaygın ve dengeli düzen şudur: haftada bir tam yedek, her gün artımlı yedek. Aylık bir tam yedeği ise uzun süreli arşiv olarak ayrı tutun.

Neyi Yedeklemelisiniz?#

Sunucunun tamamını yedeklemek her zaman gerekmez; asıl önemli olan geri kurulamayacak veriyi kaçırmamaktır.

• Uygulama verisi: yüklenen dosyalar, medya kitaplığı, kullanıcı içerikleri.
• Veritabanı: dump alınmalı; ham veri dosyalarını kopyalamak servis çalışırken tutarsız sonuç verir.
• Yapılandırma dosyaları: /etc/nginx, /etc/systemd/system, .env, sanal konak tanımları.
• Sertifikalar: /etc/letsencrypt dizini.
• Cron görevleri: crontab -l çıktısı ve /etc/cron.d.
• Oyun sunucusu dünyaları: world klasörleri, eklenti verileri, izin dosyaları.
• Yedeklemenize gerek olmayanlar: node_modules, önbellek klasörleri, geçici dosyalar, işletim sistemi paketleri.

Bu dizinleri bulmak ve boyutlarını görmek için du, find ve tar komutlarını kullanacaksınız; kullanım örnekleri Linux temel komutları sayfasında. Alan adı ve DNS yapılandırmanızın bir kopyasını da metin dosyası olarak saklayın; kayıtların tam listesini DNS kayıtları rehberindeki örnek tablodan çıkarabilirsiniz.

Çalışan Bir Yedek Betiği#

Aşağıdaki betik dosya ve veritabanı yedeğini birlikte alır, arşivi doğrular ve eski yedekleri temizler:

#!/bin/bash
# /usr/local/bin/yedek.sh
set -euo pipefail

TARIH=$(date +%F_%H%M)
HEDEF=/var/yedek
KAYNAK=/var/www/site.com
DB_ADI=site_db
DB_KULLANICI=yedekci
SAKLAMA_GUN=14
LOG=/var/log/yedek.log

mkdir -p "$HEDEF"

echo "[$(date '+%F %T')] Yedek başladı" >> "$LOG"

# 1) Veritabanı dump'ı - tabloları kilitlemeden tutarlı kopya
mysqldump -u "$DB_KULLANICI" --single-transaction --quick --routines \
  --triggers "$DB_ADI" | gzip > "$HEDEF/db_${DB_ADI}_$TARIH.sql.gz"

# 2) Dosya arşivi - gereksizleri hariç tut
tar --exclude='*/node_modules' \
    --exclude='*/cache' \
    --exclude='*.log' \
    -czf "$HEDEF/dosya_$TARIH.tar.gz" -C "$KAYNAK" .

# 3) Yapılandırma dosyaları
tar -czf "$HEDEF/konfig_$TARIH.tar.gz" \
    /etc/nginx /etc/letsencrypt /etc/systemd/system 2>/dev/null || true

# 4) Arşiv bütünlüğünü doğrula
for arsiv in "$HEDEF"/*_"$TARIH".tar.gz; do
  if ! tar -tzf "$arsiv" > /dev/null 2>&1; then
    echo "[$(date '+%F %T')] HATA: bozuk arşiv $arsiv" >> "$LOG"
    exit 1
  fi
done

# 5) Eski yedekleri temizle
find "$HEDEF" -type f -name "*.gz" -mtime +$SAKLAMA_GUN -delete

BOYUT=$(du -sh "$HEDEF" | cut -f1)
echo "[$(date '+%F %T')] Yedek tamamlandı. Toplam boyut: $BOYUT" >> "$LOG"

# Çalıştırılabilir yap
sudo chmod +x /usr/local/bin/yedek.sh

# Elle bir kez çalıştırıp test et
sudo /usr/local/bin/yedek.sh
tail -5 /var/log/yedek.log

# Örnek çıktı:
# [2026-08-12 04:00:03] Yedek başladı
# [2026-08-12 04:02:41] Yedek tamamlandı. Toplam boyut: 3.8G

Cron ile Zamanlama#

# Kök kullanıcının crontab'ını düzenle
sudo crontab -e

# Her gece 04:00'te tam yedek
0 4 * * * /usr/local/bin/yedek.sh

# Her 6 saatte bir yalnızca veritabanı
0 */6 * * * /usr/local/bin/db-yedek.sh

# Her pazar 03:00'te uzak sunucuya senkron
0 3 * * 0 /usr/local/bin/uzak-senkron.sh

# Zamanlamayı doğrula
sudo crontab -l

Sistem yükünü düşürmek için yedekleme işini disk önceliği düşük çalıştırabilirsiniz:

# CPU ve disk önceliğini düşürerek çalıştır
0 4 * * * nice -n 19 ionice -c3 /usr/local/bin/yedek.sh

Uzak Kopyalama: rsync ve restic#

rsync ile senkronizasyon#

rsync yalnızca değişen blokları aktarır, bu yüzden ikinci çalıştırmadan itibaren çok hızlıdır:

# Yedekleri uzak sunucuya kopyala
rsync -avz --delete --partial --progress \
  -e "ssh -p 22 -i /root/.ssh/yedek_key" \
  /var/yedek/ yedekci@203.0.113.80:/depo/site-yedek/

# Örnek çıktı:
# sending incremental file list
# db_site_db_2026-08-12_0400.sql.gz
#      41,238,912 100%   58.21MB/s    0:00:00 (xfr#1, to-chk=0/6)
# sent 41,251,004 bytes  received 235 bytes  27,500,826.00 bytes/sec

--delete parametresine dikkat edin: kaynakta silinmiş dosyaları hedefte de siler. Bu, ayna (mirror) davranışıdır ve fidye yazılımı senaryosunda şifrelenmiş dosyaların temiz kopyaların üzerine yazılmasına yol açabilir. Arşiv amaçlı kopyalarda bu parametreyi kullanmayın.

restic ile şifreli ve sürümlü yedek#

Sürüm geçmişi, tekilleştirme (deduplication) ve şifreleme istiyorsanız restic gibi bir araç işi çok kolaylaştırır:

# Depo oluştur (bir kez)
restic init --repo /depo/restic

# Yedek al
restic --repo /depo/restic backup /var/www/site.com /etc/nginx

# Anlık görüntüleri listele
restic --repo /depo/restic snapshots

# Örnek çıktı:
# ID        Time                 Host       Paths
# a1b2c3d4  2026-08-11 04:00:12  web01      /var/www/site.com
# e5f6g7h8  2026-08-12 04:00:09  web01      /var/www/site.com

# Saklama politikası uygula: 7 günlük, 4 haftalık, 6 aylık tut
restic --repo /depo/restic forget --prune \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6

# Depo bütünlüğünü doğrula
restic --repo /depo/restic check

Veritabanı Yedeklemenin İncelikleri#

Veritabanı dosyalarını çalışırken kopyalamak tutarsız bir yedek üretir. Doğru yöntem dump almaktır:

# MySQL / MariaDB - InnoDB tablolarını kilitlemeden tutarlı dump
mysqldump -u yedekci -p --single-transaction --quick --routines --triggers \
  --default-character-set=utf8mb4 site_db | gzip > site_db.sql.gz

# PostgreSQL
pg_dump -U botuser -Fc botdb > botdb_$(date +%F).dump

# Tüm veritabanlarını tek seferde
mysqldump -u root -p --all-databases --single-transaction | gzip > tumu.sql.gz

# Geri yükleme
gunzip < site_db.sql.gz | mysql -u root -p site_db
pg_restore -U botuser -d botdb botdb_2026-08-12.dump

Yedek için ayrı ve yetkisi kısıtlı bir veritabanı kullanıcısı oluşturmak iyi bir alışkanlıktır:

sudo mysql -u root -p -e "
CREATE USER 'yedekci'@'localhost' IDENTIFIED BY 'uzun-bir-parola';
GRANT SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER
  ON *.* TO 'yedekci'@'localhost';
FLUSH PRIVILEGES;"

Oyun Sunucularına Özel Notlar#

Minecraft gibi oyun sunucularında dünya dosyaları sürekli yazılır; sunucu çalışırken kopyalamak bozuk chunk verisi üretebilir. Doğru sıra şudur: konsoldan kaydetmeyi durdur, diske yaz, kopyala, kaydetmeyi tekrar aç.

# RCON veya screen üzerinden komut göndererek güvenli yedek
screen -S mc -p 0 -X stuff "save-off$(printf '\r')"
screen -S mc -p 0 -X stuff "save-all flush$(printf '\r')"
sleep 10

tar -czf /var/yedek/dunya_$(date +%F_%H%M).tar.gz \
    -C /opt/minecraft world world_nether world_the_end

screen -S mc -p 0 -X stuff "save-on$(printf '\r')"

Minecraft’a özgü yedekleme yöntemlerinin tamamı, eklenti tabanlı çözümler ve panel üzerinden yedek alma Minecraft sunucu yedekleme rehberinde. Sunucu taşırken yedekten yararlanma adımları için sunucu taşıma rehberine bakabilirsiniz.

Geri Dönüş Testi: En Çok Atlanan Adım#

Aylarca sorunsuz çalışan bir yedek sistemi, felaket anında işe yaramayabilir: arşiv bozuktur, veritabanı dump’ı eksiktir, sıkıştırma yarıda kesilmiştir ya da yedeklenen dizin baştan yanlış seçilmiştir. Bunların hepsi yalnızca geri yükleme denendiğinde ortaya çıkar.

1. Ayda bir rastgele yedek seçin#

   En yenisini değil, birkaç gün öncesini seçin. Zincirin ortasındaki bir yedeğin çalıştığını görmek daha değerlidir.

2. Boş bir dizine ya da test sunucusuna geri yükleyin#

   Üretim ortamının üzerine asla test geri yüklemesi yapmayın.

3. Bütünlüğü doğrulayın#

   Dosya sayısı ve toplam boyut beklendiği gibi mi? Veritabanı açılıyor ve tablolar dolu mu?

4. Uygulamayı çalıştırın#

   Site açılıyor mu, oyun sunucusu dünyayı yüklüyor mu, bot bağlanıyor mu?

5. Süreyi ölçün#

   Geri dönüş kaç dakika sürdü? Bu, gerçek RTO değerinizdir. Hedefinizin üzerindeyse yöntemi değiştirmeniz gerekir.

6. Sonucu kayda geçin#

   Tarih, yedek adı, süre ve varsa aksaklıklar. Bir sonraki testte karşılaştırma yaparsınız.

# Hızlı bütünlük kontrolleri
tar -tzf /var/yedek/dosya_2026-08-12_0400.tar.gz | head -20
tar -tzf /var/yedek/dosya_2026-08-12_0400.tar.gz | wc -l

# Örnek çıktı:
# ./
# ./index.php
# ./wp-content/
# ...
# 48213

# Sıkıştırılmış dump'ın okunabilirliğini kontrol et
gunzip -t /var/yedek/db_site_db_2026-08-12_0400.sql.gz && echo "Arşiv sağlam"

İzleme ve Uyarı#

Yedek sisteminin sessizce durması, en sık rastlanan felaket senaryosudur: disk dolar, parola değişir, cron görevi silinir ve aylarca kimse fark etmez. Bunu önlemek için yedek işini de izleyin:

• Yedek betiğinin çıkış kodunu kontrol edin; başarısızlıkta bildirim gönderin.
• Son yedek dosyasının tarihini ve boyutunu izleyin. Boyut aniden düştüyse bir şey ters gitmiştir.
• Yedek diskinin doluluk oranına eşik koyun.
• Aylık geri dönüş testini takvime kalıcı görev olarak ekleyin.

# Son yedeğin yaşını kontrol eden basit denetim
SON=$(find /var/yedek -name "dosya_*.tar.gz" -mtime -1 | wc -l)
if [ "$SON" -eq 0 ]; then
  echo "UYARI: son 24 saatte yedek alınmamış" | \
    mail -s "Yedek uyarısı" yonetici@alanadiniz.com
fi

Bu kontrolleri bir izleme sistemine bağlamak isterseniz kurulum adımları sunucu izleme rehberinde. Sunucunuzun genel güvenlik yapılandırması için VDS ilk ayarlar sayfasına da göz atın.

Özetle#

İyi bir yedekleme planı üç sayıyla başlar: kaç kopya (3), kaç ortam (2), kaç tanesi uzakta (1). Buna RPO ve RTO hedeflerinizi ekleyin; yedek sıklığı ve yöntemi bu iki sayıdan çıkar. Pratikte haftalık tam + günlük artımlı düzeni çoğu senaryo için doğru dengeyi verir.

Veritabanını mutlaka dump ile alın, betiğinizde set -euo pipefail kullanın, arşiv bütünlüğünü otomatik doğrulayın ve en az bir kopyayı sunucudan tamamen bağımsız bir yerde tutun. En önemlisi de şu: ayda bir geri dönüş provası yapın. Test edilmemiş bir yedek, yedek değil sadece bir dosyadır.