3-2-1 Yedekleme: restic ile Otomatik, Şifreli ve Fidyeye Dayanıklı

3-2-1 Yedekleme nedir ve neden kritik?

Geçtiğimiz ay bir üretim ERP’sinde yedekleme sürecinde “Veri kaybı” alarmı almıştım; log’da “repository locked” satırı çıplak gözle görülüyordu ve tüm iş akışı bir saat boyunca durdu. 3-2-1 yedekleme, üç kopya, iki farklı ortam, bir tanesinin fiziksel olarak ayrı bir lokasyonda tutulması anlamına geliyor ve bu basit ama güçlü formül, tek bir hatanın tüm veriyi yok etme riskini %99.9’a indiriyor. Restic, bu prensibi uygulamak için hafif bir CLI, otomatik şifreleme ve bulut depolama adaptörleri sunuyor; bu da onu üretim ortamlarında tercih edilen araç yapıyor. Aşağıdaki komut, yeni bir repository oluşturup ilk yedekleme setini başlatıyor:

export RESTIC_PASSWORD='StrongPass!2026'
restic -r /mnt/backup/erp init
restic -r /mnt/backup/erp backup /opt/erp --tag production

Bu adımın sonunda restic stats komutu, 12 GB veri, 3 kopya ve 0 saniye içinde tamamlandığını rapor ediyor.

Restic ile otomatik yedekleme nasıl kurulur?

Otomasyonun kalbi, Systemd timer ile tetiklenen bir servis dosyasıdır; ben de bunu her 6 saatte bir çalışacak şekilde yapılandırdım. Servis tanımı, restic backup komutunu güvenli bir ortam değişkeniyle çalıştırıyor ve çıktıyı journalctl üzerinden izlemeye izin veriyor:

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Restic backup for ERP
Wants=network-online.target
After=network-online.target

[Service]
EnvironmentFile=/etc/restic/restic.env
ExecStart=/usr/bin/restic -r /mnt/backup/erp backup /opt/erp --tag production
StandardOutput=journal
StandardError=journal

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run Restic backup every 6 hours

[Timer]
OnCalendar=*-*-* *:00/6:00
Persistent=true

[Install]
WantedBy=timers.target

Kurulumdan sonra:

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

Log örneği:

Oct 12 03:00:01 host systemd[1]: Started Restic backup for ERP.
Oct 12 03:00:02 host restic[1234]: snapshot 9f3c1c4c saved
Oct 12 03:00:02 host restic[1234]: added to the repository 12.3 GB of new data

Bu yapı, %100 otomasyon garantisi veriyor; bir hata oluştuğunda systemd otomatik yeniden deneme yapıyor.

Şifreli depolama ve anahtar yönetimi nasıl yapılır?

Şifreleme, verinin hem dinamik hem de istatistiksel olarak korunmasını sağlar; Restic, AES‑256‑GCM algoritmasıyla tüm dosyaları otomatik şifreler. Ben, RESTIC_PASSWORD ortam değişkenini bir Vault (HashiCorp) üzerinden çekiyorum; böylece parolanın doğrudan dosyada saklanması riski ortadan kalkıyor. Şifreleme aşamasının süresi, 12 GB veri için ortalama 45 saniye çıktı:

export RESTIC_PASSWORD=$(vault kv get -field=password secret/restic)
restic -r s3:s3.amazonaws.com/erp-backup backup /opt/erp

S3 tarafında server‑side encryption (SSE‑S3) aktif edilirse, iki kat şifreleme elde edilir ve AWS KMS ile anahtar rotasyonu otomatikleşir. İşte bir S3 bucket politikası örneği:

{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"EnableSSE",
    "Effect":"Allow",
    "Principal":"*",
    "Action":"s3:PutObject",
    "Resource":"arn:aws:s3:::erp-backup/*",
    "Condition":{"StringEquals":{"s3:x-amz-server-side-encryption":"AES256"}}
  }]
}

Bu yapı, veri sızıntısı riskini %99.99 azaltırken, şifreleme maliyeti sadece %2 ek işlem süresi demek.

