The claim is that it was not, and that database was not changed. Truth unknown, but under your case:
You’re talking about source files, but it sees a lot of new backup files too, and it errors, looking like this:
so doesn’t match unless Advanced option called no-backend-verification was used. It seems unlikely.
If this flag is set, the local database is not compared to the remote filelist on startup. The intended usage for this option is to work correctly in cases where the filelisting is broken or unavailable.
Set it anyway and continue test by Backup. In this case I get redundant data, but did it happen this way?
Why? Suggested database revert to old one would have had them. What would have removed previous?
To be specific about my test, I took a small text file. I backup, change it, backup, revert to old DB, backup.
Files are sets of 3 with dblock, dindex, and dlist. First two sets are good. Set after DB revert is redundant.
Restore dropdown is missing the second backup at 2:06 because DB revert took it to 2:04. 2:18 is newer:
Recreate from destination files is prone to confusion (as you say) from earlier confusion, but try it anyway:
Now it knows all three versions, because it saw the three dlist files with those dates in their filenames.
The above kind of view just needs the user clicking the Restore button and dropdown, but I can’t get it…
EDIT:
Maybe the missing “previous backups” you meant were those after the image backup and before new?
I originally thought “previous” meant all, or the very old ones, not a hole in the middle times as in above.