Restic ile VPS yedekleme ve uzak sunucuya aktarma rehberi

Aynı sunucu üzerindeki yedek neden yedek sayılmaz

Restic, dosyalarınızın şifrelenmiş ve tekilleştirilmiş anlık görüntülerini (snapshot) başka bir yerdeki depoya gönderen ücretsiz ve açık kaynaklı bir yedekleme aracıdır: ikinci bir VPS, evdeki bir makine veya S3 uyumlu nesne depolama alanı. Bu kılavuz, Ubuntu 24.04 üzerinde kurulumdan SFTP üzerinden bir depoya, ilk yedeklemeye, gece çalışan bir systemd zamanlayıcısına, saklama politikasına ve tüm sistemin çalıştığını kanıtlayan geri yükleme tatbikatına kadar süreci açıklar. Hedef başka bir makine olmalıdır; çünkü aynı sunucuda yaşayan bir kopya, sunucu ile birlikte yok olur.

Yedeklenen makine üzerindeki bir backup/ dizini sizi yalnızca tek bir durumdan korur: yanlışlıkla bir dosyayı silmek. Disk arızasına karşı koruma sağlamaz, çünkü kopya zaten o disktedir. root yetkisine sahip bir saldırgana karşı koruma sağlamaz, çünkü saldırgan önce kopyaları siler. VPS'in kendisini kaldıran bir hesap hatasına karşı koruma sağlamaz. Dünyanın en verimsiz veri merkezi, verilerle aynı dizide duran backup_final_v2_REAL adlı bir tarball dosyası hakkında şakalar yapar ve bu şaka yerini bulur, çünkü birçoğumuz tam olarak bunu yaptık. Kural, veriyi makine dışında tutmaktır ve restic, bu kurala uymanın en zahmetsiz yoludur.

Dört maddede Restic

Repository (Depo). Restic'in veri yazdığı yerdir. Kendi formatında, şifrelenmiş veri bloklarıyla dolu bir dizindir ve yalnızca Restic tarafından okunabilir. Depoyu asla manuel olarak düzenlemeyin; onunla yalnızca Restic komutları ve -r adresi üzerinden iletişim kurun.

Snapshot (Anlık Görüntü). Yedeklediğiniz dosyaların belirli bir andaki görüntüsüdür. Her yedekleme işlemi bir snapshot oluşturur, her snapshot bağımsız olarak geri yüklenebilir ve her biri o andaki verilerinizin tam bir kopyası gibi davranır.

Deduplication (Tekilleştirme). Restic, dosyaları içeriğe dayalı parçalara böler ve yalnızca depoda bulunmayan parçaları yükler. İlk yedekleme her şeyi yükler; sonraki her çalıştırma ise yalnızca değişen kısımları yükler. 50 MB'ı değişmiş 20 GB'lık bir verinin gecelik snapshot'ı yaklaşık 50 MB yer kaplar; bu nedenle onlarca snapshot'ı saklamak oldukça ekonomiktir.

Varsayılan şifreleme. Bir Restic deposu her zaman şifrelidir (AES-256). Restic, --insecure-no-password (Restic 0.17.0 ve sonrası) bayrağını kullanmadığınız sürece boş bir parola ile depo oluşturmayı veya açmayı reddeder; bu nedenle bu kılavuzda kurulan bir depo, her komut için parolasını gerektirir. Yedekleme sunucusu veya depolama sağlayıcısı yalnızca şifrelenmiş veri bloklarını görür. Bunun kesin sonucu şudur: Parolayı kaybederseniz verileriniz kalıcı olarak ve tasarım gereği kaybolur. Parolanın bir kopyasını bu sunucunun dışında bir yerde saklayın. Bu konu o kadar önemlidir ki aşağıda iki kez daha vurgulanmıştır.

Ubuntu 24.04 üzerinde restic kurulumu

sudo apt update && sudo apt install -y restic
restic version

Ubuntu 24.04 üzerinde bu işlem restic 0.16.4 sürümünü kurar; güncel upstream sürümü ise 0.19.1'dir. Bu fark, bir LTS (uzun süreli destek) sürümünün paket sürümlerini dondurmasından kaynaklanır ve bu rehber özelinde bir sorun teşkil etmez: 0.16.4 sürümü bu rehberdeki tüm işlemleri gerçekleştirebilir. Hız iyileştirmeleri nedeniyle en yeni sürümü kullanmak isterseniz, restic projesinin GitHub yayınlar sayfasından resmi tekil binary derlemesini indirin, bunzip2 ile paketten çıkarın ve /usr/local/bin/restic dizinine kurun; restic kurulumu bundan ibarettir.

