rsync ยังคงตัดการเชื่อมต่อ: ท่อแตก

ฉันใช้rsyncเพื่อสำรองข้อมูลไดเรกทอรีบ้านของฉัน นี่ใช้งานได้ดีมานานแล้ว นี่คือคำสั่งที่ฉันใช้:

rsync \
    -pavz \
    --delete \
    --exclude 'mnt/' \
    --exclude '.cache/' \
    --exclude 'Videos/' \
    --exclude 'Music/' \
    --exclude 'Documents/virtualbox' \
    /home/"${USER}" "${server}":"${dir}" 2>> "${errorFile}"

อย่างไรก็ตามฉันเปลี่ยนเซิร์ฟเวอร์ที่ฉันสำรองข้อมูลและตอนนี้rsyncเริ่มและทำงานเป็นเวลาสองสามวินาที (ไม่กี่นาที) แต่ก็หยุดด้วยข้อความแสดงข้อผิดพลาด

packet_write_wait: Connection to x.x.x.x: Broken pipe
rsync: [sender] write error: Broken pipe (32)
rsync error: unexplained error (code 255) at io.c(820) [sender=3.1.1]

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

ฉันใช้kerberosเพื่อตรวจสอบสิทธิ์บนเซิร์ฟเวอร์ระยะไกล

ฉันพยายามหลายชุดด้วยServerAliveInterval, ServerAliveCountMaxหรือClientAliveIntervalในของฉัน~/.ssh/configแต่จะไม่มีประโยชน์

อาจเป็นไปได้ว่ามีบางสิ่งที่ทำงานบนเซิร์ฟเวอร์ที่ฆ่าrsyncคำสั่งด้วยเหตุผลบางอย่าง แต่ฉันไม่รู้วิธีตรวจสอบในเรื่องนั้น ความคิดใด ๆ

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

tar cf - $HOME | ssh ${server} tar xf -

หากยังล้มเหลวหลังจากไม่กี่นาทีก็ไม่ได้เป็นหน่วยความจำ

ฉันได้พบสิ่งนี้กับrsyncในอดีตเช่นกัน โซลูชันที่แก้ไขสำหรับฉันคือการเรียกใช้จากภายในscreenเซสชันซึ่งสามารถช่วยรักษาการเชื่อมต่อกับเซิร์ฟเวอร์ระยะไกลได้

screen -LS rsync
[execute your rsync command]
Ctrl-A+D to detach from the session

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

นอกจากนี้คุณยังสามารถดำเนินการคำสั่งในการทำงานผ่านทางscreenในพื้นหลังในหนึ่งล้มเหลวถลาลงด้วยการทำ screen -dm 'command'[คนโปรดฉันที่ถูกต้องหากฉันผิด] คุณอาจต้องการman screenก่อนลองอันสุดท้าย

แก้ไข:

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

ดังนั้นคำตอบใหม่ของฉันคือ: ใช้scp- หรือssh(พร้อมtar) - แทนrsync

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

สถานการณ์โลกแห่งความเป็นจริงสำหรับscpและทางเลือกอื่น ๆ ไปที่rsync:

ก่อนหน้านี้ฉันได้รับมอบหมายให้สร้างเชลล์สคริปต์ที่จะดึงบันทึกจากเซิร์ฟเวอร์การผลิตของเราและเก็บไว้ในเว็บเซิร์ฟเวอร์เพื่อให้นักพัฒนาสามารถเข้าถึงพวกเขาเพื่อการแก้ไขปัญหา หลังจากพยายามไม่ประสบความสำเร็จในการทำให้ทีม Unix ติดตั้งrsyncบนเซิร์ฟเวอร์ของเราฉันก็พบกับวิธีการแก้ปัญหาโดยใช้วิธีนี้scpได้ผลเช่นกัน

