Another possible way to estimate completion time in a situation with so much compacting might be to look at destination timestamps on dblock files (or perhaps all files – dindex will change with associated dblock) sorted by date, to see how many look freshly produced by compact, versus how many are left to go. This lets you estimate rate and time. Unfortunately with the big backups it will take awhile but at least it’s going.
I’d worry about disaster recovery times if you have to pull down most of these backups for a total restore…
If you ever expect a big compact on a big backup, you can spread the delay by slowly reducing this option:
--threshold (Integer): The maximum wasted space in percent
As files are changed, some data stored at the remote destination may not
be required. This option controls how much wasted space the destination
can contain before being reclaimed. This value is a percentage used on
each volume and the total storage.
* default value: 25
Alternatively, Backup retention can begin as a custom value a bit less aggressive than default which is
1W:1D,4W:1W,12M:1M. I’m not sure how safe it is to kill Duplicati during compact, but if you dare to do so, this method might get you running backups again a little sooner. A fresh start may too (but lose old ones).