Restic ile S3 yedekleme: Linux sunucuda şifreli, artımlı yedek, saklama politikası ve geri yükleme testi

Panel kullanmayan bir Linux sunucuda yedek çoğu zaman aynı diskte duran bir tar dosyasıdır. Disk bozulduğunda ya da sunucuya fidye yazılımı bulaştığında bu dosya da sunucuyla birlikte kaybolur. Restic ile S3 yedekleme, sunucunun şifreli ve artımlı bir kopyasını uzaktaki S3 uyumlu bir depoya otomatik olarak gönderir ve eski kopyaları belirlediğiniz kurala göre siler. Bu rehber, kendi Linux sunucusunu yöneten sistem yöneticileri ve KOBİ teknik sorumluları için hazırlandı. Kurulum, zamanlama, saklama politikası ve geri yükleme provası için doğrudan uygulayabileceğiniz komutları aşağıda bulabilirsiniz.

Neden restic: şifreleme, tekilleştirme ve uzak kopya

Restic tek dosyalık bir ikili olarak gelir ve kurulumu kolaydır. Öne çıkan özellikleri şunlardır:

• Şifreleme varsayılan olarak açıktır. Veri sunucudan çıkmadan şifrelenir ve depo sağlayıcısı dosyalarınızı okuyamaz. Ama depo parolasını kaybederseniz yedeğe siz de ulaşamazsınız.
• Tekilleştirme yapar. Dosyalar parçalara bölünür ve aynı parça yalnız bir kez saklanır. Bu sayede her yedek kendi başına tam bir yedek gibi görünür, ama depoya yalnız değişen parçalar yüklenir.
• Snapshot mantığıyla çalışır. Her çalıştırma bir snapshot üretir. Herhangi bir snapshot'tan tek bir dosyayı ya da bütün sistemi geri alabilirsiniz.

3-2-1 kuralı, verinin 3 kopyasını 2 farklı ortamda tutmayı ve bunlardan 1 tanesini başka bir konumda saklamayı önerir. Restic ile S3 uyumlu bir depoya alınan yedek, bu kuraldaki uzak kopya işini görür.

Hazırlık: bucket, erişim anahtarı ve depo parolası

Başlamadan önce üç şeyin hazır olması gerekir:

1. S3 uyumlu bir bucket. Yalnız yedek için ayrı bir bucket açın. S3 uyumlu Object Storage ya da başka bir S3 uyumlu depo kullanabilirsiniz. Bucket, yedeklediğiniz sunucuyla aynı fiziksel altyapıda olmamalıdır.
2. Bu iş için ayrı bir erişim anahtarı. Ana hesap anahtarını sunucuya koymayın. Yalnız bu bucket'a yetkisi olan bir anahtar oluşturun.
3. Güçlü bir depo parolası. Bu parolanın sunucu dışında da bir kopyası olsun: parola yöneticisi, kasadaki bir zarf ya da ikinci bir yönetici. Sunucu kaybolursa üzerindeki parola dosyası da onunla birlikte gider.

Aşağıdaki örneklerde depo adresi s3:https://s3.example.com/ornek-yedek/sunucu01 olarak geçiyor. s3.example.com yerine sağlayıcınızın uç noktasını, ornek-yedek yerine bucket adınızı yazın. Sondaki sunucu01, bucket içindeki bir klasördür. Bu sayede birden fazla sunucu aynı bucket'ı kendi klasörleriyle kullanabilir.

Kurulum: dağıtım paketi mi, resmi ikili mi?

Ubuntu ve Debian depolarında restic paketi var, ama bu paket çoğunlukla güncel sürümün gerisinde kalır. Bu yazıda kullanılan --retry-lock gibi seçenekler eski sürümlerde bulunmaz. Kurulumdan sonra sürümü mutlaka kontrol edin. Bu yazı hazırlanırken restic belgeleri 0.19.x serisini anlatıyordu.

