วิธีคัดลอกไฟล์จำนวนมากอย่างรวดเร็วระหว่างเซิร์ฟเวอร์สองเครื่อง

ฉันต้องการถ่ายโอน mp3 จำนวนมากระหว่างสองบริการ (Ubuntu) โดยขนาดใหญ่ฉันหมายถึงประมาณหนึ่งล้านไฟล์ซึ่งโดยเฉลี่ย 300K ฉันลองด้วยscpแต่ใช้เวลาประมาณหนึ่งสัปดาห์ (ประมาณ 500 KB / s) หากฉันถ่ายโอนไฟล์เดียวด้วย HTTP ฉันจะได้รับ 9-10 MB / s แต่ฉันไม่รู้วิธีถ่ายโอนไฟล์ทั้งหมด

มีวิธีการโอนทั้งหมดอย่างรวดเร็วหรือไม่

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

tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'

ตามความคิดเห็นของ Mackintosh ด้านล่างนี้เป็นคำสั่งที่คุณจะใช้สำหรับ rsync

rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir

ฮาร์ดไดรฟ์ภายนอกและการจัดส่งแบบจัดส่งภายในวันเดียวกัน

ฉันจะใช้ rsync

หากคุณได้ส่งออกมันผ่าน HTTP โดยมีรายชื่อไดเรกทอรีให้ใช้คุณสามารถใช้ wget และอาร์กิวเมนต์ --mirror ได้เช่นกัน

คุณเห็นแล้วว่า HTTP นั้นเร็วกว่า SCP เนื่องจาก SCP กำลังเข้ารหัสทุกอย่าง (และทำให้เกิดปัญหาคอขวดในซีพียู) HTTP และ rsync กำลังจะย้ายเร็วขึ้นเพราะพวกเขาไม่ได้เข้ารหัส

นี่คือเอกสารบางส่วนในการตั้งค่า rsync บน Ubuntu: https://help.ubuntu.com/community/rsync

เอกสารเหล่านั้นพูดถึงการทำ tunnel rsync ผ่าน SSH แต่ถ้าคุณเพิ่งย้ายข้อมูลไปรอบ ๆ บน LAN ส่วนตัวคุณไม่จำเป็นต้องใช้ SSH (ฉันสมมติว่าคุณอยู่บน LAN ส่วนตัวหากคุณได้รับ 9-10MB / วินาทีทางอินเทอร์เน็ตฉันต้องการทราบว่าคุณมีการเชื่อมต่อแบบใด!)

ต่อไปนี้เป็นเอกสารขั้นพื้นฐานอื่น ๆ ที่จะช่วยให้คุณติดตั้งเซิร์ฟเวอร์ rsync ที่ไม่ปลอดภัย (ไม่มีการพึ่งพา SSH): http://transamrit.net/docs/rsync/

หากไม่มีการพูดคุยมากนักให้ใช้เน็ตแคทเตอร์ ไม่มีโอเวอร์เฮดของโปรโตคอลคุณกำลังคัดลอกโดยตรงไปยังซ็อกเก็ตเครือข่าย ตัวอย่าง

srv1$ tar cfv - *mp3 | nc -w1 remote.server.net 4321

srv2$ nc -l -p 4321 |tar xfv -

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

อัลกอริทึมการเรียกซ้ำแบบเพิ่มส่วนใหม่ตอนนี้จะใช้เมื่อ rsync กำลังพูดคุยกับเวอร์ชัน 3.x อื่น นี่เป็นการเริ่มต้นการถ่ายโอนที่รวดเร็วยิ่งขึ้น (ก่อนที่จะพบไฟล์ทั้งหมด) และต้องการหน่วยความจำน้อยกว่ามาก ดูตัวเลือก - เรียกซ้ำใน manpage สำหรับข้อ จำกัด บางอย่าง

rsync เช่นเดียวกับคนอื่น ๆ ได้แนะนำแล้ว หากโอเวอร์เฮดของ CPU จากการเข้ารหัสเป็นคอขวดให้ใช้อัลกอริธึม CPU ที่เข้มข้นน้อยกว่าอย่างเช่นปักเป้า เช่นสิ่งที่ชอบ

rsync -ax -e 'ssh -c blowfish' /local/path user@host:/remote/path

