Restic ile Snapshot Yönetimi ve Geri Yükleme

Yedekleme dünyasında “snapshot” kavramı, bir sistemin belirli bir andaki tam görüntüsünü ifade eder. Restic, bu snapshot’ları son derece akıllı bir şekilde yönetir; artımlı yedekleme, şifreleme ve hızlı geri yükleme özellikleriyle diğer araçlardan sıyrılır. Bu yazıda Restic’in snapshot yönetimini derinlemesine ele alacağız, gerçek dünya senaryolarıyla geri yükleme süreçlerini inceleyeceğiz.

Restic Snapshot’larını Anlamak

Restic, her yedekleme işlemini bir “snapshot” olarak kaydeder. Her snapshot benzersiz bir ID’ye sahiptir ve o anki dosya sisteminin tam bir görüntüsünü temsil eder. Ancak Restic’in dehasını gösteren şey, bu snapshot’ların arka planda nasıl çalıştığıdır: veriler “pack” dosyaları ve “chunk” sistemiyle saklanır. Aynı dosya birden fazla snapshot’ta yer alıyorsa, disk üzerinde sadece bir kez depolanır. Bu de-duplikasyon özelliği sayesinde 50 adet günlük snapshot tutmak, 50 kat fazla disk alanı tüketmez.

Bunu bir örnekle somutlaştıralım: 100 GB’lık bir web sunucusu yedekliyorsunuz. Her gün sadece 500 MB değişiyor. Restic ile 30 günlük snapshot tuttuğunuzda toplam kullanılan alan yaklaşık 100 GB + 14.5 GB = 115 GB civarındadır. Geleneksel tam yedekleme yaklaşımıyla bu rakam 3 TB olurdu.

Repository Kurulumu ve İlk Yapılandırma

Snapshot yönetimine geçmeden önce sağlam bir repository yapısına ihtiyacınız var. Önce ortam değişkenlerinizi ayarlayın:

# Ortam değişkenlerini kalıcı hale getirin
cat >> /etc/restic/restic.env << 'EOF'
export RESTIC_REPOSITORY="/mnt/backup/restic-repo"
export RESTIC_PASSWORD="cok-guclu-bir-sifre-buraya"
EOF

# Değişkenleri yükleyin
source /etc/restic/restic.env

# Repository'yi başlatın
restic init

# Uzak sunucu için SFTP örneği
export RESTIC_REPOSITORY="sftp:[email protected]:/backup/restic"
restic init

Repository başarıyla oluşturulduktan sonra ilk yedeklemeyi alın:

# Temel yedekleme
restic backup /var/www /etc /home

# Etiket ekleyerek yedekleme (snapshot yönetiminde çok işe yarar)
restic backup /var/www --tag "web-server" --tag "production" --tag "v2.1"

# Belirli dizinleri hariç tutarak yedekleme
restic backup /home 
  --exclude="/home/*/.cache" 
  --exclude="/home/*/Downloads" 
  --exclude="*.tmp" 
  --exclude="*.log" 
  --tag "home-backup"

Snapshot Listeleme ve Filtreleme

Zamanla repository’nizde onlarca, hatta yüzlerce snapshot birikebilir. Bunları etkin şekilde yönetmek kritik önem taşır.

# Tüm snapshot'ları listele
restic snapshots

# Belirli bir etikete göre filtrele
restic snapshots --tag "production"

# Belirli bir host'a ait snapshot'ları listele
restic snapshots --host "web-server-01"

# Belirli bir path'e ait snapshot'ları listele
restic snapshots --path "/var/www"

# JSON formatında çıktı al (otomasyon için)
restic snapshots --json | jq '.[].id'

# Son 5 snapshot'ı göster
restic snapshots --last 5

Çıktıyı incelediğinizde her snapshot için şu bilgileri görürsünüz:

• ID: Snapshot’ın benzersiz kısa kimliği (örn: a1b2c3d4)
• Time: Snapshot’ın alındığı zaman damgası
• Host: Yedeklemenin alındığı sunucu adı
• Tags: Atanmış etiketler
• Paths: Yedeklenen dizinler

Snapshot İçeriğini İnceleme

Geri yüklemeden önce bir snapshot’ın içinde ne olduğunu görmek isteyebilirsiniz. Restic bunun için mükemmel araçlar sunar:

# Snapshot içeriğini listele
restic ls a1b2c3d4

# Belirli bir dizini listele
restic ls a1b2c3d4 /var/www/html

# Snapshot istatistiklerini görüntüle
restic stats a1b2c3d4

# Tüm repository istatistikleri
restic stats

# İki snapshot arasındaki farkı göster
restic diff a1b2c3d4 e5f6g7h8