Paket deposundan kurulum Ubuntu 24.04 ve Debian 12 için hazırlandı. Geri almak için sudo apt remove restic yeterlidir.

# Dağıtım deposundan kurulum ve sürüm kontrolü
sudo apt update
sudo apt install -y restic
restic version

Güncel ikiliyi kullanmak isterseniz, projenin GitHub sürümler sayfasından mimarinize uygun .bz2 dosyasını ve aynı sürüme ait SHA256SUMS dosyasını indirip aynı dizine koyun. Aşağıdaki betik bu dosyaları doğrular ve ikiliyi kurar. Betik x86_64 mimarili Ubuntu 24.04 ve Debian 12 için hazırlandı. ORNEK_SURUM yerine indirdiğiniz sürüm numarasını yazın. Geri almak için /usr/local/bin/restic dosyasını kaldırmanız yeterlidir. Paket de kuruluysa önce apt remove restic ile kaldırın. Aksi halde hangi ikilinin çalışacağı PATH sırasına bağlı kalır ve karışıklık çıkabilir.

#!/usr/bin/env bash
# Elle indirilen restic ikilisini SHA256 ile doğrular ve /usr/local/bin altına kurar
set -euo pipefail
# İndirilen dosyaların bulunduğu dizin ve dosya adı (değerleri kendinize göre düzenleyin)
INDIRME_DIZINI="$HOME/restic-indirme"
DOSYA="restic_ORNEK_SURUM_linux_amd64.bz2"
cd "$INDIRME_DIZINI"
# Yalnız indirilen dosyanın satırını kontrol et
grep " ${DOSYA}\$" SHA256SUMS | sha256sum -c -
# -k: sıkıştırılmış dosyayı koru, -f: önceki açılmış dosyanın üzerine yaz
bunzip2 -kf "$DOSYA"
sudo install -m 0755 "${DOSYA%.bz2}" /usr/local/bin/restic
restic version

Restic ile S3 yedekleme: depoyu başlatma ve ilk yedek

Ortam dosyası

Erişim bilgileri tek bir dosyada toplanmalı ve bu dosyayı yalnız root okuyabilmelidir. Aşağıdaki adımlar Ubuntu 24.04 ve Debian 12 için hazırlandı. Geri almak için /etc/restic dizinini önce yedekleyin, sonra kaldırın. Depo parolasının başka bir yerde kopyası yoksa bu dizini silmeyin.

# Yapılandırma dizini ve dosyalar, yalnız root erişebilir
sudo install -d -m 0700 /etc/restic
sudo install -d -m 0700 /var/cache/restic

# Depo parolası: ORNEK_DEPO_PAROLASI yerine kendi parolanızı yazın
# (komut geçmişine düşmemesi için editörle yazmak daha güvenlidir)
sudo sh -c 'umask 077; [ -f /etc/restic/parola ] || printf "%s\n" "ORNEK_DEPO_PAROLASI" > /etc/restic/parola'

sudo tee /etc/restic/restic.env > /dev/null <<'EOF'
# S3 uyumlu depo ve erişim bilgileri
RESTIC_REPOSITORY=s3:https://s3.example.com/ornek-yedek/sunucu01
RESTIC_PASSWORD_FILE=/etc/restic/parola
RESTIC_CACHE_DIR=/var/cache/restic
AWS_ACCESS_KEY_ID=ORNEK_ERISIM_ANAHTARI
AWS_SECRET_ACCESS_KEY=ORNEK_GIZLI_ANAHTAR
# Sağlayıcınız bölge adı istiyorsa açın
#AWS_DEFAULT_REGION=ORNEK_BOLGE
EOF
sudo chmod 600 /etc/restic/restic.env

Depoyu başlatma

Aşağıdaki komut, depo zaten varsa hiçbir şey yapmaz. Depo yoksa yenisini oluşturur. Bu yüzden komutu tekrar çalıştırmak güvenlidir.

