กำลังคัดลอกแผนผังไดเรกทอรีขนาดใหญ่ในเครื่องหรือไม่ cp หรือ rsync?

ฉันต้องคัดลอกทรีไดเรกทอรีขนาดใหญ่ประมาณ 1.8 TB มันคือทั้งหมดที่ท้องถิ่น ออกจากนิสัยฉันต้องการใช้แต่ฉันสงสัยว่ามีจุดมากและถ้าผมค่อนข้างควรใช้rsynccp

ฉันกังวลเกี่ยวกับสิทธิ์และ uid / gid เนื่องจากพวกเขาจะต้องได้รับการเก็บรักษาไว้ในสำเนา (ฉันรู้ว่า rsync ทำเช่นนี้) รวมถึงสิ่งต่าง ๆ เช่น symlinks

ปลายทางว่างเปล่าดังนั้นฉันไม่ต้องกังวลกับการอัปเดตบางไฟล์ตามเงื่อนไข มันคือโลคัลดิสก์ทั้งหมดดังนั้นฉันไม่ต้องกังวลกับ ssh หรือเครือข่าย

เหตุผลที่ฉันถูกล่อลวงให้ห่างจาก rsync นั้นเป็นเพราะ rsync อาจทำมากกว่าที่ฉันต้องการ rsync ตรวจสอบไฟล์ ฉันไม่ต้องการและกังวลว่าอาจใช้เวลานานกว่า cp

ดังนั้นสิ่งที่คุณคิด, rsyncหรือcp?

ฉันจะใช้ rsync เพราะมันหมายความว่าถ้ามันถูกขัดจังหวะด้วยเหตุผลใดก็ตามคุณสามารถเริ่มต้นใหม่ได้อย่างง่ายดายด้วยค่าใช้จ่ายน้อยมาก และเมื่อเป็น rsync ก็สามารถรีสตาร์ทส่วนผ่านไฟล์ขนาดใหญ่ได้ ตามที่คนอื่นพูดถึงมันสามารถแยกไฟล์ได้อย่างง่ายดาย วิธีที่ง่ายที่สุดในการรักษาสิ่งต่าง ๆ ส่วนใหญ่คือการใช้-aแฟล็ก - 'เก็บถาวร' ดังนั้น:

rsync -a source dest

แม้ว่า UID / GID และ symlink จะถูกเก็บรักษาไว้โดย-a(ดู-lpgo) คำถามของคุณบอกเป็นนัยว่าคุณอาจต้องการสำเนาข้อมูลระบบไฟล์แบบเต็ม และ-aไม่รวมฮาร์ดลิงก์แอตทริบิวต์เพิ่มเติมหรือ ACLs (บน Linux) หรือข้างบนหรือทรัพยากรส้อม (บน OS X. ) ดังนั้นสำหรับสำเนาที่แข็งแกร่งของระบบไฟล์คุณจะต้องรวมค่าสถานะเหล่านี้:

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

ซีพีเริ่มต้นจะเริ่มต้นอีกครั้งแม้ว่า-uธงจะ"คัดลอกเฉพาะเมื่อแฟ้มแหล่งที่ใหม่กว่าแฟ้มปลายทางหรือเมื่อแฟ้มปลายทางจะหายไป" และ-aแฟล็ก (ที่เก็บถาวร) จะเรียกซ้ำไม่ใช่ไฟล์ที่จัดเรียงใหม่หากคุณต้องรีสตาร์ทและสงวนสิทธิ์ ดังนั้น:

cp -au source dest

เมื่อคัดลอกไปยังระบบไฟล์ในเครื่องฉันมักจะใช้ตัวเลือก rsync ต่อไปนี้:

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

นี่คือเหตุผลของฉัน:

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

ฉันเห็นการถ่ายโอนเร็วขึ้น 17% โดยใช้การตั้งค่า rsync เหนือคำสั่ง tar ต่อไปนี้ตามคำแนะนำอื่น:

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

เมื่อฉันต้องคัดลอกข้อมูลจำนวนมากฉันมักจะใช้ tar และ rsync ร่วมกัน เส้นทางแรกคือทาร์มันอย่างนี้:

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

โดยปกติแล้วด้วยไฟล์จำนวนมากจะมีบางอย่างที่ tar ไม่สามารถจัดการได้ด้วยเหตุผลใดก็ตาม หรืออาจจะเป็นกระบวนการที่ถูกขัดจังหวะหรือหากเป็นการย้ายระบบไฟล์คุณอาจต้องการทำสำเนาเริ่มต้นก่อนขั้นตอนการโอนย้ายจริง ไม่ว่าในอัตราใดหลังจากการคัดลอกครั้งแรกฉันทำขั้นตอน rsync เพื่อซิงค์ทั้งหมด:

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