ในการย้าย 80 TB ของข้อมูล (ล้านไฟล์เล็ก ๆ ) เมื่อวานนี้เปลี่ยนจากrsyncการtar พิสูจน์แล้วว่าเป็นได้เร็วขึ้นมากในขณะที่เราพยายามหยุด

# slow
rsync -av --progress /mnt/backups/section01/ /mnt/destination01/section01

และเปลี่ยนtarเป็น ...

# fast
cd /mnt/backups/
tar -cf - section01 | tar -xf - -C /mnt/destination01/ 

เนื่องจากเซิร์ฟเวอร์เหล่านี้อยู่บน LAN เดียวกันปลายทางจึงติดตั้ง NFS บนระบบต้นทางซึ่งกำลังดำเนินการอยู่ ไม่ทำให้เร็วขึ้นเราตัดสินใจที่จะไม่เก็บรักษาatimeไฟล์ไว้:

mount -o remount,noatime /mnt/backups
mount -o remount,noatime /mnt/destination01

ภาพด้านล่างแสดงความแตกต่างของการเปลี่ยนแปลงจาก rsync เป็น tar มันเป็นของฉันเจ้านายของความคิดของฉันและเพื่อนร่วมงานของทั้งสองดำเนินการและทำดีเขียนขึ้นในบล็อกของเขา ฉันชอบภาพสวยๆ :)

เมื่อทำการคัดลอกไฟล์จำนวนมากฉันพบว่าเครื่องมือเช่น tar และ rsync ไม่มีประสิทธิภาพมากกว่าที่พวกเขาต้องการเนื่องจากการเปิดและปิดไฟล์จำนวนมาก ผมเขียนเป็นเครื่องมือที่เรียกว่าโอเพนซอร์สอย่างรวดเร็ว Archiver ว่าจะเร็วกว่า tar สำหรับสถานการณ์เหล่านี้: https://github.com/replicon/fast-archiver ; มันทำงานได้เร็วขึ้นโดยดำเนินการไฟล์หลายไฟล์พร้อมกัน

นี่คือตัวอย่างของ fast-archiver กับ tar ในการสำรองข้อมูลมากกว่าสองล้านไฟล์ fast-archiver ใช้เวลา 27 นาทีในการเก็บถาวรเทียบกับ tar ใช้เวลา 1 ชั่วโมง 23 นาที

$ time fast-archiver -c -o /dev/null /db/data
skipping symbolic link /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps

$ time tar -cf - /db/data | cat > /dev/null
tar: Removing leading `/' from member names
tar: /db/data/base/16408/12445.2: file changed as we read it
tar: /db/data/base/16408/12464: file changed as we read it
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps

ในการถ่ายโอนไฟล์ระหว่างเซิร์ฟเวอร์คุณสามารถใช้ fast-archiver กับ ssh เช่นนี้:

ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x

ฉันใช้ tar ถึงnetcatวิธีเช่นกันยกเว้นฉันชอบที่จะใช้socat- พลังงานมากขึ้นเพื่อเพิ่มประสิทธิภาพสำหรับสถานการณ์ของคุณ - ตัวอย่างเช่นโดย tweaking mss (หัวเราะด้วยถ้าคุณต้องการ แต่ฉันพบsocatข้อโต้แย้งที่ง่ายกว่าที่จะจำได้เพราะมันสอดคล้องกัน) ดังนั้นสำหรับฉันนี่เป็นเรื่องธรรมดามากเมื่อเร็ว ๆ นี้เนื่องจากฉันย้ายสิ่งต่าง ๆ ไปยังเซิร์ฟเวอร์ใหม่:

host1$ tar cvf - filespec | socat stdin tcp4:host2:portnum

host2$ socat tcp4-listen:portnum stdout | tar xvpf -

นามแฝงเป็นตัวเลือก

ทางเลือกหนึ่งคือความพร้อมเพรียงกัน อาจมีประสิทธิภาพมากกว่า Rsync เล็กน้อยในกรณีนี้และการตั้งค่าการรับฟังค่อนข้างง่ายกว่า

ดูเหมือนว่าอาจมีการพิมพ์ผิดสองสามข้อในคำตอบยอดนิยม สิ่งนี้อาจทำงานได้ดีกว่า:

tar -cf - /path/to/dir | ssh remote_server 'tar -xvf - -C /path/to/remotedir'

• Network File System (NFS)จากนั้นคัดลอกสิ่งที่คุณต้องการเช่น Midnight Commander (mc), Nautilus (จาก gnome) ฉันใช้ NFS v3 กับผลลัพธ์ที่ดี
• Samba (CIFS)แล้วคัดลอกไฟล์ด้วยสิ่งที่คุณต้องการ แต่ฉันไม่รู้ว่ามันมีประสิทธิภาพแค่ไหน
• HTTPกับwget --mirrorเป็นอีวานเดอร์สันได้แนะนำหรือลูกค้า http อื่น ๆ ระวังอย่าให้มี symlink ที่น่ารังเกียจหรือไฟล์ดัชนีที่ทำให้เข้าใจผิด ถ้าสิ่งที่คุณมีคือ MP3 คุณควรจะปลอดภัย
• rsync ฉันใช้มันกับผลลัพธ์ที่ดีมากและหนึ่งในคุณสมบัติที่ดีของมันคือคุณสามารถขัดจังหวะและเริ่มการถ่ายโอนต่อในภายหลัง

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

ขอบคุณคำตอบที่ยอดเยี่ยมของ Scott Pack (ฉันไม่เคยรู้วิธีการทำสิ่งนี้กับ ssh มาก่อน) ฉันสามารถเสนอการปรับปรุงนี้ได้ (ถ้าbashเป็นเชลล์ของคุณ) สิ่งนี้จะเพิ่มการบีบอัดแบบขนานตัวบ่งชี้ความคืบหน้าและตรวจสอบความสมบูรณ์ของลิงก์เครือข่าย:

tar c file_list |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        tar xC /directory/to/extract/to
    '

pvเป็นโปรแกรมดูความคืบหน้าที่ดีสำหรับไพพ์ของคุณและpigzเป็นโปรแกรม gzip แบบขนานที่ใช้เธรดจำนวนมากเท่าที่ซีพียูของคุณมีตามค่าเริ่มต้น (ฉันเชื่อว่ามากถึง 8 สูงสุด) คุณสามารถปรับระดับการบีบอัดให้เหมาะสมกับอัตราส่วนของ CPU กับแบนด์วิดท์เครือข่ายที่ดีขึ้นและสลับมันออกมาด้วยpxz -9eและpxz -dถ้าคุณมี CPU มากกว่าแบนด์วิธมาก คุณต้องยืนยันว่าผลรวมทั้งสองนั้นตรงกันเมื่อเสร็จสิ้น

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

ตัวอย่างผลลัพธ์:

6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -                     ]
 176MiB [9.36MiB/s] [9.36MiB/s] [                                            <=>                                                                        ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e  -

สำหรับอุปกรณ์บล็อก:

dd if=/dev/src_device bs=1024k |
    tee >(sha512sum >&2) |
    pv -prab |
    pigz -9 |
    ssh [user@]remote_host '
        gunzip |
        tee >(sha512sum >&2) |
        dd of=/dev/src_device bs=1024k
    '

ตรวจสอบให้แน่ใจว่ามีขนาดหรือขีด จำกัด เดียวกันกับ count =, skip =, find =, ฯลฯ

เมื่อฉันคัดลอกระบบไฟล์ด้วยวิธีนี้ฉันมักdd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefsจะทำให้พื้นที่ที่ไม่ได้ใช้ส่วนใหญ่เป็นศูนย์ก่อนซึ่งจะเพิ่มความเร็วให้กับ xfer ขึ้น

ฉันไม่คิดว่าคุณจะทำอะไรได้ดีไปกว่า scp เว้นแต่ว่าคุณจะติดตั้งการ์ดเครือข่ายที่เร็วขึ้น หากคุณกำลังทำสิ่งนี้ผ่านอินเทอร์เน็ตนั่นจะไม่ช่วยได้

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

หากคุณสามารถเชื่อมต่อ 2 เครื่องโดยตรงโดยใช้กิกะบิตอีเธอร์เน็ตนั่นอาจเป็นวิธีที่เร็วที่สุด

สำหรับ 100Mb / s อัตราความเร็วของทฤษฏีคือ 12.5 MB / s ดังนั้นที่ 10MB / s คุณทำได้ค่อนข้างดี

ฉันจะสะท้อนข้อเสนอแนะเพื่อทำ rsync อาจผ่าน ssh สิ่งที่ต้องการ:

rsync -avW -e ssh $SOURCE $USER@$REMOTE:$DEST

ที่ 100Mb / s CPU ของคุณควรสามารถจัดการการเข้ารหัส / ถอดรหัสได้โดยไม่กระทบกับอัตราการส่งข้อมูล และถ้าคุณขัดจังหวะการไหลของข้อมูลคุณควรจะสามารถกลับมาทำงานต่อจากจุดที่คุณค้างไว้ ระวังด้วยไฟล์ "นับล้าน" การเริ่มต้นใช้เวลาสักครู่ก่อนที่จะถ่ายโอนสิ่งใด ๆ

ฉันพบสิ่งนี้ยกเว้นว่าฉันกำลังถ่ายโอนบันทึกของ Oracle

นี่คือรายละเอียด

• SCP

  inefficient and encrypted (encrypted = slower than unencrypted 
  depending on the link and your processor) 
  

• rsync

  efficient but typically encrypted (though not necessarily)
  

• FTP / HTTP

  both seem to be efficient, and both are plaintext. 
  

ฉันใช้ FTP กับความสำเร็จที่ยิ่งใหญ่ (ที่ความสำเร็จยิ่งใหญ่เทียบเท่ากับ ~ 700Mb / s ในเครือข่าย Gb) หากคุณได้รับ 10MB (ซึ่งเท่ากับ 80Mb / s) อาจมีบางอย่างผิดปกติ

คุณบอกอะไรเราได้บ้างเกี่ยวกับแหล่งที่มาและปลายทางของข้อมูล มันเป็นไดรฟ์เดียวกับไดรฟ์เดียวหรือไม่ RAID เป็น USB หรือไม่

ฉันรู้ว่าคำถามนี้มีคำตอบอยู่แล้ว แต่หากเครือข่ายของคุณใช้สายครอสโอเวอร์ Gb / s ช้าสิ่งที่จำเป็นต้องแก้ไขก็คือ

คุณไม่ได้พูดถึงถ้าสองเครื่องอยู่ใน LAN เดียวกันหรือถ้าช่องทางที่ปลอดภัย (เช่นใช้ SSH) มีผลบังคับใช้ แต่เครื่องมืออื่นคุณสามารถใช้เป็นnetcat

ฉันจะใช้สิ่งต่อไปนี้บนเครื่องรับ:

cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m

จากนั้นในด้านการส่ง:

cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>

มันมีข้อดีดังต่อไปนี้:

• ไม่มีโอเวอร์เฮดของ CPU สำหรับการเข้ารหัสที่ ssh มี
• การgzip -1บีบอัดแสงให้โดยไม่อิ่มตัวซีพียูจึงทำให้การแลกเปลี่ยนที่ดีให้การบีบอัดเล็กน้อยในขณะที่ยังคงรักษาปริมาณงานสูงสุด (อาจไม่ได้ประโยชน์สำหรับข้อมูล MP3 แต่ไม่เจ็บ)
• หากคุณสามารถแบ่งพาร์ติชันไฟล์ออกเป็นกลุ่มคุณสามารถรันไพพ์สองไฟล์หรือมากกว่าในแบบขนานและมั่นใจได้ว่าคุณมีแบนด์วิธเครือข่ายที่อิ่มตัว

เช่น,

find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>

หมายเหตุ:

• ไม่ว่าคุณจะถ่ายโอนทางไหนฉันอาจจะเรียกใช้ rsync หรือพร้อมเพรียงกันเพื่อให้แน่ใจว่าคุณได้ทุกอย่าง
• คุณสามารถใช้tarแทนcpioหากคุณต้องการ
• แม้ว่าคุณจะจบลงด้วยการใช้ ssh ฉันจะให้แน่ใจว่ามันไม่ได้ใช้การบีบอัดใด ๆ และไปป์gzip -1ตัวเองแทนเพื่อหลีกเลี่ยงความอิ่มตัวของ CPU (หรืออย่างน้อยตั้งค่า CompressionLevel เป็น 1)

scp อย่างง่ายพร้อมตัวเลือกที่เหมาะสมจะสามารถเข้าถึง 9-10 MB / s ผ่าน LAN ได้อย่างง่ายดาย:

scp -C -c arcfour256 ./local/files.mp3 remoteuser@remoteserver:/opt/remote

ด้วยตัวเลือกเหล่านั้นมีแนวโน้มว่าปริมาณงานจะกลายเป็น 4x หรือ 5x เร็วกว่าไม่มีตัวเลือก (ค่าเริ่มต้น)

ถ้าคุณมีเซิร์ฟเวอร์ FTP ในด้าน src คุณสามารถใช้ncftpgetจากเว็บไซต์ ncftp มันทำงานได้อย่างยอดเยี่ยมกับไฟล์ขนาดเล็กที่ใช้ tar ภายใน

การเปรียบเทียบหนึ่งรายการแสดงถึงสิ่งนี้: การย้ายไฟล์ขนาดเล็ก 1.9GB (33926 ไฟล์)

1. การใช้ scp ใช้เวลา 11m59s
2. การใช้ rsync ใช้เวลา 7m10s
3. การใช้ ncftpget ใช้เวลา 1m20s

คุณสามารถลองใช้คำสั่ง BBCP เพื่อทำการถ่ายโอนของคุณ มันเป็น ssh แบบขนานบัฟเฟอร์ที่กรีดร้องอย่างแท้จริง เรามักจะได้รับ 90% + อัตราบรรทัดให้เราสามารถเก็บท่อเลี้ยง

$ bbcp -s 8 -w 64M -N io 'tar -cO srcdirectory' desthostname:'tar -x -C destdir'

โดยปกติแล้วเราพยายามอย่างหนักเพื่อหลีกเลี่ยงการเคลื่อนไหวที่ไม่เหมาะสม เราใช้พูล ZFS ที่เราสามารถ "เพิ่ม" พื้นที่ดิสก์เพิ่มเติมได้เสมอ แต่บางครั้ง ... คุณต้องย้ายสิ่งของ หากเรามีระบบไฟล์ "สด" ที่อาจใช้เวลาหลายชั่วโมง (หรือหลายวัน) ในการคัดลอกแม้ในขณะที่ระเบิดเต็ม .. เราทำตามขั้นตอนสองขั้นตอน zfs เพื่อส่งรูทีน:

1. สร้าง ZFS snapshot และโอนไปยังพูลใหม่บนเครื่องใหม่ ปล่อยให้มันใช้เวลานานเท่าที่จะทำได้
2. สร้างสแนปช็อตที่สองและส่งเป็นส่วนเพิ่ม สแนปชอตที่เพิ่มขึ้นจะรวมเฉพาะการเปลี่ยนแปลง (เล็กกว่า) ตั้งแต่ครั้งแรกดังนั้นจึงผ่านไปค่อนข้างเร็ว
3. เมื่อสแนปชอตที่เพิ่มขึ้นเสร็จสมบูรณ์คุณสามารถเปลี่ยนต้นฉบับและตัดเป็นสำเนาใหม่และ "การหยุดทำงานออฟไลน์" ของคุณจะถูกเก็บไว้ให้น้อยที่สุด

นอกจากนี้เรายังส่ง zfs ของเราไปที่ BBCP เช่นกัน ... มันเพิ่มการใช้งานเครือข่ายของเราให้สูงสุดและลดเวลาการถ่ายโอนให้น้อยที่สุด

BBCP สามารถใช้ได้อย่างอิสระคุณสามารถ google มันและมันเป็นคอมไพล์ตรงไปตรงมา เพียงแค่คัดลอกลงใน / usr / local / bin ของคุณบน src และเครื่องปลายทางและมันก็จะใช้ได้

ฉันเดาว่าคำตอบของฉันจะสายไปเล็กน้อย แต่ฉันได้รับประสบการณ์ที่ดีกับการใช้ mc (Midnight Commander) บนเซิร์ฟเวอร์เครื่องหนึ่งเพื่อเชื่อมต่อผ่าน SFTP ไปยังเซิร์ฟเวอร์อื่น

ตัวเลือกในการเชื่อมต่อผ่าน FTP อยู่ในเมนู "ซ้าย" และ "ขวา" โดยป้อนที่อยู่ดังนี้:

/#ftp:name@server.xy/

หรือ

/#ftp:name@ip.ad.dr.ess/

คุณสามารถนำทางและทำการดำเนินการกับไฟล์ได้เกือบจะเหมือนในระบบไฟล์โลคัล

มีตัวเลือกในตัวเพื่อทำการคัดลอกในพื้นหลัง แต่ฉันชอบใช้คำสั่งหน้าจอและแยกออกจากหน้าจอในขณะที่ mc กำลังคัดลอก (ฉันคิดว่ามันทำงานได้เร็วขึ้นแล้วด้วย)

ถึง @scottpack คำตอบของตัวเลือก rSync

หากต้องการแสดงความคืบหน้าของการอัปโหลดให้ใช้ '--progess' เป็นตัวเลือกหลังจาก -avW ในคำสั่งดังที่แสดงด้านล่าง

rsync -avW --progress -e ssh /path/to/dir/ remote_server:/path/to/remotedir

นี่คือมาตรฐานที่รวดเร็วในการเปรียบเทียบเทคนิคบางอย่าง

• Source เป็นซีพียู Intel 4-core Xeon (R) E5-1620 @ 3.60GHz ที่มี 250 Mbps และไดรฟ์ SATA
• ปลายทางคือซีพียู Intel Core 6-Core (R) Xeon (R) E-2136 @ 3.30GHz ที่มีแบนด์วิดท์ 1 Gbps และไดรฟ์ SSD

จำนวนไฟล์: 9632, ขนาดทั้งหมด: 814 MiB, ขนาดเฉลี่ย: 84 KiB

• RSYNC: 1m40.570s
• การอัด RSYNC +: 0m26.519s
• TAR + NETCAT: 1m58.763s
• TAR + การบีบอัด + NETCAT: 0m28.009s

คำสั่งสำหรับ tar / netcat เดิมคือ:

Source : tar -cf - /sourcedir/ | nc -v 11.22.33.44 5000
Dest : nc -v -l 5000 | tar -xf -

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

หากคุณกำลังส่งไฟล์ MP3 และไฟล์บีบอัดอื่น ๆ คุณจะไม่ได้รับประโยชน์อะไรมากจากโซลูชั่นใด ๆ ที่พยายามบีบอัดไฟล์เหล่านั้นเพิ่มเติม การแก้ปัญหาจะเป็นสิ่งที่สามารถสร้างการเชื่อมต่อที่หลากหลายระหว่างเซิร์ฟเวอร์ทั้งสองได้และทำให้เกิดความกดดันต่อแบนด์วิดท์ระหว่างระบบทั้งสองมากขึ้น เมื่อถึงจุดสูงสุดแล้วก็มีไม่มากที่จะได้รับโดยไม่ต้องปรับปรุงฮาร์ดแวร์ของคุณ (เร็วกว่าการ์ดเครือข่ายระหว่างเซิร์ฟเวอร์เหล่านั้น)

ฉันลองใช้เครื่องมือสองตัวเพื่อคัดลอกไฟล์ 1GB ผลลัพธ์คือด้านล่าง: HTTP เร็วที่สุดด้วย wget -c nc second ใน scp บรรทัดที่ช้าที่สุดและล้มเหลวสองสามครั้ง ไม่มีวิธีที่จะดำเนินการ rsync ต่อโดยใช้ ssh เป็นแบ็กเอนด์ดังนั้นผลลัพธ์เดียวกัน โดยสรุปฉันจะไปกับ http ด้วย wget -bqc และให้เวลา หวังว่าสิ่งนี้จะช่วย

ฉันต้องคัดลอกดิสก์ BackupPC ไปยังเครื่องอื่น

ฉันใช้ rsync

เครื่องมีหน่วยความจำ 256 MB

ขั้นตอนที่ฉันติดตามคืออันนี้:

• ดำเนินการrsyncโดยไม่-H(ใช้เวลา 9 ชั่วโมง)
• เมื่อ rsync เสร็จแล้วฉันจะซิงโครไนซ์cpoolไดเรกทอรีและเริ่มต้นด้วยpcไดเรกทอรี; ฉันตัดการถ่ายโอน
• จากนั้นเริ่มต้นใหม่rsyncด้วยการ-Hตั้งค่าสถานะและไฟล์ทั้งหมดที่เชื่อมโยงอย่างหนักในpcไดเรกทอรีได้รับการถ่ายโอนอย่างถูกต้อง (กระบวนการพบไฟล์จริงทั้งหมดcpoolแล้วเชื่อมโยงไปยังpcไดเรกทอรี) (ใช้เวลา 3 ชั่วโมง)

ในที่สุดฉันสามารถตรวจสอบได้df -mว่าไม่มีพื้นที่ว่างเหลือ

ด้วยวิธีนี้ฉันหลีกเลี่ยงปัญหากับหน่วยความจำและ rsync ตลอดเวลาที่ฉันสามารถตรวจสอบประสิทธิภาพโดยใช้ด้านบนและบนและในที่สุดฉันก็ถ่ายโอนข้อมูล 165GB