sudo bash -c '
set -a; . /etc/restic/restic.env; set +a
# Depo yapılandırması okunabiliyorsa depo hazırdır; değilse oluştur
restic cat config >/dev/null 2>&1 || restic init
restic snapshots
'

Neyi yedekleyip neyi dışarıda bırakacaksınız

Bütün kök dizini almak yerine neyin gerçekten önemli olduğuna karar verin. Çoğu sunucuda /etc, /home, /root, /var/www, /srv, /opt ve veritabanı dökümleri yeterlidir. Çalışan bir veritabanının veri dizinini doğrudan kopyalamayın: kopya tutarsız olur ve geri yüklendiğinde açılmayabilir. Bunun yerine önce döküm alın, sonra döküm dosyasını yedekleyin.

# Yedeklenecek ve hariç tutulacak yollar
sudo tee /etc/restic/dahil.txt > /dev/null <<'EOF'
/etc
/home
/root
/var/www
/srv
/opt
/var/backups/db
EOF

sudo tee /etc/restic/haric.txt > /dev/null <<'EOF'
/var/lib/mysql
/var/lib/postgresql
/home/*/.cache
/root/.cache
*.tmp
/swapfile
EOF

systemd timer ile otomatik günlük yedek

Yedek betiği önce veritabanı dökümünü alır, ardından restic'i çalıştırır. Betik Ubuntu 24.04 ve Debian 12 için hazırlandı. MariaDB ya da MySQL için root kullanıcısının socket üzerinden parolasız bağlanabildiği varsayıldı. PostgreSQL satırı yorum olarak bırakıldı. Geri almak için betiği ve aşağıdaki systemd birimlerini kaldırmanız yeterlidir.

sudo tee /usr/local/sbin/restic-yedek.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
# Günlük yedek: veritabanı dökümü + restic backup
set -euo pipefail
set -a; . /etc/restic/restic.env; set +a

DOKUM_DIZINI=/var/backups/db
install -d -m 0700 "$DOKUM_DIZINI"

# MariaDB/MySQL varsa tutarlı döküm al (InnoDB için kilitlemeden)
if command -v mysqldump >/dev/null 2>&1; then
  mysqldump --all-databases --single-transaction --routines --events \
    | gzip > "$DOKUM_DIZINI/mysql-tum.sql.gz.tmp"
  mv "$DOKUM_DIZINI/mysql-tum.sql.gz.tmp" "$DOKUM_DIZINI/mysql-tum.sql.gz"
fi

# PostgreSQL kullanıyorsanız açın
# sudo -u postgres pg_dumpall | gzip > "$DOKUM_DIZINI/pg-tum.sql.gz"

# Depo başka bir işlem tarafından kilitliyse 30 dakikaya kadar bekle
restic backup \
  --files-from /etc/restic/dahil.txt \
  --exclude-file /etc/restic/haric.txt \
  --exclude-caches \
  --tag gunluk \
  --retry-lock 30m
EOF
sudo chmod 700 /usr/local/sbin/restic-yedek.sh

dahil.txt içinde sunucuda bulunmayan bir yol varsa restic uyarı verir ve sıfırdan farklı bir çıkış kodu döndürebilir. Listeyi kendi sunucunuza göre düzenleyin.

Sırada servis, zamanlayıcı ve hata bildirimi birimleri var. OnFailure= satırı, yedek başarısız olduğunda bildirim servisini tetikler. Bu örnekte bildirim sistem günlüğüne yazılır, mail komutu kuruluysa e-posta olarak da gönderilir. Telegram ya da e-posta için disk doluluk uyarısı yazısındaki bildirim betiğini bu servise uyarlayabilirsiniz. Geri almak için sudo systemctl disable --now restic-yedek.timer komutunu çalıştırın, ardından /etc/systemd/system/restic-* dosyalarını kaldırıp systemctl daemon-reload yapın.

sudo tee /etc/systemd/system/restic-yedek.service > /dev/null <<'EOF'
[Unit]
Description=Restic günlük yedek
Wants=network-online.target
After=network-online.target
OnFailure=restic-hata@%n.service

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/restic-yedek.sh
Nice=10
IOSchedulingClass=idle
EOF

sudo tee /etc/systemd/system/restic-yedek.timer > /dev/null <<'EOF'
[Unit]
Description=Restic günlük yedek zamanlayıcısı

[Timer]
OnCalendar=*-*-* 02:30:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target
EOF

sudo tee /etc/systemd/system/[email protected] > /dev/null <<'EOF'
[Unit]
Description=Restic hata bildirimi (%i)

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'logger -p user.err -t restic "%i başarısız oldu"; command -v mail >/dev/null && echo "%i başarısız, journalctl -u %i ile bakın" | mail -s "Yedek hatası: %H" [email protected] || true'
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now restic-yedek.timer
# İlk yedeği hemen elle başlat ve sonucu izle
sudo systemctl start restic-yedek.service
journalctl -u restic-yedek.service -n 50 --no-pager

Persistent=true ayarı sayesinde sunucu planlanan saatte kapalıysa yedek, açılıştan sonra alınır. İlk yedek bütün veriyi yükleyeceği için uzun sürebilir. Sonraki çalıştırmalar yalnız değişen parçaları gönderir.

Saklama politikası: forget, prune ve kilit çakışmaları

Snapshot'lar kendiliğinden silinmez. restic forget, hangi snapshot'ların tutulacağını kurala göre belirler ve kalanların kaydını siler. --prune ise artık hiçbir snapshot'ın kullanmadığı veriyi depodan fiilen kaldırır. Prune yapılmazsa bucket büyümeye devam eder. Seçeneklerin tamamını restic belgelerindeki snapshot silme bölümünde bulabilirsiniz.

Başlangıç için şu politika uygundur: son 7 günlük, 4 haftalık ve 12 aylık snapshot. Silmeden önce sonucu --dry-run ile görün:

sudo bash -c '
set -a; . /etc/restic/restic.env; set +a
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --dry-run
'

Prune, depoda özel bir kilit ister. O sırada bir yedek çalışıyorsa işlemlerden biri beklemek zorunda kalır. Bu yüzden prune'u ayrı bir zamanlayıcıyla, haftada bir ve yedekten saatler sonra çalıştırın. Ardından restic check ile deponun bütünlüğünü kontrol edin. --read-data-subset her çalıştırmada verinin bir kısmını indirip okur, böylece bozuk bir parça erkenden fark edilir. Bu birimler Ubuntu 24.04 ve Debian 12 için hazırlandı. Geri alma yöntemi günlük yedek birimleriyle aynıdır.

sudo tee /usr/local/sbin/restic-bakim.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
# Haftalık bakım: saklama politikası, prune ve kısmi veri doğrulama
set -euo pipefail
set -a; . /etc/restic/restic.env; set +a
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune --retry-lock 2h
restic check --read-data-subset=5% --retry-lock 2h
EOF
sudo chmod 700 /usr/local/sbin/restic-bakim.sh

sudo tee /etc/systemd/system/restic-bakim.service > /dev/null <<'EOF'
[Unit]
Description=Restic haftalık bakım
Wants=network-online.target
After=network-online.target
OnFailure=restic-hata@%n.service

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/restic-bakim.sh
EOF

sudo tee /etc/systemd/system/restic-bakim.timer > /dev/null <<'EOF'
[Unit]
Description=Restic haftalık bakım zamanlayıcısı

[Timer]
OnCalendar=Sun *-*-* 09:00:00
Persistent=true

[Install]
WantedBy=timers.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now restic-bakim.timer
systemctl list-timers 'restic-*'

Birden fazla sunucu aynı depoyu paylaşıyorsa forget, snapshot'ları varsayılan olarak host ve yol bilgisine göre gruplar. Böylece her sunucu kendi kuralına göre temizlenir. Yine de her sunucuya ayrı bir klasör vermek yönetimi kolaylaştırır.

Geri yükleme testi: yedeğin gerçekten çalıştığını doğrulama

Hiç denenmemiş bir yedeğe güvenmeyin. Ayda bir aşağıdaki provaları yapın.

Tek dosya ve tek dizin

Önce hangi snapshot'ların olduğuna bakın, sonra istediğiniz yolu geçici bir dizine geri alın. Çalışan sistemin üzerine doğrudan yazmayın.

sudo bash -c '
set -a; . /etc/restic/restic.env; set +a
restic snapshots --compact
# Son snapshottan nginx yapılandırmasını geçici dizine al
restic restore latest --target /tmp/geri-yukleme-testi --include /etc/nginx
# Tek bir dosyayı doğrudan ekrana bas
restic dump latest /etc/hostname
# Geri alınan dosyaları canlı sistemle karşılaştır
diff -r /etc/nginx /tmp/geri-yukleme-testi/etc/nginx && echo "Fark yok"
'

Test bitince yalnız /tmp/geri-yukleme-testi dizinini kaldırın. Başka hiçbir yolu silmeyin.

Yeni sunucuya felaket kurtarma provası

Asıl sınav, sunucu tamamen kaybolmuş gibi davranmaktır. Geçici bir bulut sunucu açın ve şu adımları izleyin:

1. Restic'i kurun ve /etc/restic/restic.env dosyasını yalnız sunucu dışında sakladığınız bilgilerle yeniden oluşturun. Parolayı oradan bulamıyorsanız prova bu adımda başarısız olmuştur, bunu felaketten önce öğrenmek iyidir.
2. restic snapshots --host sunucu01 ile eski sunucunun snapshot'larını listeleyin.
3. restic restore latest --host sunucu01 --target /geri ile veriyi geri alın.
4. Veritabanı dökümünü yeni sunucudaki MariaDB ya da PostgreSQL'e yükleyin, web dosyalarını yerine koyun ve uygulamayı açın.
5. Geçen süreyi not edin. Bu süre, gerçek bir felakette işinizin ne kadar duracağını gösterir.

Fidye yazılımına karşı: silme yetkisi, sürümleme ve lifecycle

Saldırgan sunucuda root yetkisi alırsa ortam dosyasındaki anahtarı da ele geçirir. Bu anahtar bucket'taki her şeyi silebiliyorsa yedekler de gider. Restic yedek alırken kendi kilit dosyalarını silmek zorundadır. Bu yüzden S3 tarafında silme yetkisini tamamen kaldırmak her sağlayıcıda mümkün olmaz. Pratik çözüm birkaç katmandan oluşur:

• Bucket sürümlemeyi açın. Silinen ya da üzerine yazılan nesnenin eski sürümü saklanır. Saldırgan bir nesneyi sildiğinde yalnız bir silme işaretçisi oluşur.
• Lifecycle kuralı ekleyin. Eski sürümler belirli bir gün sayısından sonra kendiliğinden silinsin, örneğin 30 gün. Böylece maliyet kontrol altında kalır ve saldırıyı fark etmek için zamanınız olur.
• Sağlayıcınız destekliyorsa Object Lock kullanın. Kilit süresi boyunca nesneler hiçbir anahtarla silinemez.
• Prune'u ayrı bir makineden çalıştırın. Mümkünse sunucudaki anahtarın yetkisini daraltın. Saklama politikasını ve prune işlemini, daha geniş yetkili ayrı bir anahtarla bir yönetim makinesinden yürütün.

Kişisel veri işleyen işletmeler için yedeğin ayrı ve korumalı tutulması uyum açısından da önemlidir. Bu yaklaşımın kurumsal tarafı KVKK yedekleme sayfasında anlatılıyor.

Sık yapılan hatalar

Parolanın yalnız sunucuda durması. Depo parolası olmadan restic verisi çözülemez ve başka bir kurtarma yolu da yoktur. Parolayı en az iki ayrı yerde saklayın.

"repository is already locked" hatası. Bu çoğunlukla yarıda kesilmiş bir işlemden kalan eski bir kilittir. Önce restic list locks ile kilitleri görün ve gerçekten çalışan bir restic işlemi olmadığından emin olun (pgrep -a restic). Sonra restic unlock çalıştırın. Bu komut yalnız eski kilitleri kaldırır. --remove-all seçeneğini yalnız o anda başka bir sunucunun depoya yazmadığından eminseniz kullanın.

Büyüyen bucket. Yalnız forget çalışıp --prune unutulursa veri depoda kalmaya devam eder. Sürümleme açık ama lifecycle kuralı yoksa silinen nesnelerin eski sürümleri de birikir. İkisini birlikte kontrol edin.

Veritabanı dizinini doğrudan yedeklemek. Çalışan bir veritabanının dosyaları kopyalandığında tutarsız kalır. Döküm alın ya da veritabanının kendi yedekleme aracını kullanın.

Hata bildirimini kurmamak. Timer aylarca sessizce başarısız olabilir. OnFailure= birimini mutlaka kurun ve systemctl list-timers çıktısını ara ara kontrol edin.

Sık sorulan sorular

Restic ile S3 yedekleme yalnız AWS S3 ile mi çalışır?

Hayır. Restic, S3 API'sini destekleyen her depoyla çalışır: MinIO, Ceph tabanlı depolar ve barındırma firmalarının Object Storage hizmetleri. Depo adresine sağlayıcınızın uç noktasını yazmanız yeterlidir. Bazı sağlayıcılar bölge adı istediği için AWS_DEFAULT_REGION değişkenini tanımlamanız gerekebilir.

İlk yedekten sonra her gün ne kadar veri yüklenir?

Yalnız değişen ve depoda henüz bulunmayan parçalar yüklenir. Miktar, sunucudaki değişimin boyutuna bağlıdır. Her gün baştan oluşturulan sıkıştırılmış dökümler gibi büyük ve sık değişen dosyalar tekilleştirmeden daha az yararlanır. Depo boyutunu restic stats ile düzenli olarak izleyin.

Depo parolasını değiştirebilir miyim?

Evet. Restic birden fazla anahtarı destekler. restic key add ile yeni parolayı ekleyin, yeni parolayla erişebildiğinizi doğrulayın, ardından restic key remove ile eskisini kaldırın. Veri yeniden şifrelenmez, yalnız anahtar kaydı değişir.

check komutu ne sıklıkla çalışmalı?

Yapı kontrolü için haftada bir restic check yeterlidir. --read-data-subset ile her hafta verinin bir bölümünü okursanız zamanla deponun tamamını gözden geçirmiş olursunuz. Bu kontrol geri yükleme provasının yerini tutmaz, ikisini birlikte yapın.

Yedeklemeye ek olarak sunucu snapshot'ı almalı mıyım?

Hipervizör snapshot'ı hızlı geri dönüş için kullanışlıdır, ama çoğunlukla aynı altyapıda durur ve tek başına uzak kopya sayılmaz. Restic yedeği ise dosya düzeyindedir ve başka bir konumda tutulur. İkisi birbirini tamamlar.

Sonuç

Restic ile S3 yedekleme kurulumu birkaç dosyadan oluşur: bir ortam dosyası, bir yedek betiği ve iki systemd timer. Asıl iş, bu düzenin sürmesini sağlamaktır. Saklama politikasını prune ile birlikte çalıştırın, hata bildirimini açık tutun, parolayı sunucu dışında saklayın ve ayda bir gerçek bir geri yükleme provası yapın. Felaket anında yedeğin işe yarayacağını ancak bu dört alışkanlık gösterir.