โปรดทราบว่าเครื่องหมายทับต่อท้าย/src/เป็นสิ่งสำคัญ

rsync

นี่คือ rsync ที่ฉันใช้ฉันชอบ cp สำหรับคำสั่งง่ายๆไม่ใช่อย่างนี้

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

cpio

นี่คือวิธีที่จะปลอดภัยกว่า cpio มันเร็วพอ ๆ กับทาร์อาจจะเร็วกว่านิดหน่อย

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

น้ำมันดิน

สิ่งนี้ก็เป็นสิ่งที่ดีและยังคงมีต่อความล้มเหลวในการอ่าน

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

โปรดทราบว่าทั้งหมดนั้นมีไว้สำหรับสำเนาในเครื่องเท่านั้น

สิ่งที่คุณต้องการ เพียงแค่อย่าลืมสลับเมื่อคุณตัดสินใจที่จะใช้-acp

หากคุณต้องการคำตอบจริงๆ: ฉันจะใช้ rsync เพราะมันยืดหยุ่นกว่า จำเป็นต้องปิดเครื่องก่อนที่การคัดลอกจะเสร็จสมบูรณ์หรือไม่ เพียง ctrl-c และกลับมาทำงานต่อทันทีที่คุณกลับมา ต้องการยกเว้นบางไฟล์หรือไม่ --exclude-fromเพียงแค่ใช้ ต้องการเปลี่ยนความเป็นเจ้าของหรือการอนุญาตหรือไม่ rsync จะทำเพื่อคุณ

rsyncคำสั่งเสมอคำนวณ checksums ในไบต์จะถ่ายโอนทุก

ตัวเลือกบรรทัดคำสั่ง--checksumเกี่ยวข้องเฉพาะกับการตรวจสอบจำนวนไฟล์ที่ใช้ในการพิจารณาว่าไฟล์ใดที่จะถ่ายโอนหรือไม่เช่น:

-c, --checksum ข้ามไปตาม checksum ไม่ใช่ mod-time & size "

manpage บอกว่า:

โปรดทราบว่า rsync จะตรวจสอบว่าแต่ละไฟล์ที่ถ่ายโอนถูกสร้างขึ้นใหม่อย่างถูกต้องที่ด้านการรับโดยการตรวจสอบการตรวจสอบไฟล์ทั้งหมด แต่การตรวจสอบอัตโนมัติหลังการถ่ายโอนนั้นไม่เกี่ยวข้องกับตัวเลือกนี้ก่อนการถ่ายโอน "ไฟล์นี้ต้องการหรือไม่ จะได้รับการปรับปรุง? " ตรวจสอบ

ดังนั้นrsyncจะคำนวณการตรวจสอบของไฟล์ทั้งหมดในด้านการรับเสมอแม้ว่า-c/ --checksumตัวเลือกจะ "ปิด"

rsync -aPhW --protocol=28ช่วยเพิ่มความเร็วให้กับสำเนาขนาดใหญ่เหล่านั้นด้วย RSYNC ฉันมักจะ rsync เพราะความคิดที่จะอยู่ตรงกลางผ่าน 90GiB และมันทำให้ฉันกลัวออกจาก CP

rsync นั้นยอดเยี่ยม แต่มีปัญหากับไดเรกทอรีต้นไม้ที่มีขนาดใหญ่มากเพราะมันเก็บต้นไม้ในหน่วยความจำ ฉันแค่ต้องการดูว่าพวกเขาจะแก้ไขปัญหานี้เมื่อฉันพบกระทู้นี้หรือไม่

ฉันก็ค้นพบ:

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

คุณสามารถแยกต้นไม้ด้วยตนเองและเรียกใช้หลาย rsyncs

เธรดนี้มีประโยชน์มากและเนื่องจากมีตัวเลือกมากมายเพื่อให้ได้ผลลัพธ์ฉันจึงตัดสินใจเปรียบเทียบบางส่วน ฉันเชื่อว่าผลลัพธ์ของฉันจะมีประโยชน์ต่อผู้อื่นได้อย่างรวดเร็ว

ในการย้ายข้อมูล532Gbที่แจกจ่ายในไฟล์ 1,753,200 ไฟล์เรามีเวลาดังกล่าว

• rsync ใช้เวลา 232 นาที
• tar ใช้เวลา 206 นาที
• cpio ใช้เวลา 225 นาที
• rsync + parallel ใช้เวลา 209 นาที

