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

1つのシステムに常にマスターコピーがあり、他のシステムには常に最新のコピー（48時間以内）があると仮定して、UNIXボックス間のsshミラーリングでrsyncを改善するための最良のテクニックは何ですか？

また、それらの変更をプッシュする数十のマシンを処理するために、そのアプローチをスケーリングするために何をしなければならないでしょうか？

の場合：

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

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

スクリプトは洗練されているはずですが、あなたはそのアイデアを理解します。

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

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

--statsを使用して、rsyncインクリメンタルプロトコルを使用したファイルの転送状況を確認します。

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

バックアップ方法として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を使用して各サーバーに接続し、バックアップの新しいコピーをプルするように指示することで、最初のバックアップサーバーの過負荷を防ぐのに役立ちます。バックアップのコピーをプルしている他のマシンの数。

rsyncには、切断されたコピーを行う方法があります。言い換えれば、rsyncのは（概念的には）できdiffのディレクトリツリーを生成し、パッチあなたが後ですることができ、ファイル適用元のソースと同じですファイルを任意の数の上を。

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

最後のrsynced状態のローカルコピー（つまり、現在ミラーがどのように見えるかのコピー）をマスターと同じマシンに保持している場合、ミラーに接続することなく、マスターでこの「パッチ」を生成できます。

マスター：

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のみが集中するため）