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

akrabu · June 21, 2019, 6:21pm

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?

cdhowie · June 21, 2019, 7:58pm

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

akrabu · June 22, 2019, 1:48pm

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.