rsync + parallelเกี่ยวกับกรณีของฉันฉันต้องการที่จะใช้ ฉันหวังว่าข้อมูลนี้จะช่วยให้ผู้คนจำนวนมากขึ้นในการตัดสินใจเลือกทางเลือกเหล่านี้

มาตรฐานที่สมบูรณ์ได้รับการเผยแพร่ที่นี่

เมื่อทำสำเนาโลคัลไดเร็กทอรีในเครื่องประสบการณ์ของฉันคือ "cp -van src dest" เร็วกว่า rsync 20% เท่าที่การรีสตาร์ทนั่นคือสิ่งที่ "-n" ทำ คุณเพียงแค่ต้อง rm ไฟล์ที่คัดลอกบางส่วน ไม่เจ็บปวดเว้นแต่จะเป็น ISO หรือบางอย่าง

ARJ เป็นโรงเรียนที่เก่ามาก !! ฉันสงสัยจริงๆว่า ARJ และ / หรือ rsync จะให้ประสิทธิภาพ

สิ่งที่ฉันทำอยู่เสมอคือใช้ cpio:

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

นี่เร็วกว่า CP มากเร็วกว่าน้ำมันดินและไม่ทำอะไรเลย

แน่นอนคุณต้องการลองrclone สิ่งนี้บ้าเร็ว:

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

นี่เป็นสำเนาในเครื่องจากและไปยัง LITEONIT LCS-256 (256GB) SSD

คุณสามารถเพิ่ม--ignore-checksumในการเรียกใช้ครั้งแรกเพื่อให้เร็วยิ่งขึ้น

ทั้งสองจะทำงานได้ดี

tar ก็จะทำงานเช่นกัน แต่จะไม่ดำเนินการต่อจากการถูกขัดจังหวะเหมือน rsync

ถ้าคุณใช้ ARJ

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

-jm -m1ระดับการบีบอัดอยู่ที่ไหนและ-jeทำให้สามารถเรียกทำงานได้ ตอนนี้คุณมีไฟล์ที่ถูกบีบอัด

จากนั้นสำหรับการแยกไปยังแผนที่เป้าหมาย

filepack -y  

ตำแหน่งที่จะสร้างซอร์สแผนที่ (ซึ่ง-yยอมรับเสมอเขียนทับข้าม ฯลฯ )

หนึ่งสามารถ scp ftp filepack ไปยังพื้นที่เป้าหมายและดำเนินการถ้าเป็นไปได้

มีการเพิ่มความเร็วบางอย่างที่สามารถนำไปใช้กับrsync:

หลีกเลี่ยง

• -z/ --compress: การบีบอัดจะโหลดเฉพาะ CPU เนื่องจากการถ่ายโอนไม่ได้อยู่ในเครือข่าย แต่ผ่าน RAM
• --append-verify: ทำการถ่ายโอนต่อ นี่เป็นความคิดที่ดี แต่มีกรณีความล้มเหลวที่เป็นอันตราย: ไฟล์ปลายทางใด ๆ ที่มีขนาดเท่ากัน (หรือมากกว่า) กว่าแหล่งที่มาจะได้รับการละเว้น นอกจากนี้มันจะตรวจสอบไฟล์ทั้งหมดในตอนท้ายซึ่งหมายถึงไม่มีความเร็วเพิ่มขึ้นอย่างมาก--no-whole-fileในขณะที่เพิ่มกรณีความล้มเหลวที่เป็นอันตราย

ใช้

• -S/ --sparse: เปลี่ยนลำดับ nulls เป็นบล็อกหร็อมแหร็ม
• --partialหรือ-Pคือ--partial --progress: บันทึกไฟล์ที่ถูกถ่ายโอนบางส่วนเพื่อดำเนินการต่อในอนาคต หมายเหตุ: ไฟล์จะไม่มีชื่อชั่วคราวดังนั้นตรวจสอบให้แน่ใจว่าไม่มีสิ่งอื่นใดที่คาดว่าจะใช้ปลายทางจนกว่าสำเนาทั้งหมดจะเสร็จสมบูรณ์
• --no-whole-fileเพื่อให้สิ่งที่จำเป็นต้องส่งใหม่ใช้การถ่ายโอนของเดลต้า การอ่านไฟล์ครึ่งหนึ่งที่ถ่ายโอนบางส่วนนั้นเร็วกว่าการเขียนอีกครั้ง
• --inplace เพื่อหลีกเลี่ยงการคัดลอกไฟล์ (แต่หากไม่มีสิ่งใดที่อ่านปลายทางจนกว่าการถ่ายโอนทั้งหมดจะเสร็จสิ้น)