ที่ถูกกล่าวว่าฉันเพิ่งแก้ไขสคริปต์เพื่อให้มันใช้ทั้งหมดsshและtar- GNU tar/ gtarเป็นที่แน่นอน GNU tarสนับสนุนหลายตัวเลือกจริงที่คุณจะพบได้ในrsyncเช่น--include, --excludeได้รับอนุญาต / การเก็บรักษาแอตทริบิวต์การบีบอัดและอื่น ๆ

วิธีที่ฉันประสบความสำเร็จในตอนนี้คือการsshไปที่เซิร์ฟเวอร์ระยะไกล (ผ่าน pubkey auth) และการใช้gtar -czf - [other options such as --include='*.log' and --exclude='*core*', etc.]- นี่เป็นการเขียนข้อมูลทั้งหมดไปยังstdoutซึ่งจะถูกไพพ์[ภายใน] tar -xzfเพื่อไม่ให้มีการเปลี่ยนแปลงบนเซิร์ฟเวอร์ที่ใช้งานระยะไกล และไฟล์ทั้งหมดที่ถูกดึงไปยังเซิร์ฟเวอร์ท้องถิ่น มันเป็นทางเลือกที่ยอดเยี่ยมrsyncในกรณีนี้ สิ่งเดียวที่สำคัญไม่สนับสนุนtarหรือscpสำรองข้อมูลที่เพิ่มขึ้นและระดับของการตรวจสอบข้อผิดพลาดระดับบล็อกที่rsyncคุณสมบัติ

คำสั่งเต็มรูปแบบที่ฉันอ้างถึงเมื่อใช้sshและtarจะเป็นเช่นนี้ (ระยะไกลคือ Solaris 10; local เป็น Debian สำหรับสิ่งที่คุ้มค่า):

cd /var/www/remotelogs
ssh -C user@remotehost "cd /path/to/remote/app.directories; gtar -czf - --include='*.log' --exclude='*.pid' --exlude='*core*' *" | tar -xz

ในสถานการณ์ของคุณมันจะตรงกันข้าม - tar -cf -ในเครื่องและไปป์ที่เซิร์ฟเวอร์ระยะไกลผ่านssh user@remotehost "tar -xf -"- มีคำตอบอื่นที่อ้างอิงลักษณะการทำงานประเภทนี้ แต่ไม่ได้ลงรายละเอียดมากนัก

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

ใน Solaris 10 ฉันยังใช้-c blowfishเพราะมันเป็นรหัสที่เร็วที่สุดในการตรวจสอบความถูกต้องด้วยและยังช่วยเร่งความเร็วให้เร็วขึ้นอีกด้วย แต่ Solaris 11 ของเราไม่รองรับหรือปิดการใช้งานชุดรหัสนี้

นอกจากนี้หากคุณเลือกที่จะใช้ตัวเลือกssh/ tarมันเป็นความคิดที่ดีที่จะใช้โซลูชันดั้งเดิมของฉันในการใช้screenหากคุณทำการสำรองข้อมูลซึ่งจะใช้เวลาสักครู่ หากไม่ตรวจสอบให้แน่ใจว่าการตั้งค่า keepalive / timeout ในตัวคุณssh_configถูกปรับแต่งแล้วไม่อย่างนั้นมิฉะนั้นวิธีนี้จะทำให้ท่อแตกได้

แม้ว่าคุณจะไปกับscpฉันมักจะพบว่ามันจะเป็นวิธีที่ดีที่สุดที่จะใช้screenหรือtmuxเมื่อทำการดำเนินงานของการจัดเรียงนี้เป็นเพียงในกรณีที่ หลายครั้งที่ฉันไม่ปฏิบัติตามคำแนะนำของตัวเองและไม่สามารถทำสิ่งนี้ได้ แต่เป็นวิธีที่ดีที่จะใช้เครื่องมือเหล่านี้เพื่อให้แน่ใจว่างานระยะไกลจะไม่พลาดเนื่องจากการใช้งานเซสชั่นเชลล์ของคุณ

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

ฉันมีปัญหาเดียวกันกับ OSX El Capitan และแก้ไขปัญหานี้โดยอัปเกรดเป็น rsync v3.11 ปัญหาเกิดขึ้นสำหรับฉันใน v2.6.9

