Throttle-upload effects restores

Features
1

Hello,

Firstly, thank you very much to all involved in the development of Duplicati.

I would like to report, what is perhaps, a bug?:

I am backing up to an offsite SFTP server. I have not tested this issue for local backups.

If I set a throttle-upload value for a backup job, this also effects restores from this backup job.

For example, if I set a throttle-upload value of 37KB/s, this results in a restore of a 15.5KB file taking over 20 minutes (I think it was about 23 or 24 minutes).
If I remove the throttle-upload from the backup job, the restore takes just 3 minutes (approximately).
I have done the calculations for my ADSL speed (upload upto 1Mbps, download upto 15-16Mbps) and this roughly corresponds with the restoration timings, therefore, I have confirmed that the throttle-upload value is indeed effecting the restore operation.

Presumably, to re-create this issue for yourself:
Create a backup job with a throttle-upload value set - Destination offsite.
Make a backup
Go to restore and choose your backup job as the restore from option.
The restore should be slower with the throttle-upload value set.

My way of thinking is that the throttle-upload value should not effects restores. Is my thinking wrong (in which case, this should be a feature request to this effect) or is it a bug?

Thank you in advance.

1 Like
2

Hello,

Would it be possible for someone to help move forward with this?

Many thanks.

3

This issue on Github seems to be related During restore: arbitrary bandwith application only on first dblock.zip.aes restoring · Issue #2890 · duplicati/duplicati · GitHub
But it doesn’t have any activity either.

4

Thank you @Pectojin, I hadn’t seen that.
Incidentally, for the record, this issue does not effect backup set verifications.

5

Hi,

I have noticed the same issue. I’m currently using the “2.0.3.4_canary_2018-04-02” version. I’m a little hesitant to upgrade to the latest version due to the “should only be used in test environments” notice in the changelog, so I haven’t tried that yet. Perhaps the problem has already been fixed? If not, hopefully bumping this thread will bring it to the dev’s attention.

Thanks.

6

I have confirmed this in 2.0.3.6 as well - and noted that it effects LOCAL restores too. Since --throttle-download doesn’t seem to do anything, my guess is it’s related to a similar issue a few months ago where the order of parameters was incorrect.

I have opened an issue on GitHub for anybody interested in working to fix this.