Things are better, but not perfect.
The question posted above replied to a database corruption concern, asking about backup corruption, making one wonder what the concern is, but actually they’re sort of tied together and both are needed.
The database is probably here to stay, but in a sense adds value because it can verify the destination, however if they disagree, which one is correct? There’s a bug fix in queue where database got wrong:
Fix missing file error caused by interrupted compact #4967
The database self-checks itself, making messages like Detected non-empty blocksets with no associated blocks! which I believe you were seeing. That issue is one that seems to be fixed now.
My opinion is that the bugs from 5 years ago where Duplicati fell over by itself are largely weeded out. Environmental situations such as power loss or other interruptions in less-used operations are slower troubleshooting because there’s usually not enough history, even if end user were willing to work hard.
What would help would be additional well-equipped test volunteers able to torture test it while keeping adequate logs and other history, thereby giving developers a fighting chance to find the troubled code.
Compared to 5 years ago, https://usage-reporter.duplicati.com/ shows about twice the backups, but the report rate of database or destination corruption is vastly lower, but it’s not zero and will likely never be.
It stays well far better now, but if things go wrong, they can still be a pain to diagnose and recover from. Possibly this is the fate of any backup program that uses complicated layouts that can get out of whack.