Understand that RESTIC_READ_CONCURRENCY can be used to increase read speed when backing up fast storage.
Want to know if the same is respected during restore/check of a storage backend if it happens to be that the repo is on a NVMe drive? I am not a coder so can’t inspect the code - but from CPU usage of restic progress - it seems to be pegging 2 cores and so only 2 read threads.
Could this be changed to apply to all operations?
I’m a newbie and don’t know much, but I can say this, in case it helps:
Looking at the man/help pages, it seems to me that --read-concurrency is a specific flag for backup. It doesn’t appear as a global flag, and it doesn’t appear as a flag for either restore or check.
I would therefore conclude it can only be used when backing up. But I could be wrong!
restore and check are limited by the number of backend connections. This also applies to the local backend. By default restic performs up to two backend operations in parallel for the local backend. To increase it for example to 5, use the -o local.connections=5 option.