วิธีที่เร็วที่สุดในการส่งข้อมูลจำนวนมากระหว่างคอมพิวเตอร์สองเครื่องคืออะไร [ปิด]

นี่เป็นสถานการณ์ที่ฉันพบบ่อยใน:

• ฉันมีเซิร์ฟเวอร์ต้นทางที่มีฮาร์ดไดรฟ์ 320GB อยู่ภายในนั้นและ RAM 16 GB ( รายละเอียดที่แน่นอนมีให้ที่นี่แต่เนื่องจากนี่เป็นปัญหาที่ฉันพบบ่อยในเครื่องอื่นเช่นกันฉันต้องการคำตอบสำหรับการทำงานใด ๆ เครื่อง Linux ที่ "สมเหตุสมผล")
• ฉันมีเซิร์ฟเวอร์สำรองที่มีพื้นที่ฮาร์ดไดรฟ์หลายเทราไบต์ ( รายละเอียดที่แน่นอนที่นี่ดูข้อจำกัดความรับผิดชอบด้านบน)

ฉันต้องการถ่ายโอนข้อมูล 320GB จากเซิร์ฟเวอร์ต้นทางไปยังเซิร์ฟเวอร์เป้าหมาย (โดยเฉพาะข้อมูลจาก/dev/sda)

1. คอมพิวเตอร์สองเครื่องนั้นอยู่ติดกันดังนั้นฉันจึงสามารถใช้สายเคเบิลระหว่างกันได้
2. ฉันอยู่บน LAN และฉันใช้เราเตอร์ใหม่ ishซึ่งหมายความว่าความเร็วเครือข่ายของฉันควร "ดีเลิศ" เป็น 1000Mbit ใช่ไหม
3. ความปลอดภัยไม่ใช่ปัญหา ฉันอยู่ในเครือข่ายท้องถิ่นและฉันเชื่อว่าทุกเครื่องในเครือข่ายรวมถึงเราเตอร์
4. (ไม่บังคับ)ฉันไม่จำเป็นต้องมีการตรวจสอบข้อมูลที่ลงนาม แต่การตรวจสอบข้อผิดพลาดพื้นฐาน (เช่นแพ็คเก็ตที่ถูกทิ้งหรือไดรฟ์ไม่สามารถอ่านได้) ควรตรวจพบได้แทนที่จะหายเข้าไปในเอาต์พุต

ฉันค้นหาคำถามนี้ทางออนไลน์และทดสอบหลายคำสั่ง สิ่งที่ปรากฏบ่อยที่สุดคือ:

ssh user@192.168.1.100 'dd bs=16M if=/dev/sda | gzip' > backup_sda.gz

คำสั่งนี้พิสูจน์แล้วว่าช้าเกินไป (มันวิ่งไปหนึ่งชั่วโมงมีข้อมูลประมาณ 80GB เท่านั้น) ใช้เวลาประมาณ 1 นาทีและ 22 วินาทีสำหรับแพ็คเก็ตทดสอบ 1GB และจบลงด้วยความเร็วสองเท่าเมื่อไม่ได้บีบอัด ผลลัพธ์อาจถูกบิดเบือนด้วยข้อเท็จจริงที่ว่าไฟล์ที่ถ่ายโอนมีจำนวนน้อยกว่า RAM ในระบบต้นทาง

ยิ่งกว่านั้น (และนี่คือการทดสอบในชิ้นทดสอบ 1GB) ฉันได้รับปัญหาถ้าฉันใช้gzipคำสั่งและdd; ไฟล์ผลลัพธ์มีการตรวจสอบที่แตกต่างกันเมื่อดึงข้อมูลออกมาบนเป้าหมาย ฉันยังคงพยายามหาสาเหตุว่าเกิดอะไรขึ้น

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

netcat เหมาะสำหรับสถานการณ์เช่นนี้ซึ่งความปลอดภัยไม่ใช่ปัญหา:

# on destination machine, create listener on port 9999
nc -l 9999 > /path/to/outfile

# on source machine, send to destination:9999
nc destination_host_or_ip 9999 < /dev/sda
# or dd if=/dev/sda | nc destination_host_or_ip 9999

หมายเหตุหากคุณใช้ddจาก GNU coreutils คุณสามารถส่งSIGUSR1ไปยังกระบวนการและจะส่งความคืบหน้าไปยัง stderr สำหรับ BSD ใช้ddSIGINFO

pvมีประโยชน์มากขึ้นในการรายงานความคืบหน้าในระหว่างการคัดลอก:

# on destination
nc -l 9999 | pv > /path/to/outfile

# on source
pv /dev/sda | nc destination_host_or_ip 9999
# or dd if=/dev/sda | pv | nc destination_host_or_ip 9999

