Restic: 큰 자두를 훨씬 더 효율적으로 처리

@ifedorenko 의 비순차적 브랜치에 의해 해결된 대용량 파일이 있는 대용량 저장소/저장소에 대한 복원 성능을 통해 저장소가 로컬에 없는 멀티 테라바이트 환경에서 restic을 사용하기 위한 다음 볼더인 것 같습니다. 디스크에 있고 루프백 인터페이스에서 REST 서버를 통해 액세스되지 않습니다.

현재 이론적 대역폭이 10gbit/sec인 고급 AWS 인스턴스의 AZ-로컬 S3 버킷에 있는 리포지토리에 대한 빈 정리(이전 스냅샷과 100% 동일한 스냅샷 정리)는 다음 위치에서 실행됩니다.

1) 새 인덱스 구축 -- ~160팩/초
2) 아직 사용 중인 데이터 찾기 -- 총 56초
3) 팩 다시 쓰기 -- ~3 팩/초

160팩/초는 느리지만 여전히 견딜 수 있습니다(3TB 저장소에 대해 ~80분 실행 시간).

그러나 재작성 @ 3 packs/second는 내 noop prune의 경우에도 거의 10시간 동안 실행됩니다. 큰 리포지토리에서 의미 있는 정리를 위해 24시간 이상 동안 새 백업을 동결합니다.

팩 재작성은 현재 단일 스레드에서 발생하는 것 같으므로 현재 복사 후 제거 접근 방식이 유지되더라도 여러 작업자에 걸쳐 실행하도록 허용하면 상당한 도움이 될 수 있습니다.

개인적으로, 나는 현재 블로킹 프루닝 구현을 최적화하는 데 시간을 소비하지 않을 것입니다. 저는 비차단 프루닝이 더 나은 장기적 솔루션이라고 생각합니다.

나는 최근에 이것에 대해 작업하고 있습니다. 내가 한 일은 다음과 같습니다.

• 모든 팩을 스캔하는 대신 기존 인덱스를 로드한 다음 인덱스에 없는 팩을 스캔합니다.
• 사용된 Blob에 대한 스냅샷 병렬 스캔
• 부분적으로 사용된 팩 병렬 재작성
• 메모리에 이미 있는 인덱스 정보를 사용하여 새 인덱스 쓰기

저는 현재 부분적으로 사용된 팩을 다시 작성하는 데 사용할 병렬 수준을 파악하기 위해 노력하고 있습니다(백엔드에 대해 구성된 연결 수를 기반으로 할 계획입니다). 또한 다양한 오류 시나리오에서 더 많은 테스트를 수행해야 합니다.

다음은 몇 가지 성능 수치입니다(875GiB의 데이터, 약 180,000개의 팩, 36개의 스냅샷이 있는 저장소 사용, 백엔드로 루프백 나머지 서버 사용):

• 현재 코드:
  
  
  
  • 정리의 시작과 끝에서 인덱스를 작성하는 데 각각 35~40분(총 70~80분)
  
  
  • 사용된 얼룩을 찾는 데 4-5분
  
  
  • 부분적으로 사용된 팩을 다시 작성하는 데 몇 초
  
  
• 지금까지 내 변경 사항:
  
  
  
  • 기존 인덱스를 로드하는 데 몇 초(인덱싱되지 않은 팩을 검색해야 하는 경우 약간 더 오래)
  
  
  • 사용된 얼룩을 찾는 데 2분 미만
  
  
  • 새 색인을 작성하는 데 몇 초
  
  

또한 더 많은 팩 재작성을 포함하는 생성된 테스트 케이스를 설정할 계획입니다.

코트니:

매우 유망하게 들립니다! 현재 근무하고 있는 지점인지 확인하고 싶으십니까? 테스트하게 되어 기쁩니다.

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

