rsync terus memutus sambungan: pipa rusak

Saya menggunakan rsyncuntuk membuat cadangan direktori rumah saya. Ini sudah berfungsi dengan baik sejak lama. Inilah perintah yang saya gunakan:

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

Namun, saya beralih ke server tempat saya membuat cadangan dan sekarang rsyncmulai dan berjalan selama beberapa detik (hingga beberapa menit), tetapi kemudian berhenti dengan pesan kesalahan

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]

Karena ini bekerja pada server lain, saya menduga bahwa masalahnya adalah koneksi atau server itu sendiri. Koneksi tampaknya stabil. Saya terhubung melalui kabel dan saya tidak melihat adanya gangguan. Saya juga mencoba melakukan ping server sambil melakukan backup. Ping memiliki tingkat respons 100% bahkan ketika cadangan putus.

Saya gunakan kerberosuntuk mengautentikasi pada server jarak jauh.

Saya mencoba beberapa kombinasi dengan ServerAliveInterval, ServerAliveCountMaxatau ClientAliveIntervaldalam ~/.ssh/config, tetapi tidak berhasil.

Bisa jadi ada sesuatu yang berjalan di server yang membunuh rsyncperintah untuk beberapa alasan, tapi saya tidak tahu bagaimana cara menyelidikinya. Ada ide?

Masalah Anda mungkin (kurangnya) memori. Kembali ketika 1GB besar untuk server, rsync akan gagal pada saya untuk dataset besar. Mungkin algoritme telah meningkat dari kapasitas memori telah meningkat, tetapi saya belum melihat masalah itu dalam 8 tahun atau lebih. Jadi sungguh, ini adalah bidikan luar, tapi layak untuk dijelajahi. Coba dataset yang lebih kecil terlebih dahulu. Anda juga dapat mencoba - sebagai formulir pada pemeriksaan kewarasan - melakukan tar-tar:

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

Jika itu juga gagal setelah beberapa menit, itu bukan memori.

Saya pernah mengalami hal ini rsyncdi masa lalu. Solusi yang memperbaikinya bagi saya adalah menjalankannya dari dalam screensesi, yang dapat membantu menjaga koneksi ke server jarak jauh.

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

Anda dapat memeriksa status dengan menjalankan screen -x rsync(atau apa pun yang Anda memutuskan untuk memberi nama sesi jika Anda memberinya nama, yang tidak diperlukan). Ini akan melampirkan kembali shell Anda saat ini untuk sesi itu. Ingatlah untuk melepaskannya lagi setelah Anda memeriksa statusnya agar tetap berjalan di latar belakang.

Anda juga dapat menjalankan perintah untuk dijalankan melalui screendi latar belakang dalam satu kali gagal dengan melakukan [seseorang tolong perbaiki saya jika saya salah] screen -dm 'command'. Anda mungkin ingin man screensebelum mencoba yang terakhir.

EDIT:

Saya mengedit jawaban saya karena Anda telah mengkonfirmasi bahwa screentidak memberikan bantuan dalam skenario ini, tetapi Anda menjawab komentar saya menyarankan untuk mencoba scpdan melihat hasil seperti apa yang Anda dapatkan, yang Anda jawab dengan aneh, itu bekerja dengan baik.

Jadi jawaban baru saya adalah ini: gunakan scp- atau ssh(dengan tar) - bukanrsync

Memang, scptidak mendukung sejumlah besar fitur seperti rsync, tetapi Anda akan benar-benar terkejut untuk menemukan betapa banyak fitur yang tidak support yang hampir identik dengan yang rsync.

Skenario dunia nyata untuk scpdan alternatif lain untuk rsync:

Beberapa waktu yang lalu, saya ditugaskan untuk membuat skrip shell yang akan menarik log dari server produksi kami dan menyimpannya secara lokal di server web sehingga pengembang dapat mengaksesnya untuk tujuan pemecahan masalah. Setelah gagal mencoba membuat tim Unix menginstal rsyncdi server kami, saya menemukan solusi scpyang bekerja dengan baik.

Yang sedang berkata, saya baru-baru ini memodifikasi skrip sehingga semua yang digunakan adalah sshdan tar- GNU tar/ gtar, tepatnya. GNU tarmendukung banyak opsi yang benar-benar akan Anda temukan rsync, seperti --include,, --excludepelestarian izin / atribut, kompresi, dll.

Cara saya sekarang menyelesaikan ini adalah dengan ssh-ing ke server jauh (melalui pubkey auth) dan menggunakan gtar -czf - [other options such as --include='*.log' and --exclude='*core*', etc.]- ini menulis semua info stdout, yang kemudian disalurkan [secara lokal] ke tar -xzfsehingga tidak ada perubahan yang dibuat pada server produksi jarak jauh , dan semua file ditarik apa adanya ke server lokal. Ini merupakan alternatif yang bagus untuk rsynckasus ini. Satu-satunya hal penting yang tidak didukung tarmaupun tidak scpadalah cadangan inkremental dan tingkat kesalahan blok-tingkat memeriksa rsyncfitur itu.

Perintah lengkap yang saya maksudkan ketika menggunakan sshdan tarakan menjadi seperti ini (remote adalah Solaris 10; lokal adalah Debian, untuk apa nilainya):

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