1. อย่าใช้อย่างรวดเร็วการบีบอัด

   • สื่อการถ่ายโอนของคุณโดยเฉพาะอย่างยิ่งสำหรับเครือข่ายหรือยูเอสบีคุณจะทำงานกับข้อมูลที่มีการระเบิดสำหรับการอ่านแคชและการเขียนและสิ่งเหล่านี้จะไม่ซิงค์กัน
   • นอกเหนือจากเฟิร์มแวร์ดิสก์แคชดิสก์และเคอร์เนล / RAM แคชหากคุณสามารถใช้ CPU ของระบบในบางวิธีเพื่อรวมจำนวนข้อมูลที่แลกเปลี่ยนได้ต่อการระเบิดคุณควรทำเช่นนั้น
   • อัลกอริธึมการบีบอัดใด ๆ จะจัดการการป้อนข้อมูลแบบเบาบางโดยเร็วที่สุดเท่าที่จะเป็นไปได้โดยอัตโนมัติ แต่มีน้อยมากที่จะจัดการส่วนที่เหลือที่ทรูพุตเครือข่าย
   • lz4 เป็นตัวเลือกที่ดีที่สุดของคุณที่นี่:

     LZ4 เป็นอัลกอริธึมการบีบอัด lossless ที่รวดเร็วมากให้ความเร็วในการบีบอัดที่ 400 MB / s ต่อคอร์สามารถปรับขยายได้ด้วย CPU แบบหลายคอร์ นอกจากนี้ยังมีตัวถอดรหัสที่รวดเร็วมากด้วยความเร็วในหลาย GB / s ต่อคอร์โดยทั่วไปจะถึงขีด จำกัด ความเร็ว RAM ในระบบมัลติคอร์

2. โดยเฉพาะอย่างยิ่งไม่ได้โดยไม่จำเป็นแสวงหา

   • นี่อาจเป็นเรื่องยากที่จะวัด

   • หากมีพื้นที่ว่างจำนวนมากบนอุปกรณ์ที่คุณคัดลอกและอุปกรณ์ไม่ได้เป็นศูนย์เมื่อเร็ว ๆ นี้ แต่ควรคัดลอกไฟล์ระบบแหล่งที่มาทั้งหมดแล้วน่าจะคุ้มกับที่คุณควรทำก่อน สิ่งที่ต้องการ:

     </dev/zero tee >empty empty1 empty2; sync; rm empty*

   • แต่นั่นก็ขึ้นอยู่กับระดับที่คุณควรอ่านต้นฉบับ โดยปกติแล้วการอ่านอุปกรณ์ตั้งแต่ต้นจนจบจาก/dev/some_diskแฟ้มอุปกรณ์นั้นเป็นสิ่งที่พึงประสงค์เนื่องจากการอ่านในระดับระบบไฟล์จะเกี่ยวข้องกับการค้นหาไปมาและรอบ ๆ ดิสก์ตามลำดับ ดังนั้นคำสั่ง read ของคุณควรเป็นดังนี้:

     </dev/source_device lz4 | ...

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

     pax -r /source/tree[12] | lz4 | ...
     mksquashfs /source/tree[12] /dev/fd/1 -comp lz4 | ...
     

3. ไม่ได้sshเข้ารหัสกับ

   • การเพิ่มค่าใช้จ่ายในการเข้ารหัสเพื่อสื่อที่เชื่อถือได้เป็นที่ไม่จำเป็นและสามารถเป็นอันตรายอย่างรุนแรงกับความเร็วของยั่งยืนโอนข้อมูลที่อ่านความต้องการของการอ่านครั้งที่สอง
   • PRNGต้องการอ่านข้อมูลหรืออย่างน้อยบางส่วนของมันในการรักษาแบบแผน
   • และแน่นอนคุณต้องถ่ายโอนข้อมูลเช่นกัน
   • นอกจากนี้คุณยังจะต้องโอนค่าใช้จ่ายในการเข้ารหัสของตัวเอง - ซึ่งหมายความว่าทำงานมากขึ้นสำหรับข้อมูลน้อยโอนต่อการระเบิด

   • และดังนั้นคุณควรใช้netcat( หรืออย่างที่ฉันต้องการnmapโครงการที่มีความสามารถมากกว่าncat ) สำหรับสำเนาเครือข่ายแบบง่าย ๆ ตามที่ได้รับการแนะนำจากที่อื่น:

     ###  on tgt machine...
     nc -l 9999 > out.lz4
     ###  then on src machine...
     ... lz4 | nc tgt.local 9999
     

มีข้อ จำกัด หลายประการที่อาจ จำกัด ความเร็วในการถ่ายโอน