아니요, 해당 분기는 주 리포지토리의 분기 부분입니다. 내 변경 사항을 아직 공개적으로 푸시하지 않았습니다. 며칠 내로 작업 중인 버전을 GitHub에 푸시할 수 있어야 시도해 볼 수 있습니다.

알겠습니다. 다른 사람들이 시험해 볼 수 있는 버전이 있습니다. 이 지점에 있습니다: https://github.com/cbane/restic/tree/prune-speedup

현재 제한 사항:

• 나는 재포장 작업자 수의 자동 설정을 구현하지 않았습니다. 지금은 환경 변수 RESTIC_REPACK_WORKERS를 사용하려는 작업자 수로 설정하십시오. 설정되지 않은 경우 기본값은 4입니다.
• 다시 포장할 때 오류 처리 작업을 해야 합니다. 기존 단일 스레드 재패킹에서 실제 변경 사항을 적용하지 않았습니다. 다양한 오류 사례를 살펴보고 병렬로 다시 포장해도 문제가 발생하지 않는지 확인해야 합니다.

굉장해 보이네요. 작업해주셔서 감사합니다!

나는 이것을 Amazon S3에서 3TB+ repo 사본으로 약간 테스트했으며 지금까지 놀랍습니다. 몇 주가 걸렸을 repack prune은 이제 1시간 이내에 완료되며, 이는 tmp 공간으로 상대적으로 느린 EBS를 사용합니다.

진정한 게임 체인저가 여기에 있습니다! 수고하셨습니다, @cbane!

에크, 나는 내가 달리기 시간을 잘못 잡았다는 것을 깨달았다.

여전히 단일 스레드이고 병렬화의 이점을 얻을 수 있는 것처럼 보이는 한 영역은 "인덱스에 없는 팩 확인" 단계입니다. 이 단계는 멀티 테라바이트 저장소에서 여전히 3-4시간이 걸릴 수 있습니다. 그러나 이것은 여전히 ​​큽니다. 엄청난 개선, 감사합니다!

@cbane 귀하의 포크에 대한 문제를 열 ​​수 없었으므로 이에 대한 더 나은 장소가 있는지 알려주세요.

다른 테스트 실행 중에 32명의 작업자와 함께 실행되는 마지막(마지막 팩 다시 쓰기)에서 repack이 실패했습니다.

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 에 대해 rebase했습니다.

이전 버전과의 주요 변경 사항은 다음과 같습니다.

• 각 작업자가 단일 팩을 파이프라인으로 재포장하는 모든 단계를 수행하도록 하는 재포장을 변환했습니다.
• 재포장이 끝날 때 보고된 충돌을 수정했습니다.
• 이제 Repacking은 CPU 수와 백엔드에 대해 구성된 연결 제한을 기반으로 파이프라인 단계의 작업자 수를 자동으로 조정합니다. ( RESTIC_REPACK_WORKERS 환경 변수는 더 이상 사용되지 않습니다.)
• 사용된 얼룩을 찾는 데 약간의 조정이 있습니다.
• 알 수 없는 팩의 스캔을 병렬화했습니다.

나는 여전히 사용된 얼룩을 찾는 일을 더 하고 싶습니다. 현재 각 스냅샷은 단일 작업자가 처리합니다. 이렇게 하면 CPU보다 스냅샷 수가 적거나 스냅샷 간에 큰 크기 차이가 있는 경우 CPU 리소스를 사용하지 않을 수 있습니다. 다른 작업자에게 하위 트리 처리를 분산시키고 싶습니다. 이 작업을 수행하는 방법을 알고 있다고 생각합니다. 실제로 구현하기만 하면 됩니다.

이 문제(또는 이에 대한 향후 pull request)에 대해 계속 논의하여 모든 것이 분산되는 대신 기본 저장소에 유지되도록 하고 싶습니다.

방금 테스트했습니다. 재포장이 끝날 때 충돌을 해결하고 정말 잘 작동합니다.

증가된 병렬 처리의 이점을 얻을 수 있는 유일한 추가 위치는 현재 단일 스레드인 팩을 삭제하는 것입니다.

