Sunucu Yedekleme Stratejileri ve Felaket Kurtarma (DR) Rehberi (2026)

Sunucu yönetiminde en pahalı tecrübe, alınmamış veya hiç geri yükleme testi yapılmamış bir yedektir. Donanım arızaları (NVMe SSD kontrolcü kilitlenmesi, anakart yanması), fidye yazılımları (ransomware), veri merkezi yangınları veya insan kaynaklı yanlış komutlar (rm -rf veya yanlış DROP DATABASE) kaçınılmazdır.

Bir sunucunun yedekleme altyapısı, yalnızca veriyi kopyalamakla bitmez. Veritabanı tutarlılığı (ACID consistency), aktarım ve depolama sırasında AES-256 şifreleme, depolama maliyetini %80'e kadar düşüren blok düzeyinde tekilleştirme (deduplication) ve sistem çöktüğünde dakikalar içinde ayağa kalkmayı garanti eden RTO / RPO hedefleri belirlenmelidir.

Bu kapsamlı rehberde; 3-2-1 yedekleme kuralından canlı PostgreSQL/MySQL tutarlı yedeklemelerine, Restic ve BorgBackup mimarisinden S3 uyumlu nesne depolama (Wasabi, Cloudflare R2, Hetzner Storage Box) entegrasyonuna kadar modern sunucu yedekleme mühendisliğini adım adım inceliyoruz.

1. Modern 3-2-1-1-0 Yedekleme Mimarisi

Geleneksel "aynı sunucunun /backup dizinine cron ile tar.gz basma" yöntemi gerçek bir yedekleme değildir; zira disk veya sunucu çöktüğünde veriyle birlikte yedek de yok olur. Günümüz kurumsal sistemlerinde 3-2-1-1-0 kuralı altın standarttır:

[Canlı Sunucu (Production)]
        │
        ├── (1) Yerel Hızlı Snapshot (Hızlı Geri Alma / Rollback)
        │
        ├── (2) Farklı Bir Donanım Ortamı (Yerel NAS / Yerel Yedek Sunucusu)
        │
        └── (3) Coğrafi Olarak Uzak (Offsite) S3 Nesne Depolama
                    │
                    ├── (Immutable / Object Lock): Silinemez & Değiştirilemez Kilit
                    └── (Test Doğrulaması): Otomatik Geri Yükleme Doğrulama Testi

1. 3 Kopya Veri: Bir orijinal canlı veri ve en az 2 adet güncel yedek kopya bulunmalıdır.
2. 2 Farklı Depolama Türü: Veriler farklı ortamlarda (örneğin NVMe yerel blok depolama ve harici S3 nesne depolama havuzu) tutulmalıdır.
3. 1 Coğrafi Olarak Farklı (Offsite) Konum: Sunucunuz İstanbul veri merkezindeyse, en az bir yedek kopyanız Almanya, Hollanda veya farklı bir coğrafi bölgedeki veri merkezinde bulunmalıdır.
4. 1 Değiştirilemez (Immutable) Kopya: Fidye yazılımlarının veya sunucuyu ele geçiren saldırganların yedek havuzunu silmesini engellemek için S3 Object Lock (WORM - Write Once, Read Many) veya append-only SFTP modu kullanılmalıdır.
5. 0 Hata ile Test Edilmiş (Tested Restores): Düzenli aralıklarla otomatik olarak test edilmemiş bir yedeğin gerçek bir felaket anında çalıştığı varsayılamaz.

2. Hipervizör Snapshot'ı Neden Tam Bir Yedekleme Değildir?

Pek çok hosting kullanıcısı, barındırma sağlayıcısının kontrol panelinden haftalık veya günlük alınan VPS/VDS Snapshot (anlık görüntü) özelliğini eksiksiz bir yedekleme çözümü zannetmektedir. Oysa snapshot ve yedekleme tamamen farklı kavramlardır:

[!WARNING] Snapshot Şişme Tuzağı:
KVM ve VMware ortamlarında haftalarca silinmeden bırakılan snapshot zincirleri, hipervizör disk okuma/yazma (IOPS) performansını dramatik biçimde düşürür ve ana diske birleştirilme (merge/commit) sırasında saatler süren sunucu kilitlenmelerine yol açabilir.

3. Restic vs BorgBackup vs Duplicacy Kıyaslaması

Modern açık kaynaklı yedekleme araçları, dosya düzeyinde sıkıştırma (tar.gz) yerine İçerik Tanımlı Parçalama (Content-Defined Chunking - CDC) ve blok tekilleştirme kullanır. 100 GB'lık bir sunucuda yalnızca 200 MB veri değiştiyse, yedekleme havuzuna yalnızca o 200 MB eklenir.