1. มีโอเวอร์เฮดของเครือข่ายโดยธรรมชาติในไพพ์ 1Gbps โดยปกติสิ่งนี้จะลดทรูพุต ACTUAL เป็น 900Mbps หรือน้อยกว่า จากนั้นคุณต้องจำไว้ว่านี่เป็นการรับส่งข้อมูลแบบสองทิศทางและคุณควรคาดหวังว่าจะน้อยกว่า 900Mbps

2. แม้ว่าคุณจะใช้ "เราเตอร์ใหม่ ish" คุณแน่ใจหรือไม่ว่าเราเตอร์รองรับ 1Gbps ไม่ใช่เราเตอร์ใหม่ทุกตัวที่รองรับ 1Gbps นอกจากนี้หากเป็นเราเตอร์ระดับองค์กรคุณอาจสูญเสียแบนด์วิดท์การส่งเพิ่มเติมไปยังเราเตอร์ที่ไม่มีประสิทธิภาพ แม้ว่าจะขึ้นอยู่กับสิ่งที่ฉันพบด้านล่างดูเหมือนว่าคุณจะได้รับมากกว่า 100Mbps

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

4. คุณใช้ดิสก์ IO เท่าไร ดูเหมือนว่าคุณจะถูก จำกัด ไม่ใช่โดยเครือข่าย แต่โดยดิสก์ไดรฟ์ HDD 7200 รอบต่อนาทีส่วนใหญ่จะได้รับประมาณ 40MB / s เท่านั้น คุณใช้การจู่โจมเลยหรือไม่? คุณใช้ SSD หรือไม่ คุณใช้อะไรในรีโมตปลายทาง?

ฉันขอแนะนำให้ใช้ rsync หากคาดว่าจะสามารถเรียกใช้การสำรองข้อมูลได้อีกครั้ง คุณสามารถ scp, ftp (s), หรือ http โดยใช้ตัวดาวน์โหลดเช่น filezilla ที่ปลายอีกด้านเพราะมันจะทำการเชื่อมต่อแบบ ssh / http / https / ftp สิ่งนี้สามารถเพิ่มแบนด์วิดท์ได้เนื่องจากโซลูชันอื่นอยู่เหนือไปป์ไลน์เดียว ไปป์ / เธรดเดี่ยวยังคงถูก จำกัด โดยข้อเท็จจริงที่ว่ามันเป็นเธรดเดียวซึ่งหมายความว่ามันอาจเป็น CPU ผูก

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

จากตัวอย่าง 80GB / h ที่คุณได้รับอยู่ที่ 177Mbps (22.2MB / s) ฉันรู้สึกว่าคุณสามารถเพิ่มสิ่งนี้เป็นสองเท่าด้วย rsync บนสายอีเธอร์เน็ตโดยเฉพาะระหว่างสองกล่องในขณะที่ฉันจัดการเพื่อให้ได้สิ่งนี้ในการทดสอบของฉันกับ rsync ผ่านกิกะบิต

เราจัดการกับเรื่องนี้เป็นประจำ

สองวิธีหลักที่เรามักจะใช้คือ:

1. SATA / eSATA / sneakernet
2. Direct NFS mount, จากนั้น local cpหรือrsync

ครั้งแรกนั้นขึ้นอยู่กับว่าสามารถย้ายที่ตั้งทางกายภาพได้หรือไม่ นี่ไม่ใช่กรณีเสมอไป

ครั้งที่สองทำงานได้ดีอย่างน่าประหลาดใจ โดยทั่วไปเราใช้การเชื่อมต่อสูงสุด 1gbps ค่อนข้างง่ายด้วยการเมาท์ NFS โดยตรง คุณจะไม่เข้าใกล้สิ่งนี้ด้วย scp, dd over ssh หรืออะไรที่คล้ายกัน (คุณมักจะได้อัตราสูงสุดใกล้กับ 100mpbs อย่างน่าสงสัย) แม้แต่ตัวประมวลผลแบบมัลติคอร์ที่เร็วมากคุณจะได้รับคอขวดในปริมาณงานสูงสุดของการเข้ารหัสในคอร์หนึ่งในคอร์ที่ช้าที่สุดของทั้งสองเครื่องซึ่งช้าลงอย่างมากเมื่อเทียบกับซีพียูแบบเต็มเบื่อ บางครั้งคุณจะชนกำแพงไอโอปสักพักหนึ่งและติดที่ประมาณ ~ 53MB / s แทนที่จะเป็นแบบทั่วไป ~ 110MB / s แต่โดยปกติแล้วจะมีอายุสั้นเว้นแต่ว่าที่มาหรือปลายทางเป็นจริงไดรฟ์เดียวจากนั้นคุณอาจถูก จำกัด ด้วยอัตราที่ยั่งยืนของไดรฟ์เอง (ซึ่งแตกต่างกันมากพอสำหรับเหตุผลแบบสุ่มที่คุณไม่ทราบจนกว่าคุณจะลองใช้จริง) - ฉัน

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

แก้ไข

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

