Bir sistemden başka bir sisteme geçici dosya yazmadan veri yedeklemek gerektiğinde, restic'in --stdin ve --stdout bayrakları benim tercih ettiğim yöntemdir. Bu yaklaşım, şifrelenmiş yedek verilerini doğrudan SSH üzerinden akış olarak aktarmaya olanak tanır, böylece her iki uçta da disk G/Ç işleminden kaçınır ve ara depolama risklerine karşı maruz kalma azalır. Bu yöntem, başlıksız sistemler, konteynerler veya adlandırılmış kanallar ve canlı dökümler gibi durumlarda yedekleme yaparken özellikle faydalıdır.
stdin/stdout ile restic neden kullanılır
Diskten dosyaları yedeklemek yerine, veritabanı dökümleri, günlük akışları veya VM anlık görüntüleri gibi anlık olarak üretilen verileri korumam gerektiği sıkça ortaya çıkar. Bu verileri önce diske yazmak gecikme ve risk ekler. --stdin seçeneğiyle restic, yedek içeriğini standart girişten okur. --stdout seçeneğiyle ise şifrelenmiş arşivi bir depo yerine standart çıktıya yazar. Bu iki seçenek birleştirildiğinde, sistemler arasında veriyi güvenli bir şekilde boru (pipe) ile taşıyabilirim.
Örneğin, PostgreSQL dökümünü alıp, restic ile şifreleyip, yerel diske hiç dokunmadan doğrudan uzak bir depoya gönderebilirim:
pg_dump -Fc mydb | restic backup --stdin --stdout --tag=db-dump | ssh user@backup-server "restic -r /srv/backup/repo restore --stdin --target /tmp/latest"Bu yöntem, yedek akışını uçtan uca şifreli tutar ve şifrelenmemiş dökümlerin yerelde kalmasını önler.
SSH üzerinden yedekleme akışı
Gerçek güç, bu yöntemi SSH ile birleştirdiğimde ortaya çıkar. Yedeklemeyi yerel olarak çalıştırırım, şifreli akışı SSH üzerinden boru hattına yönlendiririm ve uzak restic örneği bu akışı doğrudan depoya yazar. Geçici dosya yok, ara senkronizasyon yok.
Canlı bir MySQL escravosunu LVM anlık görüntüleri ve akış yöntemiyle nasıl yedeklediğimi aşağıda gösteriyorum:
lvcreate -L 10G -s -n db_snap /dev/vg0/db_lv
mount /dev/vg0/db_snap /mnt/snap
mysqldump --single-transaction -A | gzip | restic backup --stdin --stdout --tag=mysql-dump | ssh backup@remote 'restic -r /srv/backup/mysql restore --stdin --target /dev/null 2>&1 | restic -r /srv/backup/mysql snapshots --last'
umount /mnt/snap
lvremove -f /dev/vg0/db_snapAnlık görüntüyü bağlarım, veritabanını dökümlerim, sıkıştırırım, restic'e stdin üzerinden beslerim, şifreler ve SSH üzerinden gönderirim. Uzak tarafta, bu akışı /dev/null'a geri yüklerim—sadece yedekleme işlemini tetiklemek için; restic akışı yine de bir anlık görüntü olarak kaydeder. Bu bir hile, ama çalışır çünkü restic, alıcı tarafında --stdout kullanılırken hedefi yok sayar—gerçekten bir geri yükleme yapmadığınız sürece.
Daha temiz bir yol, uzak tarafın doğrudan yedekleme modunda restic çalıştırmasını sağlamaktır:
mysqldump --single-transaction -A | gzip | restic backup --stdin --stdout --tag=mysql-dump | ssh backup@remote "restic -r /srv/backup/mysql backup --stdin --stdout --tag=mysql-dump"Wait—bu doğru değil. --stdin ve --stdout aynı komutta sadece bir boru hattı (pipe-through) yapıyorsanız kullanılabilir. Ben bunu düzeltmem gerekiyor.
Aslında, uzak taraf sadece normal bir restic backup komutu çalıştırıp stdin'den veri okumalıdır. Doğru desen şu şekildedir:
mysqldump --single-transaction -A | gzip | ssh backup@remote "restic -r /srv/backup/mysql backup --stdin --tag=mysql-dump"Burada, --stdin restic'e yedekleme verisini standart giriş (SSH boru hattı) üzerinden okumasını söyler, ve şifrelenmiş anlık görüntüleri normal şekilde depoya yazar. Alıcı tarafında --stdout gerekmez—bu seçenek sadece restic'in arşiv akışını çıktı olarak vermesini ve depoya kaydetmemesini istediğinizde kullanılır.
--stdout Ne Zaman Kullanılır
--stdout seçeneğini, yedek akışını incelemek, yönlendirmek veya yeniden şifrelemek istediğimde kullanırım. Örneğin, bir yedeği bir ara sunucu üzerinden göndermek veya boyutunu kaydetmek:
restic backup /var/www --stdout | pv | ssh user@archive 'restic -r /srv/backup/web restore --stdin --target /tmp/latest'Bu, pv ile transfer hızını izlememi sağlarken, sonuçta şifrelenmiş ve deduplicated bir yedek elde etmemizi sağlar.
Başka bir kullanım durumu: hava boşluğuna (air-gapped) sahip sistemler arasında aktarım. Güvenli bir ana makinede şifrelenmiş bir akış oluştururum, bunu stdout üzerinden çıkarılabilir medyaya yazarım, ardından fiziksel olarak yedek sitesine taşırım:
restic backup /etc --stdout --tag=etc-export > /mnt/usb/etc-backup-$(date +%F).tarDaha sonra, bunu şu şekilde içe aktarırım:
cat /mnt/usb/etc-backup-*.tar | restic -r /srv/backup/etc restore --stdin --target /tmp/restoredİpuçları ve dikkat edilmesi gerekenler
- İlk olarak, boru hattınızı küçük bir veri setiyle test edin. Yedekleme sırasında bozan bir boru, eksik anlık görüntüler bırakabilir.
- Akış yedeklemelerini daha sonra bulmak için
--tagseçeneğini kullanın:restic snapshots --tag=db-dump. - Veri sıkıştırılabilir ise (dökümler veya loglar gibi), şifrelemeden önce sıkıştırın—restic sıkıştırma yapmaz, bu yüzden bunu akışın üst kısmında yapın.
- Uzak tarafta
--stdinkullanıyorsanız, SSH oturumunun zaman aşımına uğramadığından emin olun; gerekirseServerAliveIntervalkullanın. - Aynı restic çağrısında
--stdoutve--stdinbirlikte kullanmaktan kaçının—nitekim bir boru olarak davranmak niyetiniz yoksa; bu iki seçeneği birlikte kullanmak kolayca karıştırılabilir.
Sonuç
Restic'in stdin/stdout üzerinden akış yedekleme, sadece disk alanı tasarrufu sağlamakla kalmaz; aynı zamanda saldırı yüzeyini azaltır, volatil verilerin gerçek zamanlı korunmasını sağlar ve otomatik işlem hatlarına entegrasyonu mümkün kılar. Veritabanlarını döküyorum, logları yönlendiriyorum veya bölge arasında anlık görüntüler taşıyorum olsun, bu model yedeklerimi ince, şifreli ve disk kullanmadan tutar.
Daha önceki restic ağ yedeklemeleriyle ilgili yazımda da belirttiğim gibi, anahtar nokta yedekleme akışını birincel sınıf üye olarak ele almak—şifreli, doğrulanabilir ve asla düz metin olarak diske yazmadan taşınabilir. Akışa yönelik düşünmeye başladığınızda, birçok zahmetli geçici çözüm kalmaz.
Kapak görseli: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/7580004/vector-people-illustrations-public-domain