Depoyu SFTP üzerinden başka bir sunucuda oluşturma

Bir hedef makineye ihtiyacınız vardır: İkinci bir küçük VPS genellikle tercih edilen çözümdür; SSH sunucusu ve boş disk alanı olan herhangi bir makine iş görür. Restic, SFTP (SSH üzerinden dosya aktarımı) protokolünü desteklediği için yedekleme sunucusuna herhangi bir yazılım kurulması gerekmez. Bu kılavuzda yedekleme sunucusu 10.0.0.12, kullanıcı adı ise restic olarak belirlenmiştir. Bu kullanıcıya backup adını vermeyin: Ubuntu ve Debian kurulumlarında backup (uid 34, giriş kabuğu yok) adında ayrılmış bir sistem hesabı bulunur; bu nedenle adduser backup başarısız olur ve ssh backup@..., nologin dizinine düşer.

Gece çalışacak yedekleme işi, yedeklenen sunucuda root yetkisiyle çalışacaktır; bu nedenle root kullanıcısının yedekleme sunucusuna anahtar tabanlı giriş yapabilmesi gerekir. Saat 03:00'te parola girecek bir kullanıcı bulunmayacağından, parola içermeyen özel bir anahtar oluşturun ve bunu karşı tarafa kopyalayın:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

Anahtarlar sizin için yeniyse, SSH anahtar yönetimi temelleri modeli, izinleri ve bir anahtarın daha sonra nasıl iptal edileceğini açıklar.

Sırada depo parolası var. Yalnızca root kullanıcısının erişebileceği bir dosyaya güçlü bir parola oluşturun:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

Daha ileri gitmeden önce bu parolayı parola yöneticinize kopyalayın. Bu VPS çökerse, depo ve bu parola sayesinde her şeyi geri yükleyebilirsiniz; parola olmadan depo hiçbir işe yaramaz.

Depoyu başlatın:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

Alternatif hedef, ikinci bir makine çalıştırmak istemediğiniz durumlarda doğru tercih olan S3 uyumlu nesne depolamadır. S3 uyumlu herhangi bir bucket aynı şekilde çalışır; yalnızca adres ve iki kimlik bilgisi değişkeni değişir:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

init sonrasındaki her şey her iki hedef için de aynıdır. Bu kılavuzun geri kalanı SFTP adresini kullanır; kendi adresinizle değiştirin.

İlk yedekleme ve hariç tutulanlar

Tüm dosya sistemini değil, yeniden yükleyemeyeceğiniz verileri yedekleyin. İşletim sistemi yeniden kurulumla geri gelir; ancak yapılandırmanız ve verileriniz gelmez. Tipik bir VPS için bu, /etc, /home ve uygulamalarınızın durum bilgilerini tuttuğu /srv veya /var/www gibi dizinler anlamına gelir. Önbellekleri hariç tutun; çünkü bunlar büyüktür, her gün değişir ve kendilerini yeniden oluştururlar:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

İlk çalıştırma her şeyi yüklediği için biraz zaman alır. Aynı komutu tekrar çalıştırdığınızda işlem saniyeler içinde biter; birkaç dosyanın değiştiğini ve birkaç MiB eklendiğini raporlar. Bunun nedeni, tekilleştirme (deduplication) özelliğinin yalnızca yeni parçaları yüklemesidir. Mevcut yedeklerinizi listeleyin:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

Her anlık görüntü (snapshot) bir kimlik (ID), zaman ve içerdiği yolları gösterir. Geri yükleme işlemini bu kimlikleri kullanarak yaparsınız.

systemd zamanlayıcısı ile gece yedeklemeleri

Her komutta depo adresini yazmak zahmetli bir iştir ve manuel olarak başlatılan yedeklemeler bir ay içinde aksamaya başlar. Her iki sorun da tek bir betik ve tek bir zamanlayıcı ile çözülür. Betik, restic tarafından okunan RESTIC_REPOSITORY ve RESTIC_PASSWORD_FILE ortam değişkenlerini ayarlar, böylece içindeki her komut kısa kalır:

sudo nano /usr/local/bin/restic-backup.sh

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

forget ve check satırları sonraki iki bölümde açıklanmıştır. Şimdi zamanlama: betiği çalıştıran bir oneshot servisi ve onu her gece 03:00'te tetikleyen bir zamanlayıcı. Bir zamanlayıcı, cron satırına göre burada daha avantajlıdır çünkü çalışma kayıtları journal'a yazılır ve Persistent=true, sunucu kesinti sonrası tekrar açıldığında kaçırılan yedeklemeyi hemen başlatır.

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

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

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