การพิสูจน์ในอนาคต

คำแนะนำนี้เป็นของกลางปี ​​2558 นี้จะเกือบแน่นอนไม่ได้เป็นกรณีที่เป็นเวลาหลายปีเกินไปมากขึ้น ดังนั้นเอาทุกอย่างไปด้วยเม็ดเกลือและถ้าคุณเผชิญกับงานนี้เป็นประจำลองใช้วิธีการที่หลากหลายในการโหลดจริงแทนที่จะจินตนาการว่าคุณจะได้อะไรที่ใกล้เคียงกับทฤษฎีที่เหมาะสมที่สุดหรือแม้กระทั่งอัตราการรับส่งข้อมูลแบบบีบอัด / เข้ารหัส การจราจรซึ่งส่วนใหญ่เป็นข้อความ (protip: การถ่ายโอนจำนวนมากมักประกอบด้วยภาพเสียงวิดีโอฐานข้อมูลรหัสไบนารี่รูปแบบไฟล์สำนักงาน ฯลฯ ซึ่งถูกบีบอัดไว้แล้วในทางของตัวเองและได้รับประโยชน์น้อยมากจากการถูกเรียกใช้ผ่านรูทีนการบีบอัดอื่นขนาดบล็อกการบีบอัดที่เกือบจะรับประกันว่าจะไม่สอดคล้องกับข้อมูลไบนารีที่บีบอัดแล้วของคุณ ... )

ฉันคิดว่าในอนาคตแนวคิดเช่น SCTP จะถูกนำไปยังสถานที่ที่น่าสนใจมากขึ้นซึ่งการเชื่อมต่อที่ถูกผูกมัด (หรือการเชื่อมต่อใยแก้วนำแสงที่มีช่องสัญญาณภายใน) เป็นเรื่องปกติและแต่ละช่องสามารถรับกระแสที่เป็นอิสระจากคนอื่น สตรีมสามารถบีบอัด / เข้ารหัสในแบบคู่ขนาน ฯลฯ ฯลฯ นั่นจะยอดเยี่ยม! แต่นั่นไม่ใช่กรณีในวันนี้ในปี 2015 และถึงแม้ว่าการเพ้อฝันและการสร้างทฤษฎีเป็นสิ่งที่ดี แต่พวกเราส่วนใหญ่ไม่มีกลุ่มการจัดเก็บแบบกำหนดเองที่ทำงานในข้อมูลการส่ง cryo-Chamber โดยตรงไปยังอวัยวะภายในของ Blue Gene / Q นั่นไม่ใช่ความจริง เราไม่มีเวลาในการวิเคราะห์ปริมาณข้อมูลของเราอย่างละเอียดถี่ถ้วนเพื่อพิจารณาว่าการบีบอัดเป็นความคิดที่ดีหรือไม่ - การถ่ายโอนข้อมูลจะเสร็จสิ้นก่อนที่เราจะทำการวิเคราะห์เสร็จสิ้น

แต่...

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

bbcpเครื่องมือที่ดีที่ผมเคยใช้ในอดีตที่ผ่านมาคือ เท่าที่เห็นนี่: https://www.slac.stanford.edu/~abh/bbcp/

ดูเพิ่มเติมที่http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htm

ฉันมีความเร็วในการถ่ายโอนที่รวดเร็วมากด้วยเครื่องมือนี้

หากคุณได้รับการส่งผ่านครั้งแรกอย่างใด (ผ่านสาย / sneakernet / อะไรก็ตาม) คุณสามารถดูrsyncด้วยตัวเลือกบางอย่างที่สามารถเพิ่มความเร็วในการถ่ายโอนที่ตามมาอย่างมาก วิธีที่ดีมากที่จะไปคือ:

rsync -varzP sourceFiles destination

ตัวเลือกคือ: verbose, โหมดเก็บถาวร, เรียกซ้ำ, บีบอัด, ความคืบหน้าบางส่วน

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

bashมีพิเศษไวยากรณ์การเปลี่ยนเส้นทาง:
สำหรับการส่งออก:      > /dev/tcp/ IP  / พอร์ต
สำหรับการป้อนข้อมูล:       < /dev/tcp/ IP  / พอร์ต
IPห้ามเป็นได้ทั้ง IP ประทศนิยมหรือชื่อโฮสต์; พอร์ต/etc/servicesห้ามเป็นได้ทั้งตัวเลขทศนิยมหรือชื่อพอร์ตจาก

ไม่มี/dev/tcp/ไดเรกทอรีจริง เป็น kludge วากยสัมพันธ์พิเศษที่คำสั่งbashในการสร้างซ็อกเก็ต TCP เชื่อมต่อกับปลายทางที่ระบุจากนั้นทำสิ่งเดียวกันกับการเปลี่ยนเส้นทางไฟล์ตามปกติ

