大規模な rsync 転送をチャンク化しますか?

Question

弊社では、プライマリ ファイル サーバーのミラーをオフサイトの共存バックアップ サーバーに更新するために rsync を使用しています。現在抱えている問題の 1 つは、ファイル サーバーに 1 TB を超える、主に小さいファイル (10 ～ 100 KB の範囲) があり、これだけの量のデータを転送すると、転送開始から数時間後に接続が切断されてしまうことがよくあることです。rsync には、サーバーに再接続して中断したところから再開する再開/再試行機能がありません。ファイル比較プロセスを実行する必要があり、ファイルの量が多いため、非常に時間がかかります。

回避策として推奨されるのは、大規模な rsync 転送を一連の小さな転送に分割することです。これを行う最善の方法は、最上位ディレクトリ名の最初の文字を使用することだとわかりました。これでは完全に均等に分散されるわけではありませんが、十分です。

私がこれを実行するための方法論が妥当なものか、あるいは目標を達成するためのより簡単な方法があるかどうかを確認したいと思います。

これを実行するには、AZ、az、0-9を反復して1文字を選択します$prefix。最初は、

rsync -av --delete --delete-excluded --exclude "*.mp3" "src/$prefix*" dest/

(--exclude "*.mp3" は単なる例です。一時ファイルなどを削除するためのより長い除外リストがあります)

これの問題は、src に存在しない dest/ 内のトップレベル ディレクトリが --delete によって取得されないことです。この問題を回避するために、代わりに次のことを試しています。

rsync \
--filter 'S /$prefix*' \
--filter 'R /$prefix*' \
--filter 'H /*' \
--filter 'P /*' \
-av --delete --delete-excluded --exclude "*.mp3" src/ dest/

私は およびshowではhideなくを使用していますinclude。excludeそうしないと、--delete-excluded によって $prefix に一致しないものがすべて削除されてしまうからです。

これは、rsync を小さなチャンクに分割する最も効果的な方法でしょうか? これをより簡単にする、より効果的なツールや、私が見逃したフラグはありますか?

Answer 1

これに対する私の解決策は、ディスク領域をいくらか犠牲にする、異なる 2 パス アプローチでした。サーバー上で rsync --only-write-batch を実行し、次にバッチ ファイル自体を宛先に rsync し、rsync が成功するまでループします。バッチが完全に終了したら、宛先で rsync --read-batch を実行して、すべての変更を再作成します。

私にとって、これにはいくつか予期せぬ利点もあります。

• 私はバックアップが「使用可能」であることよりも「存在する」ことの方が心配なので、受信側で毎日読み取りバッチを実行するわけではありません。ほとんどの場合、バッチは比較的小さいです。

• --checksum-seed=1 を試しています... ドキュメントの読み間違いかもしれませんが、バッチ ファイルの同期性が向上すると思います (つまり、特定の日に --read-batch を実行しない場合、前日のバッチが適切な基準となるため、翌日のバッチの同期が速くなります)

• バッチが大きくなりすぎてインターネット経由で「時間内に」送信できない場合は、外付けドライブに忍び込んで送信できます。時間内にというのは、翌日のバックアップが始まる前にバッチを送信して読み取ることができない場合を意味します。

• 私は個人的にはこれを行いませんが、別々の場所に 2 つのオフサイト バックアップを用意し、両方にバッチを送信することができます。

Answer 2

質問に正確に答えているわけではありませんが、私がよく使用する別のオプションは、2 パス アプローチでこれを行うことです。最初にファイルのリストを作成し、次に転送するファイルのリストを分割して、ファイル リストを rsync/cpio/cp などに渡します。

rsync --itemize-changes <rest of options>転送されるファイルのリストが一連の便利なメタデータとともに出力されます。その出力からファイル名を抽出し、どちらかまたはrsync --files-from別のツールを使用して実際のコピーを実行するのは非常に簡単です。

あなたの状況には役立つかもしれません - 壊れた転送からの再開ははるかに速くなります。

Answer 3

別の「問題」を作り出して解決しようとするのではなく、接続の問題を注意深く調べることをお勧めします。

これは一般的な動作ではありません。SSH または rsyncd 経由で rsync を使用していますか?

私の知る限り、ほとんどの「閉じた」接続は、エンドポイント間でデータが転送されていないときに発生します。