Furkan İkkan English
Yazılara geri dön
Yazı

· Network & System Administrator

Restic ile Ağ Üzerinden Şifreli Yedekleme: --stdin ve --stdout Kullanımı

Tar, SSH ve restic ile geçici dosya kullanmadan ağ üzerinden şifreli yedekleme yapın. Disk kullanımını azaltın, saldırı yüzeyini küçültün ve uçtan uca koruma sağlayın.

BackupresticSSHtarencryptionstreaming

Benim ortamımda, uzak sistemleri yedeklerken diske geçici arşiv bırakmak istemiyorum. Bunun için restic'in --stdin ve --stdout bayraklarını tar ve SSH ile birlikte kullanıyorum. Böylece ağ üzerinden doğrudan şifreli yedek akışı oluşturabiliyorum. Bu yöntem, yerel geçici dosyaları ortadan kaldırarak G/Ç baskısını azaltır ve bir sistem tehlikeye girdiğinde veri sızdırmazlığını artırır.

Why pipe-based backups with restic make sense

Geleneksel yedek iş akışları genellikle şöyle olur: yerelde bir tarball oluşturulur, aktarılır, ardından restic backup komutu çalıştırılır. Bu yaklaşım disk kullanımını iki katına çıkarır ve şifrelenmemiş verinin diskte beklediği bir pencere oluşturur. SSH üzerinden tar çıktısını doğrudan restic'e borulayarak bu ara dosyayı ortadan kaldırıyorum. Veri aktarım sırasında ve depolama sırasında şifrelenir; restic asla şifresiz akışı diske yazmaz.

Bu yöntem, yerel depolama sınırlı veya geçici olan başsız sunucular, konteynerler veya sanal makineler için özellikle etkili olur. Ben, web sunucuları ve veritabanı dökümleri gibi sistemlerde gece yedekleri için bu yöntemi kullanıyorum; sadece geçici hazırlık için paylaşılan NFS veya kalıcı birimlere bağımlı olmak istemiyorum.

The core command: tar + SSH + restic

Yedek ana makinemden uzak bir host'tan veri çekip şifrelemek için çalıştırdığım tek satır komut şu şekildedir:

ssh user@remote-host "tar -czpf - /etc /var/www" | restic backup --stdin --stdin-filename backup.tar.gz

Uzak tar komutu, belirtilen klasörleri gzip ile sıkıştırarak bir tarball oluşturur ve stdout'a yönlendirir. SSH bu akışı yerel restic sürecine iletir; restic ise --stdin bayrağıyla bu akışı okur ve deposu içinde backup.tar.gz adlı bir dosya olarak ele alır. Herhangi bir anda yerel veya uzakta geçici dosya yazılmaz.

Yönü tersine çevirerek — yerelden uzakta yedeklemek için — şu komutu kullanıyorum:

tar -czpf - /etc /var/www | ssh user@backup-host "restic backup --stdin --stdin-filename backup.tar.gz"

Bu yöntem, yedek makinesinin gelen SSH izinleri sınırlı olsa da giden bağlantı kurabildiği durumlarda işe yarar.

Encryption and integrity: what’s actually protected

Restic, veriyi gönderenden önce istemci tarafında AES-256-GCM ile şifreler. Bu şifreleme, veri SSH üzerinden gönderilmeden önce gerçekleşir. Dolayısıyla SSH şifrelemesi kırılsa veya veri yakalansa, restic şifresi olmadan yedek okunamaz.

Önemli olan başka bir nokta da integrite kontrolüdür. Restic, geri yükleme sırasında veri bütünlüğünü doğrular. Aktarım sırasında veri bozulursa, yedek yüklenemez. Bu sayede SSH'nın gizliliğine güvenmek zorunda kalmadan uçtan uca koruma sağlarım.

Bu akışlardan gelen yedeklerin geri yüklenebilirliğini her zaman test ederim. Bunun için hızlı bir kontrol yaparım:

restic restore latest --target /tmp/test-restore

Eğer tarball sorunsuz çıkarılır ve dosyalar bozulmamışsa, boru hattı doğru çalışmıştır.

Handling large datasets and performance

Büyük dosya sistemleriyle çalışırken, tamponlama ve sıkıştırma ayarlarını ayarlıyorum. Tar tarafında, gzip'i paralel hale getirmek için --use-compress-program=pigz seçeneğini kullanıyorum:

ssh user@remote-host "tar -cf - --use-compress-program=pigz /var/log" | restic backup --stdin --stdin-filename logs.tar

Restic tarafında ise, iş saatleri içinde bağlantıyı doyurmamak için --limit-upload bayrağını kullanarak yükleme hızını sınırlıyorum:

restic backup --stdin --stdin-filename data.tar --limit-upload 5M

Ayrıca restic'in bellek kullanımını izliyorum. Akış tabanlı yöntem bellek tüketimini düşük tutar, ancak çok büyük tarballar deposu yavaş yanıt veriyorsa veya kilitliyse ani artışlar yaşanabilir. Bu durumu, restic sunucusu yük altında olduğunda gözlemledim; bu tür durumlarda yeniden deneme mantığı olan bir sarmaç betik kullanarak sorunu azaltıyorum.

Automation with cron and logging

Boru hattını, loglama ve çıkış kodu kontrolleri içeren bir betik içinde sarmalıyorum:

#!/bin/bash
set -eo pipefail

REMOTE="user@backup-host"
SOURCE="/etc /var/www"

ssh "$REMOTE" "tar -czpf - $SOURCE" | \
  restic backup --stdin --stdin-filename backup.tar.gz \
  --limit-upload 10M \
  --verbose

if [ $? -eq 0 ]; then
  logger -t restic-pipe "Backup successful"
else
  logger -t restic-pipe "Backup failed"
  exit 1
fi

Bu betiği cron üzerinden saat 02:00'te çalıştırıyorum. pipefail ayarı sayesinde, tar veya SSH başarısız olursa restic komutu kısmi veriyle devam etmez.

Limitations and gotchas

Bu yöntem, değişen dosyalarda blok seviyeli veri çıkarımlı yedeklemeler için ideal değildir. Her tar akışı yeni bir blob olarak göründüğü için, restic onu yeni bir dosya olarak ele alır. Veri çıkarımlı sadece tam olarak aynı tar çıktısı üretildiğinde çalışır; zaman damgası gibi değişkenler olduğu için bu nadiren gerçekleşir.

Gerçek veri çıkarımlı yedeklemeler için, uzak dosya sistemini SSHFS ile bağlayıp restic'in doğrudan taramasını tercih ederim. Ancak bu her zaman mümkün olmuyor — güvenlik duvarı kısıtlamaları veya FUSE desteği eksikliği gibi durumlarda boru hattı yöntemi güvenli ve verimli bir alternatif teklif eder.

Ayrıca, daha sonra snapshot'ları içe aktarmak veya manipüle etmek planlıyorsanız, --stdin-filename ile arbitrary isimler kullanmaktan kaçının. Geri yükleme mantığının öngörülebilir kalması için backup.tar.gz veya data.tar gibi tutarlı isimler kullanın.

When to choose this over other methods

Boru tabanlı yöntemi şu durumlarda tercih ederim:

  • Kaynak host'ta hazırlık için boş disk yoktur
  • Ağ bant genişliği sınırlıdır ama CPU sıkıştırma için kullanılabilir
  • SSH'ya güvenmek zorunda kalmadan uçtan uca şifreleme gerekir
  • Yedek makinesi bağlantıyı başlatabilir (ters SSH uygulanamaz)

Veritabanı dökümleri için, pg_dump veya mysqldump çıktısını doğrudan boru hattına vermeyi sık sık yaparım:

ssh db-host "pg_dump -Fc mydb" | restic backup --stdin --stdin-filename db.dump

İlkesi aynı: geçici dosya yok, akış şifreli, geri yükleme kontrol edilebilir.

Final thoughts

Restic'in stdin/stdout üzerinden akışlı yedekleme, Unix felsefesine uygun basit ama güçlü bir desendir: bir işi iyi yap ve borularla birleştir. Bu yöntem bende disk tasarrufu sağladı, saldırı yüzeyini azalttı ve sınırlı ortamlarda yedek otomasyonunu daha güvenilir hâle getirdi.

Eğer zaten restic kullanıyorsanız, tar-kopyala iş akışını boru hattıyla değiştirmeyi deneyin. İlk olarak geri yükleme yolunu test edin — sonra cron sessizce çalışsın.

Kapak görseli: f0976531950182 · PDM (Openverse / kamu malı) · https://www.flickr.com/photos/204310491@N07/55131284510