rsync ile Yedeği Başka Makineye Aktarmak: Güvenli, Kısıtlı ve Doğrulanabilir

Yedeğiniz, yedeklediğiniz makineyle aynı yerde duruyorsa, yangın, hırsızlık, fidye yazılımı ya da basit bir disk arızası ikisini birden götürür. 3-2-1 kuralının "bir kopya başka yerde" maddesi tam olarak bunu söyler. Bu yazıda, yerelde oluşturulmuş yedek dosyalarını başka bir makineye aktarmanın en yaygın aracı olan rsync'i, SSH üzerinden ve güvenli biçimde kullanmayı anlatıyoruz.

rsync neden iyi bir araç?

rsync, iki konum arasında yalnızca değişen kısımları gönderir. İlk aktarım uzun sürebilir, sonrakiler çok kısadır. Kesilen bir aktarım kaldığı yerden devam eder (--partial), dosya izinleri ve zamanları korunur ve her şey SSH ile şifrelenir. Hem Linux hem macOS'ta bulunur; Windows'ta ise OpenSSH istemcisiyle gelen scp ya da WSL üzerinden benzer iş görülür.

Temel komut

rsync -avh --partial --progress -e ssh \
  /home/kullanici/yedekler/  yedek@uzak-makine:/srv/yedekler/pi01/

Parametrelerin anlamı:

• -a arşiv modu: alt dizinler, izinler, zaman damgaları ve semboller korunur.
• -v ayrıntılı çıktı, -h insan okunur boyutlar.
• --partial yarım kalan aktarımı saklar ve devam ettirir.
• Kaynak yolun sonundaki / önemlidir: dizinin içeriğini kopyalar. / olmasaydı dizinin kendisi de hedefte oluşurdu.

Her zaman önce deneme çalıştırın: --dry-run (kısaca -n) hiçbir şey kopyalamadan neyin yapılacağını listeler.

rsync -avhn /home/kullanici/yedekler/ yedek@uzak-makine:/srv/yedekler/pi01/

--delete konusunda dikkatli olun

--delete, kaynakta artık olmayan dosyaları hedeften de siler; böylece hedef kaynağın bire bir kopyası olur. Ama bu aynı zamanda tehlikelidir: kaynakta bir hata olursa (örneğin yedek dizini boşalırsa ya da yanlış bağlanırsa), rsync bunu "her şeyi sil" diye yorumlayıp uzak yedeğinizi de silebilir. Yedek amaçlı kullanımda iki güvenli yaklaşım vardır:

1. --delete kullanmayın; hedefteki eski yedekleri ayrı bir rotasyon betiğiyle (örneğin 30 günden eskileri) siliniz.
2. Kullanacaksanız --max-delete=10 gibi bir sınır koyun; rsync bu sayıdan fazla silme gerektiğinde durur.

Yedeğin kendisini rotasyonlu üretiyorsanız (tarihli dosya adları), kaynak zaten eski dosyaları temizler ve uzak tarafta saklama süresini farklı tutmak isteyebilirsiniz.

Şifresiz giriş: yalnızca bu iş için bir anahtar

Otomatik çalışacak bir betik parola soramaz; bu yüzden SSH anahtarı gerekir. Ama bu anahtarla bağlanan kullanıcının uzak makinede her şeyi yapabilmesi istenmez. Çözüm: yalnızca yedek amaçlı ayrı bir anahtar ve kısıtlı kullanıcı.

Yedek gönderecek makinede anahtar üretin (parolasız, yalnızca bu iş için):

ssh-keygen -t ed25519 -f ~/.ssh/yedek_anahtar -C "pi01-yedek" -N ""

Uzak makinede, yedek kullanıcısının ~/.ssh/authorized_keys dosyasına genel anahtarı şu seçeneklerle ekleyin:

restrict,command="rrsync /srv/yedekler/pi01" ssh-ed25519 AAAA... pi01-yedek

