meningkatkan kinerja cadangan rsync

8

Apa teknik terbaik untuk meningkatkan rsync daripada mirroring antara kotak unix, dengan asumsi bahwa satu sistem akan selalu memiliki salinan master dan sistem lainnya akan selalu memiliki salinan terbaru (kurang dari 48 jam)

Juga, apa yang harus dilakukan untuk mengukur pendekatan itu untuk menangani lusinan mesin yang mendapat dorongan dari perubahan itu?

— sal
sumber

6

Jika:

Waktu modifikasi file Anda benar
File tidak terlalu besar
Tidak ada dorongan yang dapat dilewatkan (atau ada semacam pemrosesan backlog)

Anda dapat menggunakan find -ctimeatau file -cneweruntuk membuat daftar file yang diubah sejak eksekusi terakhir, dan menyalin hanya file yang dimodifikasi (Hanya dorongan diferensial yang dimuliakan).

Ini menerjemahkan sendiri dengan cukup baik untuk beberapa host: cukup lakukan tar diferensial pada sumbernya, dan untar pada semua host.

Ini memberi Anda sesuatu seperti itu:

find -type f -cnewer /tmp/files_to_send.tar.gz > /tmp/files_to_send.txt
tar zcf /tmp/files_to_send.tar.gz --files-from /tmp/files_to_send.txt 
for HOST in host1 host2 host3 ...
do
    cat /tmp/files_to_send.tar.gz | ssh $HOST "tar xpf -"
done

Script telah disempurnakan, tetapi Anda mendapatkan idenya.

— Steve Schnepp
sumber

Ups: Penggunaan berguna lain kucing :-)

— Steve Schnepp

Sebenarnya, ini bisa dilakukan hampir persis seperti ini; dengan asumsi kekuatan yang ada akan baik-baik saja dengan menambahkan ini untuk berjalan tepat setelah skrip yang memelihara file data

— sal

4

Menganggap bahwa data yang Anda rsyncing belum dikompres, mengaktifkan kompresi (-z) kemungkinan akan membantu kecepatan transfer, dengan biaya beberapa CPU di kedua ujungnya.

— pjz
sumber

kompresi sudah aktif melalui ssh

— sal

3

Kompresi melalui rsync biasanya lebih efektif daripada kompresi di terowongan SSH. Alasannya adalah bahwa rsync memiliki lebih banyak pengetahuan, dan dapat memanfaatkannya. Sebagai contoh, kompresinya dapat merujuk bagian file yang tidak ditransfer.

— derobert

5

@derobert memindahkan kompresi dari ssh ke rsync meningkatkan kinerja hampir 20%

— sal

2

Jika Anda mentransfer file yang sangat besar dengan banyak perubahan, gunakan opsi --inplace dan --whole-file, saya menggunakan ini untuk gambar VM 2Gb saya dan itu sangat membantu (terutama karena protokol rsync tidak melakukan banyak hal dengan melewatkan data tambahan dengan file-file ini). saya tidak merekomendasikan opsi ini untuk sebagian besar kasus.

gunakan --stats untuk melihat seberapa baik file Anda ditransfer menggunakan protokol rsync incremental.

— gbjbaanb
sumber

2

Strategi lain adalah membuat ssh dan rsync lebih cepat. Jika Anda menggunakan jaringan tepercaya (baca: pribadi), maka mengenkripsi muatan sebenarnya tidak diperlukan. Anda dapat menggunakan HPN ssh . Versi ssh ini hanya mengenkripsi otentikasi. Juga, rsync versi 3 mulai mentransfer file sambil membangun daftar file. Ini tentu saja merupakan penghematan waktu yang sangat besar dibandingkan rsync versi 2. Saya tidak tahu apakah itu yang Anda cari, tapi saya harap ini membantu. Juga, rsync mendukung multicasting dalam beberapa cara, meskipun saya tidak akan berpura-pura mengerti caranya.

— Jackalheart
sumber

Kembali beberapa tahun yang lalu, ketika saya menggunakan sistem dengan prosesor yang jauh lebih lambat, saya membandingkan semua metode kompresi OpenSSH yang tersedia dan sumber "arcfour" adalah yang tercepat. Itu, dikombinasikan dengan menyalakan frame jumbo jika menggunakan gig-e, berakhir secara signifikan meningkatkan kecepatan transfer.

— Derek Pressnall

2

Ketika Anda melakukan sinkronisasi sebagai metode cadangan, masalah terbesar yang akan Anda hadapi adalah jika Anda memiliki banyak file yang Anda buat cadangannya. Rsync dapat menangani file besar tanpa masalah tetapi jika jumlah file yang Anda buat cadangannya terlalu besar maka Anda akan melihat bahwa rsync tidak akan selesai dalam jumlah waktu yang wajar. Jika ini terjadi, Anda perlu memecah cadangan menjadi beberapa bagian yang lebih kecil dan kemudian mengulangi bagian-bagian tersebut misalnya

