Restic: タイムスタンプをチェックしているだけですが、遅いです

作成日 2016年02月17日  ·  5コメント  ·  ソース: restic/restic

定期的にバックアップする164809ファイルがあります(約60GB)...「resticbackup」を実行するたびに、レポートは33MB / sを超えず、straceでチェックするとlstat()呼び出しのみが実行されます。

これにより、バックアップごとに約20分がレンダリングされます。 ほとんどすべてのファイルが変更されていないため、resticは何をしているのだろうか、安定した33MB /秒を示し、lstat()を実行するだけでよいことを理解しています。これは、バックアップの最初のステップでresticがすでに実行していることとまったく同じです。合計サイズ(6秒または7秒)。

同じファイル/タイムスタンプの内容をチェックするのに費やされたCPU時間は、以前のスナップショットにすでに存在していますか?

feature enhancement

最も参考になるコメント

はい、これがおそらく理由です。 この特定のユースケースには、回避策があります。 backupコマンドに-f--force )オプションを使用します。これにより、すべてのファイルがローカルで再度読み取られ、リポジトリからメタデータが読み込まれなくなります。 。 それは速いはずです。

全てのコメント5件

現時点では、ファイルとディレクトリのメタデータはキャッシュされませんが、リポジトリからロード(および復号化)されます。 これは、ディレクトリごとに1回実行されます。 メタデータをローカルにキャッシュすることを計画しています。これはまだ実装されていませんが、「増分」バックアップを大幅に高速化するはずです。

やあ

これにより、低速のWAN接続での増分バックアップのパフォーマンスが低下する可能性もありますか?

9000ファイルを超えるフォルダーと250MBのフォルダーをリモートのs3サーバーにバックアップしました。 両方のコンピューターは、上下に50/5 mbit/sの非対称インターネット接続で接続されています。

最初のバックアップには約5分かかり、かなり妥当なようでした。 しかし、その直後の2回目のバックアップには、ほぼ2倍の時間がかかりました。 ファイルが少ないフォルダの方がはるかに高速なようです。

はい、これがおそらく理由です。 この特定のユースケースには、回避策があります。 backupコマンドに-f--force )オプションを使用します。これにより、すべてのファイルがローカルで再度読み取られ、リポジトリからメタデータが読み込まれなくなります。 。 それは速いはずです。

どうもありがとうございました! チャームのように機能します!

マスターブランチにローカルメタデータキャッシュ(#1040を参照)を追加しました。この問題は解決されたと思うので、閉じます。 ありがとう!

このページは役に立ちましたか?
0 / 5 - 0 評価