ดังนั้นหนึ่งสามารถสตรีมข้อมูลจากddหรือtarที่เครื่องต้นทางโดยตรงผ่าน TCP หรือในทางกลับกันการสตรีมข้อมูลไปยังtarหรือสิ่งที่เหมือนกันโดยตรงผ่าน TCP ไม่ว่าในกรณีใด netcat ที่ฟุ่มเฟือยหนึ่งตัวจะถูกกำจัด

หมายเหตุเกี่ยวกับ netcat

มีความไม่สอดคล้องกันในไวยากรณ์ระหว่าง netcat คลาสสิกและ GNU netcat ฉันจะใช้ไวยากรณ์ดั้งเดิมที่ฉันคุ้นเคย แทนที่-lpด้วย-lสำหรับ GNU netcat

นอกจากนี้ฉันไม่แน่ใจว่า GNU netcat ยอมรับ-qสวิตช์หรือไม่

การถ่ายโอนภาพดิสก์

(ตามแนวคำตอบของ zackse)
บนปลายทาง:

nc -lp 9999 >disk_image

บนแหล่งที่มา:

dd if=/dev/sda >/dev/tcp/destination/9999
 

การสร้างไฟล์เก็บถาวร tar.gz ด้วย tar

บนปลายทาง:

nc -lp 9999 >backup.tgz

บนแหล่งที่มา:

tar cz files or directories to be transferred >/dev/tcp/destination/9999

แทนที่.tgzด้วย.tbzและczด้วยcjเพื่อรับการbzip2เก็บถาวรแบบบีบอัด

ถ่ายโอนด้วยการขยายทันทีไปยังระบบไฟล์

tarนอกจากนี้ยังมี
บนปลายทาง:

cd backups
tar x </dev/tcp/destination/9999

บนแหล่งที่มา:

tar c files or directories to be transferred |nc -q 1 -lp 9999

มันจะทำงานโดยไม่ต้อง-q 1แต่ netcat จะติดเมื่อข้อมูลสิ้นสุดลง ดูน้ำมันดิน (1) tarสำหรับคำอธิบายไวยากรณ์และคำเตือนของ หากมีไฟล์จำนวนมากที่มีความซ้ำซ้อนสูง (เอนโทรปีต่ำ) คุณสามารถลองทำการบีบอัด (e. g. czและxzแทนที่จะเป็นcและx) ได้ แต่หากไฟล์เป็นเรื่องปกติและเครือข่ายนั้นเร็วพอก็จะทำให้กระบวนการช้าลง ดูคำตอบของ mikeserv สำหรับรายละเอียดเกี่ยวกับการบีบอัด

รูปแบบทางเลือก (ปลายทางรับฟังพอร์ต)

บนปลายทาง:

cd backups
nc -lp 9999 |tar x

บนแหล่งที่มา:

tar c files or directories to be transferred >/dev/tcp/destination/9999

ลองคำแนะนำเกี่ยวกับการเชื่อมต่อโดยตรงและหลีกเลี่ยงโปรโตคอลที่เข้ารหัสเช่น ssh จากนั้นหากคุณยังคงต้องการประสิทธิภาพการทำงานทุกบิตให้อ่านไซต์นี้ได้ที่: https://fasterdata.es.net/host-tuning/linux/สำหรับคำแนะนำในการเพิ่มประสิทธิภาพหน้าต่าง TCP ของคุณ

ฉันจะใช้สคริปต์นี้ฉันเขียนที่ต้องการsocatแพคเกจ

บนเครื่องต้นทาง:

tarnet -d wherefilesaretosend pass=none 12345 .

บนเครื่องเป้าหมาย:

tarnet -d wherefilesaretogo pass=none sourceip/12345

หากvbufแพ็กเกจ (Debian, Ubuntu) อยู่ที่นั่นผู้ส่งไฟล์จะแสดงความคืบหน้าของข้อมูล ตัวรับไฟล์จะแสดงไฟล์ที่ได้รับ ตัวเลือก pass = สามารถใช้ในกรณีที่ข้อมูลอาจถูกเปิดเผย (ช้ากว่า)

แก้ไข:

ใช้-nตัวเลือกเพื่อปิดใช้งานการบีบอัดหาก CPU เป็นคอขวด

หากงบประมาณไม่ใช่ประเด็นหลักคุณสามารถลองเชื่อมต่อไดรฟ์กับ "ตัวเชื่อมต่อไดรฟ์" Intel Xeon E5 12 core ตัวเชื่อมต่อนี้มักจะมีประสิทธิภาพมากจนคุณสามารถเรียกใช้ซอฟต์แวร์เซิร์ฟเวอร์ปัจจุบันของคุณได้ จากเซิร์ฟเวอร์ทั้งสอง!

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

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

