Restic: 大規模なプルーンをはるかに効率的に処理する

@ifedorenkoの順序が正しくないブランチによって解決された、大きなファイルを含む大きなリポジトリ/リポジトリの復元のパフォーマンスにより、これは、リポジトリがローカルにないマルチテラバイト環境でResticを使用するための次のボルダーのようです。ディスクであり、ループバックインターフェイス上のRESTサーバーを介してアクセスされていません。

現在、理論上の帯域幅が10gbit /秒のハイエンドAWSインスタンス上のAZローカルS3バケットのレポジトリに対して、空のプルーニング（以前のスナップショットと100％同一のスナップショットをプルーニング）は次のように実行されます。

1）新しいインデックスの構築-〜160パック/秒
2）まだ使用中のデータを見つける-合計56秒
3）パックの書き換え-〜3パック/秒

160パック/秒は遅いですが、それでも許容できます（3TBレポに対して約80分の実行時間）。

しかし、リライト@ 3パック/秒は、私のnoop pruneの場合でも、ほぼ10時間実行されます（0パックを削除して111098パックをリライトします。これにより、180.699 GiBが解放されます）。 大規模なリポジトリで意味のある整理を行うには、新しいバックアップを24時間以上フリーズします。

パックの書き換えは現在シングルスレッドで行われているようです。そのため、現在のコピーとパージのアプローチが維持されている場合でも、複数のワーカー間で実行できるようにすることは非常に役立つ場合があります。

個人的には、現在のブロッキングプルーンの実装を最適化することに時間を費やすことはありません。ノンブロッキングプルーンの方が長期的な解決策として優れていると思います。

私は最近これに取り組んでいます。 これが私がしたことです：

• すべてのパックをスキャンする代わりに、既存のインデックスをロードします（次に、インデックスに含まれていなかったパックをスキャンします）
• 使用済みブロブのスナップショットの並列スキャン
• 部分的に使用されたパックの並列書き換え
• すでにメモリにあるインデックス情報を使用して新しいインデックスを書き込みます

私は現在、部分的に使用されているパックの書き換えに使用する並列処理のレベルを把握するために取り組んでいます（これは、バックエンド用に構成された接続数に基づいて行う予定です）。 また、さまざまなエラーシナリオでさらに多くのテストを行う必要があります。

パフォーマンスの数値は次のとおりです（875 GiBのデータ、約180,000パック、36のスナップショットを含むリポジトリを使用し、バックエンドとしてループバックRESTサーバーを使用）。

• 現在のコード：
  
  
  
  • プルーンの開始時と終了時にインデックスを作成するために35〜40分（それぞれ）（合計70〜80分）
  
  
  • 使用済みのブロブを見つけるために4〜5分
  
  
  • 部分的に使用されたパックを書き換えるのに数秒
  
  
• これまでの私の変更：
  
  
  
  • 既存のインデックスをロードするのに数秒（インデックスのないパックをスキャンする必要がある場合は、もう少し長くなります）
  
  
  • 使用済みのブロブを見つけるために2分未満
  
  
  • 新しいインデックスを書き込むための数秒
  
  

また、さらに多くのパックの書き換えを伴う、生成されたテストケースを設定することも計画しています。

コートニー：

非常に有望に聞こえます！ これがあなたが働いているブランチであることを確認したいですか？ テストしてうれしいです。

https://github.com/cbane/restic/tree/prune-aggressive

いいえ、そのブランチはメインリポジトリからのフォークの一部です。 私はまだ自分の変更をどこにも公開していません。 作業中のバージョンを数日でGitHubにプッシュして、試してみることができるはずです。

OK、他の人が試してみる準備ができているバージョンがあります。 それはこのブランチにあります： https ：//github.com/cbane/restic/tree/prune-speedup

現在の制限：

• 再梱包作業員数の自動設定は実装していません。 今のところ、環境変数RESTIC_REPACK_WORKERSを使用するワーカーの数に設定します。 設定されていない場合、デフォルトで4になります。
• 再パックするときのエラー処理に取り組む必要があります。 既存のシングルスレッドの再パッキングから実際の変更は行いませんでした。 さまざまなエラーケースを調べて、再パックを並行して実行しても問題が発生しないことを確認する必要があります。

ええと、それはすごいですね。 お疲れ様でした！

私はこれをAmazonS3の3TB +リポジトリのコピーで少しテストしましたが、これまでのところ驚くべきものに見えます。 数週間かかっていた再パックの整理が1時間以内に完了するようになり、tmpスペースとして比較的遅いEBSを使用しています。

ここで本当のゲームチェンジャー！ 素晴らしい仕事、@ cbane！

ええと、私は実行のタイミングを間違えたことに気づきました。

まだシングルスレッドであり、並列化の恩恵を受ける可能性があると思われる領域の1つは、「インデックスにないパックのチェック」ステップです。これは、マルチテラバイトのリポジトリでは3〜4時間かかる場合がありますが、それでも大規模です。大幅な改善、ありがとうございます！

@cbane私はあなたのフォークに対して問題を開くことができなかったので、これらのためのより良い場所があるかどうか私に知らせてください。

別のテスト実行中に、再パックは最後に失敗し（最後のパックを書き換え）、32人のワーカーで実行されました。

found 1396709 of 2257203 data blobs still in use, removing 860494 blobs
will remove 0 invalid files
will delete 119301 packs and rewrite 88485 packs, this frees 896.269 GiB
using 32 repack workers
Save(<data/c136027b25>) returned error, retrying after 723.31998ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx. Retry again.
Save(<data/09d4692900>) returned error, retrying after 538.771816ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxxx. Retry again.
Save(<data/23d0d4f842>) returned error, retrying after 617.601934ms: client.PutObject: Put https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx: Connection closed by foreign host https://ak-logical-db-backup.s3.dualstack.us-west-1.amazonaws.com/xxxx. Retry again.
[10:02] 100.00%  88484 / 88485 packs rewritten
panic: reporting in a non-running Progress

goroutine 386596 [running]:
github.com/restic/restic/internal/restic.(*Progress).Report(0xc42011c2c0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0)
        internal/restic/progress.go:122 +0x242
github.com/restic/restic/internal/repository.Repack.func2(0x8, 0xe17f58)
        internal/repository/repack.go:66 +0x136
github.com/restic/restic/vendor/golang.org/x/sync/errgroup.(*Group).Go.func1(0xc4389246c0, 0xc56f509160)
        vendor/golang.org/x/sync/errgroup/errgroup.go:57 +0x57
created by github.com/restic/restic/vendor/golang.org/x/sync/errgroup.(*Group).Go
        vendor/golang.org/x/sync/errgroup/errgroup.go:54 +0x66

以前と同じブランチで、新しいバージョンを利用できます。 また、 masterに対してリベースしました。

以前のバージョンからの主な変更点は次のとおりです。

• 再梱包を、各ワーカーに単一のパックをパイプラインに再梱包するすべての段階で実行させることから変換しました。
• 再梱包の最後に報告されたクラッシュを修正しました。
• 再パックにより、CPUの数とバックエンドに構成された接続制限に基づいて、パイプラインステージのワーカー数が自動スケーリングされるようになりました。 （ RESTIC_REPACK_WORKERS環境変数は使用されなくなりました。）
• 使用済みのブロブを見つけるためのマイナーな調整。
• 不明なパックのスキャンを並列化しました。

使用済みのブロブを見つけるために、もう少し作業をしたいと思っています。 現在、各スナップショットは1人のワーカーによって処理されます。 これにより、CPUよりもスナップショットが少ない場合、またはスナップショット間に大きなサイズの違いがある場合、CPUリソースが未使用のままになる可能性があります。 サブツリー処理をさまざまなワーカーに分散させたいと思います。 私はこれを行う方法を知っていると思います、私は実際にそれを実装する必要があります。

私はこの問題（またはこれに対する将来のプルリクエスト）について引き続き議論することに傾倒し、すべてが分散するのではなく、ここにメインリポジトリにとどまるようにします。

テストしたばかりです。 再梱包の最後のクラッシュを解決し、本当に、本当にうまく機能します。

並列処理の増加から恩恵を受けることができる唯一の追加の場所は、現在シングルスレッドであるパックの削除です。

これは、以前はプルーニングできなかったレポの最初のプルーニング中に特に激しく噛み付きます。これは、削除が必要なパックが_たくさん_あるためです。

ただし、シングルスレッドの削除を行った場合でも、14.7kパックを書き換えて33kパックを削除する1.7TB、356kパックのリポジトリに対する毎日の忘却/削除には20分弱かかります。
以前は、剪定することはまったく不可能でした。

素晴らしい仕事、ありがとう！

OK、別のバージョンがあります。 今回の唯一の実際の変更は、未使用のパックを並行して削除することです（さらに、以前の変更にいくつかのマイナーな調整を加えました）。 変更されたスナップショットスキャンを実装しましたが、十分な速度が得られず、進行状況をユーザーに報告する良い方法がなかったため、再度削除しました。

何も壊れていないと仮定して、すぐにプルリクエストを開く予定です。 （ただし、最初に履歴をクリーンアップします。） @ fd0 、最初にこれを確認しますか？

私たちのテストランでうまくいきました。 225秒で30kパックを書き直し、50秒で73kパックを削除しました。

32個のスナップショットが残っているS3の1.74TiBリポジトリに対する合計実行時間は、6分強でした。

素晴らしい仕事。

@cbane私はあなたのブランチを試しましたhttps://github.com/cbane/restic/tree/prune-speedup

しかし、これは私が受け取るエラーです:(

root<strong i="9">@srv</strong> ~/restic-backups # restic --no-cache prune
repository 49b87c6a opened successfully, password is correct
listing files in repo
loading index for repo
[0:28] 1.01%  30 / 2982 index files
pack cbbebd8d already present in the index
github.com/restic/restic/internal/index.(*Index).AddPack
    internal/index/index.go:266
github.com/restic/restic/internal/index.Load.func1
    internal/index/index.go:230
github.com/restic/restic/internal/repository.(*Repository).List.func1
    internal/repository/repository.go:640
github.com/restic/restic/internal/backend.(*RetryBackend).List.func1.1
    internal/backend/backend_retry.go:133
github.com/restic/restic/internal/backend/rest.(*Backend).listv2
    internal/backend/rest/rest.go:423
github.com/restic/restic/internal/backend/rest.(*Backend).List
    internal/backend/rest/rest.go:358
github.com/restic/restic/internal/backend.(*RetryBackend).List.func1
    internal/backend/backend_retry.go:127
github.com/cenkalti/backoff.RetryNotify
    vendor/github.com/cenkalti/backoff/retry.go:37
github.com/restic/restic/internal/backend.(*RetryBackend).retry
    internal/backend/backend_retry.go:36
github.com/restic/restic/internal/backend.(*RetryBackend).List
    internal/backend/backend_retry.go:126
github.com/restic/restic/internal/repository.(*Repository).List
    internal/repository/repository.go:634
github.com/restic/restic/internal/index.Load
    internal/index/index.go:202
main.pruneRepository
    cmd/restic/cmd_prune.go:202
main.runPrune
    cmd/restic/cmd_prune.go:128
main.glob..func18
    cmd/restic/cmd_prune.go:28
github.com/spf13/cobra.(*Command).execute
    vendor/github.com/spf13/cobra/command.go:762
github.com/spf13/cobra.(*Command).ExecuteC
    vendor/github.com/spf13/cobra/command.go:852
github.com/spf13/cobra.(*Command).Execute
    vendor/github.com/spf13/cobra/command.go:800
main.main
    cmd/restic/main.go:86
runtime.main
    /snap/go/3947/src/runtime/proc.go:200
runtime.goexit
    /snap/go/3947/src/runtime/asm_amd64.s:1337

@antetnaリポジトリには、同じパックをカバーする複数のインデックスファイルがあるようです。 それがどのように発生するかはわかりませんが、テストスイートにテストケースを追加しました。エラーを再現できます。 修正に取り組みます。

@antetna OK、重複したインデックステストケースで機能する同じブランチ（早送りではない）に新しいバージョンをプッシュしました。 試していただけませんか？

他の誰かが問題に気づかない限り、私はこのブランチの現在のバージョンでプルリクエストをすぐに開くことを計画しています。

@cbaneありがとうございます！ 標準のプルーニングは、約860GBの12000+スナップショットリポジトリをプルーニングするのに約55時間かかりました。 より積極的な並列アプローチでは、3時間強に短縮されました。

ハウディ@cbane 、素晴らしい仕事！

Go1.12.1でコンパイルされたDebian9 amd64でこのPRを実行すると、30TBのリポジトリで220分実行すると、次のエラーが発生します。

checking for packs not in index
[0:52] 16.45%  178 / 1082 packs
[5:23] 100.00%  1082 / 1082 packs
repository contains 3213929 packs (259446787 blobs) with 15.025 TiB
processed 259446787 blobs: 30090 duplicate blobs, 4.906 GiB duplicate
load all snapshots
find data that is still in use for 3 snapshots
[0:04] 0.00%  0 / 3 snapshots
tree 6f144a19eaae0e81518b396bfdfc9dd5c6c035bdba28c6a90d6f70e692aa1c55 not found in repository
github.com/restic/restic/internal/repository.(*Repository).LoadTree
        internal/repository/repository.go:707
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:52
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func3
        internal/restic/find.go:74
github.com/restic/restic/internal/restic.FindUsedBlobs.func4
        internal/restic/find.go:89
gopkg.in/tomb%2ev2.(*Tomb).run
        vendor/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
        /usr/local/go/src/runtime/asm_amd64.s:1337

これからどのように回復する必要がありますか？

ありがとう、
-ドゥルバウ。

@DurvalMenezesリポジトリにいくつかのパックファイルがないようです。 以前に剪定したことがありますか？ restic check成功しますか？ そうでない場合は、何が問題なのかをより詳細に把握できるはずです。

restic rebuild-indexを実行してから新しいバックアップを実行することで、ある程度回復できる場合があります。 不足しているパックのいずれかがバックアップ対象の場所でまだ利用可能な場合は、新しいバックアップによってリポジトリに再度追加されます。 これにより、既存のバックアップが再び機能する可能性があります。 それでも問題が解決しない場合は、プルーニングを実行する前に、影響を受けたスナップショットを忘れる必要があると思います。

返信ありがとうございます、@ cbane。 詳細、以下：

以前に剪定したことがありますか？

いいえ、これは私の最初のプルーンです。 簡単に言うと、私のリポジトリには、NAS上の3つのローカルダートリーからの約95のスナップショットがあります。 これらの3つのダートリーは合計で約30TBおよび約60Mのファイル/サブディレクトリであり、バックアップに時間がかかり、24時間の新しいデータ（10GB未満）のバックアップの実行に24時間以上かかっていました。 フォーラムでのアドバイスは、 restic forget （最後の3つのスナップショットだけを残して実行しました）を実行し、次にrestic pruneを実行することでした。 OOMのため24時間）。 次に、マシン（Google Compute Cloud上のVM）をRAMの2倍にアップグレードしてから、PRを使用したところ、上記のエラーが発生しました。

レスティックチェックは成功しますか？ そうでない場合は、何が問題なのかをより詳細に把握できるはずです。

私は過去90時間（PRも使用して） restic checkを実行していますが、これまでのところ、次の出力が得られています： restic-check-PARTIAL_output.txt

上記のファイルの最後に記載されているように、 restic checkは3日以上前に最新のメッセージ（「スナップショット、ツリー、ブロブを確認してください」）を表示しています... ：-/実際、プロセスの「strace」は、同じローカルキャッシュファイルを何度も開いていることを示しています。

`` `日付; strace -t -f -p 2608 -e openat 2>＆1 | grep openat | egrep -v unfinished \ |再開| 頭
2019年7月23日火曜日00：41：59UTC
[pid 26508] 00:41:59 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 2608] 00:41:59 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 2615] 00:41:59 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 5482] 00:41:59 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 2615] 00:41:59 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 3688] 00:41:59 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 5482] 00:41:59 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 2608] 00:41:59 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 2638] 00:41:59 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 2638] 00:41:59 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b

And then, almost 10 hours later: 

2019年7月23日火曜日10：14：27UTC
[pid 2632] 10:14:27 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 2639] 10:14:28 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 2634] 10:14:28 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 2613] 10:14:28 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 2634] 10:14:28 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 3688] 10:14:28 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 2617] 10:14:28 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 3688] 10:14:28 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 2634] 10:14:28 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
[pid 2611] 10:14:28 openat（AT_FDCWD、 "/ tmp / restic-check-cache-370688148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b
`` `

resticrebuild-indexを実行してから新しいバックアップを実行することである程度回復できる場合があります。 不足しているパックのいずれかがバックアップ対象の場所でまだ利用可能な場合は、新しいバックアップによってリポジトリに再度追加されます。 これにより、既存のバックアップが再び機能する可能性があります

次にこれを試してみようと思います。 このrestic checkが24時間以内に終了しない場合は、SIGINTしてから、 restic rebuild-indexを実行します。 再構築インデックスには、このPRを使用する必要がありますか？ レスティックマスターヘッド？ または、他の何か？

再度、感謝します、
-ドゥルバウ。

ええ、それは有望に見えません。 おそらく最善の方法は、 restic rebuild-indexを実行してから、3つのディレクトリの新しいバックアップを実行してから、他のすべてのスナップショットを忘れることです。 その後、 restic pruneを正常に実行できるようになります。

rebuild-indexコードには触れなかったので、好きなバージョンでそれを行うことができます。

@cbane 、投稿を続けるために：私は5日前にあなたのPRを使用してrestic rebuild-indexを開始し（どのバージョンでもかまいませんが、あなたのバージョンを使用すると作業が簡単になります）、それ以来実行されています。 最初の数日間の絶望的な日（パーセンテージから推定すると、30日以上実行されることを示しているように見えた場合）、速度が上がったようで、あと10日ほど（少なくとも現在は）実行する必要があります。 「リポジトリ内のファイルのカウント」フェーズ）。

このrebuild-indexが正常に終了したと仮定すると、PRでrestic pruneを実行する計画です。 それがどうなるかをあなたに知らせます。

全員を最新の状態に保つ：無料の$ 300 GCloudクレジットが終了し、 pruneを実行するために作成しなければならなかった104GBのVMに完全に食い尽くされました（そして、おそらくrebuild-indexも）。 オプションが不足しています：-/この混乱から抜け出す方法を見つけたときに/更新します。

ブランチ「prune-speedup」を試してみましたが、結果は非常に有望です。

バックエンド：S3

# bin/restic version
restic 0.9.5 compiled with go1.12.4 on linux/amd64
# bin/restic prune
repository 6240cd5d opened successfully, password is correct
counting files in repo
building new index for repo
[1:30:34] 100.00%  319784 / 319784 packs
repository contains 319784 packs (5554019 blobs) with 1.445 TiB
processed 5554019 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 30 snapshots
[3:38:52] 100.00%  30 / 30 snapshots
found 5376708 of 5554019 data blobs still in use, removing 177311 blobs
will remove 0 invalid files
will delete 3526 packs and rewrite 4850 packs, this frees 26.925 GiB
[1:28:21] 100.00%  4850 / 4850 packs rewritten
counting files in repo
[1:20:27] 100.00%  314240 / 314240 packs
finding old index files
saved new indexes as [b7029105 797145b1 0ed8981e 7f19c455 dff4d9be a52d8e7a 0cf9f266 ab32a9e4 f34331b3 84c84cbb 563896c9 9902e35d 817ef96c 6b4dcfef 32d3e18c 1d782d96 b12554dd d4b69bcf 8ec94a43 66cbd035 8e9cb96d d74b5246 ca7d7ca3 1f209708 9fe26189 28414ee2 88ff07fb 24280466 8757a1f9 8706ff35 5fab942b 549409c3 f781a762 9417afec 4b2361aa 6b43f992 8da8dfe7 54ec498e 5be6fb8a 17411b83 270f3ce3 ba520d35 95913ad0 f8f15108 cbc67971 a419ff7c 875cfcc7 13f55ece bd488aa4 7f5b588a cddd40b4 7a79d1ce bd7e3d0f 2cdcd635 ee6e28c3 98146287 50867bde 41a056ae 836ce971 e9451c8b 0f9cc7e6 52dedc04 c4e8e7f6 2e4966f0 ba4fa5b3 ddc9a766 b995fd36 fd6b3ac8 1c12bcc3 4c98c3c9 39ac7cd5 42ebf4c1 1a48465e b5245192 73a73c5e daa6ee8d d26ce697 9f84d9b3 bc371def b141466a 6906b3c1 282ce115 d8024363 10f0b924 ad4fad64 9450aada 31378365 65d785b3 98b085d0 768f420c f22512b3 be3223ba 031d5488 f2b7fcf6 87177471 fd269664 b239b89e 6bf972ea 0d6f8f36 87362542 fff9c2cd 5c85ac76 f91daae1 dc594a83 220bdc83]
remove 1459 old index files
[2:33] 100.00%  8376 / 8376 packs deleted
done
# 

現在、開発バージョンでは：

# bin/restic_linux_amd64 version
restic 0.9.5-dev (compiled manually) compiled with go1.12.4 on linux/amd64
# bin/restic_linux_amd64 prune
repository 6240cd5d opened successfully, password is correct
counting files in repo
building new index for repo
[57:21] 100.00%  314240 / 314240 packs
repository contains 314240 packs (5376708 blobs) with 1.419 TiB
processed 5376708 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 29 snapshots
[1:48:18] 100.00%  29 / 29 snapshots
found 5356653 of 5376708 data blobs still in use, removing 20055 blobs
will remove 0 invalid files
will delete 212 packs and rewrite 1427 packs, this frees 3.114 GiB
[14:16] 100.00%  1427 / 1427 packs rewritten
counting files in repo
[57:47] 100.00%  313618 / 313618 packs
finding old index files
saved new indexes as [004d6eb2 630de131 1b85faed 0fb7a978 bc500e05 34f7d187 447c3b59 ada047d2 5430430e 768f606e a5c341ea a75059c5 71d0fbec c63f5c56 ba43e69d f47699f5 d7cd2587 5826bcae 6250ec67 6af77aa4 cbf8c1f9 a7809b5f c3242748 8bb7d037 8ca69481 5a8877c3 fb30ea48 4bdb6269 eeeba466 7cdc444a bc15ddd5 c5544612 b8a5004c 2879403a c33778b7 e692013a 41ce8a1d 55b4be0a 5714b820 1adca569 b06ccd6b 16467da7 79ed066a 64c7e397 43217ede af7350a4 73c65a0f 35260990 a232ea42 c843bfa5 332aded7 0e294517 26984755 3c36a14b 68b2024e 267bf0b2 a41c4f64 aa46affb c7a6e2ac 0d34c60f 766d21f0 0d7b8b41 4fea4363 a1a3c5cd 73809a0e 56a67410 25314d47 a32ded24 68feae36 78ef5cbb b051a740 6a51f900 d2ee860f 1ad44787 c6c4358d 89de2f69 a157bd2b 77995b94 3bc58934 b905be42 0a1df2e7 ba67a98c 263b5266 7a809abc 34ff6f07 d96adc12 8f69fc74 ebb053eb 8fb68f6a 11224e7d 990f61f8 764941fc ed95513b 1c17c8aa 3226a7cb 76988c78 e4d8f156 b4d4c952 8c379d51 e968f3c9 f9cfff55 464cf3e1 f9d23c32 136957e3 02e397b1]
remove 105 old index files
[0:32] 100.00%  1639 / 1639 packs deleted
done
#

大きな改善のようです！ おめでとう！
今後数週間でより多くのマシンを試してみると、より多くの結果を投稿します。

@fbarbeira投稿した出力から、実際には私の改良版を使用していないようです。 BackblazeB2で大きなリポジトリを整理したときに得られる出力は次のとおりです。

repository 399dfab1 opened successfully, password is correct
listing files in repo
loading index for repo
[0:02] 100.00%  71 / 71 index files
checking for packs not in index
repository contains 208840 packs (1675252 blobs) with 1006.203 GiB
processed 1675252 blobs: 0 duplicate blobs, 0 B duplicate
load all snapshots
find data that is still in use for 32 snapshots
[0:16] 100.00%  32 / 32 snapshots
found 1675113 of 1675252 data blobs still in use, removing 139 blobs
will remove 0 invalid files
will delete 4 packs and rewrite 24 packs, this frees 26.404 MiB
[3:31] 100.00%  24 / 24 packs rewritten
saving new index
[10:31] 70 index files
remove 71 old index files
[0:04] 100.00%  28 / 28 packs deleted
done

その主な速度低下の原因は、ケーブルモデムを介したアップロード速度の制限です。

restic versionからの出力も次のようになります。

restic 0.9.5 (v0.9.5-31-g09b92d6d) compiled with go1.11.6 on linux/amd64

このアップデート@ fd0をマージする意図はありますか？

この改善により、公式リリースにもなりますので、よろしくお願いいたします。 バックアップのローテーションが非常に遅くなったため、悲しいことに、resticはもはや実際にはオプションではなくなり始めています。

@cbane 、間違いなくブロッカーではないが、私がフラグを立てると考えた1つのアイテム：プルーンパックの書き換えは、リポジトリが大きくなるにつれて遅くなります。

たとえば、3,984,097パックレポのパックリライトステップは、同じAZ内のS3バケットと通信するi3.8xlargeで110パック/秒でパックをリライトします。

同じインスタンスとバッキングストアの組み合わせで、リポジトリが小さい（450,473）と、200パック/秒で書き換えられます。

@pmkane 、同じ数のパックを書き換えている場合でも、速度の違いはありますか？ それとも、いくつのパックが書き直されても、それは常にありますか？ また、それは単にパックの書き換えですか、それとも他のステージも遅くなりますか？

リポジトリが大きくなるにつれて速度が低下するコードには明らかなものは何もありません。 ローカルバージョンのパック書き換えステージにプロファイリングサポートを追加して、速度低下の原因を突き止めました。 ただし、私の最大のリポジトリは約200,000パックしかないため、表示されているものとの比較はできません。 プロファイリングを有効にして実行し、出力ファイルを利用できるようにしますか？

@cbane 、それがパックの数またはリポジトリのサイズの関数であるかどうかはわかりません。 小さいリポジトリの複製でいくつかのテストを実行して確認できます。 プロファイリングを使用してバージョンを実行し、結果を共有してください。

460kパックリポジトリのサンプルタイミング-3.7mmタイミングは次のとおりです。

リポジトリの読み込みインデックス
[0:01] 100.00％154/154インデックスファイル

36個のスナップショットにまだ使用されているデータを検索する
[0:34] 100.00％36/36スナップショット
[0:26] 100.00％4555/4555パックが書き直されました（175パック/秒）
[0:21] 151個のインデックスファイル
[0:01] 100.00％11401/11401パックが削除されました

3,752,505パックリポジトリ。 また、「14個のスナップショットにまだ使用されているデータを検索する」ステップで、メモリ使用量が最大1GBRSSから8GBRSSに膨れ上がることにも注意してください。 Resticは最終的に最大16GBのRSSになります。 リポジトリのサイズが大きいことを考えると、おそらく避けられません。

リポジトリの読み込みインデックス
[0:33] 100.00％1188/1188インデックスファイル

14個のスナップショットにまだ使用されているデータを検索する
[2:12] 100.00％14/14スナップショット
[49:07] 100.00％339187/339187パックが書き直されました（115パック/秒）
新しいインデックスを保存する
[10:59] 1176インデックスファイル
1188個の古いインデックスファイルを削除する
[4:51] 100.00％409728/409728パックが削除されました

@cbane 、お詫び申し上げます。 プルーン速度の赤いニシン-いくつかの独立したプロファイリングを行っていたときに、2つのリポジトリが異なるAZにあることに気づきました。そのため、違いは完全に、より遠いAZへの遅延の違いによるものでした。

大規模なリポジトリ（20.791TiB、40,522,693ブロブ）では、「まだ使用中のデータを検索する」ステップでプルーニング中に次のエラーが発生します。

ツリー5e40b6de93549df6443f55f0f68f24bf36671e28590579c78bc62f7557490c56がリポジトリに見つかりません
github.com/restic/restic/internal/repository。（リポジトリ）.LoadTreeinternal / repository / repository.go：711github.com/restic/restic/internal/restic.FindUsedBlobs.func3internal / restic / find.go：52github.com/restic/restic/internal/restic.FindUsedBlobs.func3internal / restic / find.go：74github.com/restic/restic/internal/restic.FindUsedBlobs.func4internal / restic / find.go：89gopkg.in/tomb%2ev2.(Tomb).run
ベンダー/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

すべてのバックアップが正常に完了し、resticチェックでエラーが返されることはありません。

ここで行う価値のある追加の掘り起こし、 @ cbane ？

再構築インデックスにより、プルーニングは成功しました。 プルーンをより回復力のあるものにする良い方法があるかどうかわからないので、問題をネイティブに処理できます。

うーん、今日も同じエラーが発生しました。 再構築インデックスで解決しましたが、プルーニング自体が問題を引き起こしているのではないかと考え始めています。 レスティックチェックは毎回きれいに戻ります。

ツリー7dc9112b587a2b67a2459e6badf7c14f986408e05dbe8a68e7458a30740ea951がリポジトリに見つかりません
github.com/restic/restic/internal/repository。（リポジトリ）.LoadTreeinternal / repository / repository.go：711github.com/restic/restic/internal/restic.FindUsedBlobs.func3internal / restic / find.go：52github.com/restic/restic/internal/restic.FindUsedBlobs.func3internal / restic / find.go：74github.com/restic/restic/internal/restic.FindUsedBlobs.func4internal / restic / find.go：89gopkg.in/tomb%2ev2.(Tomb).run
ベンダー/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

毎日のスポットファイルの復元を補完するために、バックアップの整合性を検証するために、週に1回完全な復元を実行します。

Resticチェックではバックアップに問題は見られませんでしたが、blobが欠落しているため、完全な復元は失敗します。 したがって、あるべきではない途中で何かが剪定された可能性があるように見えます。

それがスピードアップブランチのバグなのか、ベースプルーンコードのバグなのか、それとも完全に何か他のものなのかは不明です。 残念ながら、再現性の高いテストケースはありませんが、最大のレポでこのタイプのレポの破損が発生したのはこれが2回目です。 私たちの小さなリポジトリは問題を示していません。

残念ながら、リポジトリのサイズが原因で、ストックプルーンを使用したテストは不可能です。

今のところ、EBSスナップショットに戻りますが、この問題や他の問題を引き続き監視し、意味のある場所でテストできることを嬉しく思います。

状況を改善する小さなPR＃2507を追加しました。 これについていくつかのテストを実行していただければ幸いです...
ありがとう！

プルーニングコードの読み取り-再パックするとblobが読み取られ、新しいパックが順番に保存されます。 ネットワークを介して再梱包する場合は、それがボトルネックになります。

@DurvalMenezesは、ローカルネットワークまたはインターネット上のNASですか？ ローカルネットワーク上にある場合、wifiまたはイーサネット経由で接続しますか？

ブロブの読み取り/パックの保存をネットワークに並列化するのは簡単な方法のようです。

それとは別に、代わりにプルーンをインクリメンタルにしようとする方が良い戦略ではないかと思います。 複製の2ステップの化石コレクションのようなもの： https ：//github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

それとは別に、代わりにプルーンをインクリメンタルにしようとする方が良い戦略ではないかと思います。 複製の2ステップの化石コレクションのようなもの： https ：//github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

このトピックに関する議論については、＃1141を参照してください。

PR＃2513の2つの新しいコマンド「cleanup-index」と「cleanup-packs」も状況を大幅に改善するはずです。 これらのコマンドを使用すると、リポジトリが正常である場合、再パックせずに整理を実行できます。

そのため、誤って2つのことを実行しました。1時間ごとのバックアップを1回ではなく11回実行し、過去384日間ほど忘れたジョブを実行しませんでした。 101417のスナップショットがあります。 これを忘れたり、整理したりするには遅すぎると思いました。削除するだけだと思います。

＃2718を試してみることができますが、スナップショットを「忘れる」ことに対する改善はありません。
忘れるステップがあなたの悩みであるならば、私はあなたにアドバイスするでしょう：

• たとえば、最後のバックアップログを確認するか、別のバックアップを作成するなどして、保持するスナップショットを特定します。
• これらのファイルを除くすべてのファイルをリポジトリの/snapshotsディレクトリから手動で削除します
• その後、 pruneを実行します（＃2718が必要な場合）

数日間だけ保持するつもりだったので、S3のディレクトリ全体を削除して最初からやり直します。 私はforgetプロセスを開始しましたが、非常に長い時間がかかりました。新しいブランチが役立つか（そうではないように見えます）、少なくとも誰かがそれを面白いと思うかもしれないと思いました。

私は本当にこのブランチを試してみたいです（または、実際に、マスターにプルされたらいいのにと思います）。 私はテストして取得しようとしました

致命的：設定ファイルを開くことができません：統計：指定したAWSアクセスキーIDがレコードに存在しません。

マスタービルドを使用すると問題なく動作します。 また、 https：//github.com/restic/restic/pull/2340のブランチを問題なく使用できました。

NFSマウントされたリポジトリでこのブランチを使用できますが、AWSに保存されているリポジトリのみが機能していません。 トラブルシューティングの方法がわかりません...

関係なくすべての良い仕事に感謝します

@ vtwaldo21どのブランチを試しましたか？ ＃2718でしたか？
エラーメッセージは、AWSクレデンシャルに問題があることを示しています。 これは、NFSが問題なく機能した理由も説明している可能性があります。

他のresticコマンドはAWSリポジトリで機能しますか？

@aawsome 、私はばかで、ブランチ/イシュー番号を入れ替えて、本当に混乱しました。 ごめん。

ブランチ2718は問題なく機能しました（AWSとNFSがサポートするリポジトリの両方で）。 それがまだ実行されているので、私はそれがより速かったかどうかを明確に言うことはできません
ブランチ2340が問題を抱えていて、なぜ私がこのフォーラムスレッドに参加したのかを説明しました。

ブランチ2340は0.9.5ベースなので、少し古いですが、それほど悪くはありません。 私は次のような簡単なテストを行っていました。

Resticバイナリは、パスがRPM（0.9.6）を介してインストールされるだけです。

レスティックスナップショット
【作品】
restic.2718 / resticスナップショット
【作品】
restic.2340 / resticスナップショット
致命的：設定ファイルを開くことができません：統計：指定したAWSアクセスキーIDがレコードに存在しません。

したがって、エラーはAWSクレデンシャルに何かがあることを意味しますが、私は文字通り、変数を変更せずにコマンドを連続して実行しています。 このブランチには他に何か問題があるようです。

私のプルーンは2TBまでのレポに数日かかるので、2718と2340の両方がマスターにマージされることに非常に興味があります

@cbaneはあなたのすべての仕事に感謝します！ プルーンコードを作り直した＃2718をマージしました。これにより、この問題と＃2340が解決されると思います。

ご不便をおかけして申し訳ございません。お詫び申し上げます。 ：残念だった：

@MichaelEischerと話をしましたが、PR＃2340にはまだ実装されていないアイデアが含まれているとのことで、この問題を再開します。

@cbaneは、これらのアイデアを現在のコードにマージするために私たちと協力することに興味がありますか？ そうでない場合は完全に理解できます。それなら、私たちはあなたのPRを調べて、自分たちでそれらを抽出します:)

また、昨日は短い話し合いを行い、何がうまくいかなかったのかを特定しようとしたので、次回はもっとうまくやれるようになりました。 私たちが特定したいくつかのポイントは次のとおりです。

• PRは、コード内の非常に機密性の高い領域（prune、最終的にはデータを削除する）を変更したため、さらに精査する必要があります
• @MichaelEischerと@aawsomeがPRを確認しようとしましたが、大きすぎると言いました
• PRはたった2つのコミットで、そのうちの1つはすべてのコードを他の完全に異なるコードに置き換えました。これは、レビューするのが非常に困難です。
• PRには、少なくとも4〜5の異なるアイデアと改善が含まれていたため、レビューがさらに困難になりました。

私が逃した他の何か？

＃2340からcmd_prune.goへの変更は、＃2718によって完全に置き換えられ、 @ aawsomeによって＃2842に完全に取って代わられていることがわかります。 ＃3006は、index /index.goの変更も置き換えます。

checker.go （https://github.com/MichaelEischer/restic/tree/streamtreesを参照）から高度に並列化されたツリーウォーキングの実装を抽出しました。これにより、いくつかの並列FindUsedBlobsを実装できます。追加のコード行。 コピーコマンドにも再利用できます。 私が言及したブランチは、インデックスとスナップショットのロードを並列化するために使用されるコードも統合します。 ブランチをより小さなPRに分割します。

これにより、バックエンド接続数とGOMAXPROCSの使用が残り、＃2340の残りの部分としてIO / CPU並列処理に自動的に調整されるようです。

現在、＃2340も他のプルーニングPRも、書き換えられたインデックスのアップロードを並列化していないことに気づきました。