이것은 삭제가 필요한 _lot_의 팩이 있기 때문에 이전에는 정리할 수 없었던 리포지토리의 첫 번째 정리 중에 특히 강하게 물립니다.

그러나 단일 스레드 삭제를 사용하더라도 14.7k 팩을 다시 작성하고 33k 팩을 삭제하는 1.7TB, 356k 팩 저장소에 대한 일일 삭제/정리 작업은 이제 20분 미만이 소요됩니다.
이전에는 가지치기가 전혀 불가능했습니다.

훌륭한 작품, 감사합니다!

알겠습니다. 다른 버전을 사용할 수 있습니다. 이번에 유일한 실제 변경 사항은 이제 사용하지 않는 팩을 병렬로 삭제한다는 것입니다(이전 변경 사항에 대한 약간의 조정). 수정된 스냅샷 스캔을 구현했지만 속도가 충분하지 않고 사용자에게 진행 상황을 보고할 수 있는 좋은 방법이 없어 다시 제거했습니다.

아무 문제가 없다고 가정하고 곧 이에 대한 풀 리퀘스트를 열 계획입니다. (그래도 히스토리를 먼저 정리하겠습니다.) @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 좋아, 방금 내 중복 인덱스 테스트 케이스에서 작동하는 동일한 분기(빨리 감기가 아님)에 새 버전을 푸시했습니다. 시도해 보시겠어요?

다른 사람이 문제를 인지하지 않는 한 곧 이 분기의 현재 버전으로 풀 리퀘스트를 열 계획입니다.

@cbane님 정말 감사합니다! 표준 정리는 ~860GB 12000+ 스냅샷 저장소를 정리하는 데 약 55시간이 걸렸습니다. 보다 적극적인 병렬 접근 방식을 사용하면 3시간 이상으로 단축되었습니다.

안녕하세요 @cbane , 멋진 작업입니다!

Go 1.12.1로 컴파일된 Debian 9 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 파일/하위 디렉토리이며 백업하는 데 점점 더 오래 걸리고 있어 10GB 미만의 새 데이터를 24시간 백업하는 데 24시간 이상이 걸립니다. 포럼의 조언은 restic forget (내가 한 마지막 3개의 스냅샷만 남김)를 실행한 다음 restic prune 를 실행하는 것이었습니다. OOM으로 인한 24시간). 그런 다음 머신(Google Compute Cloud의 VM)을 RAM의 두 배로 업그레이드한 다음 PR을 사용하여 위의 오류가 발생했습니다.

단순 검사가 성공합니까? 그렇지 않은 경우 무엇이 잘못되었는지에 대한 자세한 정보를 제공해야 합니다.

나는 지난 90시간 동안 restic check 를 실행 중이며(또한 귀하의 PR을 사용하여) 지금까지 다음과 같은 출력을 제공했습니다: restic-check-PARTIAL_output.txt

위 파일의 끝에 언급된 바와 같이 restic check 은(는) 3일 전에 최신 메시지("스냅샷, 나무 및 얼룩 확인")를 표시했습니다... 나는 그것이 멈춰서 결코 끝나지 않을지 궁금해지기 시작했습니다. :-/ 실제로 프로세스의 "추적"은 ​​동일한 로컬 캐시 파일을 계속해서 여는 것을 보여줍니다.