restic diff komutu özellikle güçlüdür. Hangi dosyaların eklendiğini, silindiğini veya değiştirildiğini tam olarak gösterir. Bir ransomware saldırısını tespit etmeye çalıştığınızı düşünün; iki snapshot arasındaki farka bakarak binlerce dosyanın şifrelenip şifrelenmediğini anında görebilirsiniz.

Retention Policy ile Snapshot Budama

En kritik konulardan biri budur. Sonsuz snapshot tutmak hem depolama maliyetini artırır hem de yönetimi zorlaştırır. Restic’in forget komutu, esnek bir retention (saklama) politikası uygulamanıza olanak tanır.

# Retention politikasını sadece göster, silme yapma (--dry-run)
restic forget 
  --keep-last 7 
  --keep-daily 14 
  --keep-weekly 8 
  --keep-monthly 12 
  --keep-yearly 3 
  --dry-run

# Gerçekten uygula
restic forget 
  --keep-last 7 
  --keep-daily 14 
  --keep-weekly 8 
  --keep-monthly 12 
  --keep-yearly 3

# Budama sonrası gerçek disk alanını geri kazan (prune)
restic forget 
  --keep-last 7 
  --keep-daily 14 
  --keep-weekly 8 
  --keep-monthly 12 
  --keep-yearly 3 
  --prune

Retention parametrelerini anlamak önemlidir:

• –keep-last N: Son N snapshot’ı koru
• –keep-hourly N: Her saatten son N tanesini koru
• –keep-daily N: Her günden son N tanesini koru
• –keep-weekly N: Her haftadan son N tanesini koru
• –keep-monthly N: Her aydan son N tanesini koru
• –keep-yearly N: Her yıldan son N tanesini koru
• –keep-tag etiket: Belirtilen etikete sahip snapshot’ları her zaman koru
• –dry-run: Gerçek silme yapmadan önizleme yap

Belirli bir etikete sahip snapshot’ları korumak özellikle production ortamlarında çok kullanışlıdır. “release” etiketiyle işaretlenen snapshot’lar hiçbir zaman otomatik budama tarafından silinmez:

# Release snapshot'larını asla silme
restic forget 
  --keep-last 10 
  --keep-daily 7 
  --keep-tag "release" 
  --prune

Geri Yükleme Senaryoları

Senaryo 1: Tam Sistem Geri Yükleme

Bir gece sunucunuz çöktü. Disk arızası, yanlış bir rm -rf komutu veya başka bir felaket. Panik yapmadan şu adımları izleyin:

# Önce mevcut snapshot'ları listele
restic snapshots

# Geri yüklemek istediğiniz snapshot'ı belirleyin
# En son snapshot'ı geri yükle
restic restore latest --target /

# Belirli bir snapshot'ı geri yükle
restic restore a1b2c3d4 --target /

# Geri yükleme öncesi ne yükleneceğini gör
restic restore a1b2c3d4 --target /restore-test --dry-run

--target / kullanırken dikkatli olun. Mevcut sistemi tamamen üzerine yazar. Eğer seçici geri yükleme yapacaksanız farklı bir hedef dizin belirleyin.

Senaryo 2: Belirli Dosya ve Dizinleri Geri Yükleme

Bir geliştirici config.php dosyasını yanlışlıkla sildi ve bunun farkına üç gün sonra vardı. Tüm sistemi geri yüklemek yerine sadece o dosyayı kurtarabilirsiniz:

# Dosyanın hangi snapshot'larda bulunduğunu bul
restic snapshots --path "/var/www/html/config.php"

# Belirli bir dosyayı geri yükle
restic restore a1b2c3d4 
  --target /tmp/restore 
  --include "/var/www/html/config.php"

# Dizin bazlı geri yükleme
restic restore a1b2c3d4 
  --target /tmp/restore 
  --include "/var/www/html/uploads"

# Geri yüklenen dosyayı orijinal konumuna taşı
cp /tmp/restore/var/www/html/config.php /var/www/html/config.php

# Birden fazla dosya pattern'ı kullanma
restic restore latest 
  --target /tmp/restore 
  --include "*.php" 
  --include "*.conf"

Senaryo 3: Mount Yöntemiyle Dosya Arama

Bazen hangi snapshot’ta hangi dosyanın olduğunu bilmiyorsunuzdur. Restic’in mount özelliği bu durumda kurtarıcıdır. Repository’yi bir dosya sistemi olarak bağlayabilirsiniz:

# FUSE kurulu olduğundan emin olun
apt install fuse  # Debian/Ubuntu
yum install fuse  # RHEL/CentOS

# Mount noktası oluştur
mkdir -p /mnt/restic-snapshots

