Backup started failing "non-empty blocksets with no associated blocks"

The log one-line summaries unfortunately don’t talk about causes but if you saw locked file warnings in a longer message, those have existed for a long time AFAIK. Using –snapshot-policy is a good way to stop them, but it requires either running as a Windows service or getting administrative privileges another way.

Sometimes it’s hard to know for sure if the issue is intermittent, however one thought you may consider is that one way this has been seen before is when Duplicati tries to back up its own database area, which is in the user profile area. One especially troublesome file is the journal file for the backup database because it’s constantly changing, and a file that gets larger after the previous end-of-file has been seen causes this.

Database management Local database path being in your backup would be a sign that you hit that bug. Previously the workaround was to deselect DB folder, or use an exclude filter. Actual fix could replace that.

It’s hard to say after only 10 days, but it seems good so far. At some point the bug fixes outweigh any new issues. For me, that was at 2.0.4.22_canary_2019-06-30 for sure. Before that my backup broke too much.

There’s v2.0.4.21-2.0.4.21_experimental_2019-06-28 too, which has seemingly not been causing troubles, however there is unfortunately no way to retrieve collected information on what version people are running.

Before any release (even canary) goes out, there’s a suite of unit tests run, but they don’t catch everything. Generally it’s worth letting people with test systems without valuable data pick up canary first, and I’m sure some have (and I thank those people). How much longer to wait is your call, but those on 2.0.4.5 beta are on a release stemming from v2.0.3.14-2.0.3.14_canary_2018-11-08 so are lacking 10 months of bug fixes.

If 2.0.4.18 does turn up some new bug for you, you can downgrade to a certain extent, limited by database upgrades that the old version can’t deal with, it looks like you can downgrade Duplicati as far as the broken: v2.0.4.13-2.0.4.13_canary_2019-01-29, but you wouldn’t want to. 2.0.4.22 would be quite a bit less bugggy.

Alternatively you can do the deselect or exclude workaround and return to 2.0.4.5 if that’s what you’d prefer. If you upgraded from there, you have a “backup” database in the old format in your DB area, which you can copy into the standard DB spot for your backup, along with downgrade to old Duplicati. Depending on if the upgrade was done within Duplicati or by .msi file, you would either remove the new upgrade from a special spot that gets upgrades, or use the .msi to reinstall to Program Files\Duplicati 2 with the version you want.

Downgrading / reverting to a lower version covers this in more detail. As I said, my backups wants at least 2.0.4.22, but for you the fix was in 2.0.4.28 so the “how safe” question is not nearly so well answered yet…

There might also be a next Experimental, if the usual progress to Beta is followed, so if somehow the label Canary is uncomfortable, the label Experimental might feel better because it’s a more official approval of a particular Canary (often it’s just a rebuild). There seems to be a wish to push out another Canary though…