pengembangan-web-mp.com

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 menggunakan 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 menurut Anda, rsync atau cp?

244
Rory

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 -a flag - ‘arsip.’ Jadi:

rsync -a source dest

Meskipun UID/GID dan symlink dipertahankan oleh -a (Lihat -lpgo), pertanyaan Anda menyiratkan bahwa Anda mungkin menginginkan salinan lengkap informasi sistem file; dan -a tidak termasuk tautan keras, atribut yang diperluas, atau ACL (di Linux) atau yang di atas juga garpu sumber daya (pada OS X.) Jadi, untuk salinan sistem file yang kuat, Anda harus Saya perlu menyertakan bendera-bendera itu:

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

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

cp -au source dest
214
Hamish Downer

Saat menyalin ke sistem file lokal saya cenderung menggunakan rsync dengan opsi 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 -)
120
Ellis Percival

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.

79
Chad Huneycutt

rsync

Inilah 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

tar

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.

14
AskApache

Apapun yang kamu inginkan. Jangan lupa -a beralih 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? Cukup gunakan --exclude-from. Perlu mengubah kepemilikan atau izin? rsync akan melakukannya untuk Anda.

7
innaM

Perintah rsync selalu menghitung checksum pada setiap byte yang ditransfernya.

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

-c, --checksum lewati berdasarkan checksum, bukan mod-waktu & ukuran "

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.

Jadi rsync juga, selalu, menghitung checksum dari seluruh file di sisi penerima, bahkan ketika -c/ --checksum opsi adalah "mati".

7
John

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

6
oneguynick

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 dari data yang didistribusikan di antara 1.753.200 file kami memiliki waktu-waktu tersebut:

  • rsync butuh 232 menit
  • tar butuh 206 menit
  • cpio membutuhkan waktu 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

6
arjones

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.

5
n3bulous

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.

3
Ron

ARJ IS SO SEKOLAH TUA !! 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.

2

Anda pasti ingin memberikan rclone coba. 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 SSD LITEONIT LCS-256 (256GB).

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

1
Frédéric N.

Keduanya akan bekerja dengan baik.

0
pauska

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 sumber akan di-IGNORED. Selain itu, checksum seluruh file pada akhirnya, yang berarti tidak ada kecepatan signifikan pada --no-whole-file sambil menambahkan kasus kegagalan berbahaya.

Menggunakan

  • -S/--sparse: mengubah urutan null menjadi blok jarang
  • --partial atau -P yang mana --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-file sehingga segala sesuatu yang perlu dikirim ulang menggunakan transfer delta. Membaca setengah dari sebagian file yang ditransfer seringkali lebih cepat daripada menulisnya lagi.
  • --inplace untuk menghindari salinan file (tetapi hanya jika tidak ada yang membaca tujuan sampai seluruh transfer selesai)
0
Tom Hale

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

0
pgs

Bagaimana jika Anda menggunakan ARJ?

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

dimana -jm -m1 adalah tingkat kompresi dan -je membuatnya 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 -y selalu menerima, menimpa, melewati dll)

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

0
herauthon