☰

rsync 不断断开连接：管道损坏

tag-icon • tag-icon ssh networking rsync backup
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由于某种原因终止了该命令，但我不知道如何对此进行调查。有任何想法吗？

答案1

您的问题可能是（缺乏）内存。当 1GB 对于服务器来说已经很大时，对于大型数据集，rsync 会失败。也许是算法改进了，内存容量增加了，但我已经八年左右没有看到这个问题了。确实，这是一个外景镜头，但值得探索。首先尝试较小的数据集。您也可以尝试 - 作为健全性检查的一种形式 - 执行 tar-tar：

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

如果说还几分钟后就失败了，这不是内存。

答案2

rsync我过去也遇到过这种情况。为我解决这个问题的解决方案是从screen会话中运行它，这能够帮助维持与远程服务器的连接。

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

screen -x rsync您可以通过运行（或者您决定为会话命名的任何内容，如果您给了它一个名称，这不是必需的）来检查状态。这会将您当前的 shell 重新附加到该会话。请记住在检查状态后再次分离它，以便它继续在后台运行。

screen您还可以通过执行 [如果我错了，请纠正我] 来一次失败地执行在后台运行的命令screen -dm 'command'。man screen在尝试最后一个之前，您可能需要这样做。

编辑：

我正在编辑我的答案，因为您已经确认screen在这种情况下没有提供任何帮助，但您回复了我的评论，建议尝试scp看看您会得到什么样的结果，您的回答很奇怪，它工作得很好。

所以我的新答案是这样的： 使用scp-- 或ssh(with tar) -- 代替rsync

当然，scp不支持 的大量功能rsync，但您实际上会惊讶地发现它支持多少功能做支持几乎完全相同的到 的rsync.

现实世界的场景scp和其他替代方案rsync：

不久前，我的任务是创建一个 shell 脚本，该脚本将从我们的生产服务器中提取日志并将其存储在本地 Web 服务器上，以便开发人员可以访问它们以进行故障排除。在尝试让 Unix 团队在我们的服务器上安装失败后rsync，我想出了一个scp同样有效的解决方法。

话虽这么说，我最近修改了脚本，准确地说，它使用的只是ssh和tar-- GNU tar/ 。 gtarGNUtar支持您实际上可以在 中找到的许多选项rsync，例如--include，--exclude权限/属性保存、压缩等。

我现在实现此目的的方法是通过ssh-ing 到远程服务器（通过 pubkey auth）并使用gtar -czf - [other options such as --include='*.log' and --exclude='*core*', etc.]-- 这会将所有信息写入stdout，然后通过管道[本地]传输到，以便tar -xzf在远程生产服务器上不进行任何更改，并将所有文件按原样拉到本地服务器。在这种情况下，这是一个很好的替代方案rsync。唯一既不重要tar也不支持的事情scp是增量备份以及该功能的块级错误检查级别rsync。

ssh我在使用and时提到的完整命令tar是这样的（远程是 Solaris 10；本地是 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 -"——还有另一个答案引用了这种类型的行为，但没有详细介绍。

我还提供了一些其他选项来加快速度。我坚持不懈地对一切进行计时，以尽可能缩短执行时间。您可能会认为使用压缩 withtar是毫无意义的，但它实际上会加快速度，就像使用标志-Cwithssh来启用ssh压缩一样。我可能会在稍后更新这篇文章，以包含我使用的确切命令（这与我发布的命令非常相似），但我目前不想使用 VPN，因为我本周正在度假。

在 Solaris 10 上，我也使用-c blowfish，因为它是进行身份验证最快的密码，并且还有助于加快速度，但我们的 Solaris 11 要么不支持它，要么禁用了此密码套件。

此外，如果您选择使用ssh/选项，如果您正在进行需要一段时间的备份，tar那么实施我的原始解决方案实际上是一个好主意。screen如果没有，请确保你的 keepalive/timeout 设置ssh_config调整得恰到好处，否则这种方法也很可能会导致管道破裂。

即使你选择使用scp，我总是发现它是使用screen或的最佳实践tmux进行此类操作时的最佳实践，万一。很多时候，我没有遵循自己的建议，也没有做到这一点，但使用这些工具之一确实是一个很好的做法，可以确保远程作业不会因为活动 shell 会话以某种方式断开连接而出现问题。

我知道您想找rsync出问题的根本原因。但是，如果这确实很重要，那么您可以同时尝试这两个很好的解决方法。

答案3

我在 OSX El Capitan 上遇到了同样的问题，并通过升级到 rsync v3.11 解决了这个问题。我在 v2.6.9 上发生了这个问题。

答案4

您在远程服务器上有一些东西可以写入标准输出。这可能在您的.profile或.bash_profile.它可能是不太明显的东西，例如stty或mesg。如果有疑问，请将记录复制到您登录服务器的问题中（务必编辑主机名）。

相关内容