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を実行してみました。バックアップが壊れている場合でも、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[誰かが私が間違っている場合は修正してください]を実行することにより、1回の失敗でバックグラウンドで実行するコマンドを実行することもできscreen -dm 'command'ます。man screenその最後のものを試す前に、あなたがしたいかもしれません。

編集：

あなたがscreenこのシナリオで何の支援も提供していないことを確認したので、私の回答を編集していますが、あなたは私のコメントに返信して、scpどのような結果が得られるかを試してみるように提案しました。

私の新しい答えはこれですので： 使用scp-またはssh（でtar） -の代わりに、rsync

確かに、scpなどの機能の膨大な数をサポートしていませんrsyncが、あなたが実際にそれがいることを、どれだけ多くの機能を発見するために驚かれると思いますし、ほとんどされているサポート、同一のものとしますrsync。

の実際のシナリオscpと他の代替案rsync：

しばらく前から、運用サーバーからログをプルしてWebサーバーにローカルに保存し、開発者がトラブルシューティングの目的でログにアクセスできるようにするシェルスクリプトを作成する必要がありました。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：;（ローカルは、Debianで、何が価値があるため、リモートのSolaris 10である）このようなものになるだろう

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することを選択した場合、時間がかかるバックアップを実行している場合は、実際に使用する私のオリジナルのソリューションを実装することをお勧めします。そうでない場合は、キープアライブ/タイムアウトの設定がssh_config適切に調整されていることを確認してください。そうしないと、この方法でもパイプが破損する可能性が高くなります。

あなたが一緒に行く場合でもscp、私はいつも使用することをお勧めであることがわかりscreenまたはtmuxこの種の操作を行う際に、念のため。多くの場合、私は自分のアドバイスに従わないでこれを実行できませんが、実際にこれらのツールのいずれかを使用して、アクティブなシェルセッションが何らかの理由で切断されたためにリモートジョブが失敗しないようにすることをお勧めします。

rsync問題の根本的な原因を解明したいと思っています。ただし、これが本当に重要な場合は、当面の実験が可能な2つの優れた回避策です。

OSX El Capitanでも同じ問題が発生し、rsync v3.11にアップグレードすることでこれを修正しました。この問題はv2.6.9で発生していました。

Kerberosは認証専用であり、接続が正常に作成された後は問題は発生しません。

rsyncデーモンも使用してみましたか？

サーバーは同じネットワーク上にありますか、またはファイアウォール/ルーターが間にありますか？

サーバー間のnetcatセッションのセットアップを試すことができます。これは、サーバー間の接続に問題がある場合に試す簡単な方法です。

最初のサーバーで：

nc -lk <port-number>

そしてクライアント上で

nc <server> <port-number>

接続を開いたままにして、接続が維持するかどうか、または接続を失うかどうかを確認できます。また、クライアントで何かを書いてみることができます。それが反対側になることを確認してください。

リモートサーバー上にstdoutに書き込むものがあります。これは.profileまたはにある可能性があります.bash_profile。sttyまたはのように、それほど明白ではないものになる可能性がありますmesg。疑わしい場合は、サーバーにログインする質問に筆記録をコピーします（必ずホスト名を編集してください）。

rsyncでこのような問題が発生したのはこのときだけで、ターゲットサーバーと同じIPアドレスを持つ別のマシンの予備のイーサネットポートまで追跡しました。rsyncが不安定な場合、ほぼ確実にネットワークの信頼性または（私の場合）構成の問題です。

実行中rsyncまたは手動で（Gnome Nautilus でcp、scpまたはGnome Nautilusで）大きなファイルをLinuxデスクトップからギガビットケーブルネットワーク経由で低電力のARMベースのLinux NASにコピーしているときにも同様の問題が発生しました（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のバージョンをアップグレードして、送信側と受信側のPCでまったく同じになるようにします。ここで私の答えを参照してください：https : //serverfault.com/questions/883487/unable-to-rsync-due-to-broken-pipe/988794#988794。