更新

Question 1

当您发送同一组文件时，rsync更适合，因为它只会发送差异。tar总是会发送所有内容，当大量数据已经存在时，这会浪费资源。在这种情况下，就tar + rsync + untar失去了这一优势，以及保持文件夹与rsync --delete.

如果您第一次复制文件，首先打包，然后发送，然后解包（AFAIKrsync不接受管道输入）很麻烦，而且总是比 rsync 更糟糕，因为rsync无论如何都不需要执行任何任务tar。

提示：rsync 版本 3 或更高版本执行增量递归，这意味着它几乎在计算所有文件之前立即开始复制。

提示2：如果您使用rsyncover ssh，您也可以使用tar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

要不就scp

scp -Cr srcdir user@server:destdir

一般规则，保持简单。

更新：

我已经创建了 59M 演示数据

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

并使用这两种方法多次测试文件传输到远程服务器（不在同一局域网中）

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

同时将日志与发送的 ssh 流量数据包分开

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

在这种情况下，我看不到使用 rsync+tar 减少网络流量的任何优势，当默认 mtu 为 1500 并且文件大小为 10k 时，这是预期的。 rsync+tar 产生的流量更多，速度较慢 2-3 秒，并留下两个必须清理的垃圾文件。

我在同一局域网的两台机器上做了相同的测试，rsync+tar 的性能要好得多，网络流量也少得多。我假设是巨型帧的原因。

在更大的数据集上，也许 rsync+tar 比 rsync 更好。但坦率地说，我认为不值得这么麻烦，您需要在每一侧都有双倍的空间来打包和拆包，并且正如我上面已经提到的，还有其他一些选择。

Answer

当您发送同一组文件时，rsync更适合，因为它只会发送差异。tar总是会发送所有内容，当大量数据已经存在时，这会浪费资源。在这种情况下，就tar + rsync + untar失去了这一优势，以及保持文件夹与rsync --delete.

如果您第一次复制文件，首先打包，然后发送，然后解包（AFAIKrsync不接受管道输入）很麻烦，而且总是比 rsync 更糟糕，因为rsync无论如何都不需要执行任何任务tar。

提示：rsync 版本 3 或更高版本执行增量递归，这意味着它几乎在计算所有文件之前立即开始复制。

提示2：如果您使用rsyncover ssh，您也可以使用tar+ssh

tar -C /src/dir -jcf - ./ | ssh user@server 'tar -C /dest/dir -jxf -'

要不就scp

scp -Cr srcdir user@server:destdir

一般规则，保持简单。

更新：

我已经创建了 59M 演示数据

mkdir tmp; cd tmp
for i in {1..5000}; do dd if=/dev/urandom of=file$i count=1 bs=10k; done

并使用这两种方法多次测试文件传输到远程服务器（不在同一局域网中）

time rsync -r  tmp server:tmp2

real    0m11.520s
user    0m0.940s
sys     0m0.472s

time (tar cf demo.tar tmp; rsync demo.tar server: ; ssh server 'tar xf demo.tar; rm demo.tar'; rm demo.tar)

real    0m15.026s
user    0m0.944s
sys     0m0.700s

同时将日志与发送的 ssh 流量数据包分开

wc -l rsync.log rsync+tar.log 
   36730 rsync.log
   37962 rsync+tar.log
   74692 total

在这种情况下，我看不到使用 rsync+tar 减少网络流量的任何优势，当默认 mtu 为 1500 并且文件大小为 10k 时，这是预期的。 rsync+tar 产生的流量更多，速度较慢 2-3 秒，并留下两个必须清理的垃圾文件。

我在同一局域网的两台机器上做了相同的测试，rsync+tar 的性能要好得多，网络流量也少得多。我假设是巨型帧的原因。

在更大的数据集上，也许 rsync+tar 比 rsync 更好。但坦率地说，我认为不值得这么麻烦，您需要在每一侧都有双倍的空间来打包和拆包，并且正如我上面已经提到的，还有其他一些选择。

Question 2

rsync也进行压缩。使用-z旗帜。如果跑过来ssh，还可以使用ssh的压缩方式。我的感觉是，重复的压缩级别没有用；它只会消耗周期而不会产生显着的结果。我建议尝试rsync压缩。看来还是蛮有效的。我建议跳过使用tar或任何其他预/后压缩。

我通常使用 rsync 作为rsync -abvz --partial....

Answer

rsync也进行压缩。使用-z旗帜。如果跑过来ssh，还可以使用ssh的压缩方式。我的感觉是，重复的压缩级别没有用；它只会消耗周期而不会产生显着的结果。我建议尝试rsync压缩。看来还是蛮有效的。我建议跳过使用tar或任何其他预/后压缩。

我通常使用 rsync 作为rsync -abvz --partial....

Question 3

我今天必须将我的主目录备份到 NAS，并遇到了这个讨论，我想添加我的结果。长话短说，在我的环境中，通过网络 tar 到目标文件系统比 rsync 到同一目标要快得多。

环境：源机i7台式机，使用SSD硬盘。目标计算机 Synology NAS DS413j 通过千兆位 LAN 连接到源计算机。

当然，所涉及套件的确切规格会影响性能，而且我不知道有关两端网络硬件质量的确切设置的细节。

源文件是我的 ~/.cache 文件夹，其中包含 1.2Gb 的大部分非常小的文件。

1a/ tar files from source machine over the network to a .tar file on remote machine

$ tar cf /mnt/backup/cache.tar ~/.cache

1b/ untar that tar file on the remote machine itself

$ ssh admin@nas_box
[admin@nas_box] $ tar xf cache.tar

2/ rsync files from source machine over the network to remote machine

$ mkdir /mnt/backup/cachetest
$ rsync -ah .cache /mnt/backup/cachetest

我将 1a 和 1b 保留为完全独立的步骤只是为了说明该任务。对于实际应用，我建议 Gilles 上面发布的内容涉及通过 ssh 将 tar 输出传输到接收器上的解压过程。

时间：

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

很明显，与 tar 操作相比，rsync 的性能差得惊人，这大概可以归因于上面提到的网络性能。

我建议任何想要备份大量（大部分是小文件）（例如主目录备份）的人使用 tar 方法。 rsync 似乎是一个非常糟糕的选择。如果我的任何程序似乎不准确，我会回到这篇文章。

缺口

Answer