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（或者，如果确实给会话命名，则可以选择命名会话，这不是必需的）。这会将您当前的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/ 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;地方是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 -"-还有另一个答案引用了这种类型的行为，但没有涉及太多细节。

我还包括其他一些选项来加快处理速度。我无情地安排了所有时间，以尽可能缩短执行时间。您可能认为使用with压缩tar是没有意义的，但是实际上与使用-C标志with ssh启用ssh压缩一样，它可以使速度加快一点。我可能会在以后的某个日期更新此帖子，以包含我使用的确切命令（这与我发布的命令非常相似），但是由于我本周正在休假，所以我暂时不希望使用VPN。

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

此外，如果您选择使用ssh/ tar选项，那么screen如果要进行一段时间的备份，那么实施我最初使用的解决方案实际上是一个好主意。如果没有，请确保ssh_config正确调整了其中的keepalive / timeout设置，否则此方法也很可能导致管道损坏。

即使您一起使用scp，我也总是发现使用它screen或tmux进行这种操作是一种最佳做法，以防万一。很多时候，我没有遵循自己的建议，但没有做到这一点，但是，使用这些工具之一来确保远程活动不会因您的活动Shell会话断开连接而搞砸了，这的确是一个好习惯。

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

我在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地址与目标服务器的IP地址相同。如果rsync不稳定，则几乎肯定是网络可靠性或（在我的情况下）配置问题。

在运行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

另外，安装时使用的客户端上的NAS驱动器gvfs在nautilus这个问题拷贝大文件时就不会坚持（但不工作结合rsync虽然）。

让Linux与本地磁盘读取同时写入网络文件系统进一步说明了为什么可能会出现此问题。

只需升级您的rsync版本，以确保它们在发送和接收PC上完全相同。在这里查看我的答案：https : //serverfault.com/questions/883487/unable-to-rsync-due-to-broken-pipe/988794#988794。