Local restore speed / "b2.connections" usage on HDD

Relates to this thread.

I am exactly five hours into a restore of 239GB from a USB 3.0 HDD repo to another USB 3.0 HDD. It’s copied about 173GB. Doing the math, that works out to roughly 9.84MB/s. Both of these drives usually perform around 80-120MB/s. Obviously I expect some overhead in reassembling the data from the repo, but…

Would it make sense to use --b2.connections=1 on a local spinning drive? Would that even have any effect on a local drive (not sure if it’s b2-specific)? I’m thinking that trying to copy two files at a time is actually making the spinning disk drive slower, not faster, due to seek times.

I should add that there haven’t been any other operations happening on the repo during this time. I suspended client backups.

Thoughts?

b2.connections is specific to the B2 backend. If you are not using B2 for the repository then this option does nothing.

Is there any option to read one thing at a time, when using a local HDD repo? I’d imagine it’d be faster than making the drive thrash about and try to read however many things at a time restic does by default. That works great for cloud storage, but locally on a non-flash repo, you might want to do one thing at a time due to seek times.