I think that’s typical of computer error messages that are reporting unexpected situations such as this.
Presumably this is more to stop damage from spreading and to alert developers about the problem so debugging can look for where the problem may have originated. That’s often extremely difficult, unless problems have a known test case to reproduce them. Rare and random without any clues is real hard.
How does Duplicati Resume After Interruption? speaks a bit about the states. Source code has others:
My interpretation of the message is that blocks that the backup process would have put in block volumes somehow have no volume in a good state currently. Four are OK. Deleting and deleted are not accepted.
You could try looking in the database with a viewer, to see if it looks like volumes are there, in a bad state. Maybe instead, the problem was on the original backup work as opposed to a confused delete. Unknown. You can also run that SQL in the typical viewer (e.g. DB Browser for SQLite), remove the COUNT to see specifics, then see what you can make of all that in terms of characterizing the issue to chase the cause.
These are the sorts of things where a database bug report and logs (preferably at profiling level) help. Getting the bug report earlier would have been easier, but if you have the old DB it might still be possible. Even looking in the ordinary automatic job logs can sometimes find clues about what led up to that issue.