web-dev-qa-db-ja.com

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コマンドを強制終了する何かがサーバーで実行されている可能性がありますが、その調査方法がわかりません。何か案は？

sshnetworkingrsyncbackup
14
pfnuesel

問題はメモリの不足です。サーバーにとって1GBが大きかったとき、rsyncは大きなデータセットに対して失敗しました。アルゴリズムによってメモリ容量が改善されたのかもしれませんが、8年ほどはその問題は見られませんでした。本当に、これは外見ですが、探索する価値があります。最初に小さいデータセットを試してください。健全性チェックのフォームとして、tar-tarを実行することもできます。

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

alsoが数分後に失敗した場合、それはメモリではありません。

6
Otheus

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

3
Bruno

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

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

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

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

最初のサーバーで：

nc -lk <port-number>

そしてクライアント上で

nc <server> <port-number>

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

2
toed

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

1
Nathan Siemers

rsyncを実行するとき、または手動で（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

または、gvfsでnautilusを使用してクライアントにNASドライブをマウントする場合、大きなファイルをコピーするとこの問題は解決しません（ただし、rsyncと組み合わせて使用​​すると機能しません）。

Linuxがローカルディスクの読み取りと同時にネットワークファイルシステムに書き込むようにする この問題が発生している理由について詳しく説明します。

1
davidovitch

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

1
roaima

Rsyncのバージョンをアップグレードして、送信側と受信側の両方のPCでが完全に同じであることを確認してください。ここで私の答えを参照してください： https://serverfault.com/questions/883487/unable-to-rsync-due-to-broken-pipe/988794#988794 。

0
Gabriel Staples