Solusi 1:
rsync --ignore-existing --sparse ...
Untuk membuat file baru dalam mode renggang
Diikuti oleh
rsync --inplace ...
Untuk memperbarui semua file yang ada (termasuk file jarang yang dibuat sebelumnya) di tempat.
Solusi 2:
Rsync hanya mentransfer perubahan ke setiap file dan dengan --inplace hanya boleh menulis ulang blok yang berubah tanpa membuat ulang file. Dari halaman fitur mereka.
rsync adalah program transfer file untuk sistem Unix. rsync menggunakan "algoritme rsync" yang menyediakan metode yang sangat cepat untuk menyinkronkan file jarak jauh. Hal ini dilakukan dengan hanya mengirimkan perbedaan pada file melalui tautan, tanpa mengharuskan kedua kumpulan file ada di salah satu ujung tautan sebelumnya.
Menggunakan --inplace harus bekerja untuk Anda. Ini akan menunjukkan kepada Anda kemajuan, kompres transfer (pada tingkat kompresi default), transfer konten direktori penyimpanan lokal secara rekursif (garis miring pertama itu penting), buat perubahan pada file di tempat dan gunakan ssh untuk transportasi.
rsync -v -z -r --inplace --progress -e ssh /path/to/local/storage/ \
[email protected]:/path/to/remote/storage/
Saya sering menggunakan flag -a juga yang melakukan beberapa hal lagi. Ini setara dengan -rlptgoD Saya akan meninggalkan perilaku yang tepat untuk Anda cari di halaman manual.
Solusi 3:
Lihatlah Proyek Penyimpanan Zumastor Linux yang mengimplementasikan pencadangan "snapshot" menggunakan biner "rsync" melalui ddsnap alat.
Dari halaman manual:
ddsnap menyediakan replikasi perangkat blok dengan fasilitas snapshot level blok yang mampu menahan beberapa snapshot simultan secara efisien. ddsnap dapat membuat daftar potongan snapshot yang berbeda di antara dua snapshot, kemudian mengirimkan perbedaan tersebut melalui kabel. Di server downstream, tulis data yang diperbarui ke perangkat blok snapshot.
Solusi 4:
Saya akhirnya menulis perangkat lunak untuk melakukan ini:
http://www.virtsync.com
Ini adalah perangkat lunak komersial seharga $49 per server fisik.
Saya sekarang dapat mereplikasi file jarang 50GB (yang memiliki konten 3GB) dalam waktu kurang dari 3 menit di broadband perumahan.
[email protected]:~$ time virtsync -v /var/lib/libvirt/images/vsws.img backup.barricane.com:/home/chris/
syncing /var/lib/libvirt/images/vsws.img to backup.barricane.com:/home/chris/vsws.img (dot = 1 GiB)
[........>.........................................]
done - 53687091200 bytes compared, 4096 bytes transferred.
real 2m47.201s
user 0m48.821s
sys 0m43.915s
Solusi 5:
Untuk menyinkronkan file besar atau memblokir perangkat dengan perbedaan rendah hingga sedang, Anda dapat melakukan penyalinan biasa atau menggunakan bdsync, rsync sama sekali tidak cocok untuk kasus khusus ini*.
bdsync bekerja untuk saya, tampaknya cukup dewasa, riwayat bugnya menggembirakan (masalah kecil, penyelesaian segera). Dalam pengujian saya, kecepatannya mendekati maksimum teoretis yang bisa Anda dapatkan** (artinya Anda dapat menyinkronkan waktu yang Anda perlukan untuk membaca file). Akhirnya ini open source dan tidak ada biaya.
bdsync membaca file dari kedua host dan bertukar check-sum untuk membandingkannya dan mendeteksi perbedaan. Semua ini pada waktu yang sama . Akhirnya membuat file tambalan terkompresi pada host sumber. Kemudian Anda memindahkan file itu ke host tujuan dan menjalankan bdsync untuk kedua kalinya untuk menambal file tujuan.
Saat menggunakannya melalui tautan yang agak cepat (mis. Ethernet 100Mbit) dan untuk file dengan perbedaan kecil (seperti yang paling sering terjadi pada disk VM), ini mengurangi waktu sinkronisasi ke waktu yang Anda perlukan untuk membaca file. Melalui tautan yang lambat, Anda memerlukan lebih banyak waktu karena Anda harus menyalin perubahan terkompresi dari satu host ke host lain (tampaknya Anda dapat menghemat waktu menggunakan trik yang bagus tetapi belum diuji). Untuk file dengan banyak perubahan, waktu untuk menulis file tambalan ke disk juga harus diperhitungkan (dan Anda memerlukan ruang kosong yang cukup di kedua host untuk menampungnya).
Inilah cara saya biasanya menggunakan bdsync. Perintah ini dijalankan pada $LOCAL_HOST untuk "menyalin" $LOCAL_FILE ke $REMOTE_FILE pada $REMOTE_HOST . Saya menggunakan pigz (gzip yang lebih cepat ) untuk mengompresi perubahan, ssh untuk menjalankan bdsync pada host jarak jauh dan rsync /ssh untuk menyalin perubahan. Perhatikan bahwa saya sedang memeriksa apakah tambalan telah berhasil diterapkan tetapi saya hanya mencetak "Pembaruan berhasil" jika berhasil. Anda mungkin ingin melakukan sesuatu yang lebih cerdik jika terjadi kegagalan.
REMOTE_HOST=1.2.3.4
LOCAL_FILE=/path/to/source/file
REMOTE_FILE=/path/to/destination/file
PATCH=a_file_name
LOC_TMPDIR=/tmp/
REM_TMPDIR=/tmp/
# if you do use /tmp/ make sure it fits large patch files
# find changes and create a compressed patch file
bdsync "ssh $REMOTE_HOST bdsync --server" "$LOCAL_FILE" "$REMOTE_FILE" --diffsize=resize | pigz > "$LOC_TMPDIR/$PATCH"
# move patch file to remote host
rsync "$LOC_TMPDIR/$PATCH" $REMOTE_HOST:$REM_TMPDIR/$PATCH
# apply patch to remote file
(
ssh -T $REMOTE_HOST <<ENDSSH
pigz -d < $REM_TMPDIR/$PATCH | bdsync --patch="$REMOTE_FILE" --diffsize=resize && echo "ALL-DONE"
rm $REM_TMPDIR/$PATCH
ENDSSH
) | grep -q "ALL-DONE" && echo "Update succesful" && rm "$LOC_TMPDIR/$PATCH"
# (optional) update remote file timestamp to match local file
MTIME=`stat "$LOCAL_$FILE" -c %Y`
ssh $REMOTE_HOST touch -c -d @"$MTIME_0" "$REMOTE_FILE" </dev/null
*:rsync sangat tidak efisien dengan file besar. Bahkan dengan --inplace pertama-tama akan membaca seluruh file di host tujuan, SETELAHNYA mulai membaca file di host sumber dan akhirnya mentransfer perbedaannya (jalankan saja dstat atau serupa saat menjalankan rsync dan amati). Hasilnya adalah bahwa bahkan untuk file dengan perbedaan kecil dibutuhkan sekitar dua kali lipat waktu yang Anda perlukan untuk membaca file untuk menyinkronkannya.
**:Dengan asumsi bahwa Anda tidak memiliki cara lain untuk mengetahui bagian mana dari file yang telah berubah. Snapshot LVM menggunakan bitmap untuk merekam blok yang diubah sehingga bisa sangat cepat (readme lvmsync memiliki lebih banyak info).