在中断的传输上恢复 rsync partial (-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

我发现添加 --inplace 可以修复它。不确定没有它 --partial 应该如何工作，但它恢复了我的转移。我的文件仍然很大，我想知道如果传输开始，我是否会收到损坏的文件，几个小时后另一个传输开始但看到一个不完整的文件并且不知道它当前正在上传，然后开始添加字节到它。有人知道吗？也许一些 bash 脚本来记录当前进程 ID 而不是开始另一个传输？

Answer 2

如果您害怕恢复后的文件损坏，您可以添加--checksum 以强制它每次对整个文件进行校验和。实际上，它会花费您一些磁盘 IO 和 CPU 周期，但只会产生轻微的网络开销。

Answer 3

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

问题是 rsync 服务器进程（其中有两个，请参阅接收器上的 ps 输出中的 rsync --server ...）继续运行，等待 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 运行 second rsync 以坚持校验和，以防止文件大小和 modtime 双方相同但数据错误的奇怪情况已经写好了。

Answer 4

对不起，这里的其他答案太复杂了：-7。 一个对我有用的更简单的答案：（使用 rsync over -e ssh）

# optionally move rsync temp file, then resume using rsync 
dst$ mv .<filename>.6FuChr <filename>
src$ rsync -avhzP --bwlimit=1000 -e ssh <fromfiles> <user@somewhere>:<destdir>/

从中断的 scp 恢复时也有效。

Rsync 创建一个临时文件...临时文件快速增长到部分传输文件的大小。转让简历。

Scp 写入实际的最终目标文件。如果传输中断，这是一个截断的文件。

args的解释：

-avhz .. h=humanoid, v=verbose, a=archive, z=compression .. 存档指示它维护 time_t 值，因此即使时钟超时 rsync 也知道每个文件的真实日期

-P 是 --partial --progress 的缩写。 --partial 告诉 rsync 保留部分传输的文件（并且在恢复时，rsync 将始终在安全校验和后使用部分传输的文件）

来自手册页： http://ss64.com/bash/rsync_options.html

--partial
By default, rsync will delete any partially transferred file if the transfer
is interrupted. In some circumstances it is more desirable to keep partially
transferred files. Using the --partial option tells rsync to keep the partial
file which should make a subsequent transfer of the rest of the file much faster.

--progress
This option tells rsync to print information showing the progress of the transfer.
This gives a bored user something to watch.
This option is normally combined with -v. Using this option without the -v option
will produce weird results on your display.

-P
The -P option is equivalent to --partial --progress.
I found myself typing that combination quite often so I created an option to make
it easier.

注意：对于多次中断的连接： 如果您需要在 rsync 后恢复（连接中断后），那么最好重命名目标上的临时文件。 scp 在目标上创建一个与最终文件同名的文件。如果 scp 被中断，则此文件是该文件的截断版本。 rsync (-avzhP) 将从该文件恢复，但开始写入临时文件名，如 ..Yhg7al。

scp启动时的流程：

scp; *interrupt*; rsync; [REPEAT_as_needed: *interrupt*; mv .destfile.tmpzhX destfile; rsync;]. 

rsync启动时的流程：

rsync; [REPEAT_as_needed: *interrupt*; mv .destfile.tmpzhX destfile; rsync;].