Restic: menangani prune besar jauh lebih efisien

Dengan kinerja untuk pemulihan untuk repo/repo besar dengan file besar sekarang diselesaikan oleh cabang rusak @ifedorenko , sepertinya ini adalah batu berikutnya untuk menggunakan restic di lingkungan multi-terabyte di mana repo tidak berada di lokal disk dan tidak sedang diakses melalui server REST pada antarmuka loopback.

Saat ini, pemangkasan kosong (memangkas snapshot yang 100% identik dengan snapshot sebelumnya) terhadap repo di bucket S3 lokal AZ pada instans AWS kelas atas dengan bandwidth teoritis 10gbit/dtk berjalan pada:

1) membangun indeks baru -- ~160 bungkus/detik
2) menemukan data yang masih digunakan -- total 56 detik
3) menulis ulang paket -- ~3 paket/detik

160 paket/detik lambat, tetapi masih dapat ditoleransi (~80 menit run-time terhadap repo 3TB).

Tetapi penulisan ulang @ 3 paket/detik akan berjalan selama hampir 10 jam, bahkan untuk noop prune saya (akan menghapus 0 paket dan menulis ulang 111098 paket, ini membebaskan 180.699 GiB). Untuk pemangkasan yang berarti pada repo besar, Anda membekukan cadangan baru selama 24+ jam.

Sepertinya penulisan ulang paket saat ini terjadi dalam satu utas, sehingga memungkinkan untuk dijalankan di beberapa pekerja mungkin sedikit membantu, bahkan jika salinan saat ini maka pendekatan pembersihan dipertahankan.

Secara pribadi, saya tidak akan menghabiskan waktu untuk mengoptimalkan implementasi prune pemblokiran saat ini, saya pikir prune non-blocking adalah solusi jangka panjang yang lebih baik.

Saya telah mengerjakan ini baru-baru ini. Inilah yang telah saya lakukan:

• Muat indeks yang ada alih-alih memindai semua paket (lalu pindai semua paket yang tidak ada dalam indeks)
• Pemindaian snapshot secara paralel untuk gumpalan bekas
• Penulisan ulang paralel paket yang digunakan sebagian
• Tulis indeks baru menggunakan info indeks yang sudah ada di memori

Saat ini saya sedang bekerja untuk mengetahui tingkat paralelisme yang akan digunakan untuk menulis ulang paket yang digunakan sebagian (saya berencana untuk mendasarkan ini pada jumlah koneksi yang dikonfigurasi untuk backend). Saya juga perlu melakukan lebih banyak pengujian dalam berbagai skenario kesalahan.

Berikut adalah beberapa angka kinerja (menggunakan repositori dengan 875 GiB data, sekitar 180.000 paket, dan 36 snapshot, menggunakan server istirahat loopback sebagai backend):

• Kode saat ini:
  
  
  
  • 35-40 menit (masing-masing) untuk membangun indeks di awal dan akhir pemangkasan (total 70-80 menit)
  
  
  • 4-5 menit untuk menemukan gumpalan bekas
  
  
  • Beberapa detik untuk menulis ulang paket yang digunakan sebagian
  
  
• Perubahan saya sejauh ini:
  
  
  
  • Beberapa detik untuk memuat indeks yang ada (agak lama jika perlu memindai paket yang tidak diindeks)
  
  
  • Kurang dari 2 menit untuk menemukan gumpalan bekas
  
  
  • Beberapa detik untuk menulis indeks baru
  
  

Saya juga berencana untuk menyiapkan test case yang dihasilkan yang akan melibatkan lebih banyak penulisan ulang paket.

Courtney:

Kedengarannya sangat menjanjikan! Ingin mengonfirmasi bahwa ini adalah cabang tempat Anda bekerja? Saya senang untuk menguji.

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

Tidak, cabang itu adalah bagian dari garpu dari repositori utama. Saya belum mendorong perubahan saya ke publik. Saya seharusnya dapat mendorong versi pekerjaan saya yang sedang berlangsung ke GitHub dalam beberapa hari sehingga Anda dapat mencobanya.

Oke, saya punya versi yang harus siap untuk dicoba orang lain. Ada di cabang ini: https://github.com/cbane/restic/tree/prune-speedup

Batasan saat ini:

• Saya belum menerapkan pengaturan otomatis jumlah pekerja pengemasan ulang. Untuk saat ini, setel variabel lingkungan RESTIC_REPACK_WORKERS ke jumlah pekerja yang ingin Anda gunakan. Ini akan default ke 4 jika tidak disetel.
• Saya perlu memperbaiki penanganan kesalahan saat mengemas ulang. Saya tidak membuat perubahan nyata dari pengemasan ulang utas tunggal yang ada; Saya perlu memeriksa berbagai kasus kesalahan dan memastikan bahwa melakukan pengemasan ulang secara paralel tidak menyebabkan masalah.

Um, itu terlihat luar biasa. Terima kasih atas kerjamu!

Saya telah menguji ini sedikit dengan salinan repo 3TB+ di Amazon S3 dan sejauh ini terlihat luar biasa. Pemangkasan repack yang akan memakan waktu berminggu-minggu sekarang selesai dalam waktu kurang dari satu jam, dan itu menggunakan EBS yang relatif lambat sebagai ruang tmp.

Pengubah permainan nyata di sini! Kerja bagus, @cbane!

Eek, aku sadar aku salah waktu lari.

Satu area yang masih berulir tunggal dan sepertinya dapat mengambil manfaat dari paralelisasi adalah langkah "memeriksa paket yang tidak ada dalam indeks" -- yang masih dapat memakan waktu 3-4 jam dalam repo multi-terabyte -- tetapi ini masih merupakan masalah besar, peningkatan besar-besaran, terima kasih!

@cbane Saya tidak dapat membuka masalah terhadap garpu Anda, jadi beri tahu saya jika ada tempat yang lebih baik untuk ini.

Selama uji coba lain, pengemasan ulang gagal di bagian paling akhir (menulis ulang paket terakhir), berjalan dengan 32 pekerja:

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

Saya memiliki versi baru yang tersedia, di cabang yang sama seperti sebelumnya. Saya juga melakukan rebased terhadap master .

Berikut adalah perubahan utama dari versi sebelumnya:

• Mengonversi pengemasan ulang dari meminta setiap pekerja melakukan semua tahap pengemasan ulang satu paket ke saluran pipa.
• Memperbaiki kerusakan yang dilaporkan pada akhir pengemasan ulang.
• Pengemasan ulang sekarang otomatis menskalakan jumlah pekerja untuk tahapan pipeline berdasarkan jumlah CPU dan batas koneksi yang dikonfigurasi untuk backend. (Variabel lingkungan RESTIC_REPACK_WORKERS tidak lagi digunakan.)
• Tweak kecil untuk menemukan gumpalan bekas.
• Memparalelkan pemindaian paket yang tidak dikenal.

Saya masih ingin melakukan lebih banyak pekerjaan untuk menemukan gumpalan bekas. Saat ini, setiap snapshot diproses oleh satu pekerja. Ini dapat membuat sumber daya CPU tidak digunakan jika snapshot lebih sedikit daripada CPU, atau jika ada perbedaan ukuran besar di antara snapshot. Saya ingin itu menyebarkan pemrosesan sub-pohon di seluruh pekerja yang berbeda; Saya pikir saya tahu bagaimana melakukan ini, saya hanya perlu benar-benar menerapkannya.

Saya condong untuk terus membahas hal-hal tentang masalah ini (atau permintaan tarik di masa mendatang untuk ini), sehingga semuanya tetap di sini di repositori utama alih-alih menyebar.

Baru saja diuji. Ini menyelesaikan kerusakan pada akhir pengemasan ulang dan bekerja dengan sangat, sangat baik.

Satu-satunya tempat tambahan yang bisa mendapatkan keuntungan dari peningkatan paralelisme adalah penghapusan paket, yang saat ini berulir tunggal.

Ini menggigit sangat keras selama pemangkasan pertama dari repo yang sebelumnya tidak dapat dipangkas, karena ada _banyak_ paket yang perlu dihapus.

Namun, bahkan dengan penghapusan satu utas, lupa/pangkas setiap hari terhadap 1,7TB, repositori paket 356k yang menulis ulang paket 14,7k dan menghapus 33k paket sekarang hanya membutuhkan waktu kurang dari 20 menit.
Sebelumnya, tidak mungkin untuk memangkas sama sekali.

Kerja bagus, terima kasih!