[Install]
WantedBy=timers.target

Zamanlayıcıyı etkinleştirin, ardından servisi bir kez manuel olarak çalıştırın ve işlemleri izleyin:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

systemctl list-timers bir sonraki çalıştırma zamanını gösterir. Ayrıca bu birim dosyalarını manuel yazmak yerine oluşturabilirsiniz:

Takvim sözdizimi ve bir servisin taşıyabileceği güvenlik yönergeleri dahil olmak üzere bu iki dosyanın arkasındaki tam yapı, bir programı VPS üzerinde systemd servisi olarak çalıştırma bölümünde yer almaktadır.

Geri yüklemediğiniz sürece yedek bir söylentiden ibarettir

Bu cümleyi bir emir olarak kabul edin. Her gece başarıyla tamamlanan bir yedekleme işi, yalnızca işin çalıştığını kanıtlar; verilerinizin geri geleceğini kanıtlamaz. İki kontrol bu açığı kapatır.

Birincisi, betiğin zaten her gece çalıştırdığı restic check komutudur. Bu komut, depo yapısını ve dizini doğrular; böylece yedekleme sunucusundaki sessiz bozulmalar, geri yükleme gününde değil, bir sonraki gece tespit edilir. Ayda bir kez, gerçek verilerin rastgele onda birini indiren ve kriptografik olarak doğrulayan daha kapsamlı sürümü çalıştırın:

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

Alt küme her seferinde rastgele seçildiği için, Restic belgeleri, tekrarlanan çalıştırmaların kaç tane yaparsanız yapın her paket dosyasını kapsayacağının garantisi olmadığını açıkça belirtir. Aylık çalıştırmaların tam bir indirme maliyeti olmadan tüm depoyu taramasını istiyorsanız, sabit grup biçimini kullanın: bir ay --read-data-subset=1/10, sonraki ay 2/10 ve bu şekilde 10/10 değerine kadar devam edin. Restic, paket dosyalarını yaklaşık on eşit gruba böler ve yalnızca n grubunu kontrol eder; böylece on çalıştırmalık tam bir döngü her grubu bir kez okumuş olur.

İkincisi, geri yükleme tatbikatıdır. Yukarıdaki root kabuğunda kalarak, en son snapshot'tan gerçek bir dizini geçici bir konuma geri yükleyin ve canlı dosyalarla karşılaştırın:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

diff komutunun hiçbir çıktı vermemesi, her baytın aynı şekilde geri geldiği anlamına gelir; bu, geçerli olan tek kanıttır. İşlem sonrasında /srv/restore-drill dizinini silin. Bu tatbikatı aylık olarak yapın ve yılda bir veya iki kez tam sürümünü gerçekleştirin: en son snapshot'ın tamamını geçici bir VPS'ye geri yükleyin ve uygulamanızın gerçekten oradan başlayıp başlamadığını kontrol edin. Buna baskı altında ihtiyaç duyduğunuz gün, daha önce defalarca yaptığınız bir rutin olmasını istersiniz.

Saklama: forget ve prune kullanımı

Bir politika tanımlanmadığında snapshot'lar süresiz olarak birikir ve depo sürekli büyür. Betiğin forget satırı her gece bir politika uygular: --keep-daily 7 son yedi gün için günde bir, --keep-weekly 4 dört hafta için haftada bir ve --keep-monthly 6 altı ay için ayda bir snapshot saklar. Bir kural tarafından korunmayan her şey unutulur (forget).

forget tek başına yalnızca snapshot kayıtlarını kaldırır; veri parçaları (chunks) bir şey onları silene kadar depoda kalmaya devam eder. --prune komutunun işlevi budur: hiçbir snapshot tarafından referans verilmeyen parçaları bulur ve siler; disk alanı ancak bu işlemden sonra geri kazanılır. Prune işlemi depo üzerinde gerçek bir işlem gerçekleştirdiğinden, bazı kullanıcılar büyük depolarda forget komutunu her gece, --prune komutunu ise haftalık olarak çalıştırır; tipik VPS boyutları için her gece çalıştırmak yeterlidir.

Veritabanları: önce dump alın, ardından dump dosyasını yedekleyin