หากคุณแคร์เกี่ยวกับการสำรองข้อมูลเท่านั้นและไม่เกี่ยวกับไบต์สำหรับการคัดลอกไบต์ของฮาร์ดไดรฟ์ฉันขอแนะนำ backupPC http://backuppc.sourceforge.net/faq/BackupPC.htmlมันค่อนข้างเจ็บปวดในการติดตั้ง แต่มันถ่ายโอนได้อย่างรวดเร็ว

เวลาในการถ่ายโอนเริ่มต้นของฉันสำหรับข้อมูล 500G อยู่ที่ประมาณ 3 ชั่วโมง การสำรองข้อมูลครั้งต่อไปจะเกิดขึ้นในประมาณ 20 วินาที

หากคุณไม่สนใจการสำรองข้อมูล แต่พยายามซิงค์สิ่งต่างๆแล้ว rsync หรือพร้อมเพรียงจะเหมาะกับความต้องการของคุณ

ไบต์สำหรับสำเนาไบต์ของฮาร์ดดิสก์มักเป็นแนวคิดที่น่ากลัวสำหรับจุดประสงค์ในการสำรองข้อมูล (ไม่มีส่วนเพิ่มไม่มีการประหยัดพื้นที่ไดรฟ์ไม่สามารถใช้งานได้คุณต้องสำรอง "พื้นที่ว่าง" และคุณต้องสำรองขยะ (เช่นไฟล์ swap 16 G หรือ 200G ของ core dumps หรือบางอย่าง) การใช้ rsync (หรือ backuppc หรืออื่น ๆ ) คุณสามารถสร้าง "snapshot" ในเวลาเพื่อให้คุณสามารถไปที่ "สิ่งที่ระบบไฟล์ของคุณดูเหมือน 30 นาทีที่ผ่านมา" ด้วย ค่าใช้จ่ายน้อยมาก

ที่กล่าวว่าหากคุณต้องการถ่ายโอนไบต์สำหรับการคัดลอกไบต์ปัญหาของคุณจะอยู่ที่การถ่ายโอนไม่ใช่ในการรับข้อมูลจากไดรฟ์ หากไม่มี RAM 400G การถ่ายโอนไฟล์ 320G จะใช้เวลานานมาก การใช้โปรโตคอลที่ไม่ได้เข้ารหัสนั้นเป็นตัวเลือก แต่ไม่ว่าคุณจะต้องนั่งรอและรอเป็นเวลาหลายชั่วโมง (ผ่านเครือข่าย)

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

นอกจากนี้หากคุณกำลังจะใช้ไดรฟ์ระดับกลางให้พิจารณาสิ่งนี้: รับไดรฟ์ภายนอก (ไม่ว่าจะเป็นแพคเกจหรือไดรฟ์แยกต่างหากเข้ากับสถานีติดตั้งอุปกรณ์) ซึ่งใช้ eSATA แทน USB จากนั้นในคอมพิวเตอร์แต่ละเครื่องทั้งสองติดตั้งการ์ดด้วยพอร์ต eSATA หรือรับสายเคเบิลอะแดปเตอร์อย่างง่ายซึ่งนำหนึ่งในพอร์ต SATA ภายในไปยังช่องเสียบ eSATA ภายนอก จากนั้นเสียบไดรฟ์เข้ากับคอมพิวเตอร์ต้นทางเปิดไดรฟ์แล้วรอให้เมานต์อัตโนมัติ (คุณสามารถเมาต์ manaully แต่ถ้าคุณทำสิ่งนี้ซ้ำ ๆ คุณอาจใส่เข้าไปในไฟล์ fstab ของคุณ) จากนั้นคัดลอก; คุณจะเขียนด้วยความเร็วเท่ากับไดรฟ์ภายใน จากนั้นยกเลิกการต่อเชื่อมไดรฟ์ปิดเครื่องเชื่อมต่อกับคอมพิวเตอร์เครื่องอื่นเปิดเครื่องรอการเมาท์อัตโนมัติและอ่าน

ฉันจะแนะนำให้คุณดู NIC-teaming สิ่งนี้เกี่ยวข้องกับการใช้การเชื่อมต่อเครือข่ายหลายอย่างที่ทำงานพร้อมกัน สมมติว่าคุณต้องการการถ่ายโอนมากกว่า 1Gb จริง ๆ และ 10Gb นั้นเป็นค่าใช้จ่ายต้องห้าม 2Gbs ที่จัดทำโดย NIC จะเป็นค่าใช้จ่ายเล็กน้อยและคอมพิวเตอร์ของคุณอาจมีพอร์ตเพิ่มเติมอยู่แล้ว

FWIW ฉันใช้สิ่งนี้เสมอ:

tar -cpf - <source path> | ssh user@destserver "cd /; tar xf -"

สิ่งที่เกี่ยวกับวิธีนี้คือมันจะรักษาสิทธิ์ของไฟล์ / โฟลเดอร์ระหว่างเครื่อง (สมมติว่ามีผู้ใช้ / กลุ่มเดียวกันอยู่ทั้งคู่) (ปกติฉันจะทำสิ่งนี้เพื่อคัดลอกอิมเมจดิสก์เสมือนเนื่องจากฉันสามารถใช้พารามิเตอร์ -S เพื่อจัดการไฟล์กระจัดกระจาย )

เพิ่งทดสอบสิ่งนี้ระหว่างเซิร์ฟเวอร์ไม่ว่างสองเครื่องและจัดการ ~ 14GB ใน 216 วินาที (ประมาณ 64MB / s) - อาจจะทำได้ดีกว่าระหว่างเครื่องเฉพาะและ / หรือการบีบอัด ... YMMV

$ date; tar -cpf - Installers | ssh elvis "cd /home/elvis/tst; tar xf -"; date
Wed Sep  9 15:23:37 EDT 2015
Wed Sep  9 15:27:13 EDT 2015

$ du -s Installers
14211072   Installers

ยกเว้นว่าคุณต้องการทำระบบไฟล์นิติวิทยาศาสตร์ให้ใช้โปรแกรมดัมพ์ / กู้คืนสำหรับระบบไฟล์ของคุณเพื่อหลีกเลี่ยงการคัดลอกพื้นที่ว่างที่ FS ไม่ได้ใช้ ทั้งนี้ขึ้นอยู่กับสิ่งที่คุณมีระบบแฟ้มนี้มักจะจะเก็บทุกctimeข้อมูลเมตารวมทั้ง หมายเลขไอโหนดอาจเปลี่ยนแปลงได้อีกครั้งขึ้นอยู่กับระบบไฟล์ (xfs, ext4, ufs ... )

เป้าหมายการเรียกคืนสามารถเป็นไฟล์ในระบบเป้าหมาย

หากคุณต้องการภาพดิสก์เต็มด้วยตารางพาร์ทิชันคุณสามารถdd1M แรกของดิสก์เพื่อรับตารางพาร์ทิชัน / bootloaders / สิ่ง แต่จากนั้นxfsdumpพาร์ทิชัน

ฉันไม่สามารถบอกได้จากข้อมูลการถ่ายโอนข้อมูลของคุณว่าคุณมีระบบไฟล์ประเภทใด หากเป็น BSD เราก็คิดว่ามีโปรแกรม dump / restore ถ้าเป็น ZFS IDK ก็น่าจะมีบางอย่าง

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

คุณสามารถตั้งค่าระบบเพื่อให้มีที่เก็บข้อมูลร่วมกันได้!

ฉันกำลังพิจารณาว่าสิ่งเหล่านี้อยู่ติดกันและคุณมีแนวโน้มที่จะทำเช่นนี้อีกครั้ง & อีกครั้ง ....

สายเคเบิลอีเธอร์เน็ตแบบไขว้เป็นอย่างไร? แทนที่จะพึ่งความเร็วไร้สายคุณจะถูก จำกัด ด้วยความเร็วในการใช้สายของ NIC ของคุณ

นี่เป็นคำถามที่คล้ายกันกับตัวอย่างบางส่วนของการแก้ปัญหาประเภทนั้น

เห็นได้ชัดว่าเพียงแค่สายเคเบิลอีเธอร์เน็ตทั่วไปจะพอเพียงในปัจจุบัน เห็นได้ชัดว่า NIC ของคุณดีกว่าการโอนเร็วขึ้น

เพื่อสรุปหากจำเป็นต้องตั้งค่าเครือข่ายใด ๆ ควร จำกัด เพียงแค่ตั้งค่า IP คงที่สำหรับเซิร์ฟเวอร์ของคุณและคอมพิวเตอร์สำรองด้วย subnet mask 255.255.255.0

โชคดี!

แก้ไข:

@ Khrystoph ได้สัมผัสกับสิ่งนี้ในคำตอบของเขา

หลายคนแนะนำให้คุณข้าม ssh เพราะการเข้ารหัสจะทำให้คุณช้าลง ซีพียูสมัยใหม่อาจเร็วพอที่ 1Gb แต่ OpenSSH มีปัญหากับการติดตั้งภายในหน้าต่างที่ทำให้คุณช้าลงอย่างมาก

หากคุณต้องการที่จะทำเช่นนี้กับ SSH, ดูที่HPN SSH มันแก้ปัญหาหน้าต่างและเพิ่มการเข้ารหัสแบบมัลติเธรด น่าเสียดายที่คุณจะต้องสร้าง ssh ใหม่ทั้งบนไคลเอนต์และเซิร์ฟเวอร์

ตกลงฉันได้พยายามตอบคำถามนี้สำหรับคอมพิวเตอร์สองเครื่องที่มี "ท่อขนาดใหญ่มาก" (10Gbe) ที่ "ปิด" ซึ่งกันและกัน

ปัญหาที่คุณพบที่นี่คือ: การบีบอัดส่วนใหญ่จะเป็นปัญหาคอขวดใน cpu เนื่องจากท่อมีขนาดใหญ่มาก

ประสิทธิภาพในการถ่ายโอนไฟล์ 10GB (การเชื่อมต่อเครือข่าย 6 Gb [linode] ข้อมูลที่ไม่บีบอัด):

$  time bbcp 10G root@$dest_ip:/dev/null
0m16.5s 

iperf:

server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)

