web-dev-qa-db-ja.com

rsyncバックアップのパフォーマンスの向上

一方のシステムには常にマスターコピーがあり、もう一方のシステムには常に最新のコピー（48時間未満）があると仮定して、UNIXボックス間のsshミラーリングよりもrsyncを改善するための最良の手法は何ですか？

また、これらの変更のプッシュを取得する数十台のマシンを処理するために、そのアプローチを拡張するには何をする必要がありますか？

backupunixrsyncmirror
8
sal

場合：

  • あなたのファイルの変更時間は正しいです
  • ファイルはそれほど大きくありません
  • プッシュを見逃すことはできません（または何らかのバックログ処理があります）

find -ctimeまたはfile -cnewerを使用して、最後の実行以降に変更されたファイルのリストを作成し、変更されたファイルのみをコピーできます（単に栄光の差分プッシュ）。

これは、複数のホストに対して非常にうまく変換されました。ソースで差分tarを実行し、すべてのホストでuntarします。

それはあなたにそのような何かを与えます：

find -type f -cnewer /tmp/files_to_send.tar.gz > /tmp/files_to_send.txt
tar zcf /tmp/files_to_send.tar.gz --files-from /tmp/files_to_send.txt 
for Host in Host1 Host2 Host3 ...
do
    cat /tmp/files_to_send.tar.gz | ssh $Host "tar xpf -"
done

スクリプトは洗練されていますが、あなたはその考えを理解しています。

6
Steve Schnepp

同期しているデータがまだ圧縮されていないことを前提として、圧縮（-z）をオンにすると、転送速度が向上する可能性がありますが、両端のCPUがいくらか犠牲になります。

4
pjz

rsyncにはdisconnectedコピーを実行する方法があります。言い換えれば、rsyncは（概念的に）diffディレクトリツリーを生成し、patchファイルを生成し、後でそれを任意の数のファイルにapplyできます。元のソースと同じです。

マスターでrsyncを呼び出し、--write-batchでミラーリングする必要があります。ファイルを生成します。次に、このファイルを他の任意の数のターゲットに転送し、次にバッチを適用--read-batchを使用してそれらの各ターゲットに転送します。

最後に同期された状態のローカルコピー（つまり、現在のミラーの外観のコピー）をマスターと同じマシンに保持している場合、ミラーに接続しなくても、マスターでこの「パッチ」を生成できます。

マスターについて：

rsync --write-batch=my-batch.rsync /master/data /current/mirror

他に必要なオプションを追加します。これは2つのことを行います：

  1. /current/mirrorを反映するように/master/dataを変更します
  2. バイナリパッチファイルを作成（またはバッチファイル）my-batch.rsyncと呼ばれ、後で使用します。

my-batch.rsyncファイルをマスターからすべてのミラーに転送してから、ミラー上でパッチを適用いわば：

rsync --read-batch=my-batch.rsync /local/mirror

このアプローチの利点：

  • マスターは圧倒されていません
  • マスター/ミラーを同時に調整/アクセスする必要はありません
  • 異なる特権を持つ異なる人々がマスターとミラーで作業を行うことができます。
  • TCPチャネル（ssh、netcat、何でも;ファイルは電子メールで送信できます;-)）を持つ必要はありません
  • オフラインミラーは後で同期できます（オンラインにしてパッチを適用するだけです）
  • すべてのミラーは同一であることが保証されています（同じ「パッチ」を適用するため）
  • すべてのミラーを同時に更新できます（--read-batchはミラー自体にCPU/ioのみを集中させるため）
2
mogsie

多くの変更を加えた非常に大きなファイルを転送する場合は、-inplaceオプションと--whole-fileオプションを使用します。これらを2Gb VMイメージに使用すると、（主に） rsyncプロトコルは、これらのファイルでインクリメンタルデータを渡すことをあまり行っていなかったため）。ただし、ほとんどの場合、これらのオプションはお勧めしません。

--statsを使用して、rsyncインクリメンタルプロトコルを使用してファイルがどの程度適切に転送されているかを確認します。

2
gbjbaanb

もう1つの戦略は、sshとrsyncを高速化することです。信頼できるネットワーク（読み取り：プライベート）を経由する場合は、実際のペイロードを暗号化する必要はありません。 HPN ssh を使用できます。このバージョンのsshは、認証のみを暗号化します。また、rsyncバージョン3は、ファイルリストの作成中にファイルの転送を開始します。もちろん、これはrsyncバージョン2に比べて大幅な時間の節約になります。それがあなたが探していたものかどうかはわかりませんが、それがお役に立てば幸いです。また、rsyncは何らかの方法でマルチキャストをサポートしていますが、その方法を理解しているふりはしません。

2
Jackalheart

バックアップ方法としてrsyncを実行している場合、発生する最大の問題は、バックアップするファイルが多数ある場合です。 Rsyncは大きなファイルを問題なく処理できますが、バックアップするファイルの数が多すぎると、rsyncが妥当な時間内に完了しないことに気付くでしょう。これが発生した場合は、バックアップを小さな部分に分割してから、それらの部分をループする必要があります。

find /home -mindepth 1 -maxdepth 1 -print0 | xargs -0 -n 1 -I {} -- rsync -a -e ssh {} backup@mybackupserver:/backup/

または、ファイルセットをタールダウンしてファイル数を減らします。

数十台のマシンがこれらの変更のミラーを取得することに関しては、バックアップがどれだけ新鮮である必要があるかによって異なります。 1つのアプローチは、プライマリサーバーからバックアップサーバーへの変更をミラーリングしてから、最初のバックアップサーバーのrsyncデーモンによって他のサーバーに変更をバックアップサーバーからプルさせ、他のサーバーをわずかにプルするようにスケジュールすることです。異なる時間に、またはスクリプトでパスワードなしのsshを使用して各サーバーに接続し、バックアップの新しいコピーをプルするように指示することで、最初のバックアップサーバーを圧倒するのを防ぐことができますが、それほど多くの問題が発生するかどうかは状況によって異なりますバックアップのコピーをプルしている他のマシンの数。

2
Rodney Amato