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

Tim*_*Tim 62 rsync

rsync--compress-z将在传输过程中压缩文件数据。

如果我理解正确,它会在传输前压缩文件,然后在传输后解压缩它们。由于压缩而减少的传输时间是否超过压缩和解压缩的时间?

问题的答案是否取决于我是通过 USB(2.0 或 3.0)备份到外部 HDD,还是通过 Internet 上的 SSH 备份到服务器?

PSk*_*cik 75

这是一个普遍的问题。端点的压缩和解压缩是否提高了链路的有效带宽?

在端点进行压缩和解压缩的链路的有效(感知)带宽是以下函数:

  1. 您可以压缩多快(您的 CPU 速度)
  2. 您网络的实际带宽

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

在此处输入图片说明

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

  • 您的数据类型也是一个主要因素(列表中缺少因素 #3)。链接的文章使用了典型的数据组合。你的可能不典型。如果您要同步 100% ZIP 文件(或任何预压缩数据),您可能不需要压缩。如果您同步 100% 的文本文件,即使您的网络速度很快且 CPU 速度很慢,您的压缩速度也可能会更快。权衡所有 3 个因素。 (8认同)
  • 这是一个很好的答案。该图表帮助我以以前从未有过的方式思考这个问题。 (2认同)

mic*_*has 18

如果您的连接速度很慢(想想 GPRS),您肯定希望尽可能地压缩您的数据,否则您的连接会减慢速度。

如果您有一个非常慢的 CPU 和一个快速连接(如嵌入式网络设备),您通常不想压缩您的数据,否则您的 CPU 会减慢速度。


Kus*_*nda 9

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

rsync如果中间链路“足够慢”,即如果一端的机器能够足够快地产生压缩数据流以使通信链路饱和,则使用压缩只会加快速度。

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

以下是一个非常不科学的测试,它将显示gzip生成数据的速度,以及这对于您是否应该压缩网络批量传输的一般意义。

输入的数据将极大地改变测试的结果。我在我的计算机上使用了一个未压缩的 (!) 常规文件,它可能代表我通常通过网络传输的数据类型。使用/dev/zero(产生无限的零)会产生误导,因为零流很容易压缩,而使用/dev/random会由于相反的原因产生误导。因此,我改为使用我$HOME/local目录的 tar 文件,其中包含我安装在$HOME. 该文件本身未压缩,但包含二进制文件、小型压缩文件和源/文本文件的混合,我是否会使用默认设置压缩它,因为gzip它会从 64 MiB 缩小 67% 到 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)
Run Code Online (Sandbox Code Playgroud)

我这样做了几次以了解平均值可能是多少,它大约为 7800000 字节/秒。

然后我使用网络带宽计算器(对不起,链接已死,我还没有找到好的替代品)来看看它会转换成什么。在这种特殊情况下,它恰好低于“100Mb 以太网”有线链路的容量,仅比“VDSL 下载”互联网上行链路快,比“802.11[a/g]”无线链路略快,并且在某处介于“蓝牙 v3.0”(较慢)和“USB 2.0”(较快)之间。

这意味着,如果我在比这更快的速度上使用压缩,压缩可能会减慢文件的传输速度

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

rsync不过,正如您所知,它的作用不仅仅是压缩,真正的速度提升来自仅传输已更改的 [bits of] 文件。

根据我自己的经验,rsync在过去 10 年左右的时间里,随着网络带宽的增加(我所在的位置),使用压缩的好处越来越少。

对于进行增量备份,我绝对建议调查该--link-dest选项(这与传输的内容无关,仅与目标如何存储内容有关)。此外,如果您是通过 SSH 进行的,如果您的 SSH 连接已经被压缩,则不要使用压缩,并且仅压缩通过慢速链接的 SSH 连接(隧道等),原因与上述相同。


Ren*_*zke 8

是的,连接速度决定了速度是否加快。这只会是 USB 备份的开销,因为不是磁盘膨胀数据,而是写入数据的过程。因此,读取和放气的同一台机器也必须充气和写入。我认为 Rsync 仍然是两个进程,但是您将数据从一个进程传递到另一个进程的内存足够快,并且 cpu 需要更多时间来压缩它(同时将其读入同一内存中,然后再将其移交给 :)。

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

我认为 rsync 可能会注意到它不是在两台机器上运行,而是在一台机器上运行并跳过压缩但不确定。

  • +1。对于认为使用压缩将文件复制到连接到笔记本电脑的外部驱动器会更快的人来说,这是一个很好的观点。(不,它不会。) (2认同)

RAK*_*AKK 5

取决于您的数据的可压缩程度以及源和目标的处理能力。根据我的经验,完整磁盘备份将压缩到其原始大小的 30-50% 左右,因此值得一试。否则,不要打扰压缩。测试您的压缩率pigz -c <your file> | wc -c并将返回的大小与原始大小进行比较可能是值得的。