web-dev-qa-db-ja.com

多数のファイルの完全バックアップまたは増分バックアップ

ファイルの量と合計サイズの両方で大量のファイルがあります。 (私たちは数テラバイトを話している)。これらのファイル/フォルダーを外部バックアップシステムに一度同期してから、毎日の変更に基づいてバックアップを再同期する毎日のタスクを実行したいと思います。変更はそれほど頻繁ではありませんが、日によっては約300GBの差分(約1.5Kファイルの場合)が発生する可能性があります。

私はいくつかのツールとしてrsyncまたはrdiff-backupまたはrsnapshotを検討してきましたが、最初にrsynchを使用していくつかのテストを実行したいと思っていました。私はrsyncで1つの大きな問題を抱えていました。それは:

既存のファイルの変更をチェックするのに時間がかかりすぎます。 20時間以上話しているので、毎日のバックアップは無意味です。これはrsync-rvhzPまたは-rvhPを使用しています。すべてのファイルをスキャンするだけのようで、ファイルが追加/変更/削除されていなくても、何時間もかかります。

私は何か間違ったことをしていますか?私が言及した他のシステム(rdiff-backupまたはrsnapshot)のいずれかがより良いパフォーマンスを発揮しますか?私はそれらがとにかくrsyncに基づいているという仮定の下で行っていました。

前もって感謝します。

追加情報で更新:約2600のディレクトリと合計約3.5TBの100kのファイルがあり、rsync version 3.0.9 protocol version 30を使用してテストを実行しました。毎日の変更に関しては、通常1日に10個のファイルの変更がありますが、約1.5Kのファイルの変更/追加/削除、および約300Gbのボリュームでピークに達する可能性があります(ただし、これらのピークはそれほど頻繁ではなく、一般的に広がります)

5
D.Mill

ソースファイルの変更タイムスタンプが正当である(そしてファイルが変更されると更新される)と仮定すると、時間を同期するために-t引数を追加することは理にかなっていると思います。 Quoth rsyncのマニュアルページ

-t、 -回
これは、rsyncにファイルと一緒に変更時間を転送し、リモートシステムでそれらを更新するように指示します。このオプションを使用しない場合、変更されていないファイルを除外する最適化は効果的ではないことに注意してください。つまり、-tまたは-aがない場合、次の転送は-Iを使用したかのように動作し、すべてのファイルが更新されます(ただし、rsyncのデルタ転送アルゴリズムにより、ファイルが更新されていない場合、更新はかなり効率的になります)実際に変更されたので、-tを使用する方がはるかに良いです)。

基本的に、rsyncがファイルの変更タイムスタンプをセンチネルとして使用して、ファイルが変更されたことを示すことができるという最適化が失われています。変更のタイムスタンプが送信者と受信者の間で一致しない場合、デルタコピーアルゴリズムが使用され、ファイルの内容がスキャンされます。あなたが話しているのと同じくらい大きいコーパスでは、あなたが見ているように、それは長いスキャンプロセスになるでしょう。

ファイルが変更されたときにファイルの変更タイムスタンプが更新されていない場合(何らかの奇妙な理由で)、これは効果的ではなく、ファイル全体をスキャンする必要があります。ソースファイルの変更タイムスタンプではなく、同期された日時を反映するリモートファイルの変更タイムスタンプが必要な場合、これも実行可能なソリューションではありません。

ただし、このオプションを使用すると、同期が根本的に高速化されると思います。

5
Evan Anderson

Lvmスナップショットと lvmsync を使用して、1つ下のレイヤーに移動することをお勧めします。

このソリューションでは、スナップショットは何が変更されたかを認識し、スキャンは必要ありません。欠点は、このソリューションがファイルを理解せず、ブロックを転送するだけであるということです。

もう1つの解決策は、inotifyを使用して、変更されたファイルの情報を格納するデーモンです。次に、リスト上のファイルのみをrsyncすることができます。 Lsyncd あなたが探しているソフトウェアのように見えます。

3
neutrinus