# Repository'yi mount et
restic mount /mnt/restic-snapshots

# Başka bir terminal'de snapshot'ları gez
ls /mnt/restic-snapshots/
# hosts/  ids/  snapshots/  tags/

ls /mnt/restic-snapshots/snapshots/
# latest  2024-01-15T03:00:00+03:00  2024-01-14T03:00:00+03:00 ...

# İstediğiniz dosyayı normal dosya gibi kopyalayın
cp /mnt/restic-snapshots/snapshots/latest/var/www/html/config.php /var/www/html/

# İşiniz bitince unmount edin
fusermount -u /mnt/restic-snapshots

Bu yöntem özellikle hangi tarihteki versiyonu istediğinizi bilmediğiniz durumlarda çok pratiktir. Farklı snapshot’ların içeriğini karşılaştırarak doğru versiyonu bulabilirsiniz.

Otomatik Yedekleme ve Snapshot Yönetimi

Manuel yedekleme almak kabul edilemez. Her şeyin otomatikleştirilmesi gerekiyor. İşte kapsamlı bir bash scripti:

#!/bin/bash
# /usr/local/bin/restic-backup.sh

set -euo pipefail

# Konfigürasyon
source /etc/restic/restic.env
LOG_FILE="/var/log/restic/backup-$(date +%Y%m%d).log"
LOCK_FILE="/var/run/restic-backup.lock"

# Log fonksiyonu
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

# Lock kontrolü (aynı anda iki yedekleme çalışmasın)
if [ -f "$LOCK_FILE" ]; then
    log "HATA: Yedekleme zaten çalışıyor! Lock dosyası: $LOCK_FILE"
    exit 1
fi
touch "$LOCK_FILE"
trap "rm -f $LOCK_FILE" EXIT

log "Yedekleme başlıyor..."

# Yedekleme al
restic backup 
    /var/www 
    /etc 
    /home 
    --exclude="/home/*/.cache" 
    --exclude="/home/*/Downloads" 
    --exclude="*.tmp" 
    --tag "daily" 
    --tag "$(hostname)" 
    2>&1 | tee -a "$LOG_FILE"

log "Retention politikası uygulanıyor..."

# Retention politikası ve prune
restic forget 
    --keep-last 7 
    --keep-daily 14 
    --keep-weekly 8 
    --keep-monthly 6 
    --keep-tag "release" 
    --prune 
    2>&1 | tee -a "$LOG_FILE"

log "Repository bütünlüğü kontrol ediliyor..."

# Repository kontrolü (haftada bir çalıştırın)
if [ "$(date +%u)" -eq 7 ]; then
    restic check 2>&1 | tee -a "$LOG_FILE"
fi

log "Yedekleme tamamlandı."

# Eski log dosyalarını temizle (30 günden eski)
find /var/log/restic/ -name "*.log" -mtime +30 -delete

Bu scripti cron ile zamanlayın:

# Crontab'a ekleyin
crontab -e

# Her gece 03:00'de çalıştır
0 3 * * * /usr/local/bin/restic-backup.sh

# Systemd timer da kullanabilirsiniz
# /etc/systemd/system/restic-backup.service ve .timer dosyaları oluşturun

Repository Bakımı ve Sağlık Kontrolü

Yedekleme almak kadar önemli olan şey, o yedeklemelerin sağlıklı olduğundan emin olmaktır. Geri yüklemeye ihtiyaç duyduğunuzda bozuk bir repository’yle karşılaşmak felaket olur.

# Temel sağlık kontrolü
restic check

# Veri bütünlüğünü de kontrol et (daha yavaş ama kapsamlı)
restic check --read-data

# Sadece bir kısmını kontrol et (büyük repository'ler için)
restic check --read-data-subset=10%

# Repository'yi optimize et (parçalanmayı önler)
restic prune

# Önbelleği temizle
restic cache --cleanup

# Repository şifresi değiştir
restic key add
restic key list
restic key remove <old-key-id>

restic check --read-data komutu tüm veriyi okuyup hash’leri doğruladığından büyük repository’lerde uzun sürebilir. Bunu haftalık veya aylık çalıştırmanız yeterlidir. Günlük restic check (veri okumadan) ise saniyeler içinde tamamlanır.

Snapshot Etiketleme Stratejisi

Gerçek dünya ortamlarında iyi bir etiketleme stratejisi, yönetim kolaylığı açısından çok değerlidir. Şu yaklaşımı benimseyebilirsiniz:

• Ortam etiketleri: production, staging, development
• Uygulama etiketleri: web-server, database, app-server
• Zaman etiketleri: daily, weekly, monthly
• Özel olaylar: before-deploy, after-migration, release-v2.1

