Question

我正在尝试使用rsync将文件服务器备份到删除文件服务器。传输中断时，Rsync无法成功恢复。我使用了部分选项，但是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停止的位置并将其重命名为< strong> 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在两端都相同的奇怪情况，但是写了不好的数据。

Answer 2

很抱歉，这里的其他答案太复杂了：-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 .. 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;].

Answer 3

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

Answer 4

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

在中断的传输上恢复rsync partial（-P / - partial）

4 个答案: