Menyalin pohon direktori besar secara lokal? cp atau rsync?

Saya harus menyalin pohon direktori besar, sekitar 1,8 TB. Semuanya lokal. Karena kebiasaan saya akan menggunakan rsync, namun saya bertanya-tanya apakah ada gunanya, dan jika saya lebih suka menggunakannya cp.

Saya khawatir tentang izin dan uid / gid, karena harus disimpan dalam salinan (saya tahu rsync melakukan ini). Serta hal-hal seperti symlink.

Tujuannya kosong, jadi saya tidak perlu khawatir memperbarui beberapa file dengan syarat. Ini semua disk lokal, jadi saya tidak perlu khawatir tentang ssh atau jaringan.

Alasan saya tergoda jauh dari rsync, adalah karena rsync mungkin melakukan lebih dari yang saya butuhkan. file rsync checksums. Saya tidak membutuhkan itu, dan saya khawatir itu akan memakan waktu lebih lama dari cp.

Jadi apa yang menurutmu, rsyncatau cp?

Saya akan menggunakan rsync karena artinya jika terputus karena alasan apa pun, maka Anda dapat memulai kembali dengan mudah dengan biaya yang sangat sedikit. Dan menjadi rsync, ia bahkan dapat memulai kembali sebagian jalan melalui file besar. Seperti yang disebutkan orang lain, itu dapat mengecualikan file dengan mudah. Cara paling sederhana untuk melestarikan sebagian besar hal adalah dengan menggunakan -abendera - 'arsip'. Begitu:

rsync -a source dest

Meskipun UID / GID dan symlink dipertahankan oleh -a(lihat -lpgo), pertanyaan Anda menyiratkan bahwa Anda mungkin ingin salinan lengkap dari informasi sistem file; dan -atidak termasuk tautan keras, atribut yang diperluas, atau ACL (di Linux) atau di atas atau garpu sumber daya (di OS X.) Jadi, untuk salinan sistem file yang kuat, Anda harus menyertakan flag-flag tersebut:

rsync -aHAX source dest # Linux
rsync -aHE source dest  # OS X

Cp default akan mulai lagi, meskipun -uflag akan "menyalin hanya ketika file SOURCE lebih baru dari file tujuan atau ketika file tujuan hilang" . Dan -abendera (arsip) akan bersifat rekursif, bukan menyalin file jika Anda harus memulai ulang dan mempertahankan izin. Begitu:

cp -au source dest

Saat menyalin ke sistem file lokal saya selalu menggunakan opsi rsync berikut:

# rsync -avhW --no-compress --progress /src/ /dst/

Inilah alasan saya:

-a is for archive, which preserves ownership, permissions etc.
-v is for verbose, so I can see what's happening (optional)
-h is for human-readable, so the transfer rate and file sizes are easier to read (optional)
-W is for copying whole files only, without delta-xfer algorithm which should reduce CPU load
--no-compress as there's no lack of bandwidth between local devices
--progress so I can see the progress of large files (optional)

Saya telah melihat transfer 17% lebih cepat menggunakan pengaturan rsync di atas melalui perintah tar berikut seperti yang disarankan oleh jawaban lain:

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)

Ketika saya harus menyalin sejumlah besar data, saya biasanya menggunakan kombinasi tar dan rsync. Pass pertama adalah untuk tar itu, kira-kira seperti ini:

# (cd /src; tar cf - .) | (cd /dst; tar xpf -)

Biasanya dengan sejumlah besar file, akan ada beberapa tar yang tidak dapat menangani karena alasan apa pun. Atau mungkin prosesnya akan terganggu, atau jika ini adalah migrasi sistem file, Anda mungkin ingin melakukan salinan awal sebelum langkah migrasi yang sebenarnya. Bagaimanapun, setelah salinan awal, saya melakukan langkah rsync untuk menyinkronkan semuanya:

# cd /dst; rsync -avPHSx --delete /src/ .

Perhatikan bahwa trailing slash on /src/penting.

rsync

Berikut adalah rsync yang saya gunakan, saya lebih suka cp untuk perintah sederhana, bukan ini.

$ rsync -ahSD --ignore-errors --force --delete --stats $SRC/ $DIR/

cpio

Inilah cara yang bahkan lebih aman, cpio. Ini tentang secepat tar, mungkin sedikit lebih cepat.

$ cd $SRC && find . -mount -depth -print0 2>/dev/null | cpio -0admp $DEST &>/dev/null

ter

Ini juga bagus, dan berlanjut pada kegagalan baca.

$ tar --ignore-failed-read -C $SRC -cf - . | tar --ignore-failed-read -C $DEST -xf -

Perhatikan itu semua hanya untuk salinan lokal.

Apapun yang kamu inginkan. Hanya saja, jangan lupa -asaklar ketika Anda memutuskan untuk menggunakan cp.

Jika Anda benar-benar membutuhkan jawaban: Saya akan menggunakan rsync karena jauh lebih fleksibel. Perlu mematikan sebelum penyalinan selesai? Cukup ctrl-c dan lanjutkan segera setelah Anda kembali. Perlu mengecualikan beberapa file? Gunakan saja --exclude-from. Perlu mengubah kepemilikan atau izin? rsync akan melakukannya untuk Anda.

The rsyncperintah selalu menghitung checksum pada setiap byte itu transfer.

Opsi baris perintah --checksumhanya berkaitan dengan apakah checksum file digunakan untuk menentukan file mana yang akan ditransfer atau tidak, yaitu:

