我正在尝试使用 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以便它看到已经存在它可以恢复的文件。
我该如何解决这个问题，这样我就不必每次都手动干预？
TL;DR：使用--timeout=X(X in seconds) 更改默认的 rsync 服务器超时，而不是--inplace.
问题是 rsync 服务器进程（其中有两个，请参见接收器rsync --server ...的ps输出）继续运行，以等待 rsync 客户端发送数据。
如果 rsync 服务器进程在足够长的时间内没有接收到数据，它们确实会超时、自行终止并通过将临时文件移动到它的“正确”名称（例如，没有临时后缀）来进行清理。然后你就可以恢复了。
如果您不想等待较长的默认超时导致 rsync 服务器自行终止，那么当您的 Internet 连接恢复时，登录服务器并手动清理 rsync 服务器进程。但是，您必须礼貌地终止rsync ——否则，它不会将部分文件移动到位；而是删除它（因此没有要恢复的文件）。礼貌地要求 rsync 终止，不要SIGKILL（例如，-9），而是SIGTERM（例如，pkill -TERM -x rsync- 只是一个示例，您应该注意仅匹配与您的客户端相关的 rsync 进程）。
幸运的是，有一个更简单的方法：使用--timeout=X(X in seconds) 选项；它也被传递给 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对于细节，您无疑会因此遇到其他问题。-t在您的 rsync 选项中是多余的，它由-a.--checksum/ -c，在这种情况下它不会帮助你。它会影响 rsync 如何决定是否应该传输文件。虽然，在第一次 rsync 完成后，您可以运行第二次rsync-c以坚持校验和，以防止文件大小和 modtime 双方相同但写入错误数据的奇怪情况。抱歉，这里的其他答案太复杂了：-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 写入实际的最终目标文件。如果传输中断，这是一个截断的文件。
参数解释：
-avhz .. h=humanoid, v=verbose, a=archive, z=compression .. archive 指示它维护 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;].
我发现添加 --inplace 可以修复它。不确定没有它 --partial 应该如何工作，但它恢复了我的转移。我的文件仍然很大，我想知道如果传输开始，我是否会收到损坏的文件，几个小时后另一个传输开始但看到一个不完整的文件并且不知道它当前正在上传，然后开始添加字节到它。有人知道吗？也许一些 bash 脚本来记录当前进程 ID 而不是开始另一个传输？
如果您害怕恢复后文件损坏，您可以添加--checksum强制它每次对整个文件进行校验和。实际上，它会花费您一些磁盘 IO 和 CPU 周期，但只会产生轻微的网络开销。