Restic, dosyaları okuduğu sırada kopyalar; ancak bir veritabanı kendi dosyalarına sürekli olarak yazma işlemi yapar. Yazma işlemi sırasında yakalanan canlı bir veritabanı dosyası, kopyalama işlemi yazma öncesi ve sonrası sayfaları karıştırdığı için bozuk bir veritabanı olarak geri yüklenir. Çözüm standarttır: veritabanı motorunun tutarlı bir dışa aktarım dosyası oluşturmasını sağlayın, ardından restic'in bu dosyayı yedeklemesine izin verin.

PostgreSQL için, restic-backup.sh dosyasının en üstüne, restic backup komutundan önce bir dump satırı ekleyin ve dump dizinini yedekleme yollarına dahil edin:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

mysqldump, MariaDB ve MySQL için aynı rolü üstlenir. Tüm sürecin işleyişine dair uygulamalı bir örnek için, Nextcloud yedekleme bölümü bakım modunu açar, Postgres dump'ını alır ve dosyaları, restic'in her gece sunucudan dışarı taşıması gereken tam ve tutarlı bir set olarak kopyalar. SQLite için de mantık aynıdır ancak daha basit bir yöntem kullanılır: Vaultwarden rehberi, db.sqlite3 dosyasının soğuk kopyasını almak için container'ı birkaç saniyeliğine durdurur ve restic, sunucudan bu arşivi gönderir.

FAQ

Restic yedekleri şifreli midir?

Evet, her zaman. Her Restic deposu AES-256 ile şifrelenir ve şifrelenmemiş bir mod yoktur. Restic ayrıca --insecure-no-password (Restic 0.17.0'dan beri mevcuttur) bayrağını kullanmadığınız sürece boş bir parolayı reddeder; bu nedenle bu kılavuzda kurulan bir depo, her komut için parolasını gerektirir. Depoyu barındıran makine veya sağlayıcı yalnızca şifrelenmiş veri bloklarını tutar, bu nedenle ele geçirilmiş bir yedekleme sunucusu dosyalarınızı ifşa etmez. Bunun bedeli kesindir: parola olmadan veriler kimse tarafından kurtarılamaz, bu yüzden parolanın bir kopyasını sunucudan uzakta saklayın.

Restic artımlı (incremental) yedekleme yapar mı?

Her Restic snapshot'ı, artımlı depolama maliyetiyle tam bir yedekleme gibi davranır. Restic dosyaları parçalara böler ve yalnızca depoda henüz bulunmayan parçaları yükler, bu nedenle gecelik bir çalıştırma yalnızca o gün değişen kısımları aktarır. Geleneksel artımlı şemaların aksine, yeniden oynatılacak bir zincir yoktur: herhangi bir snapshot doğrudan geri yüklenebilir ve eski bir snapshot'ı silmek asla daha yenisini bozmaz.

Restic yedeğinden dosyaları nasıl geri yüklerim?

Snapshot ID'sini bulmak için restic snapshots komutunu, ardından geri yüklemek için restic restore <id> --target /some/empty/dir komutunu çalıştırın; yalnızca bir kısmını geri yüklemek için --include /path ekleyin. latest, ID yerine kullanılabilir. Restic, orijinal dizin yapısını hedef altında yeniden oluşturur, bu nedenle /etc/ssh geri yüklemesi /some/empty/dir/etc/ssh içine yerleşir. Buna ihtiyaç duymadan önce pratik yapın, çünkü test edilmemiş bir yedek sadece bir söylentidir.

Restic yedeklemesini ne sıklıkla çalıştırmalıyım?

Gecelik çalıştırma bir sunucu için makul bir alt sınırdır ve tekilleştirme bunu ekonomik hale getirir: her çalıştırma yalnızca son yedeklemeden bu yana değişen parçaları yükler. Hızlı değişen veya bir gün bile kaybedilmesi zarar verecek veriler için aynı zamanlayıcı düzeniyle birkaç saatte bir yedekleme yapılabilir. Sıklık işin kolay kısmıdır; ayrıca düzenli olarak restic check çalıştırın ve aylık geri yükleme tatbikatı yapın, çünkü doğrulama içermeyen bir zamanlama sahte bir güvencedir.

Restic depo parolamı kaybedersem ne olur?

Yedekler kurtarılamaz. Restic'in şifrelemesinde arka kapı veya sıfırlama yoktur, bu nedenle parola yedeklerin kendisi kadar önemlidir. Parolanın bir kopyasını parola yöneticinizde ve yedeklenen sunucu dışında dayanıklı başka bir yerde saklayın. Erişiminizi kaybetmediğiniz sürece, restic key add komutu aynı depo için ikinci bir parola kaydedebilir, bu da size bir yedek sağlar.