Most certain way given lack of information is to start over again. This is especially relevant if backup is running at default blocksize of 100 KB, which is suitable for 100 GB of backups before things get slow. Because you have a “very large amount of data”, maybe set 2 MB unless you want to allow for growth. Going high is not much of an issue for photos, because blocksize is for deduplication of repeated data visible at the file block level. With photos, two shots of the same thing will look very different in the files.
Because you can’t change blocksize on an existing backup, this may be an incentive to start from new.
If you don’t want to do that, you can consider providing information such as link to database bug report.
If you don’t want to do that, it may turn into a Q&A session, e.g. are cited files some of the newer ones?
Having extra log file options turned on would help understand how it got bad, but it’s too late currently…
If problem is easily reproduced by something you did, say what and maybe it can be reproduced to lead eventually to a fix. Ideally Duplicati withstands lots of abuse, but there may still be holes to be identified. Some are currently issues, with steps to reproduce, but I’m not recalling known steps to this. Got steps?
In terms of what you tried (which are mainly aimed at losses you can’t recover from in any cleaner way):
The first question is whether you were trying to recreate the database, or maybe had auto-cleanup on.
Every dblock file should have a dindex file saying what’s in it, and every dindex should have its dblock.
Sometimes, especially when interrupted, things get mismatched. You have a dindex without its dblock. Was that something like the last dindex uploaded before interruption visible from lack of a flow of files?
Please clarify. It’s not a command. It’s an option to the repair command where it was mentioned.
Although there’s a misleading status in GUI top status bar, that quote looks like it’s Commandline,
where you’re running backup (unless repair at bottom is asking for repair, which is possible…).
Where does “rebuild-missing-dblock-files” fit in? Use dropdown at bottom to set advanced options.
The PURGE command purges files to your un-stated specifications. Did you try to tell it something?
I forget what orphan files are, but from quantity, maybe backup interruption messed up transactions.
Database bug report may reveal a lot (after a lot of studying by an expert) if you wish to provide one.
For a rough ballpark, is that maybe all the files uploaded in fraction-to-date of this 9-10 day backup?
Another way to get a smooth backup is Export As Command-line for shell, and leave it alone in GUI. Looking after it’s done is fine. You just don’t want both in the database at the same time. They clash.
EDIT:
Regarding orphan files, at least one definition seems to be files that are not in a backup version, per:
This is possibly explainable by what makes it into the database from transaction commit versus what is rolled back on restart after unexpected interruption.Still waiting for any comment on how that was done.
As an unfortunate side note on that, rollback also rolls back evidence of some history, so external logs are more reliable (though rarely actually set up unless someone is working hard on diagnosing issues).