我经常发现自己将包含10K-100K文件的文件夹发送到远程计算机（在校园内的同一网络中）。

我只是想知道是否有理由相信这一点，

 tar + rsync + untar

或者简单地

 tar (from src to dest) + untar

在实践中可能比

rsync 

首次传输文件时。

我对在两种情况下解决上述问题的答案很感兴趣：使用压缩而不使用压缩。

更新资料

我刚刚进行了一些实验，移动了10,000个小文件（总大小= 50 MB），并且tar+rsync+untar始终比rsync直接运行（都没有压缩）要快。

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

如果您是第一次复制文件，先打包然后发送，然后再拆包（AFAIK 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

一般规则，请保持简单。

更新：

我已经创建了5900万个演示数据

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，并进行了讨论，以为我要添加结果。长话短说，在我的环境中，通过网络将目标文件系统压缩到目标文件系统比同步到同一目标要快得多。

环境：源机器使用SSD硬盘的i7桌面。目标计算机通过Synology NAS DS413j以千兆位局域网连接到源计算机。

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

源文件是我的〜/ .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将焦油输出通过管道传输到接收器上的非压缩过程。

时间：

1a - 33 seconds

1b - 1 minutes 48 seconds

2 - 22 minutes

很明显，与tar操作相比，rsync的性能非常差，这大概可以归因于上述网络性能。

我建议任何想要备份大量主要是小文件（例如主目录备份）的人，请使用tar方法。rsync似乎是一个非常糟糕的选择。如果我在任何程序中都不正确，我将返回本文。

缺口

实际上，使用rsync按照要求发送tar存档将是浪费或资源，因为您将在流程中添加一个验证层。当您希望对单个文件进行检查时，Rsync会对tar文件进行校验和检查是否正确。（不知道在发送方可能有缺陷的tar文件已经在接收端显示了相同的效果）。如果要发送存档，则只需要ssh / scp。

您可能必须选择发送档案的一个原因是，如果您选择的tar能够保留更多文件系统特殊功能，例如访问控制列表或通常存储在扩展属性（Solaris）或资源叉（MacOS）中的其他元数据）。处理此类问题时，您将主要关注的是哪些工具能够保留与源文件系统上的文件相关联的所有信息，前提是目标文件系统也能够跟踪它们。

当您最关心速度时，它在很大程度上取决于文件的大小。通常，大量的小文件会在rsync或scp上严重扩展，因为它们都会浪费每个单独的网络数据包，而tar文件会在单个网络数据包的数据负载中包含其中的几个文件。如果将tar文件压缩，那就更好了，因为小文件整体上的压缩比单个文件的压缩更好。据我所知，在发送初次传输时发送整个单个文件时，rsync和scp都无法优化，因为每个文件都占用了整个数据帧及其整个协议开销（并浪费了更多的来回查询）。但是珍妮丝克指出这仅适用于scp，详细说明rsync将优化网络流量，但以在内存中构建巨大的数据结构为代价。请参阅Janecek 2006上的 “ 有效文件传输”一文。因此，根据他的说法，scp和rsync在小型文件上都无法很好地扩展，这是事实，但这是完全不同的原因。猜猜我这个周末必须深入研究资源以找出答案。

对于实际的相关性，如果您知道要发送的文件大都是较大的，则速度不会有太大差异，使用rsync的另一个好处是可以在中断时占用它的剩余位置。

后记：如今，rdist似乎陷入了遗忘，但是在rsync出现之前，它是一个功能非常强大的工具，并且被广泛使用（在ssh上安全使用，否则不安全）。我的表现不如rsync好，因为它没有进行优化以仅传输已更改的内容。它与rsync的主要区别在于它的配置方式，以及如何阐明更新文件的规则。

对于小型目录（与使用的磁盘空间一样小），这取决于检查文件信息中要同步的文件的开销。一方面，rsync节省了传输未修改文件的时间，另一方面，它确实必须传输有关每个文件的信息。

我不完全了解的内部rsync。文件统计信息是否引起延迟取决于rsync数据传输的方式-如果文件统计信息被一一传输，则RTT可使tar + rsync + untar更快。

但是，如果您拥有1 GiB数据，那么rsync将会更快，除非您的连接非常快！

我不得不一次在全国范围内移动了几TB的数据。作为实验，我使用rsync和运行了两个传输，ssh/tar以查看它们之间的比较。

结果：

• rsync 传输文件的平均速度为每秒2.76兆字节。
• ssh/tar 以每秒4.18兆字节的平均速度传输文件。

详细信息： 我的数据包含数百万个.gz压缩文件，平均大小为10兆字节，但有些超过1千兆字节。有一个目录结构，但与文件内部数据的大小相比显得相形见war。如果我还有其他事情要做，我只会使用，rsync但是在这种情况下，这ssh/tar是一个功能解决方案。

我的工作rsync包括：

rsync --compress --stats --no-blocking-io --files-from=fileList.txt -av otherSystem:/the/other/dir/ dest/

其中，fileList.txt是另一端文件的相对路径名的很长的列表。（我注意到--compress启动后，压缩文件无效，但是我不打算重新启动。）

我用ssh和tar启动了另一个具有：

ssh otherSystem "cd /the/other/dir/;  tar cf - ." | tar xvf -

您将观察到此副本的所有内容，抱歉，这不是100％的苹果与苹果的比较。

我应该补充一点，在使用公司内部网络时，我必须经过中介才能访问数据源计算机。从目标计算机到中介的ping时间是21 ms，从中介到数据源的ping时间是26 ms。两次转移都一样。

通过中介的SSL连接通过以下~/.ssh/config条目完成：

Host otherSystem
    Hostname dataSource.otherSide.com
    User myUser
    Port 22
    ProxyCommand ssh -q -W %h:%p intermediary.otherSide.com
    IdentityFile   id_rsa.priv

时间：

tar cf - ~/.cache | ssh admin@nas_box "(cd /destination ; tar xf -)"