find /home -mindepth 1 -maxdepth 1 -print0 | xargs -0 -n 1 -I {} -- rsync -a -e ssh {} backup@mybackupserver:/backup/

atau tarring file ke bawah untuk mengurangi jumlah file.

Adapun lusinan mesin mendapatkan cermin dari perubahan itu, itu tergantung pada seberapa segar cadangan perlu. Salah satu pendekatan akan mencerminkan perubahan dari server utama ke server cadangan dan kemudian memiliki server lain menarik perubahan mereka dari server cadangan baik dengan daemon rsync pada server cadangan awal dan kemudian menjadwalkan server lain untuk menarik sedikit waktu yang berbeda atau dengan memiliki skrip menggunakan ssh tanpa kata sandi untuk terhubung ke masing-masing server dan meminta mereka untuk menarik salinan cadangan baru yang akan membantu mencegah membanjiri server cadangan awal Anda - tetapi apakah Anda pergi ke banyak masalah akan tergantung pada berapa banyak mesin lain Anda telah menarik salinan cadangan.

— Rodney Amato
sumber

Apakah Anda tahu perbedaan antara: untuk f di /ackup/*.bak; lakukan rsync -e ssh $ f backup @ mybackupserver; selesai dan rsync -re ssh /ackup/*.bak backup @ mybackupserver?

— Osama ALASSIRY

Menurut saya perbedaannya hanyalah yang pertama akan menjalankan rsync untuk setiap file .bak (dengan asumsi * .bak hanya mencocokkan file) di direktori / Backup / sedangkan yang kedua akan menjalankan satu rsync untuk mentransfer semuanya. Jika * .bak dimaksudkan untuk mencocokkan direktori, yang pertama tidak akan muncul kembali ke dalam subdirektori (dengan anggapan bahwa Anda tidak sengaja menggunakan -r). Umumnya Anda ingin melakukan yang kedua daripada yang pertama sampai Anda memiliki terlalu banyak file untuk dapat ditangani dengan baik.

— Rodney Amato

1

Sadarilah bahwa menggunakan for for iterate melalui direktori atau file, secara umum, bukan ide yang baik. Ini akan rusak parah jika mengenai direktori atau file dengan spasi di dalamnya.

— Nathan

@Nathan, jadi kira-kira seperti itu find /Backup/ -name '*.bak' -print0 | xargs -0 -n 1 rsync -e ssh?

— hiu

Saya telah memperbarui contoh untuk menggunakan pendekatan xargs. Saya tidak pernah harus melakukan ini sendiri karena saya tidak pernah memiliki direktori di bawah / home yang memiliki ruang di dalamnya tetapi kita harus memiliki contoh terbaik di sana.

— Rodney Amato

2

rsync memiliki cara melakukan salinan yang terputus . Dengan kata lain, rsync dapat (secara konseptual) melakukan diff pohon direktori dan menghasilkan file tambalan yang kemudian Anda dapat terapkan pada sejumlah file yang identik dengan sumber aslinya.

Ini mengharuskan Anda memanggil rsync dengan master dan mirror with --write-batch; menghasilkan file. Anda kemudian mentransfer file ini ke sejumlah target lain, dan Anda kemudian menerapkan batch untuk masing-masing target menggunakan --read-batch.

Jika Anda menyimpan salinan lokal dari kondisi rsynced terakhir (yaitu salinan dari apa yang tampak seperti cermin sekarang) pada mesin yang sama dengan master, Anda dapat membuat "tambalan" ini pada master tanpa bahkan menghubungi mirror apa pun:

Pada tuan:

rsync --write-batch=my-batch.rsync /master/data /current/mirror

Tambahkan opsi apa pun yang Anda inginkan. Ini akan melakukan dua hal:

Itu akan membuat /current/mirrorperubahan untuk mencerminkan/master/data
Ini akan membuat file patch biner (atau file batch) yang dipanggil my-batch.rsyncuntuk digunakan nanti.

Transfer my-batch.rsyncfile dari master ke semua mirror Anda, dan kemudian di mirror, terapkan tambalan untuk berbicara:

rsync --read-batch=my-batch.rsync /local/mirror

Manfaat dari pendekatan ini:

master tidak kebanjiran
tidak perlu mengoordinasikan / memiliki akses ke master / cermin secara bersamaan
orang yang berbeda dengan hak istimewa yang berbeda dapat melakukan pekerjaan pada master dan mirror (s).
tidak perlu memiliki saluran TCP (ssh, netcat, apa pun; file dapat dikirim melalui e-mail ;-))
cermin offline dapat disinkronkan nanti (bawa saja secara online dan terapkan tambalan)
semua mirror dijamin identik (karena mereka menerapkan "patch" yang sama)
semua mirror dapat diperbarui secara bersamaan (karena --read-batchhanya cpu / io intensif pada mirror itu sendiri)

— mogsie
sumber