restrict, terminal, port yönlendirme ve benzeri her şeyi kapatır. rrsync, rsync paketiyle gelen bir sarmalayıcıdır; bu anahtarın yalnızca belirtilen dizine rsync yapmasına izin verir. (Betiğin yolu dağıtıma göre değişebilir; which rrsync ile bulun.) Böylece anahtar çalınsa bile saldırgan o makinede komut çalıştıramaz, yalnızca o dizine dosya gönderebilir. Çok iyi bir ek önlem olarak, uzak makinede gönderilen dosyaların üzerine yazılmasını önlemek için dosya sistemi anlık görüntüleri (snapshot) ya da sürümlü depolama kullanmayı düşünün.

Şimdi komuta anahtarı belirtin:

rsync -avh --partial -e "ssh -i ~/.ssh/yedek_anahtar" \
  /home/kullanici/yedekler/ yedek@uzak-makine:/

rrsync hedef yolu kendi kökü sayar; bu yüzden uzak yol / olur ve gerçekte /srv/yedekler/pi01 içine yazılır.

Aktarımı doğrulamak

"rsync hata vermedi" ile "yedek sağlam geldi" aynı şey değildir. Kontrol edin:

# Gönderen tarafta
cd /home/kullanici/yedekler && sha256sum *.sql.gz > SHA256SUMS

SHA256SUMS dosyası da rsync ile gönderilir. Uzak tarafta (ya da yedeği geri çektiğiniz makinede) doğrulama:

cd /srv/yedekler/pi01 && sha256sum -c SHA256SUMS

Çıktıda her satır OK olmalıdır. Ayrıca zaman zaman yedeği gerçekten geri yükleyip denemek gerekir; özet doğrulaması yalnızca dosyanın bozulmadan geldiğini söyler, içeriğin kullanışlı olduğunu değil.

Betik hâline getirmek

#!/bin/bash
set -euo pipefail
exec 9>/tmp/yedek-gonder.lock
flock -n 9 || { echo "baska bir aktarim suruyor"; exit 0; }

KAYNAK=/home/kullanici/yedekler/
HEDEF=yedek@uzak-makine:/
ANAHTAR=/home/kullanici/.ssh/yedek_anahtar

( cd "$KAYNAK" && sha256sum *.sql.gz > SHA256SUMS )
rsync -avh --partial --timeout=120 -e "ssh -i $ANAHTAR -o BatchMode=yes" "$KAYNAK" "$HEDEF"
echo "TAMAM $(date -Is)"

flock aynı betiğin iki kez üst üste çalışmasını engeller; --timeout ve BatchMode ise ağ sorununda ya da anahtar sorununda betiğin sonsuza kadar asılı kalmasını önler. Betiği systemd timer ile gece yedeği alındıktan hemen sonra çalıştırın. Başarısız olursa sizi bilgilendirmesi için çıkış kodunu izleyin (ör. günlük özet e-postası içinde "son aktarım zamanı").

Windows tarafı

Yedeği bir Windows makinede toplamak istiyorsanız iki yol vardır. İlki, Windows'un OpenSSH sunucusunu etkinleştirip Pi'den scp ile göndermektir. İkincisi (genellikle daha güvenli), Windows makinenin Pi'ye bağlanıp yedeği çekmesidir: böylece yedek sunucusundan üretim sistemine erişim yoktur ve Pi tehlikeye girerse saldırgan yedeklerinize ulaşamaz. Windows 10/11'de scp ve ssh yerleşiktir; bir zamanlanmış görev (Task Scheduler) ile her gece çalıştırabilirsiniz. Çekme yaklaşımı, fidye yazılımı senaryolarında önemli bir avantajdır.

Yedekte kişisel veri varsa

Uzak makine de bir veri deposudur. Disk şifrelemesi, erişimin kısıtlanması ve saklama süresinin tanımlanması gerekir; veritabanı yedeği kişisel veri içeriyorsa bu yedeklerin de KVKK kapsamında olduğunu unutmayın (ayrıntılar).

Kontrol listesi

• Uzak kopya ayrı bir makinede (ve mümkünse ayrı bir yerde).
• Yalnızca bu iş için, kısıtlı bir anahtar kullanılıyor.
• --delete kullanılmıyor ya da --max-delete ile sınırlandırılmış.
• Aktarım sonrası özet doğrulaması yapılıyor.
• En az üç ayda bir gerçek geri yükleme denemesi yapılıyor.
• Betik başarısız olduğunda biri haberdar oluyor.