# Deployment öncesi özel snapshot
restic backup /var/www 
  --tag "before-deploy" 
  --tag "production" 
  --tag "release-v2.1"

# Database migration öncesi
restic backup /var/lib/postgresql 
  --tag "pre-migration" 
  --tag "database"

# Bu etiketlere sahip snapshot'ları listele
restic snapshots --tag "before-deploy"

# Varolan snapshot'a etiket ekle
restic tag --add "verified" a1b2c3d4

# Etiket kaldır
restic tag --remove "temp" a1b2c3d4

Çoklu Repository ile Yedek Yedekleme (3-2-1 Stratejisi)

Sysadmin’lerin kutsal kuralı: 3 kopya, 2 farklı ortam, 1 uzak lokasyon. Restic ile bunu uygulamak oldukça basittir:

#!/bin/bash
# Aynı veriyi birden fazla repository'ye yedekle

# Yerel depolama
RESTIC_REPOSITORY="/mnt/local-backup/restic" 
RESTIC_PASSWORD="sifre1" 
restic backup /var/www --tag "local"

# NAS (SFTP)
RESTIC_REPOSITORY="sftp:[email protected]:/restic" 
RESTIC_PASSWORD="sifre2" 
restic backup /var/www --tag "nas"

# Bulut depolama (S3)
RESTIC_REPOSITORY="s3:s3.amazonaws.com/my-bucket/restic" 
AWS_ACCESS_KEY_ID="your-key" 
AWS_SECRET_ACCESS_KEY="your-secret" 
RESTIC_PASSWORD="sifre3" 
restic backup /var/www --tag "s3"

Her repository için farklı şifre kullanmak güvenlik açısından önerilir. Böylece bir repository’nin şifresi ele geçirilse dahi diğerleri güvende kalır.

Geri Yükleme Testi

Yedeklemenin değerini bilmenin tek yolu, düzenli olarak test etmektir. Şu anda geri yükleyip yükleyemediğinizi bilmiyorsanız yedeklemediğiniz anlamına gelir.

#!/bin/bash
# /usr/local/bin/restic-restore-test.sh
# Her hafta otomatik geri yükleme testi yap

source /etc/restic/restic.env
TEST_DIR="/tmp/restic-restore-test"
LOG_FILE="/var/log/restic/restore-test-$(date +%Y%m%d).log"

log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"; }

# Test dizinini hazırla
rm -rf "$TEST_DIR"
mkdir -p "$TEST_DIR"

log "Geri yükleme testi başlıyor..."

# Son snapshot'tan kritik dosyaları geri yükle
restic restore latest 
  --target "$TEST_DIR" 
  --include "/etc/nginx" 
  --include "/etc/ssh/sshd_config" 
  2>&1 | tee -a "$LOG_FILE"

# Dosyaların gerçekten geri yüklendiğini doğrula
if [ -f "$TEST_DIR/etc/nginx/nginx.conf" ]; then
    log "BASARILI: nginx.conf geri yuklendi"
else
    log "HATA: Geri yukleme basarisiz!"
    # Bildirim gönder
    echo "Restic restore test BASARISIZ" | mail -s "ALARM: Yedekleme Sorunu" [email protected]
fi

# Test dizinini temizle
rm -rf "$TEST_DIR"
log "Test tamamlandi."

Sonuç

Restic, snapshot yönetimini hem güçlü hem de erişilebilir kılmaktadır. De-duplikasyon sayesinde disk alanından tasarruf ederken, şifreleme sayesinde verileriniz güvende kalır. Anlattığımız konuları özetlemek gerekirse:

• Snapshot listeleme ve filtreleme ile neyin nerede olduğunu her zaman bilirsiniz
• Retention politikaları ile repository’nizi düzenli ve yönetilebilir tutarsınız
• Seçici geri yükleme ile tüm sistemi geri yüklemek yerine sadece ihtiyacınız olan dosyaları kurtarırsınız
• Mount özelliği ile snapshot’ları bir dosya sistemi gibi gezebilirsiniz
• Otomatik scriptler ile insan hatasını minimuma indirirsiniz
• Düzenli test ile yedeklerinizin gerçekten çalıştığından emin olursunuz

Yedekleme söz konusu olduğunda en kötü senaryo, felaketi yaşadıktan sonra yedeklerinizin bozuk ya da eksik olduğunu keşfetmektir. Bu yüzden retention politikalarınızı dikkatli planlayın, repository’lerinizi düzenli kontrol edin ve geri yükleme testlerinizi aksatmayın. Restic bu süreçte size sağlam bir temel sağlar; gerisini iyi alışkanlıklar tamamlar.