web-dev-qa-db-ja.com

ディレクトリのrsync可能な圧縮ミラーを作成する適切な方法は？

元の宛先とリモートの宛先の両方で再びrsyncできるように、いくつかのディレクトリの圧縮ミラーを作成したいと思います。

2つのステップで非効率的に行うことができます。

rsync -a /source/ /compressed-mirror/
gzip --recursive --rsyncable --force /compressed-mirror/
# later: rsync -a /compressed-mirror/ remote:/another-compressed-mirror/

問題は、最初のrsyncを再実行してミラーを更新する場合、変更されたソースファイルが数個しかない場合でも、すべてのソースファイルをもう一度コピーしてgzipする必要があることです。

質問：更新ごとに必要なデータ転送とハードドライブの使用量を最小限に抑える方法はありますか？

メモ：

  • 圧縮のためにgzipにこだわっていません-圧縮ファイルをrsyncできるようにするためだけに選択しました。

  • ローカル圧縮ミラーの目的は、ソースマシン（ラップトップ）のインターネット接続と電源状態の両方が信頼できないため、リモートミラーに対してrsyncを実行するために必要な「ネットワークの稼働」時間を最小限に抑えることです。ローカルミラーの一部は、リモートミラーへのrsyncの前に暗号化されます。リモートミラーは、rsnapshotでバージョン管理され、より安定したインターネット接続を介して別のリモートサーバーにアップロードされます。

更新/アイデア：

  • ファイルシステム圧縮を使用します（casによるコメントを参照）-しかし、これにより、rsyncはファイルをリモートサーバーに転送するときにファイルを再圧縮するように強制されます。
  • Rsyncされたディレクトリを圧縮しないでください。 rsyncが更新するたびに、変更されたファイルを記録します。変更されたファイルごとに、圧縮ミラーに個別に圧縮コピーを作成（または削除）します。しかし、次のアイデアは同じことをより効率的に行います。
  • ソースのファイルパスとファイルサイズ（またはチェックサム）のリストを保持します。更新するたびに、新しいリストを作成し、古いリストと比較します。変更されたファイルごとに、gzip < source/path/file > mirror/path/file.gzを使用して、最初の圧縮ミラーにgzipされたコピーを個別に作成（または削除）します。これは、これまでのところ最も効率的なソリューションのようです。
rsyncbackupcompressiongzip
2
Oleg

要件を処理する最も効率的な方法は、中間ミラーターゲットを圧縮しないことです。これにより、rsyncがローカルとリモートのホスト間でデルタアルゴリズムを使用して、変更されたデータのみを転送できるようになります。 （ただし、同じホスト上の2つのディレクトリ間でコピーする場合、デルタアルゴリズムは適用されません。）

# Any changed files will be copied completely, even if only one byte changed
rsync -a --delete /source/ /mirror/

# Only copy changed parts of changed files
rsync -az --delete /mirror/ remote:/mirror/

（ローカルハードディスクと中間ネットワークへのヒットに関して）最も効率的なソリューションは、ローカルミラーを完全に省き、ソースからリモートの宛先に直接コピーすることです。

# Only copy changed parts of changed files
rsync -az --delete /source/ remote:/mirror/
1
roaima