定期的にバックアップする164809ファイルがあります(約60GB)...「resticbackup」を実行するたびに、レポートは33MB / sを超えず、straceでチェックするとlstat()呼び出しのみが実行されます。
これにより、バックアップごとに約20分がレンダリングされます。 ほとんどすべてのファイルが変更されていないため、resticは何をしているのだろうか、安定した33MB /秒を示し、lstat()を実行するだけでよいことを理解しています。これは、バックアップの最初のステップでresticがすでに実行していることとまったく同じです。合計サイズ(6秒または7秒)。
同じファイル/タイムスタンプの内容をチェックするのに費やされたCPU時間は、以前のスナップショットにすでに存在していますか?
現時点では、ファイルとディレクトリのメタデータはキャッシュされませんが、リポジトリからロード(および復号化)されます。 これは、ディレクトリごとに1回実行されます。 メタデータをローカルにキャッシュすることを計画しています。これはまだ実装されていませんが、「増分」バックアップを大幅に高速化するはずです。
やあ
これにより、低速のWAN接続での増分バックアップのパフォーマンスが低下する可能性もありますか?
9000ファイルを超えるフォルダーと250MBのフォルダーをリモートのs3サーバーにバックアップしました。 両方のコンピューターは、上下に50/5 mbit/sの非対称インターネット接続で接続されています。
最初のバックアップには約5分かかり、かなり妥当なようでした。 しかし、その直後の2回目のバックアップには、ほぼ2倍の時間がかかりました。 ファイルが少ないフォルダの方がはるかに高速なようです。
はい、これがおそらく理由です。 この特定のユースケースには、回避策があります。 backup
コマンドに-f
( --force
)オプションを使用します。これにより、すべてのファイルがローカルで再度読み取られ、リポジトリからメタデータが読み込まれなくなります。 。 それは速いはずです。
どうもありがとうございました! チャームのように機能します!
マスターブランチにローカルメタデータキャッシュ(#1040を参照)を追加しました。この問題は解決されたと思うので、閉じます。 ありがとう!
最も参考になるコメント
はい、これがおそらく理由です。 この特定のユースケースには、回避策があります。
backup
コマンドに-f
(--force
)オプションを使用します。これにより、すべてのファイルがローカルで再度読み取られ、リポジトリからメタデータが読み込まれなくなります。 。 それは速いはずです。