在rsync、--compress或中-z，将在传输过程中压缩文件数据。
如果我理解正确的话，它会在传输前压缩文件，然后在传输后解压缩它们。由于压缩而减少的传输时间是否超过了压缩和解压缩的时间？
问题的答案是否取决于我是否通过 USB（2.0 或 3.0）备份到外部 HDD，还是通过 Internet 通过 SSH 备份到服务器？
答案1
这是一个一般性问题。端点处的压缩和解压缩是否会提高链路的有效带宽？
在端点进行压缩和解压缩的链路的有效（感知）带宽是以下函数：
- 你的压缩速度有多快（你的CPU速度）
- 您网络的实际带宽
此 3D 图表描述了该函数，您可能需要针对您的特定情况查阅该图表：
该图源自压缩工具比较 2005年文章作者：http://www.linuxjournal.com/。
答案2
如果您的连接速度非常慢（例如 GPRS），您肯定希望尽可能地压缩数据，否则您的连接速度会减慢。
如果您的 CPU 非常慢并且连接速度很快（例如嵌入式网络设备），您通常不想压缩数据，否则您的 CPU 会减慢速度。
答案3
太长了；博士通过慢速传输链接，进行压缩，否则不进行压缩。下面是压缩速度测试、带宽转换工具的链接和一些信息。
rsync如果中间链路“足够慢”，即如果一端的机器能够足够快地产生压缩数据流以使通信链路饱和，则使用压缩只会加快速度。
那么，我应该使用压缩来获得任何东西的最慢链接是什么？
以下是一个非常不科学的测试，它将显示gzip生成数据的速度有多快，以及这对于您是否应该压缩网络批量传输意味着什么。
输入的数据会改变测试的结果大大地。我在计算机上使用未压缩的（！）常规文件，它可能代表我通常通过网络传输的数据类型。使用/dev/zero（产生无限的零）会产生误导，因为零流非常容易压缩，而使用/dev/random则会因相反的原因而产生误导。因此，我使用目录中的 tar 文件$HOME/local，其中包含我在$HOME.该文件本身未压缩，但包含二进制文件、小型压缩文件和源/文本文件的混合，如果我使用默认设置压缩它，gzip它会从 64 MiB 缩小到 22 MiB 67%。
$ 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 年左右的时间里，随着网络带宽的增加（我所在的地方），使用压缩的好处越来越少。
对于进行增量备份，我绝对建议研究该--link-dest选项（这与传输的内容无关，仅与目标存储内容的方式有关）。另外，如果您通过 SSH 执行此操作，并且您的 SSH 连接已经压缩，则不要使用压缩，并且仅压缩通过慢速链接的 SSH 连接（隧道等），原因与上述相同。
答案4
取决于您的数据的可压缩程度以及源和目标的处理能力。根据我的经验，完整磁盘备份将压缩到原始大小的 30-50% 左右，因此值得一试。否则，不要费心压缩。可能值得测试您的压缩率并将pigz -c <your file> | wc -c返回的大小与原始大小进行比较。