web-dev-qa-db-ja.com

圧縮オプション-rsyncを使用してバックアップを高速化しますか

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

私が正しく理解していれば、-z転送前にファイルを圧縮し、転送後に解凍します。圧縮による転送中の時間は、圧縮と解凍の時間を上回っていますか?

質問への回答は、USB(2.0または3.0)を介して外部HDDにバックアップするか、インターネット経由でsshを使用してサーバーにバックアップするかによって異なりますか?

46
Tim

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

エンドポイントで圧縮と解凍を行うリンクの有効な(認識される)帯域幅は、次の関数です。

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

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

enter image description here

グラフは http://www.linuxjournal.com/ による Compression Tools Compared 2005の記事から始まります。

55
PSkocik

接続が非常に遅い場合(GPRSなど)、確実に可能な限りデータを圧縮する必要があります。そうでない場合、接続によって速度が低下します。

非常に遅いCPUと高速な接続(組み込みネットワークデバイスなど)がある場合、通常はデータを圧縮する必要はありません。それ以外の場合、CPUは速度を低下させます。

14
michas

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

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

Rsyncは、2台のマシンでは実行されず、1台のマシンで実行され、圧縮をスキップすることに気づくかもしれませんが、確かではありません。

3

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

3
RAKK

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

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

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

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

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

これは、それよりも圧縮が速い場合、圧縮によってファイルの転送が遅くなることを意味します。

rsyncは、圧縮を行うためにgzipと同じexactライブラリを使用していない可能性がありますが、上記は少なくとも少しヒントを提供します。

rsyncは、ご存知のように圧縮以上のことを行います。realの速度の向上は、変更された[ビット]ファイルのみを転送することから生じます。

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

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

1
Kusalananda