Oke, saya punya versi lain yang tersedia. Satu-satunya perubahan nyata kali ini adalah sekarang menghapus paket yang tidak digunakan secara paralel (ditambah beberapa perubahan kecil pada beberapa perubahan sebelumnya). Saya menerapkan pemindaian snapshot yang dimodifikasi, tetapi tidak memberikan kecepatan yang cukup dan tidak ada cara yang baik untuk melaporkan kemajuan kepada pengguna, jadi saya menghapusnya lagi.

Saya berencana untuk membuka permintaan tarik untuk ini segera, dengan asumsi tidak ada yang rusak. (Saya akan membersihkan sejarahnya terlebih dahulu.) @fd0 , apakah Anda ingin melihat ini terlebih dahulu?

Bekerja dengan baik dalam uji coba kami. Menulis ulang paket 30rb dalam 225 detik, menghapus 73rb paket dalam 50 detik.

Total runtime terhadap repo 1,74TiB di S3 dengan 32 snapshot yang bertahan hanya lebih dari 6 menit.

Pekerjaan yang brilian.

@cbane Saya mencoba cabang Anda https://github.com/cbane/restic/tree/Prune-speedup

tapi ini adalah kesalahan yang saya terima :(

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 Sepertinya repositori Anda memiliki beberapa file indeks yang mencakup paket yang sama. Saya tidak tahu bagaimana itu bisa terjadi, tetapi saya telah menambahkan kasus uji untuk itu ke rangkaian pengujian, dan saya dapat mereproduksi kesalahan Anda. Saya akan bekerja untuk memperbaikinya.

@antetna OK, saya baru saja mendorong versi baru ke cabang yang sama (tidak maju cepat) yang berfungsi dengan kasus uji indeks duplikat saya. Bisakah Anda mencobanya?

Saya berencana untuk segera membuka permintaan tarik dengan versi saat ini dari cabang ini, kecuali ada orang lain yang melihat ada masalah.

Terima kasih banyak @cbane! Pemangkasan standar membutuhkan waktu sekitar ~55 jam untuk memangkas repo snapshot ~860GB 12000+ saya. Dengan pendekatan paralel Anda yang lebih agresif, itu menurunkannya menjadi lebih dari 3 jam.

Halo @cbane , kerja yang luar biasa!

Menjalankan PR ini di Debian 9 amd64, dikompilasi dengan Go 1.12.1, mendapatkan kesalahan berikut setelah 220 menit berjalan pada repo 30TB saya:

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

Bagaimana saya harus pulih dari ini?

Terima kasih,
-- Durval.

@DurvalMenezes Sepertinya repositori Anda kehilangan beberapa file paket. Sudahkah Anda memangkasnya sebelumnya? Apakah restic check berhasil? Jika tidak, itu akan memberi Anda gambaran yang lebih rinci tentang apa yang salah.

Anda mungkin dapat memulihkan sedikit dengan menjalankan restic rebuild-index dan kemudian menjalankan cadangan baru. Jika apa pun dalam paket yang hilang masih tersedia di lokasi yang dicadangkan, cadangan baru akan menambahkannya ke repositori lagi. Ini mungkin membuat cadangan Anda yang ada berfungsi kembali. Jika itu tidak memperbaikinya, saya pikir Anda harus melupakan snapshot yang terpengaruh sebelum Anda dapat melakukan pemangkasan.

Terima kasih atas jawabannya, @cbane. Lebih lanjut, di bawah ini:

Sudahkah Anda memangkasnya sebelumnya?

Tidak, ini adalah pangsit pertama saya. Singkat cerita: repo saya memiliki ~95 snapshot dari 3 kotoran lokal di NAS saya; total 3 file kotor tersebut ~30TB dan ~60M file/subdir, dan telah memakan waktu lebih lama dan lebih lama untuk mencadangkan, sampai-sampai mencadangkan hanya 24 jam data baru (di bawah 10GB) membutuhkan waktu lebih dari 24 jam untuk dijalankan. Saran di forum adalah menjalankan restic forget (yang saya lakukan, hanya menyisakan 3 snapshot terakhir) dan kemudian restic prune , yang saya lakukan pertama kali menggunakan restic 0.9.5 (tetapi dibatalkan setelah ~ 24 jam karena OOM). Saya kemudian memutakhirkan mesin (VM di Google Compute Cloud) menjadi dua kali RAM, dan kemudian menggunakan PR Anda, yang memberikan kesalahan di atas.

Apakah restic check berhasil? Jika tidak, itu akan memberi Anda gambaran yang lebih rinci tentang apa yang salah.

Saya menjalankan restic check selama 90 jam terakhir (juga menggunakan PR Anda), dan sejauh ini memberi saya hasil ini: restic-check-PARTIAL_output.txt

Seperti yang disebutkan di akhir file di atas, restic check telah menampilkan pesan terbarunya ("periksa foto, pohon, dan gumpalan") selama 3 hari yang lalu... Saya mulai bertanya-tanya bahwa pesan ini macet dan tidak akan pernah selesai :-/ Faktanya, sebuah "strace" pada proses menunjukkannya membuka file cache lokal yang sama berulang-ulang:

```tanggal; strace -t -f -p 2608 -e buka di 2>&1 | grep openat | egrep -v belum selesai\|dilanjutkan | kepala
Sel 23 Jul 00:41:59 UTC 2019
[Pid 26.508] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2608] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 10
[Pid 2615] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 5482] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2615] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 3688] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 5482] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 10
[Pid 2608] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 11
[Pid 2638] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5
[Pid 2638] 00:41:59 openat (AT_FDCWD, "/ tmp / restic-check-cache-370.688.148 / abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2 / data / 53 / 53d242f8d6444bc2bd49e6689b4c7688fec8996c5e86863bf146a9eb28f54b5d", O_RDONLY | O_CLOEXEC) = 5

And then, almost 10 hours later: 

Sel 23 Jul 10:14:27 UTC 2019
[5bCpid 2632] 10:14:27 terbuka(AT_FDCWD, "/tmp/restic-check-cache-370688148/abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/data/53/53d242f8d6444bcd0r3rd895ECLY)
[5bCpid 2639] 10:14:28 buka(AT_FDCWD, "/tmp/restic-check-cache-370688148/abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/data/53/53d242f8d6444bccd0e4dbe10d29a2/data/53/53d242f8d6444bc
[5bCpid 2634] 10:14:28 buka(AT_FDCWD, "/tmp/restic-check-cache-370688148/abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/data/53/53d242f8d6444bcd0r3RD891ECY/data/53/53d242f8d6444bc
[5bCpid 2613] 10:14:28 buka(AT_FDCWD, "/tmp/restic-check-cache-370688148/abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/data/53/53d242f8d6444bccd0e4dbe10d29a2/data/53/53d242f8d6444bcly
[5bCpid 2634] 10:14:28 buka(AT_FDCWD, "/tmp/restic-check-cache-370688148/abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/data/53/53d242f8d6444bcd0r3RD891ECY/data/53/53d242f8d6444bc
[5bCpid 3688] 10:14:28 buka(AT_FDCWD, "/tmp/restic-check-cache-370688148/abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/data/53/53d242f8d6444bcd0r4895ECLY2/data/53/53d242f8d6444bc
[5bCpid 2617] 10:14:28 buka(AT_FDCWD, "/tmp/restic-check-cache-370688148/abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/data/53/53d242f8d6444bccd0e4dbe10d29a2/data/53/53d242f8d6444bc
[5bCpid 3688] 10:14:28 buka(AT_FDCWD, "/tmp/restic-check-cache-370688148/abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/data/53/53d242f8d6444bcd0r4895ECLY2/data/53/53d242f8d6444bc
[5bCpid 2634] 10:14:28 buka(AT_FDCWD, "/tmp/restic-check-cache-370688148/abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/data/53/53d242f8d6444bcd0r3RD891ECY/data/53/53d242f8d6444bc
[5bCpid 2611] 10:14:28 buka(AT_FDCWD, "/tmp/restic-check-cache-370688148/abb62ab49b950e4b2ab5eb82c4386a9b199a08eb6fd93bdaccd0e4dbe10d29a2/data/53/53d242f8d6444bcd0r285ECLY"
```

Anda mungkin dapat memulihkan sedikit dengan menjalankan indeks pembangunan kembali restic dan kemudian menjalankan cadangan baru. Jika apa pun dalam paket yang hilang masih tersedia di lokasi yang dicadangkan, cadangan baru akan menambahkannya ke repositori lagi. Ini mungkin membuat cadangan Anda yang ada berfungsi kembali

Saya pikir saya akan mencoba ini selanjutnya; jika restic check ini tidak selesai dalam 24 jam ke depan, saya akan MENDAFTAR dan kemudian menjalankan restic rebuild-index . Untuk indeks pembangunan kembali, haruskah saya menggunakan PR ini? Kepala istirahat-master? Atau sesuatu yang lain?

Terima kasih lagi,
-- Durval.

Ya, itu tidak terlihat menjanjikan. Mungkin hal terbaik yang harus dilakukan adalah melakukan restic rebuild-index , lalu menjalankan pencadangan baru dari tiga direktori Anda, dan kemudian melupakan semua snapshot lainnya. Setelah itu, Anda harus berhasil melakukan restic prune .

Saya tidak menyentuh kode rebuild-index , jadi Anda dapat melakukannya dengan versi apa pun yang Anda inginkan.

@cbane , hanya untuk membuat Anda tetap diposting: Saya memulai restic rebuild-index menggunakan PR Anda 5 hari yang lalu (saya mengerti versi apa pun bisa dilakukan, tetapi menggunakan milik Anda membuat segalanya lebih sederhana) dan itu telah berjalan sejak itu. Setelah beberapa hari putus asa pertama (ketika mengekstrapolasi dari persentase tampaknya menunjukkan itu akan berjalan selama lebih dari 30 hari), tampaknya telah mengambil beberapa kecepatan dan harus berjalan untuk 'hanya' 10 hari lagi atau lebih (setidaknya di saat ini 'menghitung file dalam fase repo').

Anggap rebuild-index ini selesai dengan baik, rencananya adalah menjalankan restic prune dengan PR Anda. Akan memberi tahu Anda bagaimana kelanjutannya.

Menjaga semua orang tetap up-to-date: kredit $300 GCloud gratis saya berakhir, benar-benar habis oleh VM 104GB yang harus saya buat untuk menjalankan prune (dan, saya kira, juga rebuild-index ). Saya kehabisan opsi :-/ Akan memperbarui ketika/jika saya menemukan jalan keluar dari kekacauan ini.

Saya mencoba cabang "prune-speedup" dan hasilnya sangat menjanjikan!

Latar Belakang: 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
# 

Sekarang dengan versi dev:

# 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
#

Sepertinya peningkatan besar! Selamat!
Saya akan memposting lebih banyak hasil jika saya mencoba lebih banyak mesin dalam beberapa minggu mendatang.

@fbarbeira Dari output yang Anda posting, sepertinya Anda tidak benar-benar menggunakan versi saya yang lebih baik. Inilah output yang saya dapatkan ketika saya memangkas repositori besar saya di 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

Sumber utama kelambatan itu adalah kecepatan unggah yang terbatas melalui modem kabel saya.

Output dari restic version juga akan terlihat seperti ini:

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

Ada niat untuk menggabungkan pembaruan ini @ fd0 ?

Saya akan sangat menghargai peningkatan ini membuatnya menjadi rilis resmi juga. Rotasi cadangan menjadi sangat lambat sehingga restic mulai tidak lagi menjadi pilihan, sayangnya.

@cbane , satu item yang jelas bukan pemblokir tetapi saya pikir saya akan menandai: penulisan ulang paket prune menjadi lebih lambat saat repo tumbuh.

Misalnya, langkah penulisan ulang paket untuk repo paket 3.984.097 menulis ulang paket pada 110 paket/detik pada i3.8xlarge yang berbicara dengan bucket S3 di AZ yang sama.

Instans yang sama + kombo penyimpanan cadangan dengan repo yang lebih kecil (450.473) ditulis ulang dengan kecepatan 200 bungkus/detik.

@pmkane , apakah perbedaan kecepatan itu ada meskipun mereka menulis ulang jumlah paket yang sama? Atau selalu ada tidak peduli berapa banyak paket yang sedang ditulis ulang? Juga, apakah itu hanya penulisan ulang paket, atau apakah tahapan lain juga melambat?

Tidak ada yang jelas dalam kode yang akan memperlambatnya saat repositori semakin besar. Saya telah menambahkan dukungan pembuatan profil ke tahap penulisan ulang paket di versi lokal saya untuk membantu melacak sumber kelambatan. Namun, repositori terbesar saya hanya sekitar 200.000 paket, yang tidak memberikan perbandingan yang baik untuk apa yang Anda lihat. Apakah Anda bersedia menjalankannya dengan profil yang diaktifkan dan membuat file keluaran tersedia?

@cbane , tidak yakin apakah itu fungsi dari jumlah paket atau ukuran repo. Saya dapat menjalankan beberapa tes pada duplikat repo kami yang lebih kecil dan melihatnya. Senang menjalankan versi dengan pembuatan profil dan membagikan hasilnya.

Beberapa contoh pengaturan waktu untuk repo paket 460k -- pengaturan waktu 3.7mm berikut:

memuat indeks untuk repo
[0:01] 100,00% 154 / 154 file indeks

temukan data yang masih digunakan untuk 36 snapshot
[0:34] 100,00% 36 / 36 cuplikan
[0:26] 100,00% 4555 / 4555 paket ditulis ulang (175 paket/detik)
[0:21] 151 file indeks
[0:01] 100,00% 11401 / 11401 paket dihapus

3.752.505 paket repo. Perlu juga dicatat bahwa penggunaan memori meningkat dari ~1GB RSS ke RSS 8GB dalam langkah "temukan data yang masih digunakan untuk 14 snapshot". Restic akhirnya berakhir di ~ 16GB RSS. Mungkin tidak dapat dihindari, mengingat ukuran repo yang besar:

memuat indeks untuk repo
[0:33] 100,00% 1188 / 1188 file indeks

temukan data yang masih digunakan untuk 14 snapshot
[2:12] 100,00% 14 / 14 cuplikan
[49:07] 100,00% 339187 / 339187 paket ditulis ulang (115 paket/detik)
menyimpan indeks baru
[10:59] 1176 file indeks
hapus 1188 file indeks lama
[4:51] 100,00% 409728 / 409728 paket dihapus

@cbane , saya minta maaf. Ikan haring merah pada kecepatan pemangkasan -- ketika saya melakukan beberapa pembuatan profil independen, saya melihat bahwa kedua repo berada di AZ yang berbeda, jadi perbedaannya sepenuhnya karena latensi yang berbeda ke AZ yang lebih jauh.

Dalam repo besar kami (20.791TiB, 40.522.693 gumpalan), kami mendapatkan kesalahan berikut saat memangkas dalam langkah "temukan data yang masih digunakan":

pohon 5e40b6de93549df6443f55f0f68f24bf36671e28590579c78bc62f7557490c56 tidak ditemukan dalam repositori
github.com/restic/restic/internal/repository.( Repositori).LoadTreeinternal/repositori/repositori.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.( Makam).run
vendor/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

semua pencadangan berhasil diselesaikan dan pemeriksaan restic tidak mengembalikan kesalahan apa pun.

Adakah penggalian tambahan yang layak dilakukan di sini, @cbane ?

Indeks pembangunan kembali memungkinkan pemangkasan berhasil. Tidak yakin apakah ada cara yang baik untuk membuat prune lebih tangguh, sehingga bisa mengatasi masalah secara asli.

Hmm, mendapat kesalahan yang sama lagi hari ini. Diselesaikan dengan indeks pembangunan kembali, tetapi saya mulai bertanya-tanya apakah prune itu sendiri yang menyebabkan masalah. Sebuah cek restic kembali bersih setiap kali.

pohon 7dc9112b587a2b67a2459e6badf7c14f986408e05dbe8a68e7458a30740ea951 tidak ditemukan dalam repositori
github.com/restic/restic/internal/repository.( Repositori).LoadTreeinternal/repositori/repositori.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.( Makam).run
vendor/gopkg.in/tomb.v2/tomb.go:163
runtime.goexit
/usr/lib/golang/src/runtime/asm_amd64.s:1337

Kami melakukan pemulihan penuh seminggu sekali untuk memverifikasi integritas cadangan, untuk melengkapi pemulihan file spot harian.

Meskipun pemeriksaan restic tidak menunjukkan masalah apa pun dengan pencadangan, pemulihan penuh gagal karena gumpalan yang hilang. Jadi sepertinya ada sesuatu yang dipangkas di sepanjang jalan yang seharusnya tidak terjadi.

Tidak jelas apakah itu bug di cabang speedup, sesuatu di kode pangkas dasar atau yang lainnya sama sekali. Sayangnya, saya tidak memiliki kasus uji yang dapat direproduksi, tetapi ini adalah kedua kalinya kami melihat jenis korupsi repo ini dengan repo terbesar kami. Repo kami yang lebih kecil tidak menunjukkan masalah apa pun.

Sayangnya pengujian dengan stock prune tidak mungkin, karena ukuran repo.

Kami akan kembali ke snapshotting EBS, untuk saat ini, tetapi akan terus memantau masalah ini dan lainnya dan dengan senang hati menguji di mana itu masuk akal!

Saya menambahkan PR kecil #2507 yang seharusnya memperbaiki situasi. Saya akan sangat menghargai jika beberapa dari Anda dapat menjalankan beberapa tes ini ...
Terima kasih!

Membaca kode prune - pengemasan ulang membaca gumpalan dan kemudian menyimpan paket baru secara serial. Jika Anda mengemas ulang melalui jaringan, itu akan menjadi hambatan.

@DurvalMenezes apakah NAS Anda di jaringan lokal atau melalui internet? Jika di jaringan lokal apakah Anda terhubung melalui wifi atau ethernet?

Sepertinya kemenangan yang mudah adalah dengan memparalelkan gumpalan bacaan / menyimpan paket ke jaringan.

Secara terpisah, saya bertanya-tanya apakah strategi yang lebih baik adalah mencoba dan membuat pemangkasan tambahan sebagai gantinya. Sesuatu seperti koleksi fosil dua langkah duplikat: https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

Secara terpisah, saya bertanya-tanya apakah strategi yang lebih baik adalah mencoba dan membuat pemangkasan tambahan sebagai gantinya. Sesuatu seperti koleksi fosil dua langkah duplikat: https://github.com/gilbertchen/duplicacy/wiki/Lock-Free-Deduplication#two -step-fossil-collection

Silakan lihat #1141 untuk diskusi tentang topik ini.

Dua perintah baru 'cleanup-index' dan 'cleanup-packs' dari PR #2513 juga harus banyak memperbaiki situasi. Dengan perintah ini Anda dapat melakukan pemangkasan tanpa mengemas ulang jika repo Anda waras..

Jadi saya tidak sengaja melakukan dua hal, saya menjalankan pencadangan setiap jam 11 kali dalam satu jam, bukan 1, dan saya tidak menjalankan pekerjaan lupa saya selama 384 hari terakhir atau lebih. Saya memiliki 101417 snapshot. Saya pikir akan terlalu lambat untuk melupakan/pangkas ini, saya pikir saya hanya akan menghapusnya.

Anda dapat mencoba #2718 - namun, tidak ada perbaikan untuk snapshot "melupakan".
Jika langkah lupa adalah masalah Anda, saya akan menyarankan Anda untuk:

• cari tahu snapshot mana yang ingin Anda simpan, misalnya dengan melihat log cadangan terakhir Anda atau buat cadangan lain saja.
• hapus semua kecuali file-file itu secara manual dari direktori /snapshots repositori Anda
• setelah itu, jalankan prune (jika Anda mau dengan #2718)

Saya hanya bermaksud menyimpannya selama beberapa hari, jadi saya akan menghapus seluruh direktori di S3 dan memulai dari awal. Saya memulai proses lupa dan itu memakan waktu yang sangat lama, saya pikir cabang yang lebih baru akan membantu (tidak terlihat seperti itu), atau setidaknya seseorang mungkin menganggapnya lucu.

Saya benar-benar ingin mencoba cabang ini (atau sungguh, berharap itu ditarik ke master). Saya mencoba untuk menguji dan mendapatkan

Fatal: tidak dapat membuka file konfigurasi: Stat: Id Kunci Akses AWS yang Anda berikan tidak ada dalam catatan kami.

Bekerja tanpa masalah menggunakan master build. Saya juga dapat menggunakan cabang di https://github.com/restic/restic/pull/2340 tanpa masalah.

Saya dapat menggunakan cabang ini pada repositori yang dipasang NFS, hanya repo tersimpan AWS yang tidak berfungsi. Saya tidak tahu bagaimana memecahkan masalah ...

terima kasih untuk semua pekerjaan yang baik terlepas dari

@vtwaldo21 Cabang mana yang Anda coba? Apakah itu #2718?
Pesan kesalahan Anda menunjukkan bahwa Anda mengalami masalah dengan kredensial AWS Anda. Ini mungkin juga menjelaskan mengapa NFS bekerja tanpa masalah.

Apakah perintah restic lainnya berfungsi dengan repositori AWS Anda?

@aawsome , saya idiot dan mengubah nomor cabang/masalah dan hal-hal yang benar-benar membingungkan. maaf.

Cabang 2718 bekerja dengan baik (pada repo yang didukung AWS dan NFS). Saya tidak bisa mengatakan secara pasti itu lebih cepat atau tidak karena masih berjalan
Cabang 2340, adalah yang bermasalah dan mengapa saya ada di utas forum ini.

Cabang 2340 berbasis 0,9.5 jadi sedikit lebih tua tetapi tidak terlalu buruk. Saya melakukan tes sederhana seperti ini:

biner restic adalah jalur yang baru saja diinstal melalui RPM (0.9.6)

snapshot istirahat
[bekerja]
restic.2718/snapshot restic
[bekerja]
snapshot restic.2340/restic
Fatal: tidak dapat membuka file konfigurasi: Stat: Id Kunci Akses AWS yang Anda berikan tidak ada dalam catatan kami.

Jadi sementara kesalahan menyiratkan sesuatu dengan kredensial AWS, saya benar-benar menjalankan perintah secara berurutan tanpa perubahan variabel. Sepertinya ada yang salah dengan cabang ini.

Plum saya membutuhkan waktu berhari-hari untuk repo ~ 2TB, jadi sangat tertarik dengan 2718 dan 2340 yang digabung menjadi master

@cbane terima kasih banyak untuk semua pekerjaan Anda! Kami baru saja menggabungkan #2718, yang mengerjakan ulang kode pangkas, dan saya pikir itu menyelesaikan masalah ini serta #2340.

Saya sangat menyesal dengan cara kami menangani kontribusi Anda, saya harap Anda dapat menerima permintaan maaf saya. :kecewa:

Saya sudah berbicara dengan @MichaelEischer , dia menyebutkan bahwa PR #2340 mencakup lebih banyak ide yang belum diimplementasikan, jadi saya membuka kembali masalah ini.

@cbane apakah Anda tertarik bekerja sama dengan kami untuk menggabungkan ide-ide ini ke dalam kode saat ini? Saya benar-benar bisa mengerti jika tidak, maka kami akan memeriksa PR Anda dan mengekstraknya sendiri :)

Kami juga berdiskusi singkat kemarin dan mencoba mengidentifikasi apa yang salah, sehingga kami dapat melakukan yang lebih baik di lain waktu. Beberapa poin yang kami identifikasi adalah:

• PR mengubah area yang sangat sensitif dalam kode (pangkas, yang pada akhirnya menghapus data), sehingga perlu pengawasan ekstra
• @MichaelEischer serta @aawsome mencoba meninjau PR dan mengatakan itu terlalu besar
• PR hanya dua komit, salah satunya mengganti semua kode dengan yang lain, kode yang sama sekali berbeda, ini sangat sulit untuk ditinjau
• PR mencakup setidaknya 4-5 ide dan peningkatan yang berbeda, yang membuatnya semakin sulit untuk ditinjau

Adakah hal lain yang saya lewatkan?

Perubahan cmd_prune.go dari #2340 sejauh yang saya bisa lihat sepenuhnya digantikan oleh #2718 dan #2842 oleh @aawsome . #3006 juga menggantikan perubahan index/index.go.

Saya telah mengekstrak implementasi tree walking yang sangat paralel dari checker.go (lihat https://github.com/MichaelEischer/restic/tree/streamtrees), yang memungkinkan penerapan paralel FindUsedBlobs dengan beberapa baris kode tambahan. Itu juga dapat digunakan kembali untuk perintah salin. Cabang yang saya sebutkan juga menyatukan kode yang digunakan untuk memparalelkan pemuatan indeks dan snapshot. Saya akan membagi cabang menjadi PR yang lebih kecil.

Itu tampaknya meninggalkan penggunaan jumlah koneksi backend dan GOMAXPROCS untuk secara otomatis menyesuaikan dengan paralelisme IO/CPU sebagai bagian yang tersisa dari #2340.

Saya perhatikan bahwa baik #2340 maupun PR pangkas lainnya saat ini tidak memparalelkan unggahan indeks yang ditulis ulang.