Restic ile VPS verilerini yedekleme rehberi

Neden aynı sunucu üzerindeki yedekleme bir yedekleme değildir

Restic; dosyalarınızın şifrelenmiş ve tekilleştirilmiş anlık görüntülerini başka bir yere, örneğin ikinci bir VPS'e, evdeki bir makineye veya S3 uyumlu nesne depolamaya gönderen ücretsiz ve açık kaynaklı bir yedekleme aracıdır. Bu kılavuz; Ubuntu 24.04 üzerinde kurulumdan SFTP üzerinden bir depolama birimine, ilk yedeklemeden gece çalışan systemd zamanlayıcısına, saklama politikasından sistemin çalıştığını kanıtlayan geri yükleme işlemine kadar tüm süreci yapılandırmaktadır. Hedef başka bir makine olmalıdır; çünkü aynı sunucuda bulunan bir kopya, sunucuyla birlikte yok olur.

Yedeklenen makine üzerindeki bir backup/ dizini sizi sadece tek bir durumdan korur: bir dosyanın yanlışlıkla silinmesi. Disk arızası durumunda veri kurtarılamaz, çünkü kopya da aynı disk üzerindedir. Root yetkisine sahip bir saldırgan durumunda veri kurtarılamaz, çünkü saldırgan önce kopyaları siler. VPS'in kendisinin silindiği hesap hatalarında veri kurtarılamaz. Dünyanın en az verimli veri merkezi ifadesi, verilerle aynı dizide bulunan backup_final_v2_REAL adlı bir tarball dosyasıyla şaka yapar; bu şaka, pek çoğumuzun tam olarak bunu yaşamış olması nedeniyle anlamlıdır. Kural, verinin makine dışında tutulmasıdır ve restic bu kurala uymanın en zahmetsiz yoludur.

Restic dört temel kavram

Repository. Restic'in veri yazdığı yerdir. Restic'e özgü formatta, şifrelenmiş blob dosyalarından oluşan bir dizindir ve yalnızca restic tarafından okunabilir. Bu dizin manuel olarak düzenlenmemelidir; işlemler restic komutları ve -r adresi aracılığıyla gerçekleştirilir.

Snapshot. Yedeklenen 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 verilerin o andaki tam bir kopyası gibi davranır.

Deduplication. Restic, dosyaları içeriğe dayalı parçalara (chunks) ayırır ve yalnızca repository'de bulunmayan parçaları yükler. İlk yedekleme tüm veriyi yükler; sonraki her işlem yaklaşık olarak sadece değişen veriyi yükler. 20 GB boyutundaki bir günlük snapshot içerisinde 50 MB veri değişmişse, maliyet yaklaşık 50 MB olur; bu nedenle onlarca snapshot tutmak düşük maliyetlidir.

Encryption by default. Bir restic repository'si her zaman şifrelidir (AES-256) ve her komut için repository şifresi gereklidir. Yedekleme sunucusu veya depolama sağlayıcısı yalnızca şifrelenmiş blob dosyalarını görür. Bunun kesin sonucu şudur: şifre kaybedilirse veriler kalıcı olarak ve tasarım gereği silinmiş sayılır. Şifrenin bir kopyasını bu sunucunun dışında bir yerde saklayın. Bu konu aşağıda iki kez daha vurgulanacaktır.

Ubuntu 24.04 üzerine restic kurulumu

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

Ubuntu 24.04 üzerinde restic 0.16.4 sürümü kurulur; ancak güncel sürüm 0.19.1'dir. Bu farkın sebebi, bir LTS (long term support) sürümünün paket versiyonlarını sabitlemesidir. Bu durum bir sorun teşkil etmez: 0.16.4 sürümü bu kılavuzdaki tüm işlemleri gerçekleştirmektedir. Performans iyileştirmeleri için en yeni sürümü istiyorsanız, restic projesinin GitHub releases sayfasından resmi tekil-binary dosyasını indirin, bunzip2 ile açın ve /usr/local/bin/restic dizinine kurun; restic kurulumu için başka bir işlem gerekmemektedir.

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