netcat (1.187 openbsd):

server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G 
0m13.311s
(58% cpu)

scp:

$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly): 
1m32.707s

socat:

server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s

และสองกล่องใน 10 Gbe, netcat รุ่นเก่ากว่าเล็กน้อย (CentOs 6.7), ไฟล์ 10GB:

nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)

ดังนั้นหนึ่งอินสแตนซ์ netcat ใช้ cpu น้อยลงบน socat อื่นดังนั้น YMMV

ด้วย netcat หากไม่มีตัวเลือก "-N -q 0" จะสามารถถ่ายโอนไฟล์ที่ถูกตัดทอนได้โปรดระวัง ... ตัวเลือกอื่น ๆ เช่น "-w 10" อาจทำให้ไฟล์ถูกตัดทอนได้

สิ่งที่เกิดขึ้นในเกือบทุกกรณีเหล่านี้คือซีพียูถูก maxed out ไม่ใช่เครือข่าย scpสูงสุดประมาณ 230 MB / s, ตรึงหนึ่งคอร์ที่การใช้งาน 100%

Iperf3 โชคไม่ดีที่สร้างไฟล์ที่เสียหาย netcat บางเวอร์ชันดูเหมือนจะไม่ถ่ายโอนไฟล์ทั้งหมดซึ่งแปลกมาก โดยเฉพาะรุ่นเก่าของมัน

