非常に大きなフォルダー構造の同期

イントラネットには、約800,000個のファイルが約4,000個のフォルダーに分割されたフォルダー構造があります。これをDMZのマシンの小さなクラスターに同期する必要があります。構造の深さは非常に浅い（2レベルを超えない）。

ほとんどのファイルは変更されず、毎日数千の更新されたファイルと1〜2千の新しいファイルがあります。データは、ソースデータが削除された場所で保持されている履歴レポートデータです（つまり、これらはアーカイブされて削除されるほどソースデータが十分に古いファイナライズされたレポートです）。合理的な時間枠で発生する可能性があるため、1日に1回の同期で十分です。レポートは夜間に生成され、午前中にスケジュールされたタスクとして最初に同期します。

明らかに、定期的に変更されるファイルはごくわずかなので、インクリメンタルコピーの恩恵を受けることができます。Rsyncを試してみましたが、「ファイルリストの作成」操作を完了するだけで8〜12時間かかる場合があります。rsyncの能力を急速に上回っていることは明らかです（12時間の時間枠は長すぎます）。

RepliWebという別のツールを使用して構造を同期していましたが、約45分で増分転送を実行できます。ただし、制限を超えたようで、ファイルが削除されていないときにファイルが表示されるようになりました（おそらく、内部メモリ構造が使い果たされたのかどうかはわかりません）。

他の誰かがこの種の大規模な同期プロジェクトに遭遇しましたか？同期のためにこのような大規模なファイル構造を処理するように設計されたものはありますか？

ファイルシステムの最終変更タイムスタンプを信頼できる場合は、RsyncをUNIX / Linuxの「find」ユーティリティと組み合わせることにより、速度を上げることができます。「find」は、過去1日以内の最終変更時刻を示すすべてのファイルのリストを作成し、その短縮されたファイル/ディレクトリのリストのみをRsyncにパイプします。これは、Rsyncが送信側のすべての単一ファイルのメタデータをリモートサーバーと比較するよりもはるかに高速です。

要するに、次のコマンドは、過去24時間以内に変更されたファイルとディレクトリのリストに対してのみRsyncを実行します（Rsyncは、他のファイル/ディレクトリをチェックすることはありません）。

find /local/data/path/ -mindepth 1 -ctime -0 -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.

「find」コマンドに慣れていない場合は、特定のディレクトリサブツリーを再帰処理し、指定した条件に一致するファイルやディレクトリを検索します。たとえば、次のコマンド：

find . -name '\.svn' -type d -ctime -0 -print

現在のディレクトリ（ "。"）で開始し、すべてのサブディレクトリを再帰的に検索して、以下を探します。

• 任意のディレクトリ（「-type d」）、
• ".svn"（ "-name '.svn'"）という名前、
• 過去24時間にメタデータが変更された（「-ctime -0」）

これらの基準に一致するもののフルパス名（ "-print"）を標準出力に出力します。オプション「-name」、「-type」、および「-ctime」は「テスト」と呼ばれ、オプション「-print」は「アクション」と呼ばれます。「検索」のマニュアルページには、テストとアクションの完全なリストがあります。

本当に賢くなりたい場合は、「-ctime」の代わりに「find」コマンドの「-cnewer」テストを使用して、このプロセスの耐障害性と柔軟性を高めることができます。'-cnewer'は、ツリー内の各ファイル/ディレクトリのメタデータが参照ファイルよりも最近変更されたかどうかをテストします。「タッチ」を使用して、各実行の開始時、「検索...」の直前に次の実行の参照ファイルを作成します。rsync ... 'コマンドが実行されます。基本的な実装は次のとおりです。

#!/bin/sh
curr_ref_file=`ls /var/run/last_rsync_run.*`
next_ref_file="/var/run/last_rsync_run.$RANDOM"
touch $next_ref_file
find /local/data/path/ -mindepth 1 -cnewer $curr_ref_file -print0 | xargs -0 -n 1 -I {} -- rsync -a {} remote.host:/remote/data/path/.
rm -f $curr_ref_file

このスクリプトは、最後に実行された日時を自動的に認識し、最後の実行以降に変更されたファイルのみを転送します。これはより複雑ですが、ダウンタイムまたはその他のエラーのために24時間以上ジョブを実行できなかった状況から保護します。

unisonを試してください。変更リスト（ビルドファイルリスト）をローカルに各サーバーに保持し、デルタを計算する時間を短縮し、その後ワイヤを介して送信される量を削減することにより、この問題を解決するために特別に設計されました。

http://oss.linbit.com/csync2/は、このようなことを想定して設計されています。試してみます。

rsyncで-zスイッチを使用している場合は、それなしで実行してみてください。何らかの理由で、ファイルの最初の列挙でさえ、このスピードアップを見ました。

圧縮ではないrsyncコマンドから-zを削除すると、「受信ファイルリスト」が非常に高速になり、約500 GBを転送する必要がありました。-zスイッチで1日かかる前。