Bir hedef makineye ihtiyaç vardır: genellikle ikinci bir küçük VPS kullanılır; SSH sunucusu ve boş disk alanı olan herhangi bir cihaz uygundur. Restic, SFTP (SSH üzerinden dosya aktarımı) protokolünü kullanır, bu nedenle yedekleme sunucusuna herhangi bir yazılım kurulmasına gerek yoktur. Bu kılavuzda yedekleme sunucusu, restic adlı kullanıcıya sahip 10.0.0.12 makinesidir. Bu kullanıcıya backup ismini vermeyin: Ubuntu ve Debian, her kurulumda backup (uid 34, giriş shell'i yok) adlı ayrılmış bir sistem hesabı ile gelir; bu durum adduser backup işleminin hata vermesine ve ssh backup@... verilerinin nologin dizinine düşmesine neden olur.

Gece çalışan işler, yedeklenen sunucuda root yetkisiyle çalışacaktır; bu nedenle root kullanıcısının yedekleme sunucusuna anahtar ile giriş yapabilmesi gerekir. Saat 03:00'te parola girecek bir kullanıcı olmayacağı için parolası olmayan özel bir anahtar oluşturun ve bunu 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

Anahtar kullanımı konusunda yeniyseniz, SSH anahtar yönetimi temelleri modeli, izinleri ve bir anahtarın daha sonra nasıl iptal edileceğini açıklar.

Sıradaki adım, depo parolasıdır. Güçlü bir parola oluşturun ve bunu sadece root'un erişebileceği bir dosyaya kaydedin:

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

Daha fazla ilerlemeden önce bu parolayı parola yöneticinize kopyalayın. Eğer bu VPS çökerse, depo ve bu parola her şeyi geri getirir; parola olmadan depo hiçbir şeyi geri getiremez.

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 seçim olan S3 uyumlu nesne depolamadır (object storage). S3 uyumlu tüm bucket'lar aynı şekilde çalışır; sadece adres ve iki kimlik doğrulama 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 tüm adımlar her iki hedef için de aynıdır. Bu kılavuzun geri kalanı SFTP adresini göstermektedir; kendi adresinizle değiştirin.

İlk yedekleme, hariç tutulanlar ile

Tüm dosya sistemini değil, yeniden yüklenemeyecek verileri yedekleyin. İşletim sistemi yeniden yükleme ile geri gelir; ancak konfigürasyonlarınız ve verileriniz gelmez. Tipik bir VPS için bu durum /etc, /home ve uygulamalarınızın durum bilgisini tuttuğu /srv veya /var/www gibi dizinler anlamına gelir. Önbellekleri (cache) hariç tutun; çünkü bunlar büyüktür, her gün değişirler 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 uzun sürer. Aynı komutu tekrar çalıştırın; yeni eklenen birkaç dosya ve birkaç MiB veri bildirerek saniyeler içinde tamamlanacaktır, çünkü deduplication işlemi yalnızca yeni chunk'ları yükler. Mevcut olanları listeleyin:

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

Her snapshot bir ID, bir zaman ve içerdiği yolları gösterir. Geri yükleme işlemleri bu ID'ler üzerinden yapılır.

systemd timer ile gece çalışmaları

Her komutta depo adresini yazmak zahmetlidir ve manuel olarak çalıştırılan yedekleme işlemleri bir ay içinde aksamaya başlar. Her iki sorun da bir script ve bir timer ile çözülür. Script, restic tarafından okunan RESTIC_REPOSITORY ve RESTIC_PASSWORD_FILE ortam değişkenlerini ayarlar; böylece script 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çıklanmaktadır. Planlama şu şekildedir: scripti çalıştıran bir oneshot servisi ve her gece saat 03:00'te tetiklenen bir timer. Bu senaryoda timer, cron kullanımından daha avantajlıdır; çünkü loglar journal'a yazılır ve Persistent=true sayesinde sunucu kesintiden sonra açıldığında kaçırılan yedekleme işlemi hemen gerçekleştirilir.

# /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

Timer'ı etkinleştirin, ardından servisi manuel olarak bir kez çalıştırarak işleyişi gözlemleyin:

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ışmanın ne zaman tetikleneceğini gösterir. Unit dosyalarını manuel yazmak yerine şu komutla oluşturabilirsiniz:

Takvim sözdizimi ve bir servisin taşıyabileceği sıkılaştırma direktifleri dahil olmak üzere bu iki dosyanın arkasındaki tam yapı bir programı VPS üzerinde systemd servisi olarak çalıştırma içeriğinde yer almaktadır.

Yedekleme, geri yüklenene kadar sadece bir söylentidir

Bu cümleyi bir kural olarak kabul edin. Her gece başarıyla tamamlanan bir yedekleme işi, sadece işin çalıştığını kanıtlar; verilerin geri geleceğini kanıtlamaz. Bu boşluğu iki kontrol yöntemi kapatır.

Birincisi, script tarafından her gece halihazırda çalıştırılan restic check işlemidir. Bu işlem, depo yapısını ve indeksi doğrular. Böylece yedekleme sunucusundaki sessiz veri bozulmaları, geri yükleme gününde değil, bir sonraki gece tespit edilir. Ayda bir kez, gerçek verinin rastgele %10'luk bir kısmını indirip 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ğinden, aylık çalıştırmalar tam bir indirme işlemi yapmaya gerek kalmadan tüm depo üzerinde ilerler.

İkincisi, geri yükleme tatbikatıdır. Yukarıdaki kök kabukta (root shell), en son anlıktan (snapshot) 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 çıktısının boş olması, her baytın özdeş şekilde geri geldiği anlamına gelir; bu, geçerli olan tek kanıttır. İşlemden sonra /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ığın tamamını geçici bir VPS üzerine geri yükleyin ve uygulamanın bu anlıktan gerçekten başlayıp başlamadığını kontrol edin. Bu işlemin baskı altında çalışması gereken gün geldiğinde, bu sizin halihazırda uyguladığınız bir rutin olmalıdır.

Retention: forget ve prune

Bir politika tanımlanmadığında, snapshotlar sürekli birikir ve repository boyutu sürekli artar. Script içindeki forget satırı her gece bir politika uygular: --keep-daily 7 son yedi gün için her güne bir snapshot, --keep-weekly 4 dört hafta için her haftaya bir snapshot ve --keep-monthly 6 altı ay için her aya bir snapshot saklar. Bir kural tarafından korunmayan tüm veriler silinir.

forget tek başına sadece snapshot kayıtlarını kaldırır; veri chunkları, bir işlem onları silene kadar repository içinde kalmaya devam eder. --prune ise şu işlemi yapar: artık hiçbir snapshot referansı bulunmayan chunkları bulur ve siler; disk alanı bu işlemle geri kazanılır. Prune işlemi gerçek repository temizliğini gerçekleştirir. Bu nedenle büyük repository kullananlar forget işlemini her gece, --prune işlemini ise haftalık olarak çalıştırır; tipik VPS boyutlarında her gece çalıştırmak yeterlidir.

Veritabanları: Önce dump alın, sonra dump dosyasını yedekleyin

Restic dosyaları okurken kopyalar, veritabanları ise dosyalarına sürekli veri yazar. Yazma işlemi sırasında yakalanan canlı bir veritabanı dosyası bozuk olarak geri yüklenir; çünkü kopya, yazma işleminden önceki ve sonraki sayfaları birbirine karıştırır. Standart çözüm şudur: Veritabanı motorunun tutarlı bir dışa aktarım (dump) dosyası oluşturması sağlanır ve ardından restic bu dosyanın yedeğini alır.

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ı görevi görür. Tüm desenin işlevsel bir örneği için, Nextcloud yedekleme bölümü bakım modunu açar, Postgres verilerini dump eder ve dosyaları tek bir tutarlı set olarak kopyalar; bu set, restic'in her gece sistemden alması gereken settir. SQLite için de benzer mantık geçerlidir ancak daha basit bir yöntem kullanılır: Vaultwarden kılavuzu db.sqlite3 dosyasının soğuk bir kopyasını almak için konteyneri birkaç saniyeliğine durdurur ve restic bu arşivi sunucudan taşır.

FAQ

restic yedekleri şifreli midir?

Evet, her zaman. Her restic repository AES-256 ile şifrelenir; şifresiz bir mod bulunmamaktadır ve her komut repository şifresini gerektirir. Repository'yi saklayan makine veya sağlayıcı yalnızca şifrelenmiş blob'lara sahiptir, bu nedenle yedekleme sunucusunun ele geçirilmesi dosyalarınızı açığa çıkarmaz. Bu durum mutlak bir takastır: şifre olmadan veriler hiç kimse tarafından kurtarılamaz, bu nedenle şifrenin bir kopyasını sunucudan uzakta saklayın.

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

Her restic snapshot, artımlı depolama maliyetiyle tam yedekleme gibi davranır. Restic, dosyaları chunk'lara ayırır ve yalnızca repository'nin daha önce saklamadığı chunk'ları yükler; bu sayede gece yapılan bir işlem yalnızca o gün değişen verileri aktarır. Geleneksel artımlı şemaların aksine, yeniden oynatılacak bir zincir yoktur: herhangi bir snapshot doğrudan geri yüklenir ve eski bir snapshot'ın silinmesi yeni bir snapshot'ı bozmaz.

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

Snapshot ID'sini bulmak için restic snapshots, 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, hedef dizin altında orijinal dizin yapısını yeniden oluşturur; bu nedenle /etc/ssh geri yüklemesi /some/empty/dir/etc/ssh dizinine yapılır. İhtiyaç duyulmadan önce bu işlemi deneyin, çünkü test edilmemiş bir yedek sadece bir söylentidir.

restic backup komutu ne sıklıkla çalıştırılmalıdır?

Bir sunucu için gece kullanımı makul bir alt sınırdır ve deduplication sayesinde bu işlem düşük maliyetlidir: her çalıştırma yalnızca son işlemden bu yana değişen chunk'ları yükler. Hızlı değişen veya bir günlük kaybın bile zarar vereceği veriler için aynı zamanlayıcı deseniyle birkaç saatte bir çalıştırma yapılabilir. Sıklık işin kolay kısmıdır; ayrıca düzenli olarak restic check komutunu ve ayda bir kez geri yükleme provasını çalıştırın, çünkü doğrulama içermeyen bir takvim sahte bir güven sağlar.

restic repository şifresini kaybedersem ne olur?

Yedekler kurtarılamaz. Restic'in şifrelemesinde bir arka kapı veya sıfırlama seçeneği yoktur, bu nedenle şifre yedeklerin kendisi kadar önemlidir. Bir kopyasını şifre yöneticinizde ve yedeklenen sunucu dışında dayanıklı başka bir yerde saklayın. Erişiminize sahipken, aynı repository için ikinci bir şifre tanımlayabilen restic key add komutunu kullanarak yedek bir şifre oluşturabilirsiniz.