Fortunately, Duplicati looks like it handles the database recreation on a new backup successfully. I tested by moving my DB, basically equivalent to a delete, but more reversible, then ran a backup with 12 existing files on the destination. It complained about them, gave me a button on its complaint popup for repair, and repair recreated the database without deleting the remote. Without a database (e.g. on a newly configured backup), Database buttons offer only a blue Repair button, but without a DB present, repair recreates DB.
The REPAIR command describes the dual behavior of Repair. The way people get in trouble with Duplicati is by restoring a stale DB from an image backup or such. Repair aligns things by deleting new remote files.
Tries to repair the backup. If no local database is found or the database is empty, the database is re-created with data from the storage.
So maybe your anti-damage precautions weren’t required, and maybe you just didn’t push the blue button.
Failed to process file duplicati-xxx.dindex.zip.aes is the most recent explanation, but you already got some additional error information posted. Now the question is how old are those files, and how correct are they?
Test files are sampled, so might not be from that backup. You’d have to check dates on files or something, however the more direct approach at getting error details are mentioned in the link in the paragraph above.
You can also sample other files to see how widespread the issue is by using the Verify files button for the job. Watching About → Show log → Live → Retry will let you see any issues. Here’s an example after temporarily turning a dblock file into an empty file:
however I’m not sure how yours would have wrong size so soon after DB recreate via repair read the size.