Dalam skenario Anda, itu akan menjadi sebaliknya - tar -cf -secara lokal, dan pipa ke server jauh melalui ssh user@remotehost "tar -xf -"- ada jawaban lain yang merujuk jenis perilaku ini tetapi tidak masuk ke detail sebanyak mungkin.

Ada beberapa opsi lain yang telah saya sertakan untuk mempercepat. Saya mengatur waktu semuanya tanpa henti untuk mendapatkan waktu eksekusi serendah mungkin. Anda akan berpikir bahwa menggunakan kompresi dengan tartidak ada gunanya, tetapi sebenarnya mempercepat segalanya, seperti halnya menggunakan -Cflag dengan sshuntuk mengaktifkan sshkompresi juga. Saya dapat memperbarui posting ini di kemudian hari untuk memasukkan perintah persis yang saya gunakan (yang sangat mirip dengan apa yang saya posting), tetapi saya tidak merasa ingin mendapatkan VPN saat ini karena saya sedang berlibur minggu ini.

Pada Solaris 10, saya juga menggunakan -c blowfish, karena ini adalah cipher tercepat untuk mengotentikasi dan juga membantu mempercepat, tetapi Solaris 11 kami tidak mendukungnya atau menonaktifkan cipher suite ini.

Selain itu, jika Anda memilih untuk menggunakan opsi ssh/ tar, sebenarnya akan menjadi ide yang baik untuk mengimplementasikan solusi asli saya menggunakan screenjika Anda melakukan pencadangan yang akan memakan waktu. Jika tidak, pastikan pengaturan keepalive / timeout Anda di ssh_config-tweak tepat, atau metode ini juga akan sangat mungkin menyebabkan pipa rusak.

Bahkan jika Anda ikut scp, saya selalu menganggapnya sebagai praktik terbaik untuk digunakan screenatau tmuxketika melakukan operasi semacam ini, untuk berjaga-jaga . Sering kali saya tidak mengikuti saran saya sendiri dan gagal melakukan ini, tetapi memang merupakan praktik yang baik untuk menggunakan salah satu alat ini untuk memastikan bahwa pekerjaan jarak jauh tidak kacau karena sesi shell aktif Anda terputus entah bagaimana.

Saya tahu Anda ingin mengetahui akar penyebab rsyncmasalah Anda . Namun, jika ini benar-benar penting, ini adalah dua solusi hebat yang dapat Anda coba untuk sementara waktu.

Saya mengalami masalah yang sama pada OSX El Capitan dan memperbaikinya dengan memutakhirkan ke rsync v3.11. Masalah ini terjadi pada saya di v2.6.9.

Kerberos hanya untuk otentikasi, yang seharusnya tidak menyebabkan masalah setelah Anda berhasil membuat koneksi.

Sudahkah Anda mencoba menggunakan daemon rsync juga?

Apakah server Anda berada di jaringan yang sama atau apakah Anda memiliki firewall / router?

Anda dapat mencoba mengatur sesi netcat antara server, itu adalah cara sederhana untuk mencoba jika Anda memiliki masalah koneksi antara server Anda.

Di server pertama:

nc -lk <port-number>

Dan pada klien

nc <server> <port-number>

Anda bisa membiarkan koneksi tetap terbuka, dan melihat apakah koneksi tetap ada, atau jika Anda kehilangan koneksi. Anda juga dapat mencoba menulis sesuatu di klien, melihat bahwa itu berakhir di sisi lain.

Anda memiliki sesuatu di server jauh yang menulis ke stdout . Ini mungkin ada di Anda .profileatau .bash_profile. Bisa jadi sesuatu yang kurang jelas seperti sttyatau mesg. Jika ragu, salin transkrip ke pertanyaan Anda tentang Anda masuk ke server (kurangi nama host dengan segala cara).

satu-satunya saat saya mengalami masalah seperti ini dengan rsync, saya melacaknya ke port ethernet cadangan di komputer lain yang memiliki alamat IP yang sama dengan server target saya. Jika rsync terkelupas, itu hampir pasti merupakan keandalan jaringan atau (dalam kasus saya) masalah konfigurasi.

Saya mengalami masalah yang sama ketika menjalankan rsyncatau secara manual (baik dengan cp, scpatau di Gnome Nautilus) menyalin file besar dari desktop Linux ke Linux NAS berbasis ARM berdaya rendah melalui jaringan kabel gigabit (tidak ada kerberosdalam pengaturan saya). Drive NAS dibagikan menggunakan samba, dan dipasang pada klien menggunakan cifs. Solusi bagi saya adalah me-mount sistem file NAS dari klien tanpa caching (lihat juga mount.cifs man pages):

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

Atau, saat memasang drive NAS pada klien yang menggunakan gvfsdalam nautilusmasalah ini tidak akan bertahan saat menyalin file besar (tetapi meskipun tidak bekerja dalam kombinasi dengan rsync).

Buat Linux menulis ke sistem file jaringan bersamaan dengan disk lokal membaca menjelaskan lebih lanjut tentang mengapa masalah ini mungkin terjadi.

Cukup tingkatkan versi rsync Anda untuk memastikan keduanya persis sama pada PC pengirim dan penerima. Lihat jawaban saya di sini: /server/883487/unable-to-rsync-due-to-broken-pipe/988794#988794 .