-c, --checksum lewati berdasarkan checksum, bukan mod-time & size "

Halaman manual juga mengatakan ini:

Perhatikan bahwa rsync selalu memverifikasi bahwa setiap file yang ditransfer direkonstruksi dengan benar di sisi penerima dengan memeriksa seluruh file checksum, tetapi verifikasi setelah transfer otomatis tidak ada hubungannya dengan opsi ini sebelum transfer, "Apakah file ini perlu akan diperbarui? " memeriksa.

Demikian rsyncjuga, selalu, menghitung checksum dari seluruh file di sisi penerima, bahkan ketika -c/ --checksumopsi "mati".

rsync -aPhW --protocol=28membantu mempercepat salinan besar itu dengan RSYNC. Saya selalu pergi rsync karena memikirkan menjadi pertengahan 90GiB dan itu membuat saya takut menjauh dari CP

rsync bagus, tetapi memiliki masalah dengan pohon direktori yang sangat besar karena menyimpan pohon dalam memori. Saya hanya ingin melihat apakah mereka akan memperbaiki masalah ini ketika saya menemukan utas ini.

Saya juga menemukan:

http://matthew.mceachen.us/geek/gigasync/

Anda juga bisa memecah pohon secara manual dan menjalankan beberapa rsyncs.

Utas ini sangat berguna dan karena ada begitu banyak pilihan untuk mencapai hasil, saya memutuskan untuk membandingkan beberapa dari mereka. Saya percaya hasil saya dapat membantu orang lain untuk mengetahui apa yang bekerja lebih cepat.

Untuk memindahkan 532Gb data yang didistribusikan di antara 1.753.200 file, kami memiliki waktu-waktu tersebut:

• rsync Butuh 232 menit
• tar Butuh 206 menit
• cpio Butuh 225 menit
• rsync + parallel Butuh 209 menit

Dalam kasus saya, saya lebih suka menggunakan rsync + parallel. Saya harap informasi ini membantu lebih banyak orang untuk memutuskan di antara alternatif-alternatif ini.

Patokan lengkap diterbitkan di sini

Ketika melakukan salinan direktori lokal lokal, pengalaman saya adalah bahwa "cp -van src dest" adalah 20% lebih cepat dari rsync. Sejauh restartability, itulah yang dilakukan "-n". Anda hanya perlu rm file yang disalin sebagian. Tidak menyakitkan kecuali ISO atau semacamnya.

ARJ ADALAH SEKOLAH LAMA !! Saya benar-benar ragu bahwa ARJ dan / atau rsync akan memberikan kinerja.

Yang pasti selalu saya lakukan adalah menggunakan cpio:

find . -print | cpio -pdm /target/folder

Ini hampir cepat daripada CP, jelas lebih cepat dari tar dan tanpa pipa apa pun.

Anda pasti ingin mencoba rclone . Hal ini gila cepat:

sudo rclone sync /usr /home/fred/temp -P -L --transfers 64

Transferred:       17.929G / 17.929 GBytes, 100%, 165.692 MBytes/s, ETA 0s
Errors:                75 (retrying may help)
Checks:            691078 / 691078, 100%
Transferred:       345539 / 345539, 100%
Elapsed time:     1m50.8s

Ini adalah salinan lokal dari dan ke LITEONIT LCS-256 (256GB) SSD.

Anda dapat menambahkan --ignore-checksumpada menjalankan pertama untuk membuatnya lebih cepat.

Keduanya akan bekerja dengan baik.

tar akan juga melakukan pekerjaan itu, tetapi tidak akan melanjutkan dari terganggu seperti yang akan dilakukan rsync.

Bagaimana jika Anda menggunakan ARJ?

arj a -jm -m1 -r -je filepack /source

di mana -jm -m1level kompresi dan -jemembuatnya menjadi executable. Sekarang Anda memiliki bash file yang dienkapsulasi.

Kemudian untuk ekstraksi ke peta target

filepack -y  

di mana peta sumber akan dibuat (di mana -yselalu menerima, menimpa, lewati dll)

Satu kemudian dapat scp ftp filepack ke area target dan jalankan, jika itu mungkin.

Ada beberapa speed-up yang dapat diterapkan ke rsync:

Menghindari

• -z/ --compress: kompresi hanya akan memuat CPU karena transfer tidak melalui jaringan tetapi lebih dari RAM.
• --append-verify: melanjutkan transfer yang terputus. Ini kedengarannya seperti ide yang bagus, tetapi memiliki kasus kegagalan berbahaya: file tujuan apa pun dengan ukuran yang sama (atau lebih besar) dari sumbernya akan di-IGNORED. Selain itu, checksum seluruh file di akhir, yang berarti tidak ada mempercepat secara signifikan --no-whole-filesambil menambahkan kasus kegagalan berbahaya.

Menggunakan

• -S/ --sparse: mengubah urutan null menjadi blok jarang
• --partialatau -Pyang --partial --progress: menyimpan file yang ditransfer sebagian untuk melanjutkan kembali di masa depan. Catatan: file tidak akan memiliki nama sementara, jadi pastikan tidak ada lagi yang mengharapkan untuk menggunakan tujuan sampai seluruh salinan selesai.
• --no-whole-filesehingga segala sesuatu yang perlu dikirim ulang menggunakan transfer delta. Membaca setengah dari file yang ditransfer sebagian seringkali jauh lebih cepat daripada menulisnya lagi.
• --inplace untuk menghindari penyalinan file (tetapi hanya jika tidak ada yang membaca tujuan sampai seluruh transfer selesai)