linux - 在中断的传输上恢复rsync局部(-P/-partial)

Question

我正在尝试使用rsync将文件服务器备份到删除文件服务器。传输中断时，Rsync无法成功恢复。我使用了partial选项，但rsync找不到它已经启动的文件，因为它将其重命名为临时文件，并且在恢复时会创建一个新文件并从头开始。

这是我的命令:
rsync -avztP -e "ssh -p 2222" /volume1/ myaccont@backup-server-1:/home/myaccount/backup/ --exclude "@spool" --exclude "@tmp"
运行此命令后，将在本地计算机上从本地计算机上创建名为 OldDisk.dmg 的备份文件，就像 .OldDisk.dmg.SjDndj23 一样。

现在，当互联网连接中断并且我必须继续传输时，我必须通过找到 .OldDisk.dmg.SjDndj23 之类的临时文件来找到rsync的中断位置，并将其重命名为 OldDisk.dmg ，以便看到已经存在一个可以恢复的文件。

如何解决此问题，所以不必每次都手动干预？

Answer 1

TL; DR :使用--timeout=X(以秒为单位的X)更改默认的rsync服务器超时，而不是--inplace。

问题是rsync服务器进程(其中有两个，请参见接收器上rsync --server ...输出中的ps)继续运行，以等待rsync客户端发送数据。

如果rsync服务器进程在足够长的时间内没有接收到数据，则它们确实会超时，自行终止并通过将临时文件移动到其“适当”名称(例如，没有临时后缀)进行清理。然后，您将可以继续。

如果您不想等待较长的默认超时时间来导致rsync服务器自行终止，那么当您的Internet连接恢复时，请登录服务器并手动清理rsync服务器进程。但是，您使用must politely terminate rsync －否则，它将不会将部分文件移到适当的位置；而是删除它(因此没有要恢复的文件)。要礼貌地要求rsync终止，请不要SIGKILL(例如-9)，而不要SIGTERM(例如pkill -TERM -x rsync-仅是示例，您应注意仅匹配与客户端有关的rsync进程)。

幸运的是，有一种更简单的方法:使用--timeout=X(X秒)选项；它也传递给rsync服务器进程。

例如，如果指定rsync ... --timeout=15 ...，则如果客户端和服务器rsync进程在15秒内不发送/接收数据，则它们将干净退出。在服务器上，这意味着将临时文件移到可以恢复的位置。

我不确定各种rsync进程的默认超时值是否会在它们死之前尝试发送/接收数据(它可能随操作系统而变化)。在我的测试中，服务器rsync进程的运行时间比本地客户端的运行时间长。在“无效”网络连接上，客户端在大约30秒后以断开的管道(例如，没有网络套接字)终止；您可以尝试或查看源代码。这意味着，您可以尝试“摆脱”不良的互联网连接15-20秒。

如果不清理服务器rsync进程(或等待它们终止)，而是立即启动另一个rsync客户端进程，则会启动两个其他服务器进程(用于新客户端进程的另一端)。具体来说，新的rsync客户端不会重新使用/重新连接到现有的rsync服务器进程。因此，您将拥有两个临时文件(和四个rsync服务器进程)-但是，只有新的第二个临时文件才写入新数据(从新的rsync客户端进程接收)。

有趣的是，如果您随后清理所有rsync服务器进程(例如，停止将停止新rsync服务器的客户端，然后SIGTERM较旧的rsync服务器，则它似乎会将所有部分文件合并(组装)到新的正确命名文件中因此，想象一个长时间运行的部分副本终止(并且您认为您已经“丢失”了所有复制的数据)，以及一个短暂运行的重新启动rsync(哎呀!)。您可以停止第二个客户端，SIGTERM第一台服务器，它将合并数据，您可以继续。

最后，简短说明一下:

不要使用--inplace解决此问题。因此，您无疑会遇到其他问题，请使用man rsync进行详细说明。

很简单，但是rsync选项中的-t是多余的，-a暗含了它。

通过rsync发送的已经压缩的磁盘镜像而不进行压缩可能会缩短传输时间(避免双重压缩)。但是，我不确定这两种情况下的压缩技术。我会测试。

据我了解--checksum/-c，在这种情况下它对您没有帮助。它会影响rsync决定是否应传输文件的方式。但是，在第一个rsync完成之后，您可以使用-c运行第二个rsync来坚持校验和，以防止出现奇怪的情况，即文件大小和modtime双方相同，但是写入了错误的数据。