Kerberos ใช้สำหรับการรับรองความถูกต้องเท่านั้นซึ่งไม่ควรทำให้เกิดปัญหาใด ๆ หลังจากที่คุณสร้างการเชื่อมต่อที่สำเร็จ

คุณลองใช้ rsync daemon ด้วยหรือไม่

เซิร์ฟเวอร์ของคุณอยู่ในเครือข่ายเดียวกันหรือคุณมีไฟร์วอลล์ / เราเตอร์อยู่หรือไม่

คุณสามารถลองตั้งค่าเซสชัน netcat ระหว่างเซิร์ฟเวอร์ซึ่งเป็นวิธีง่ายๆในการลองหากคุณมีปัญหาการเชื่อมต่อระหว่างเซิร์ฟเวอร์ของคุณ

บนเซิร์ฟเวอร์แรก:

nc -lk <port-number>

และเมื่อลูกค้า

nc <server> <port-number>

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

คุณมีบางสิ่งบางอย่างบนเซิร์ฟเวอร์ระยะไกลที่เขียนไปstdout นี้อาจจะอยู่ในของคุณหรือ.profile .bash_profileมันอาจจะเป็นสิ่งที่น้อยที่เห็นได้ชัดเช่นหรือstty mesgหากมีข้อสงสัยให้คัดลอกคำบรรยายลงในคำถามที่คุณล็อกอินไปยังเซิร์ฟเวอร์ (ทำซ้ำชื่อโฮสต์โดยใช้วิธีการทั้งหมด)

ครั้งเดียวที่ฉันมีปัญหาเช่นนี้กับ rsync ฉันติดตามมันไปยังพอร์ตอีเธอร์เน็ตสำรองในเครื่องอื่นที่มีที่อยู่ IP เดียวกับเซิร์ฟเวอร์เป้าหมายของฉัน หาก rsync ไม่สม่ำเสมอก็เป็นความน่าเชื่อถือของเครือข่ายหรือปัญหาการกำหนดค่า (ในกรณีของฉัน)

ผมพบปัญหาที่คล้ายกันเมื่อทำงานrsyncหรือด้วยตนเอง (ทั้งที่มีcp, scpหรือใน Gnome Nautilus) การคัดลอกไฟล์ขนาดใหญ่จากเดสก์ทอปลินุกซ์กับ ARM ขับเคลื่อนต่ำตามลินุกซ์ NAS ผ่านเครือข่ายกิกะบิต cabled (ไม่มีการkerberosในการตั้งค่าของฉัน) ไดรฟ์ NAS ที่ใช้ร่วมกันใช้และมีการติดตั้งที่ลูกค้าใช้samba cifsทางออกสำหรับฉันคือการเมานต์ระบบไฟล์ NAS จากลูกค้าโดยไม่ต้องแคชใด ๆ (ดูหน้าคนmount.cifs ):

sudo mount -t cifs //server.lan/somedir /mnt/somedir/ -o cache=none

อีกทางหนึ่งเมื่อทำการติดตั้งไดรฟ์ NAS บนไคลเอนต์ที่ใช้gvfsในnautilusปัญหานี้จะไม่คงอยู่เมื่อคัดลอกไฟล์ขนาดใหญ่ (แต่ไม่สามารถใช้งานร่วมกับrsync)

ทำให้ Linux เขียนไปยังระบบไฟล์เครือข่ายพร้อมกันกับการอ่านโลคอลดิสก์ซึ่งจะอธิบายเพิ่มเติมว่าทำไมปัญหานี้จึงเกิดขึ้น

เพียงอัปเกรดเวอร์ชัน rsync ของคุณเพื่อให้แน่ใจว่าเหมือนกันทั้งบนพีซีที่ส่งและรับ ดูคำตอบของฉันที่นี่: /server/883487/unable-to-rsync-due-to-broken-pipe/988794#988794