Bulut sunucu (VPS/VDS) ve S3 tabanlı nesne depolama kullanan modern Linux altyapılarında Restic, harici bağımlılık gerektirmemesi ve doğrudan S3/REST backend'i desteklemesi nedeniyle en popüler çözümdür.

4. Canlı Veritabanı Tutarlılığı: Dump vs Sıcak Yedek (Hot Backup)

Sunucu dosya sistemini (/var/lib/mysql veya /var/lib/postgresql) çalışırken doğrudan kopyalamak, bozuk bir veritabanı (corrupted database) elde etmenin en kesin yoludur. Çünkü MySQL/PostgreSQL işlem sırasında bellekte (Buffer Pool) sayfa tutar ve diske periyodik yazar.

MySQL / MariaDB Tutarlı Yedekleme

• Küçük ve Orta Ölçekli Veritabanları (50 GB'ın altı):
  mysqldump veya mariadb-dump kullanırken InnoDB tablolarının kilitlenmemesi için --single-transaction bayrağı zorunludur:

  mariadb-dump --single-transaction --quick --routines --triggers -u root -p'parola' veritabani_adi | gzip > /tmp/db_backup.sql.gz
  

• Büyük Ölçekli Veritabanları (100 GB ve üzeri):
  Dump işlemi saatler süreceğinden ve geri yükleme SQL INSERT komutlarıyla çok yavaş olacağından Percona XtraBackup kullanılmalıdır. XtraBackup, veritabanını kilitlemeden fiziksel veri sayfalarını kopyalar ve eşzamanlı Redo Log hareketlerini kaydederek geri yükleme süresini dakikalara indirir.

PostgreSQL Tutarlı Yedekleme

• Mantıksal Yedekleme:

  pg_dump -Fc -U postgres veritabani_adi > /tmp/db_backup.dump
  

• Zaman Noktasına Geri Dönüş (Point-in-Time Recovery - PITR):
  E-ticaret ve finansal sistemlerde pgBackRest veya WAL-G kullanılarak Write-Ahead Log (WAL) dosyaları anlık olarak S3 nesne depolama havuzuna aktarılır. Bu sayede sunucu öğleden sonra 14:32'de çökse bile sistem tam olarak saat 14:31:59 anına geri döndürülebilir (Sıfır veri kaybı).

5. Adım Adım Restic + S3 Uyumlu Nesne Depolama Kurulumu

Aşağıdaki adımlarla herhangi bir Ubuntu/Debian veya RHEL tabanlı Linux sunucuyu Cloudflare R2, Wasabi veya Hetzner Storage Box S3 havuzuna şifreli olarak yedekleyebilirsiniz:

1. Restic Kurulumu

# Ubuntu / Debian
apt update && apt install -y restic

# RHEL / AlmaLinux / Rocky Linux
dnf install -y epel-release && dnf install -y restic

2. Çevre Değişkenleri ve Depo Başlatma (/root/.restic_env)

S3 kimlik bilgilerinizi güvenli bir dosyada saklayın (erişim izinlerini yalnızca root'a verin):

cat << 'EOF' > /root/.restic_env
export AWS_ACCESS_KEY_ID="s3_erisim_anahtari"
export AWS_SECRET_ACCESS_KEY="s3_gizli_anahtari"
export RESTIC_REPOSITORY="s3:https://s3.eu-central-1.wasabisys.com/sirket-yedek-havuzu/sunucu-01"
export RESTIC_PASSWORD="GucluKriptoluParola123!*#"
EOF

chmod 600 /root/.restic_env

3. Depoyu Başlatma (Init)

source /root/.restic_env
restic init

4. Yedekleme Betiği (/usr/local/bin/sunucu-yedekle.sh)

#!/usr/bin/env bash
set -euo pipefail
source /root/.restic_env

# 1. Canlı MySQL Dump (Single Transaction)
mkdir -p /tmp/sql_dumps
mariadb-dump --single-transaction --quick -u root db_prod > /tmp/sql_dumps/db_prod.sql

# 2. Restic ile Dosya ve Dökümleri Şifreli Yedekleme
restic backup \
  --verbose \
  --exclude={/dev,/proc,/sys,/tmp,/run,/mnt,/media,/lost+found} \
  --exclude={/var/cache,/var/tmp,/var/log} \
  /etc \
  /var/www \
  /tmp/sql_dumps

# 3. Geçici SQL dökümünü temizleme
rm -rf /tmp/sql_dumps

# 4. Saklama Politikası (Retention): Eski Snapshot'ları Temizleme
restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --prune

echo "[OK] Yedekleme başarıyla tamamlandı: $(date)"

Betiğe çalıştırma izni verin:

chmod 700 /usr/local/bin/sunucu-yedekle.sh

6. Systemd Timer ile Güvenli Otomasyon ve İzleme

Cron yerine systemd service & timer kullanmak, yedekleme süreçlerinin Linux cgroups ile izole edilmesini, bellek ve CPU sınırları konulabilmesini (CPUQuota=50%, MemoryMax=1G) ve sistem yeniden başlatıldığında kaçırılan işlerin anında çalıştırılmasını (Persistent=true) sağlar.

/etc/systemd/system/restic-backup.service

[Unit]
Description=Restic Guvenli S3 Sunucu Yedekleme
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/sunucu-yedekle.sh
Nice=19
IOSchedulingClass=idle
CPUWeight=20
MemoryHigh=1G
MemoryMax=1.5G
StandardOutput=journal
StandardError=journal

/etc/systemd/system/restic-backup.timer

[Unit]
Description=Her Gece Saat 03:00'te Restic Yedekleme Calistir

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=600
Persistent=true

[Install]
WantedBy=timers.target

Servisi aktifleştirin:

systemctl daemon-reload
systemctl enable --now restic-backup.timer

[!TIP] Sessiz Başarısızlıkları Önleyin:
Yedek betiğinizin son satırına Uptime Kuma veya Healthchecks.io ping adresi (curl -fsS -m 10 --retry 3 https://hc-ping.com/UUID) ekleyin. Betik hata verip erken çıkarsa veya internet kesilirse sistem size Telegram/Slack üzerinden "Yedekleme gerçekleşmedi!" uyarısı gönderir.

7. RTO ve RPO: Felaket Kurtarma (DR) Metrikleri

Kurumsal barındırma mimarisinde iki temel metrik tüm yedekleme stratejinizi belirler:

• RPO (Recovery Point Objective - Kurtarma Noktası Hedefi):
  Bir felaket anında kaybetmeyi göze alabileceğiniz maksimum veri süresidir.
  • Günlük yedek alıyorsanız: RPO = 24 saat (24 saatlik müşteri siparişleri veya içerikler kaybolabilir).
  • WAL arşivleme / PITR kullanıyorsanız: RPO = 5 dakikadan az (Neredeyse sıfır kayıp).
• RTO (Recovery Time Objective - Kurtarma Süresi Hedefi):
  Sunucu tamamen yandıktan sonra yeni bir sunucuda hizmetin tekrar yayına alınmasına kadar geçen süredir.
  • Manuel kurulum ve 500 GB dosya indirme: RTO = 6 - 12 saat.
  • Terraform / Ansible otomasyonu ve hızlı S3 bağlantısı: RTO = 30 dakika.

6 Aylık Felaket Kurtarma Tatbikatı (DR Drill)

Yedeklerinizin çalıştığından emin olmanın tek yolu, boş bir test sunucusunda geri yükleme tatbikatı yapmaktır:

1. Farklı bir sağlayıcıdan saatlik bir test VPS'i açın.
2. Restic ile en son snapshot'ı yeni sunucuya indirin (restic restore latest --target /).
3. Web sunucusunu ve MySQL servisini başlatın.
4. Sitenin açıldığını, tabloların eksiksiz olduğunu ve son kullanıcı oturumlarının geçerliliğini teyit edin.

8. En Sık Yapılan 5 Ölümcül Yedekleme Hatası

1. Yedeği Canlı Sunucunun İkinci Bölümünde Saklamak: Sunucunun anakartı veya veri merkezi kabini yandığında iki bölüm de yok olur.
2. Yedek Parolasını Unutmak: Restic ve Borg gibi araçlar güçlü şifreleme kullandığından, parola veya anahtar dosyası kaybolursa NASA gelse bile veriyi çözemez. Parolanızı 1Password veya Bitwarden gibi bir kasa üzerinde güvenle saklayın.
3. Tekilleştirme Havuzunu Asla Prune/Check Etmemek: Zamanla depolama alanı dolar ve bozuk indeksler temizlenmez. Ayda bir kez restic check komutu çalıştırılmalıdır.
4. Yalnızca Dosyaları Alıp Veritabanını Dışarıda Bırakmak: Çalışan veritabanı kopyalanmazsa yedekten geriye yalnızca boş bir web sitesi iskeleti kalır.
5. Geri Yükleme Süresini Hesaplamamak: 1 TB yedeği 100 Mbps bağlantıyla indirmek yaklaşık 24 saat sürer. Kritik sistemlerde sağlayıcının iç ağ hızı (1 Gbps / 10 Gbps) ve veri merkezi lokasyonu kurtarma süresini doğrudan etkiler.