snapshot `cp -al` yang tautan kerasnya diarahkan ke file baru saat diedit


11

Saya mencoba mengambil snapshot dari folder besar secara teratur.

Saya telah membaca di sini: http://www.mikerubel.org/computers/rsync_snapshots/#Incremental
yang cp -almengambil snapshot folder hanya dengan menyalin tautan keras.

Itu semua hebat, tetapi masalahnya adalah dalam snapshot ini, jika saya mengubah file, itu berubah di semua snapshot. Yang saya inginkan sebagai gantinya adalah agar sistem membuat file baru saat diubah dan menautkannya sebagai gantinya. Dengan begitu setiap snapshot tidak akan menjadi tidak valid pada pengeditan file pertama.

Bagaimana saya bisa mencapainya?

ps saya mencoba rsync -a --delete --link-dest=../backup.1 source_directory/ backup.0/, tetapi memiliki masalah yang sama.

Jawaban:


7

Begitulah cara kerja hardlink. Tapi, ada beberapa cara untuk mengatasinya:

Beberapa pilihan muncul di pikiran:

  • Gunakan sistem file dengan dukungan untuk file copy-on-write, seperti btrfs. Tentu saja, jika Anda menggunakan btrfs, Anda hanya akan menggunakan snapshot asli ... Jika sistem file Anda mendukungnya, Anda dapat menggunakannya cp --reflink=always. Sayangnya, ext4 tidak mendukung ini.
  • Hanya bagikan hardlink di snapshot Anda, bukan dengan yang asli. Artinya, pertama kali Anda melihat versi file yang diberikan, salin ke snapshot. Tapi lain kali, tautkan ke yang ada di snapshot sebelumnya. (Tidak yakin program apa yang saya gunakan untuk melakukan ini — satu dekade yang lalu — tetapi pencarian ternyata dirvish, obnam, storebackup, dan rsnapshot)
  • Bergantung pada bagaimana file Anda sedang diubah, Anda mungkin dapat menjamin bahwa temp / rename tulis digunakan untuk mengubahnya, maka itu akan merusak hardlink — sehingga versi dalam snapshot akan tetap murni. Ini kurang aman, karena bug dapat merusak snapshot Anda.
  • Ambil snapshot LVM dari seluruh sistem file.

Tentu saja, ada opsi lain — gunakan sistem cadangan yang tepat. Kebanyakan dari mereka dapat mengatur untuk hanya membuat cadangan file yang diubah.


Apa yang Anda rekomendasikan sebagai cara untuk membuat cadangan folder besar?
Hermann Ingjaldsson

Saya berpikir menggunakan rsync ke server yang memiliki cronjob untuk melakukan cp -al secara teratur untuk snapshot .. bersama rsync-ing dan seterusnya untuk bahkan lebih banyak salinan. Bagaimana itu terdengar?
Hermann Ingjaldsson

@HermannIngjaldsson, itu tergantung pada bagaimana Anda melakukan backup. Secara pribadi, saya hanya akan menambahkannya ke pengaturan Bacula saya — tetapi saya tidak akan merekomendasikan itu kecuali Anda memiliki banyak mesin untuk membuat cadangan, atau sudah tahu Bacula. Jadi, saya kira saya sarankan Anda mencoba rsnapshot terlebih dahulu.
derobert

rsnapshotitu baik
developerbmw

4

Apa yang Anda cari adalah bentuk copy-on-write , di mana banyak file yang memiliki konten yang sama menggunakan ruang yang sama pada disk hingga salah satu dari mereka dimodifikasi. Hard link hanya menerapkan copy-on-write jika aplikasi yang melakukan penulisan menghapus file dan membuat file baru dengan nama yang sama (yang biasanya dilakukan dengan membuat file baru dengan nama yang berbeda, kemudian memindahkannya ke tempatnya). Aplikasi yang Anda gunakan ternyata tidak melakukan ini: itu menimpa file yang ada.

Beberapa aplikasi dapat dikonfigurasi untuk menggunakan strategi penggantian. Beberapa aplikasi menggunakan strategi penggantian secara default, tetapi gunakan strategi timpa ketika mereka melihat file dengan banyak tautan keras, tepatnya agar tidak memutus tautan keras. Teknik snapshot Anda saat ini akan berfungsi jika Anda dapat mengonfigurasi aplikasi Anda untuk menggantikan alih-alih menimpa.

Fl-cow memodifikasi program untuk secara sistematis menggunakan strategi penggantian pada file dengan banyak tautan keras.

Atau, Anda dapat menyimpan file Anda di sistem file yang melakukan copy-on-write atau deduplication, atau memiliki fitur snapshot, dan tidak khawatir tentang tautan keras: Btrfs atau Zfs . Bergantung pada skema partisi Anda, menggunakan snapshot LVM dapat menjadi pilihan.

Rekomendasi saya adalah menggunakan alat snapshot yang tepat. Membuat cadangan yang andal ternyata sangat sulit. Anda mungkin ingin rsnapshot .


2

Berikut ini adalah skrip ruby ​​yang saya tulis yang membungkus "cp -al" dan rsync menjadi skrip yang bagus yang dapat dijalankan secara manual atau melalui cron. Tujuan dapat lokal atau jauh (via ssh):

Ghetto Timemachine

Jawaban dasar untuk pertanyaan Anda, seperti yang disebutkan dalam komentar sebelumnya, sumber harus dipisahkan dari tautan keras. Misalnya, anggap cadangan harian direktori home Anda:

Sumber:

  • / home / flakrat

Tujuan:

  • / data / cadangan / harian
    • /Senin
    • /Selasa
    • /Rabu
    • /Kamis
    • ...

Tautan keras dibuat dengan menjalankan "cp -al" terhadap cadangan kemarin. Katakan ini hari Selasa pagi ketika Anda menjalankannya:

cd /data/backup/daily

rm -rf tuesday

cp -al monday tuesday

rsync -a --delete /home/flakrat /data/backup/daily/tuesday/


0

rdiff-backup tampaknya melakukan apa yang Anda inginkan, lihat

Menggunakan rsync Anda harus terlebih dahulu membuat cadangan lengkap tanpa menggunakan tautan keras. Cadangan berikutnya dapat mengarah ke cadangan sebelumnya dan tautan keras ke sana. Dengan cara itu, cadangan Anda tidak ditautkan ke file kerja Anda (yang Anda modifikasi). Contoh. Jika cadangan saya sebelumnya begitu cadangan folder.01 skrip cadangan saya pertama-tama akan menambah folder dengan mengubah nama mereka menjadi satu sehingga cadangan.01 menjadi cadangan.02. Kemudian skrip membuat folder kosong baru bernama backup.01. kemudian akan rscync cadangan baru ke folder baru dan tautan keras ke backup.02 sehingga hanya file baru yang akan mengambil ruang apa pun di cadangan. Perintah rsync akan terlihat seperti ini: rsync -rlt sourcepath backuppath / backup.01 --link-dest = backuppath / backup.02

Jadi Anda bisa lihat, semua tautan keras terjadi di jalur cadangan. Dengan cara ini Anda tidak perlu khawatir tentang salin saat menulis saat memodifikasi file di jalur sumber Anda.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.