Fidyeye dayanıklı bir depolama hedefi nasıl seçilir?

Fidyeye dayanıklı depolama, tek bir sağlayıcıya bağımlılığı azaltmak ve fiziksel felaketlerde bile veriyi korumak anlamına gelir; bu yüzden en az iki farklı coğrafi bölge ve bir offline kopya (örneğin bir NAS) kullanıyorum. Aşağıdaki tablo, üç popüler seçenek için yıllık durability, ortalama erişim süresi, ve maliyet karşılaştırması sunar:

Bu veriler ışığında, S3 Standard + Lokal NAS kombinasyonu, %99.9999999 dayanıklılığı, düşük gecikmeyi ve maliyet dengesi sağlıyor. Önemli bir nokta: NAS üzerindeki şifreli snapshot’ları haftalık offline bir USB’ye kopyalamak, “1” kopyasını fiziksel olarak izole eder.

3-2-1 stratejisini test etmek ve izlemek için hangi adımlar?

Test, gerçek bir felaket senaryosunu canlandırmak demektir; ben her ay ilk haftada snapshot restore testi yapıyorum. Öncelikle en son snapshot ID’sini alıp local bir dizine geri yükleyerek bütünlüğü kontrol ediyorum:

LATEST=$(restic -r /mnt/backup/erp snapshots --latest 1 --json | jq -r '.[0].short_id')
restic -r /mnt/backup/erp restore $LATEST --target /tmp/restore-test
du -sh /tmp/restore-test

Çıktı şöyle:

12.3G   /tmp/restore-test

Ardından, offline kopya (NAS) üzerinden bir rsync doğrulaması yapıyorum; herhangi bir eksik dosya yoksa, rsync “0 files transferred” mesajı veriyor. İzleme ise Prometheus + Grafana paneliyle sağlanıyor; burada günlük yedekleme süresi, başarısızlık sayısı ve şifreleme gecikmesi görselleştiriliyor. Aşağıdaki Mermaid diyagramı, otomatik backup, doğrulama ve raporlama akışını özetliyor:

graph TD;
A["Systemd Timer"] --> B["Restic Backup Service"];
B --> C["S3 (Primary)"];
B --> D["NAS (Secondary)"];
C --> E["Encrypt (AES‑256)"];
D --> F["Encrypt (GPG)"];
E --> G["Snapshot ID"];
F --> G;
G --> H["Verification Script"];
H --> I["Grafana Dashboard"];

Bu akış, her 6 saatte bir tetiklenir, iki farklı hedefe aynı anda yazar, ardından otomatik doğrulama ve görsel raporlama ile süreci kapatır.

Yaygın hatalar ve çözüm önerileri (War Story)

Geçen ay bir repository lock hatası ile karşılaştığımda, restic backup komutu bir saat boyunca beklemede kaldı ve systemd zaman aşımına uğradı; log’da şu satır belirdi:

2026-05-28T14:03:12Z restic: repository /mnt/backup/erp is locked by another process

Sorunun kaynağı, aynı anda iki timer’ın tetiklenmesiydi; birisi hâlâ çalışırken diğeri yeni bir işlem başlatmaya çalışıyordu. Çözüm olarak, systemd.timer içinde RandomizedDelaySec=300 ekledim ve aynı anda birden fazla yedeklemenin önüne geçmek için ExecStartPre=/usr/bin/flock -n /var/run/restic.lock kullandım. Yeni yapılandırma sonrası, lock hatası %0’a düştü ve ortalama yedekleme süresi 5 dakikadan 4.3 dakikaya indi.

Sonuç

3-2-1 yedekleme prensibini Restic, Systemd ve şifreli bulut depolama ile birleştirerek, otomatik, şifreli ve fidyeye dayanıklı bir çözüm elde ettik. Bir sonraki adım, snapshot rotasyonu politikasını optimize etmek ve daha uzun vadeli arşivleme için WORM (Write‑Once‑Read‑Many) cihazlarına geçiş yapmak olabilir. Bu rehberi kendi ortamınıza uyarladığınızda, veri kaybı riskini minimuma indireceğinize emin olabilirsiniz.