Time is unclear, but if the recovered Duplicati job database is from the other backup, then it is possibly older than the Duplicati data at the storage destination. This might explain the dblock deletions, as Duplicati repair aligns two views that should stay aligned, by removing the unknowns that go beyond its stale database view. Were the deleted dblocks the newer-date files only? Fortunately you experimented on a copy (a good idea).
If you got a stale database, then you remain in the unfortunate state of not having filename info on new files, however you might be able to recover old versions of files that were found corrupted from your other backup.
If somehow you have a database and destination that are pretty close, then there is more hope of recovering latest-theoretically-possible versions, but it could take much doing. Normally an interrupted backup is noticed at the next backup, and a synthetic filelist is supposed to get uploaded to reflect progress before interruption. Although I think there may be a bug that prevents that, it’s far easier to get that built by code than by hand…
Extreme recoveries can take both skill and will. How far is it worth going? Skills with code and databases help.
How the backup process works shows the ordinary plan, and may help assess difficulty of doing manual work.
EDIT: For further technical background, you can read Disaster Recovery and How the restore process works.
Restoring files if your Duplicati installation is lost is probably the easiest path to get a few older files restored now that it sounds clearer that you have older dlist files, just not the most recent (uploaded at backup’s end).
Another question is whether you wanted your old Duplicati backup reassembled as well as possible given the age of the job database. Recovering the Duplicati-server.sqlite from the other backup might help that, but it’s still some reassembly. Alternatively you could just get what you’re willing to dig out, then start a fresh backup.