rsyncで圧縮オプション-zを実行するとバックアップが高速化されます


37

ではrsync-z転送中にファイルデータを圧縮します。

正しく理解できたら、-z転送前にファイルを圧縮し、転送後に解凍します。圧縮により転送中の時間が短縮され、圧縮と解凍の時間が長くなりますか?

質問に対する答えは、USB(2.0または3.0)経由で外部hddにバックアップするか、インターネット経由でsshでサーバーにバックアップするかによって異なりますか?


また、圧縮ファイルのサイズが元のファイルとあまり変わらない場合、これは大きなオーバーヘッドになる可能性があることを忘れないでください。
-heemayl

1
heemaylが述べていることを詳しく説明すると、コンテンツの大部分が既に圧縮形式(jpeg、mpeg、distroパッケージなど)である場合、圧縮はあまり効果的ではありません。で私が気付いman rsyncたファイル接尾辞のリスト実際に存在している圧縮されませんでもとは-z(参照します--skip-compress)。
goldilocks

回答:


46

これは一般的な質問です。エンドポイントでの圧縮と解凍は、リンクの有効帯域幅を改善しますか?

エンドポイントで圧縮および圧縮解除を行うリンクの効果的な(知覚される)帯域幅は、次の関数です。

  1. 圧縮速度(CPU速度)
  2. ネットワークの実際の帯域幅

この機能はこの3Dグラフで説明されています。特定の状況については、この3Dグラフを参照してください。

ここに画像の説明を入力してください

このグラフは、http://www.linuxjournal.com/に よるCompression Tools Compared 2005の記事に由来しています


1
データのタイプも主要な要因です(リストにない要因#3)。リンクされた記事は、典型的なデータの組み合わせを使用します。あなたのものは典型的ではないかもしれません。100%ZIPファイル(または事前に圧縮されたデータ)を同期している場合、おそらく圧縮は必要ありません。100%テキストファイルを同期している場合、ネットワークが高速でCPUが低速であっても、圧縮が高速になる可能性があります。3つの要因すべてを比較検討します。
リチャードブライトウェル

13

接続が非常に遅い場合(GPRSを考えてください)、データを可能な限り圧縮することをお勧めします。そうしないと、接続が遅くなります。

CPUが非常に遅く、接続が高速な場合(組み込みネットワークデバイスなど)、通常、データを圧縮したくない場合は、CPUの速度が低下します。


3

データの圧縮性と、ソースとデスティネーションの処理能力に依存します。私の経験では、ディスク全体のバックアップは元のサイズの約30〜50%に圧縮されるため、試してみる価値はあります。それ以外の場合は、圧縮を気にしないでください。圧縮率をテストpigz -c <your file> | wc -cし、返されたサイズを元のサイズと比較する価値があるかもしれません。


2

はい、接続の速度によって速度が上がるかどうかが決まります。ディスクがデータを増大させるのではなく、データを書き込むプロセスが増大するため、USBバックアップの場合のみオーバーヘッドになります。そのため、同じマシンでそれを読み取り、空気を抜き、膨張させ、書き込む必要があります。Rsyncはまだ2つのプロセスですが、1つのプロセスから他のプロセスにデータを渡すメモリは十分に高速であり、CPUはそれを圧縮するのにより多くの時間を必要とします(後でそれを引き継ぐ同じメモリに読み込んでいます:)。

圧縮は、送信側と受信側のrsyncがあり、その間に低速のネットワークがある場合にのみ役立ちます。たとえば、ローカルNASを使用している場合、1Gbitはすでに十分に高速である可能性があり、10Gbitはすでに生のSATA速度です。したがって、圧縮が必要なのは、接続が100Mビット以下の場合のみであり、圧縮されたデータが圧縮可能な場合にのみ意味があります。

rsyncは2台のマシンではなく1台のマシンで実行され、圧縮をスキップしますが、確かではないことに気付くと思います。


1

tl; dr低速転送リンクでは圧縮し、そうでない場合は圧縮しません。以下は、圧縮速度のテスト、帯域幅変換ツールへのリンク、およびいくつかの情報です。

で圧縮を使用するとrsync、中間リンクが「十分に遅い」場合、つまり、一方のマシンが通信リンクを飽和させるのに十分な速さで圧縮データストリームを生成できる場合にのみ速度が上がります。

それで、圧縮を使用して何かを得る必要がある最も遅いリンクは何ですか?

以下は非常に非科学的なテストであり、gzipデータを生成する速度と、ネットワークのバルク転送を一般的に圧縮する必要があるかどうかを示すものです。

入力データは、テストの結果を大きく変えます。私は通常、ネットワーク経由で転送するデータのタイプを表す可能性がある、コンピューター上の非圧縮(!)通常ファイルを使用しています。/dev/zeroゼロのストリームは非常に圧縮しやすいため、使用(無制限のゼロを生成)は誤解を招く可能性があり/dev/random、逆の理由で使用は誤解を招く可能性があります。代わりに、$HOME/localディレクトリにインストールしたソフトウェアを含むディレクトリのtarファイルを使用します$HOME。ファイル自体は圧縮されていませんが、バイナリファイル、小さな圧縮ファイル、およびソース/テキストファイルが混在しており、デフォルト設定で圧縮するとgzip64 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]」ワイヤレスリンクよりもわずかに高速で、どこかで「Bluetooth v3.0」(低速)と「USB 2.0」(高速)の間。

これは、それより高速で圧縮を使用している場合、圧縮によりファイルの転送が遅くなる可能性が高いことを意味します。

rsync圧縮を行うのとまったく同じライブラリを使用していない可能性がありますgzipが、少なくとも上記のヒントを参照してください。

rsyncただし、ご存知のように、圧縮以上のことを行います。実際の速度向上は、変更された[ビット数]のファイルのみを転送することで実現されます。

私自身の経験でrsyncは、ネットワークの帯域幅が増加するにつれて(私がいるところで)、圧縮の使用は過去10年ほどで益々少なくなりました。

増分バックアップを行うには、--link-destオプションを調査することをお勧めします(これは、転送されるものとは関係なく、ターゲットでの格納方法とのみ関係があります)。また、SSH経由で行う場合は、SSH接続が既に圧縮されている場合は圧縮を使用せず、上記と同じ理由で、低速リンク経由のSSH接続(トンネルなど)のみを圧縮します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.