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. Burası, Restic'in kendi formatında, şifrelenmiş veri bloklarıyla dolu bir dizindir ve yalnızca Restic tarafından okunabilir. Depo üzerinde manuel değişiklik yapılmaz; işlemler Restic komutları ve -r adresi üzerinden yürütülür.

Snapshot (Anlık Görüntü). Yedeklediğiniz dosyaların belirli bir zamandaki durumudur. Her yedekleme işlemi bir snapshot oluşturur; her snapshot bağımsız olarak geri yüklenebilir ve o anki 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 tüm veriyi yükler; sonraki her çalıştırma ise yalnızca değişen kısımları yükler. 50 MB'lık kısmı değişen 20 GB'lık bir verinin gecelik snapshot'ı yaklaşık 50 MB yer kaplar; bu nedenle onlarca snapshot tutmak oldukça ekonomiktir.

Varsayılan şifreleme. Bir Restic deposu her zaman şifrelidir (AES-256) ve her komut için depo parolası gerekir. Yedekleme yapılan sunucu 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 erişilemez hale gelir. Parolanın bir kopyasını bu sunucunun dışında bir yerde saklayın. Bu konu o kadar kritiktir 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.

Yedekleme, geri yükleme yapana kadar sadece bir söylentidir

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

İlk olarak, betiğin zaten her gece çalıştırdığı restic check. Bu işlem, 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 fark 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, aylık çalıştırmalar tam bir indirme maliyetine katlanmadan tüm depoyu zamanla taramış olur.

İkinci olarak, geri yükleme tatbikatı. Yukarıdaki root kabuğunda kalarak, en son anlık görüntüden gerçek bir dizini geçici bir konuma geri yükleyin ve bunu 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 çıktısının boş olması, 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 anlık görüntünün tamamını geçici bir VPS üzerine geri yükleyin ve uygulamanızın bu yedekten gerçekten başlayıp başlamadığını kontrol edin. Baskı altında bu işleme ihtiyaç duyduğunuz gün, bunun 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; şifrelenmemiş bir mod yoktur ve her komut depo 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 karşılığı kesindir: parola olmadan veriler kimse tarafından kurtarılamaz, bu yüzden parolanın bir kopyasını sunucudan ayrı bir yerde saklayın.

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

Her restic snapshot'ı, artımlı depolama maliyetiyle tam yedekleme gibi davranır. Restic dosyaları parçalara ayırır ve yalnızca depoda henüz bulunmayan parçaları yükler; bu sayede gece yapılan bir yedekleme işlemi yaklaşık olarak o gün değişen veriyi aktarır. Geleneksel artımlı yedekleme şemalarının aksine, tekrar oynatılması gereken bir zincir yoktur: herhangi bir snapshot doğrudan geri yüklenebilir ve eski bir snapshot'ı silmek daha yeni olanları asla bozmaz.

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

Snapshot kimliğini (ID) bulmak için restic snapshots komutunu, 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 parametresini ekleyin. latest, kimlik yerine kullanılabilir. Restic, orijinal dizin yapısını hedef altında yeniden oluşturur; bu nedenle /etc/ssh yolunu geri yüklemek, dosyaları /some/empty/dir/etc/ssh dizinine yerleştirir. Buna ihtiyaç duymadan önce pratik yapın, çünkü test edilmemiş bir yedek sadece bir söylentidir.

Ne sıklıkla restic yedeklemesi çalıştırmalıyım?

Bir sunucu için gece yedeklemesi makul bir alt sınırdır ve tekilleştirme (deduplication) bunu ucuz hale getirir: her çalıştırma, bir öncekinden bu yana değişen parçaları yükler. Hızlı değişen veya bir günlük kaybın bile zarar vereceği 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 komutunu ç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 seçeneği 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. Depoya erişiminiz devam ederken, restic key add komutu ile aynı depo için ikinci bir parola tanımlayarak yedek bir anahtar oluşturabilirsiniz.