我经常发现自己将包含 10K - 100K 文件的文件夹发送到远程机器（在校园内的同一网络内）。
我只是想知道是否有理由相信，
tar + rsync + untar
或者干脆
tar (from src to dest) + untar
在实践中可能比
rsync
第一次传输文件时。
我对在两种情况下解决上述问题的答案感兴趣：使用压缩和不使用压缩。
我刚刚运行了一些移动 10,000 个小文件（总大小 = 50 MB）的实验，并且tar+rsync+untar始终比rsync直接运行（都没有压缩）快。
for*_*sck 27
当您发送同一组文件时，rsync更适合，因为它只会发送差异。tar将始终发送所有内容，当大量数据已经存在时，这是一种资源浪费。在tar + rsync + untar失去了这个优势，在这种情况下，以及与保持文件夹同步的优势rsync --delete。
如果你第一次复制文件，首先打包，然后发送，然后解包（AFAIKrsync不接受管道输入）很麻烦，而且总是比 rsyncing 更糟糕，因为rsync不需要做更多的任务tar。
提示：rsync 版本 3 或更高版本执行增量递归，这意味着它几乎在计算所有文件之前立即开始复制。
Tip2：如果你使用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 更好。但坦率地说，我认为这不值得麻烦，你需要在每一侧都有双倍的空间来装箱和拆箱，还有一些其他的选择，正如我上面已经提到的。
rsync也做压缩。使用-z旗帜。如果跑过去ssh，还可以使用ssh的压缩方式。我的感觉是重复的压缩级别没有用；它只会燃烧循环而没有显着结果。我建议尝试rsync压缩。似乎相当有效。我建议跳过使用tar或任何其他前/后压缩。
我通常使用 rsync 作为rsync -abvz --partial....
今天我不得不将我的主目录备份到 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 似乎是一个非常糟糕的选择。如果我的任何程序似乎不准确，我会回到这篇文章。
缺口