rsync を使用して 1 日に 2 回マシンのバックアップを実行しています。ファイルの変更を検索する 10 分から 15 分の間に、すべてが大幅に遅くなり、神経質になり始めます。
ここで、カーネル (Linux を実行しています) の inotify インターフェイスを使用して、変更されたファイルに関する通知を収集し、それらのパス名をリストに追加する小さなバックグラウンド アプリを作成します。このアプリは、rsync の呼び出しによって定期的に処理されます。
さて、定義上、このプロセスは常に、私が作業しているファイルに対して常に機能するため、rsync がファイルをコピーしているときに、破損したファイルや部分的に更新されたファイルがバックアップに大量に含まれるかどうか疑問に思っています。私は彼らに手紙を書いています。
マンページには何も見つかりませんでしたが、答えをグーグルで検索することにまだ失敗していました。ソースを読みに行くこともできますが、それにはかなりの時間がかかる場合があります。rsync内で同時ファイルアクセスがどのように処理されるか知っている人はいますか?
まったく処理されません。rsync はファイルを開き、可能な限り読み取り、それをコピーします。
したがって、アプリケーションがこれをどのように処理するかによって異なります。ファイルを書き換えるか (新しいファイルを作成しない)、または一時ファイルを作成し、すべてのデータが書き込まれたときにその名前を変更します (必要な場合)。
最初のケースでは、できることはほとんどありません。2 つのプロセスが同期を行わずに同じデータにアクセスすると、結果は混乱します。あなたができることは、書き込みプロセスが最終的にそれより前に終了すると仮定して、rsync を N 分間延期することです。この制限時間内にファイルが再度変更された場合は、ファイルを再スケジュールします。
2 番目のケースでは、一時ファイル (*.tmp、*~ など) を無視するように rsync に指示する必要があります。
一切取り扱っておりません。問題がある場合は、LVM スナップショットなどを使用して、スナップショットからバックアップを取得できます。それ自体では、ファイルが使用可能な状態になることは保証されませんが、その名前が示すように、特定の時点でのスナップショットであることは保証されます。
これは、rsync に変更検出自体を処理させているか、独自のアプリを使用しているかとは関係がないことに注意してください。アプリ、または rsync 自体は、変更されたファイルのリストを生成するだけで、各ファイルに対して rsync バイナリ diff アルゴリズムが実行されます。問題は、ファイル リストの生成時ではなく、rsync アルゴリズムの実行中にファイルが変更された場合です。