☰

通过 SSH 备份时，Rsync 进程突然终止

tag-icon • tag-icon ubuntu ssh rsync
通过 SSH 备份时，Rsync 进程突然终止

我有一个 rsync 备份脚本，用于在两个 Ubuntu 服务器（位于不同国家/地区）之间传输数据。备份的数据在文件数量方面相当大。总共大约 17GB。该脚本在接收者服务器。所以它基本上是一个拉. 用于登录的公私钥验证。

脚本运行良好；备份已成功进行好几个月了。

最近，大约 6 天以来，备份一直未完成。rsync 进程运行了大约 45 分钟左右。然后就结束了。我不知道它为什么会停止。据我所知，它甚至没有完成文件列表的构建和扫描。我将 cron 输出定向到日志文件。在日志中，我看到的只有：。但我receiving file list ... done可以看到没有任何东西被传输到备份目标。

如果我手动运行脚本，大约 45 分钟后，我只会看到以下内容：./sync.sh: line 51: 9078 Killed $RSYNC $OPTIONS $SOURCE $DESTINATION

我如何以及在哪里可以查看失败的原因？我如何知道哪个服务器实际上终止了进程，发送方还是接收方？

这拉机器（脚本运行的地方）是低端机箱。这是一个具有 256MB RAM 的 KVM VM。因此，我想知道文件结构的构建是否占用了太多 RAM，从而导致 OOM 错误。但我如何检查是否是这种情况？此外，文件数量没有显着增加，导致突然失败。

任何建议都将不胜感激。

谢谢。

更新 1

根据 @APZ 的建议，我添加了几个详细标志（总共 3 个），并手动运行脚本，将输出重定向到文件。最后输出如下：

(.... lots of file names....)
received 5795917 names
done
recv_file_list done
get_local_name count=5795917 /storage/  <======== Reached here after about 40 minutes. Was stuck here for about 10 minutes or so.
[Receiver] _exit_cleanup(code=14, file=main.c, line=788): about to call exit(14)

rsync: fork failed in do_recv: Cannot allocate memory (12)
rsync error: error in IPC code (code 14) at main.c(788) [Receiver=3.0.9]

回答@TimHaegele，据我所知，VM 主机 (Prometeus / IperWeb) 不会对 CPU、IO 或任何东西进行任何限制。不过我可以问他们。他们的评价非常高。

我在虚拟机上安装的 Ubuntu 已配置 512 MB 交换空间。也许我可以将其增加到 2 GB 左右？磁盘空间不是问题。

当 rsync 运行时，这是输出free -m：

             total       used       free     shared    buffers     cached
Mem:           239        236          2          0          0          3
-/+ buffers/cache:        232          7
Swap:          511        510          1

根据这个证据，按照建议更改 SSH 守护进程设置是否仍然有区别？

更新 2

大家一致认为问题出在内存不足上。因此，我添加了一个 2GB 的新交换文件并激活了它。因此，现在我总共有 2.5 GB 的交换空间。

然后，我再次（手动）运行了该脚本。这一次，它运行了 90 多分钟。此时它正在传输文件。但突然间，该进程退出了。在日志中，我看到它以以下错误终止：

Invalid packet at end of run (4330026) [sender]
[generator] _exit_cleanup(code=12, file=io.c, line=1532): about to call exit(12)
rsync error: protocol incompatibility (code 2) at main.c(695) [sender=3.0.7]
rsync: writefd_unbuffered failed to write 23 bytes to socket [generator]: Broken pipe (32)
rsync error: error in rsync protocol data stream (code 12) at io.c(1532) [generator=3.0.9]
[receiver] _exit_cleanup(code=19, file=main.c, line=1316): about to call exit(19)
rsync error: received SIGUSR1 (code 19) at main.c(1316) [receiver=3.0.9]

如您所见，发送方机器的版本为 3.0.7，而接收方（拉取器）的版本为 3.0.9。我不太明白错误是什么。

同时，我看到了@APZ 的评论，并修改了我的脚本以替换--delete-after。--delete-delay我现在正在再次运行它。将回来更新。

更新 3

添加更多交换并使用--delete-delay似乎--delete-after已成功。常规 cron 作业似乎也运行正常。

此外，我还关注本文在发送机器上使用 sudo 运行 rsync。这也消除了Permission denied (13)传输过程中的警告。

谢谢大家的帮助。

PS：参与本次问答的每个人都给出了有益的建议。遗憾的是，我只能标记一个正确答案。

答案1

作为指示，我建议查看服务器端的 rsync 日志。此外，尝试 rysnc 的详细模式：

-v, --verbose 此选项会增加传输过程中提供的信息量。默认情况下，rsync 会默默工作。单个 -v 将为您提供有关正在传输的文件的信息，并在最后提供简短摘要。两个 -v 选项将为您提供有关跳过的文件的信息，并在最后提供稍多的信息。只有在调试 rsync 时才应使用两个以上的 -v 选项。

答案2

运行 rsync 脚本的 KVM VM 是否由限制 IO、CPU 时间等资源的 Hoster 控制？

尝试回答您的问题我建议：

在一台资源超过 256MB 且由您自己控制的主机上运行 sync.sh，看看它是否运行成功。如果是，则问题的根源在于客户端。

其次，有点晦涩，但值得在不同时间试运行一下。

此外缩短超时时间：

使用更积极的断开连接设置在服务器上的 /etc/ssh/sshd_config 中类似：

ClientAliveInterval 5
ClientAliveCountMax 3

答案3

即使如此rsync --verbose，输出的最终几行仍旧是这样的：

rsync: [sender] write error: Broken pipe (32)
rsync error: error in socket IO (code 10) at io.c(823) [sender=3.2.3]
rsync error: received SIGUSR1 (code 19) at main.c(1612) [generator=3.2.3]

事实证明我的系统空间不足在目标上（120 GB APFS 卷上有 20 MB 可用空间，快速检查的方法是df -h）。

  • 在紧急情况下，您还可以尝试rsync --delete-before释放空间。）
  • （系统是 macOS 12，运行 rsync 3.2.3，从 homebrew 安装。rsync 任务是从内部驱动器到外部 USB 驱动器，而这正是空间不足的地方。）

不过，错误消息中并没有立即出现什么问题。谷歌搜索 rsync +SIGUSR1指向了这个问题，所以这可能是 OP 的“更新 2”中的问题。

相关内容