☰

使用 --remove-source-files 进行多个 rsync 进程

tag-icon • tag-icon rsync
使用 --remove-source-files 进行多个 rsync 进程

假设我有 TB 级的数据，以 MB 级的文件形式保存，需要将其从距离超过 500 毫秒的服务器移走。

由于 TCP 的性质，下面的命令可以工作，但只能在可用带宽的一小部分上，无论是我的 4 Mbit/s 家庭 ADSL 连接还是宽带千兆线路。

rsync -avP --remove-source-files source.host:path/to/source/ path/to/dest

我之所以使用，--remove-source-files是因为我可能需要使用多个主机和目标目录，这些目录可能并不总是包含之前成功接收的所有内容，并且源目录是静止的。

同时运行上述命令的多个实例是否安全有效？

答案1

不，实际行为是不可预测的，但有可能多个实例会同时尝试复制同一个文件，从而浪费带宽，并且可能会发生不好的事情。

但是，巧妙地使用--include和--exclude可能会在这里很方便：

rsync -avP \
    --include '*/' --include '[a-g]*' --exclude '*' \
    source.host:path/to/source/ path/to/dest/

此命令将仅发送以字母开头的文件a至g。您可以为字母表的其他部分设置并行传输。

最后，一旦所有传输完成，你应该运行你的原来的再次执行 rsync 命令（请注意，我省略了--remove-source-files命令）以确保发生的任何奇怪现象都得到消除，并且原始过滤器遗漏的任何文件（可能是点文件？）也得到了传输。

顺便说一句，始终在源目录和目标目录上加上最后的斜杠（例如path/to/dest/），否则rsync可能不会达到您预期的效果！

然而，rsync 并不是第一次复制文件的最有效方法，尤其是在延迟较高的情况下（它主要用于后续更新过程）。

最好使用tar将数据流式传输到ssh：

ssh source.host tar -C path/to/source/ cfj - . | tar -C path/to/dest/ xfj -

这会将数据打包并压缩成连续的流，通过ssh隧道传输，返回到tar本地端，然后在一个命令中扩展回文件，并且 tar 文件无需接触磁盘。

缺点是如果连接断开则不容易恢复。

Tar 也有一个--exclude选项（但没有--include），因此，如有必要，您可以以类似的方式并行化流。同样，您可能应该使用 rsync 来验证传输。

另外：“TCP 的本质”是不是问题就在这里。TCP 使用滑动窗口方案，在任何正常延迟下都应该使链路饱和，并且旋钮如果没有的话。

然而，rsync 的本质是，它必须在传输每个文件之前来回进行一些沟通，这里延迟会受到影响（尽管实现使用流水线来最小化这一点）。

如果您的链接没有饱和，那么首先要尝试的是将 rsync 从方程式中移除（scp一个足够大的文件就可以了）。如果这仍然不起作用，那么请检查您的 CPU 使用率：压缩和加密可能是瓶颈。如果通过 Netcat（或老式 FTP）传输纯数据无法做到这一点，那么您可能需要调整 TCP。此外，使用 检查数据包丢失ping，因为这会真正搞砸 TCP。最后，可能只是链中最慢的链接不是您的。

答案2

简短回答：不。

如果您想运行 rsync 的多个实例，则应该让每个实例处理它自己的一批文件。

我不确定会发生什么，但我的累积经验告诉我，我不会相信结果。

只要您没有占用路线最慢的部分，您就应该能够通过运行多个实例来提高效率。

相关内容