```날짜; strace -t -f -p 2608 -e openat 2>&1 | 그렙 오픈 | egrep -v 완료되지 않음\|재개됨 | 머리
2019년 7월 23일 화요일 00:41:59 UTC
0시 41분 59초 openat [26,508 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
0시 41분 59초 openat [2,608 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 10
0시 41분 59초 openat [2,615 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
0시 41분 59초 openat [5482 PID (, AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
0시 41분 59초 openat [2,615 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
0시 41분 59초 openat [3688 PID (, AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
0시 41분 59초 openat [5482 PID (, AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 10
0시 41분 59초 openat [2,608 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 11
0시 41분 59초 openat [2,638 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
0시 41분 59초 openat [2,638 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5

And then, almost 10 hours later: 

2019년 7월 23일 화요일 10:14:27 UTC
10시 14분 27초 openat [2,632 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
10시 14분 28초 openat [2,639 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
10시 14분 28초 openat [2,634 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
10시 14분 28초 openat [2,613 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
10시 14분 28초 openat [2,634 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
10시 14분 28초 openat [3688 PID (, AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
10시 14분 28초 openat [2,617 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
10시 14분 28초 openat [3688 PID (, AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
10시 14분 28초 openat [2,634 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
10시 14분 28초 openat [2,611 PID] (AT_FDCWD를 "/ TMP / restic 체크 - 캐시 370,688,148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / 데이터 / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d"O_RDONLY | O_CLOEXEC) = 5
```

Restic Rebuild-index를 실행한 다음 새 백업을 실행하면 어느 정도 복구할 수 있습니다. 누락된 팩의 항목이 백업 중인 위치에서 여전히 사용 가능한 경우 새 백업이 이를 리포지토리에 다시 추가합니다. 이렇게 하면 기존 백업이 다시 작동할 수 있습니다.

나는 이것을 다음에 시도할 것이라고 생각한다. restic check 이 다음 24시간 내에 완료되지 않으면 SIGINT한 다음 restic rebuild-index 를 실행합니다. 재구축 인덱스의 경우 이 PR을 사용해야 합니까? 레스틱 마스터 헤드? 또는 다른 것?

다시 한 번 감사합니다.
-- 더발.

예, 유망해 보이지 않습니다. 아마도 가장 좋은 방법은 restic rebuild-index 를 수행한 다음 세 디렉토리의 새 백업을 실행하고 다른 모든 스냅샷을 잊어버리는 것입니다. 그 후에 restic prune 를 성공적으로 수행할 수 있어야 합니다.

나는 rebuild-index 코드를 건드리지 않았으므로 원하는 버전으로 할 수 있습니다.

@cbane , 계속 알려드리기 위해: 저는 5일 전에 귀하의 PR을 사용하여 restic rebuild-index 를 시작했으며(모든 버전이 가능하다는 것을 이해하지만 귀하의 버전을 사용하면 작업이 더 간단해짐) 그 이후로 계속 실행되고 있습니다. 절망적인 처음 며칠 후(백분율을 외삽하여 30일 이상 실행될 것으로 표시한 경우), 속도가 어느 정도 상승한 것으로 보이며 10일 정도만 더 실행해야 합니다(최소한 현재 상태에서는 '리포지토리의 파일 계산' 단계).

이 rebuild-index 가 정상적으로 완료되었다고 가정하면 계획은 PR과 함께 restic prune 를 실행하는 것입니다. 어떻게 진행되는지 알려드립니다.

모든 사람을 최신 상태로 유지하기: prune rebuild-index 실행하기 위해 생성해야 했던 104GB VM에 의해 완전히 소모된 300달러의 무료 GCloud 크레딧이 종료되었습니다. 옵션이 부족합니다 :-/ 이 혼란에서 벗어날 방법을 찾으면 업데이트하겠습니다.

나는 "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 게시한 출력에서 ​​실제로 개선된 버전을 사용하지 않는 것 같습니다. 다음은 Backblaze B2에서 큰 저장소를 정리할 때 얻은 결과입니다.

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 , 확실히 차단기는 아니지만 플래그를 지정할 것이라고 생각한 항목 중 하나입니다. prune pack rewrites는 repos가 커질수록 느려집니다.

예를 들어, 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개의 스냅샷에 대해 아직 사용 중인 데이터 찾기" 단계에서 메모리 사용량이 ~1GB RSS에서 8GB RSS로 증가한다는 점도 주목할 가치가 있습니다. Restic은 결국 ~16GB RSS로 끝납니다. 큰 repo 크기를 감안할 때 피할 수 없는 것일 수 있습니다.