คาถาต่างๆของ "gzip เป็นไพพ์ไปยัง netcat" หรือ "mbuffer" ก็ดูเหมือนว่าจะให้ซีพียูสูงสุดด้วย gzip หรือ mbuffer ดังนั้นจึงไม่ส่งผลให้ถ่ายโอนได้เร็วขึ้นด้วยไพพ์ขนาดใหญ่เช่นนี้ lz4 อาจช่วยได้ นอกจากนี้บางส่วนของท่อ gzip ที่ฉันพยายามส่งผลให้เกิดการถ่ายโอนที่เสียหายสำหรับไฟล์ที่มีขนาดใหญ่มาก (> 4 GB) ดังนั้นโปรดระวัง :)

สิ่งที่อาจทำงานได้โดยเฉพาะอย่างยิ่งสำหรับเวลาแฝงที่สูงขึ้น (?) คือการปรับการตั้งค่า tcp นี่คือคำแนะนำที่พูดถึงค่าที่แนะนำ:

http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htmและhttps://fasterdata.es.net/host-tuning/linux/ (จากคำตอบอื่น) อาจเป็นการตั้งค่า IRQ: https://fasterdata.es .net / โฮสต์จูน / 100 กรัมจูน /

คำแนะนำจาก linode ให้เพิ่ม /etc/sysctl.conf:

net.core.rmem_max = 268435456 
net.core.wmem_max = 268435456 
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq 

นอกจากนี้พวกเขาต้องการให้คุณเรียกใช้:

 /sbin/ifconfig eth0 txqueuelen 10000 

ควรตรวจสอบซ้ำอีกครั้งหลังจากปรับแต่งเพื่อให้แน่ใจว่าการเปลี่ยนแปลงจะไม่ก่อให้เกิดอันตรายเช่นกัน

อาจมีค่าปรับขนาดหน้าต่าง: https://iperf.fr/iperf-doc.php#tuningtcp

ด้วยการบีบอัดการเชื่อมต่อที่ช้า (er) สามารถช่วยได้อย่างแน่นอน หากคุณมีท่อขนาดใหญ่การบีบอัดข้อมูลที่รวดเร็วมากอาจช่วยให้สามารถบีบอัดข้อมูลได้อย่างง่ายดาย แต่ก็ไม่ได้ลองเลย

คำตอบมาตรฐานสำหรับ "การซิงค์ฮาร์ดไดรฟ์" คือการซิงค์ไฟล์ซึ่งจะหลีกเลี่ยงการถ่ายโอนหากเป็นไปได้

ตัวเลือกอื่น: ใช้ "scp แบบขนาน" (อย่างใดหรืออย่างอื่น) จากนั้นจะใช้แกนเพิ่มเติม ...