带有rsync的压缩选项-z是否可以加快备份速度

在中rsync，-z将在传输期间压缩文件数据。

如果我理解正确，请-z在传输前压缩文件，然后在传输后解压缩文件。压缩过程中转移所减少的时间是否超过了压缩和解压缩的时间？

问题的答案是否取决于我是通过USB（2.0或3.0）备份到外部硬盘，还是通过ssh通过Internet备份到服务器？

这是一个普遍的问题。端点处的压缩和解压缩是否可以改善链路的有效带宽？

在端点进行压缩和解压缩的链接的有效（感知）带宽是以下功能：

1. 压缩速度（您的CPU速度）
2. 您网络的实际带宽

此3D图形描述了该功能，您可能需要针对特定​​情况进行咨询：

该图源自http://www.linuxjournal.com/的Compression Tools Compare 2005文章。

如果您的连接速度很慢（请考虑GPRS），则绝对要尽可能地压缩数据，否则连接速度会变慢。

如果您的CPU速度非常慢且连接速度较快（例如嵌入式网络设备），则通常不希望压缩数据，否则CPU会降低速度。

取决于数据的可压缩性以及源和目标的处理能力。根据我的经验，完整磁盘备份将压缩到其原始大小的大约30-50％，因此值得尝试一下。否则，不要理会压缩。可能需要测试压缩率，pigz -c <your file> | wc -c并将返回的大小与原始大小进行比较。

是的，连接速度决定是否加快速度。仅对于USB备份，这将是开销，因为不是磁盘填充数据，而是写入数据的过程。因此，读取和压缩文件的同一台机器也必须对其进行膨胀和写入。我认为Rsync仍然是两个进程，但是您将数据从一个进程传递到另一个进程的内存足够快，并且CPU需要更多时间来压缩它（同时将其读入同一内存中，以后再交给它：）。

仅当您具有发送方和接收方rsync以及两者之间较慢的网络时，压缩才有用。例如，当您有本地NAS时1Gbit可能已经足够快，而10Gbit已经是原始SATA速度。因此，仅当您具有100Mbit或更少的连接时才需要压缩，并且仅当压缩的数据可压缩时才有意义。

我认为rsync可能会注意到它不在两台计算机上运行，​​而是在一台计算机上运行，​​并且跳过了压缩过程但不确定。

tl; dr通过慢速传输链接进行压缩，否则不要压缩。以下是压缩速度测试，带宽转换工具的链接和一些信息。

rsync仅当中间链接“足够慢”时（即，如果一端的机器能够以足够快的速度产生压缩的数据流以使通信链接饱和），才使用压缩功能将加快速度。

那么，我应该使用压缩来获得任何东西的最慢的链接是什么？

下面是一个非常不科学的测试，它将显示gzip生成数据的速度，以及通常是否应该压缩网络批量传输的含义。

输入数据将大大改变测试结果。我在计算机上使用的未压缩（！）常规文件可能代表我通常通过网络传输的数据类型。使用/dev/zero（产生无限的零）会产生误导，因为零流非常容易压缩，而使用/dev/random会产生相反的误导。因此，我改用$HOME/local目录的tar文件，其中包含我已安装的软件$HOME。该文件本身未压缩，但包含二进制文件，小型压缩文件和源/文本文件的混合，我将使用默认设置对其进行压缩，因为gzip它将从64 MiB缩小到22 MiB。

$ gzip -c local.tar | dd of=/dev/null
43092+4 records in
43093+1 records out
22063854 bytes transferred in 2.819 secs (7825741 bytes/sec)

我这样做了几次，以了解平均值，大概是7800000字节/秒。

然后，我使用网络带宽计算器查看其转换结果。在这种特殊情况下，它恰好在“ 100Mb以太网”有线链路的容量之下，仅比“ VDSL下载”互联网上行链路快，比“ 802.11 [a / g]”无线链路快一点，并且在某个地方在“蓝牙v3.0”（较慢）和“ USB 2.0”（较快）之间。

这意味着，如果我对任何内容使用压缩速度都快于此速度，则压缩可能会减慢文件的传输速度。

rsync可能不是使用精确的相同库，gzip做压缩，但上述会给你一点暗示至少。

rsync如您所知，压缩不仅仅可以完成压缩，而且真正的速度提高来自仅传输已更改的[位]文件。

以我自己的经验，随着rsync网络带宽的增加（在我所在的位置），在过去10年左右的时间里，使用with压缩已变得越来越少。

对于进行增量备份，我绝对建议您研究该--link-dest选项（这与传输的内容无关，仅与目标上存储的内容无关）。另外，如果您是通过SSH进行的，则由于上面提到的相同原因，如果您的SSH连接已被压缩，请不要使用压缩，而只能压缩通过慢速链接的SSH连接（隧道等）。