리포지토리에 대한 인덱스 로드
[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 , 죄송합니다. 정리 속도에 대한 붉은 청어 -- 독립적인 프로파일링을 수행할 때 두 개의 저장소가 서로 다른 AZ에 있다는 것을 발견했습니다.

대규모 저장소(20.791TiB, 40,522,693 blob)에서 "아직 사용 중인 데이터 찾기" 단계에서 정리하는 동안 다음 오류가 발생합니다.

나무 5e40b6de93549df6443f55f0f68f24bf36671e28590579c78bc62f7557490c56 저장소에서 찾을 수 없습니다
github.com/restic/restic/internal/repository.( 저장소).LoadTree내부/저장소/repository.go:711github.com/restic/restic/internal/restic.FindUsedBlobs.func3내부/중단/find.go:52github.com/restic/restic/internal/restic.FindUsedBlobs.func3내부/중단/find.go:74github.com/restic/restic/internal/restic.FindUsedBlobs.func4내부/중단/find.go:89gopkg.in/tomb%2ev2.( 무덤).run
공급업체/gopkg.in/tomb.v2/tomb.go:163
런타임.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

모든 백업이 성공적으로 완료되었으며 나머지 검사는 오류를 반환하지 않습니다.

여기서 할 가치가 있는 추가 파기, @cbane ?

재구축 색인을 통해 정리가 성공했습니다. prune을 더 탄력적으로 만드는 좋은 방법이 있는지 확실하지 않으므로 문제를 기본적으로 처리할 수 있습니다.

흠, 오늘 또 같은 오류가 발생했습니다. 재구축 인덱스로 해결되었지만 정리 자체가 문제를 일으키는지 궁금해지기 시작했습니다. 레스틱 체크는 매번 깨끗하게 돌아옵니다.

나무 7dc9112b587a2b67a2459e6badf7c14f986408e05dbe8a68e7458a30740ea951 저장소에서 찾을 수 없습니다
github.com/restic/restic/internal/repository.( 저장소).LoadTree내부/저장소/repository.go:711github.com/restic/restic/internal/restic.FindUsedBlobs.func3내부/중단/find.go:52github.com/restic/restic/internal/restic.FindUsedBlobs.func3내부/중단/find.go:74github.com/restic/restic/internal/restic.FindUsedBlobs.func4내부/중단/find.go:89gopkg.in/tomb%2ev2.( 무덤).run
공급업체/gopkg.in/tomb.v2/tomb.go:163
런타임.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

매주 한 번 전체 복원을 수행하여 백업 무결성을 확인하고 일일 스팟 파일 복원을 보완합니다.

나머지 검사는 백업에 문제를 표시하지 않았지만 누락된 Blob으로 인해 전체 복원이 실패합니다. 따라서 해서는 안 되는 방식으로 무언가가 정리된 것처럼 보입니다.

속도 향상 분기의 버그인지, 기본 정리 코드의 버그인지 아니면 완전히 다른 것인지 불분명합니다. 슬프게도 재현 가능한 훌륭한 테스트 케이스가 없지만 가장 큰 repo에서 이러한 유형의 repo 손상을 본 것은 이번이 두 번째입니다. 우리의 더 작은 repos는 어떤 문제도 보여주지 않았습니다.

불행히도 재고 정리로 테스트하는 것은 저장소의 크기로 인해 불가능합니다.

지금은 EBS 스냅샷으로 되돌릴 예정이지만 이 문제와 기타 문제를 계속해서 모니터링하고 어디가 합당한지 테스트하게 되어 기쁩니다!

상황을 개선해야 하는 작은 PR #2507을 추가했습니다. 몇몇 분들이 이것에 대해 몇 가지 테스트를 해 주시면 감사하겠습니다...
감사 해요!

정리 코드를 통해 읽기 - 재포장은 blob을 읽은 다음 새 팩을 연속적으로 저장합니다. 네트워크를 통해 재포장하는 경우 병목 현상이 발생합니다.

@DurvalMenezes 가 로컬 네트워크 또는 인터넷 상의 NAS입니까? 로컬 네트워크에서 Wi-Fi 또는 이더넷을 통해 연결합니까?

Blob 읽기/팩을 네트워크에 저장하는 것을 병렬화하는 것이 쉬운 승리인 것 같습니다.

이와는 별도로 프루닝(prune)을 점진적으로 하는 것이 더 나은 전략이 아닐까 싶습니다. 복제의 2단계 화석 수집과 같은 것: https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

이와는 별도로 프루닝(prune)을 점진적으로 하는 것이 더 나은 전략이 아닐까 싶습니다. 복제의 2단계 화석 수집과 같은 것: https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

이 주제에 대한 논의는 #1141을 참조하십시오.

PR #2513의 두 가지 새로운 명령인 'cleanup-index'와 'cleanup-packs'도 상황을 많이 개선할 것입니다. 이 명령을 사용하면 저장소가 정상인 경우 재포장하지 않고 정리를 수행할 수 있습니다..

그래서 저는 실수로 두 가지를 수행했습니다. 한 시간에 1번 대신 11번 시간당 백업을 실행했고 지난 384일 정도 동안 잊어버리기 작업을 실행하지 않았습니다. 101417개의 스냅샷이 있습니다. 이것을 잊거나 정리하기에는 너무 느릴 것이라고 생각했습니다. 그냥 삭제하려고 합니다.

#2718을 시도해 볼 수 있지만 스냅샷을 "잊어버리는" 개선 사항은 없습니다.
잊어 버리는 단계가 문제라면 다음과 같이 조언합니다.

• 예를 들어 마지막 백업 로그를 보거나 다른 백업을 만들어 보관하려는 스냅샷을 파악합니다.
• 저장소의 /snapshots 디렉토리에서 해당 파일을 제외한 모든 파일을 수동으로 삭제
• 그 후 prune 를 실행합니다(#2718로 원하는 경우).

며칠 동안만 보관하려고 했으므로 S3의 전체 디렉터리를 삭제하고 다시 시작하겠습니다. 나는 잊어 버리는 과정을 시작했고 그것은 매우 오랜 시간이 걸렸습니다. 나는 새로운 브랜치가 도움이 될 것이라고 생각했습니다 (그렇지 않은 것 같습니다). 아니면 최소한 누군가는 그것을 재미있다고 생각할 것입니다.

나는 정말로 이 브랜치를 시험해보고 싶다(또는 정말로, 그것이 마스터로 옮겨졌으면 한다). 테스트하고 가져오려고 했는데

치명적: 구성 파일을 열 수 없음: 통계: 제공한 AWS 액세스 키 ID가 당사 기록에 없습니다.

마스터 빌드를 사용하여 문제 없이 작동합니다. 또한 https://github.com/restic/restic/pull/2340 의 분기를 문제 없이 사용할 수 있었습니다.

NFS 탑재 리포지토리에서 이 분기를 사용할 수 있지만 AWS 저장 리포지토리만 작동하지 않습니다. 문제 해결 방법을 모르겠습니다...

상관없이 모든 좋은 작업에 감사드립니다

@vtwaldo21 어떤 브랜치를 사용해 보셨나요? #2718이었나?
오류 메시지는 AWS 자격 증명에 문제가 있음을 나타냅니다. 이것은 또한 NFS가 문제 없이 작동한 이유를 설명할 수 있습니다.

다른 restic 명령이 AWS 리포지토리에서 작동합니까?

@aawsome , 저는 바보이고 분기/문제 번호를 바꾸고 정말 혼란스러운 것입니다. 죄송합니다.

Branch 2718은 잘 작동했습니다(AWS 및 NFS 지원 리포지토리 모두에서). 아직 실행 중이기 때문에 더 빨랐는지 확실하게 말할 수는 없습니다.
Branch 2340은 문제가 있었고 내가 이 포럼 스레드에 있었던 이유입니다.

Branch 2340은 0.9.5 기반이므로 조금 오래되었지만 나쁘지 않습니다. 나는 다음과 같은 간단한 테스트를 하고 있었다.

restic 바이너리는 경로가 RPM(0.9.6)을 통해 설치됩니다.

간단한 스냅샷
[공장]
restic.2718/restic 스냅샷
[공장]
restic.2340/restic 스냅샷
치명적: 구성 파일을 열 수 없음: 통계: 제공한 AWS 액세스 키 ID가 당사 기록에 없습니다.

따라서 오류는 AWS 자격 증명과 관련된 것을 의미하지만 문자 그대로 변수 변경 없이 연속해서 명령을 실행하고 있습니다. 이 지점에 다른 문제가 있는 것 같습니다.

내 자두는 ~ 2TB 저장소에 며칠이 걸리므로 2718 및 2340이 모두 마스터에 병합되는 데 매우 관심이 있습니다.

@cbane 모든 작업에 감사드립니다! prune 코드를 재작업하는 #2718을 방금 병합했으며 #2340뿐만 아니라 이 문제도 해결했다고 생각합니다.

귀하의 기여를 처리한 방식에 대해 매우 유감스럽게 생각합니다. 제 사과를 받아 주셨으면 합니다. :실망한:

@MichaelEischer 와 이야기를 나눴는데, 그는 PR #2340에 아직 구현되지 않은 더 많은 아이디어가 포함되어 있다고 언급하여 이 문제를 다시 시작합니다.

@cbane 이러한 아이디어를 현재 코드에 병합하기 위해 우리와 협력하는 데 관심이 있습니까? 그렇지 않은 경우 완전히 이해할 수 있습니다. 그러면 귀하의 PR을 살펴보고 직접 추출하겠습니다. :)

우리는 또한 어제 짧은 토론을 하고 무엇이 잘못되었을 수 있는지 확인하여 다음에 더 잘할 수 있도록 노력했습니다. 우리가 식별한 몇 가지 사항은 다음과 같습니다.

• PR은 코드에서 매우 민감한 영역을 변경했으므로(궁극적으로 데이터를 제거하는 정리) 추가 조사가 필요합니다.
• @MichaelEischer 와 @aawsome 이 PR을 검토하려고 시도했는데 너무 큽니다.
• PR은 단지 두 개의 커밋이었고, 그 중 하나는 모든 코드를 완전히 다른 다른 코드로 대체했습니다. 이것은 검토하기가 매우 어렵습니다.
• PR에는 최소 4-5개의 서로 다른 아이디어와 개선 사항이 포함되어 있어 검토하기가 훨씬 더 어렵습니다.

내가 놓친 다른 것들이 있습니까?

#2340 에서 cmd_prune.go 에 대한 변경 사항은 내가 볼 수 있는 한 #2718 및 #2842 가 @aawsome 으로 완전히 대체되었습니다. #3006은 index/index.go 변경 사항도 대체합니다.

checker.go 에서 고도로 병렬화된 트리 워킹 구현을 추출했습니다(https://github.com/MichaelEischer/restic/tree/streamtrees 참조) FindUsedBlobs 추가 코드 줄. 복사 명령에도 재사용할 수 있습니다. 내가 언급한 분기는 인덱스 및 스냅샷 로드를 병렬화하는 데 사용되는 코드도 통합합니다. 지점을 더 작은 PR로 나눕니다.

그것은 백엔드 연결 수와 GOMAXPROCS의 사용을 #2340의 나머지 부분으로 IO/CPU 병렬 처리에 자동으로 조정하도록 남겨두는 것 같습니다.

나는 #2340이나 다른 prune PR이 현재 재작성된 인덱스의 업로드를 병렬화하지 않는다는 것을 알아차렸습니다.