Good news is there have been many backup corruptions fixed after 2.0.4.5/23, but at least one bad bug slipped in. Generally I advise people not to put Duplicati (which is still in beta) in a position where loss of backup causes major issues, e.g. don’t archive-and-delete, and preferably have multiple backups using different software if the data is critical enough. Canary gives you known fixes plus unknown new issues.
Version upgrades also bring database changes sometimes, so you sometimes can’t just downgrade and expect the old version to know a DB format that didn’t exist when it was written. There’s a backup of your database made when the format changes, but the window for going back to it is small, as the backup DB doesn’t get updated with information from newer backups, and you might want some of your recent files.
Downgrading / reverting to a lower version
Start-over is always an available but extreme option if things go wrong, and fits well with the idea of using Duplicati in ways that can forgive less-than-perfect reliability. The question is which bugs are worse? The 2.0.4.5 ones that I can think of mostly broke in obvious ways. The one (new and still not well-investigated) in 2.0.4.30 actually dates to 2.0.4.16 but is subtle enough to not notice with ordinary backups and restores because the database is good, but the backup on the destination isn’t quite right. Fortunately the error is in a dindex file which is one of the things that is less valuable, compared to dblock (data) or dlist info on files.
dblock put retry corrupts dindex, using old dblock name for index – canary regression #3932
Disaster recovery (e.g. source drive is lost) or a DB Recreate might be affected. You can watch for news, and I hope there will be a new canary out soon with a fix (may be easy or difficult depending on the cause).
You could check your logs or emails to see if you’re getting retried uploads, e.g. from flaky Internet issues. Backing up to local folder should be fine. Servers on a LAN might be the next best on the few-retries front.
If 2.0.4.30 is working seemingly well for you, and especially if you have some ability to withstand an issue (should one occur), then staying on 2.0.4.30 might be best. Also see top and consider your backup design.