Menyalin pohon direktori besar secara lokal? cp atau rsync?


230

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?


2
Jika rsync melakukan persis apa yang Anda inginkan, jika Anda sudah cukup akrab dengan penggunaannya untuk aplikasi khusus ini, dan jika fungsinya cukup cepat sesuai dengan selera Anda, lalu mengapa Anda ingin beralih?
sebelas81

2
Karena saya khawatir bahwa rsync akan memakan waktu lebih lama dari cp, karena rsync melakukan banyak pemeriksaan karena cp tidak akan melakukan
Rory

1
Cpu overhead checksum kecil dibandingkan dengan disk / jaringan i / o. Kecuali jika disk berada pada sistem yang sama dan OS dapat melakukan beberapa salinan drive-drive yang pintar di pengontrol bus.
Martin Beckett

3
Checksumming dilakukan pada file yang berbeda pada ukuran dan cap waktu. Jika Anda paranoid (seperti setelah pemadaman listrik selama penyalinan) Anda dapat memaksa checksumming pada semua file, tetapi pada transfer lokal, itu biasanya lebih lambat daripada memulai dari awal.
korkman

3
Mungkin dia ingin tahu tentang meningkatkan alur kerjanya, dan tidak mengubur kepalanya berpikir dia tahu segalanya. Komentar ini sangat mengganggu saya.
Martin Konecny

Jawaban:


204

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

5
Bendera -u cp mungkin bukan solusi terbaik, karena tidak akan mendeteksi sebagian file yang disalin / rusak. Yang menyenangkan tentang rsync adalah Anda dapat memilikinya md5 jumlah file untuk mendeteksi perbedaan.
Chad Huneycutt

3
Menambahkan opsi -w (--whole-file) akan mempercepat rsync yang terputus, karena itu hanya akan menyalin file alih-alih checksumming.
hayalci

13
sebenarnya, rsync mendeteksi transfer lokal dan memungkinkan salinan seluruh file tanpa checksumming secara otomatis.
korkman

22
dan - kemajuan yang sangat berguna!
Matt

12
-P atau --progress menunjukkan progres untuk setiap file satu per satu. Ini berguna untuk menyalin file besar, bukan untuk banyak (ribuan) file kecil karena itu berarti lebih banyak output yang tidak dapat Anda baca. Itu tidak menunjukkan kemajuan keseluruhan dari semua file yang digabungkan.
SPRBRN

106

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 -)

1
Saya mengalami kesalahan berikut: rsync: --no-compress: unknown option@Ellis Percival.
alper

Ini sangat cepat. Lebih cepat melakukan ini daripada rm -rf /src/.
Lakukan

2
Seperti @alper, --no-kompres bukan pilihan untuk versi rsync saya (dalam CentOS 7); Saya menggunakan --compress-level = 0 sebagai gantinya.
Paul

79

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.


6
+1 Saya menemukan tar umumnya lebih cepat untuk salinan besar daripada rsync. Saya suka ide menyelesaikan dengan rsync akhir juga.
Geoff Fritz

2
tar adalah pilihan yang baik jika dest dir kosong. Meskipun cara saya adalah: cd $ DSTDIR; tar c -C $ SRCDIR. | tar
asdmin

19
Itulah keindahan dari metode ini. Anda tidak perlu menggandakan ruang karena Anda tidak pernah benar-benar membuat file tar perantara. Tar sebelum pipa mengemas data dan mengalirkannya ke stdout, dan tar setelah pipa mengambilnya dari stdin dan membukanya.
Chad Huneycutt

4
Saya melakukan cp -a untuk transfer 12gb, dan metode ini untuk transfer 42gb. Metode tar membutuhkan waktu sekitar 1/4 waktu.
NGaida

3
Saya juga meletakkan pvdi tengah untuk dapat menonton kemajuan, memperkirakan ukuran semua data yang digunakan df. Saya juga menggunakan --numeric-owner, karena disk sumber berasal dari sistem lain dan saya tidak ingin tarmengacaukan pemilik:tar -C /old-path --numeric-owner -S -c . | pv -tpeba -s 100G | tar -C /new-path --numeric-owner -S -xp
Petr Pudlák

14

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.


Mengapa Anda menggunakan flag -S dan -D untuk rsync?
miyalys

7

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.


Apa yang dilakukan flag -p lagi?
Rory

1
Ini akan memiliki kepemilikan, stempel waktu, dan izin Pemelihara.
innaM

5
cp -a akan lebih baik.
David Pashley

Memang. Jawaban berubah sesuai.
innaM

7

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".


14
Sementara posting Anda menambahkan beberapa informasi menarik di sini, kata-kata kasar, dan hinaan mengurangi nilai posting Anda. Situs ini bukan forum untuk kata-kata kasar yang tidak konstruktif. Jika Anda dapat memodifikasi sumbernya, sudahkah Anda mengirimkan modifikasi sebagai tambalan? Sudahkah Anda memposting versi Anda di github atau sesuatu? Jika Anda merasa sangat kuat tentang ini, mungkin lebih baik jika Anda mencoba melakukan sesuatu yang sedikit lebih konstruktif daripada menghina yang tidak perlu.
Zoredache

Ya, paragraf terakhir tidak terlalu penting.
Penerbangan Sherwin

6

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


2
Apa nilai menggunakan protokol yang lebih lama dalam string perintah itu?
ewwhite

1
Pada mesin mac, versi lama dari Rsync yang dikirimkan tergantung pada beberapa revs protokol rsync yang lebih baru seperti 29. Memberitahunya untuk pindah ke protokol yang lebih lama membuatnya TIDAK memeriksa berulang kali.
oneguynick

Saya kira angka 28 tidak berlaku lagi?
SPRBRN

5

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.


12
Jika Anda menggunakan versi 3 itu tidak menyimpan seluruh pohon dalam memori jika besar, itu menggunakan algoritma rekursi tambahan: samba.org/ftp/rsync/src/rsync-3.0.0-NEWS
Kyle Brandt

5

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


404 halaman tidak ditemukan
Amedee Van Gasse

1
Terima kasih @AmedeeVanGasse URL telah diperbaiki sesaat setelah Anda melaporkan :)
arjones

Kenapa tidak melakukan benchmarking cp? Inilah judul pertanyaannya!
calandoa

@ calandoa saya pikir cptidak aman, yaitu: ketika istirahat Anda harus memulai dari awal, itu cara saya mendukung opsi yang dapat dilanjutkan, ergo rsyncadalah favorit saya :)
arjones

3

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.


2

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.


2
"Utilitas cpio dan find asli ditulis oleh Dick Haight saat bekerja di AT&T Unix Support Group. Mereka pertama kali muncul pada tahun 1977 di PWB / UNIX 1.0" - cpiohalaman manual FreeBSD .
Chris S

3
cpiosayangnya memiliki batas atas 8GB untuk file.

" Tanpa pipa apa pun " [sic]. Kecuali findperintah, seperti yang Anda daftarkan, memiliki pipa di dalamnya:find . -print | cpio -pdm /target/folder
warren

1

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.



0

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


Sebuah jawaban lama, tetapi bukankah TAR untuk membuat arsip file terkompresi? Bagaimana ini bisa digunakan untuk mentransfer file seperti rsync atau cp?
Penerbangan Sherwin

@SherwinFlight sumber cd; tar cf -. | (cd dest; tar xf -)
hal

0

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.


1
Arj? Bukankah itu mati di tahun 80-an?
Michael Hampton

mungkin awal 90-an jika Anda percaya wikipedia
Matt

0

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)
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.