That must have been a manual copy, but comparing its date with the dblock and dindex dates might tell how close they are, however lack of dlist implies the initial backup didn’t finish, so database would be incomplete. Possibly you saw evidence to the contrary. If so, please mention it, so we don’t head down an unsuited path.
You’re presumably looking at the Path in the File table, wishing you could get them without laborious manual work as I described (which I think is only feasible at small scale or by finding/writing specialized tools to help). What would be nice (assuming you have a backup that’s incomplete due to interruptions, and otherwise fine) would be a way to ask Duplicati to make the synthetic filelist that it would want to do if needed before backup, however that code looks like it’s tied to backup. A repair looks by your testing like it won’t do the equivalent.
I suspect that the feature does not yet exist, in any friendly form. Perhaps someone will stop by to correct me. You could Search or read the Features category if you like (probably after your crisis passes) and put that in.
If you’re not interested in the ones I painted as being very challenging, there may be the possibility of getting RAID 5 running again if there is still data on the drives for it to read, as an alternative to restore from backup.
For a Duplicati restore, it might be possible to have the incomplete backup become complete by having it run a trivial backup configuration, declare victory, and put a dlist out. Unlike some other backup programs, having the source configuration trimmed between backups doesn’t implicitly cause deletions, however I’m not certain how things work if it’s changed in the middle of an interrupted backup. If you go this route, you should at least add and check –dry-run which I’m fairly sure will protect the destination (even better, copy off the destination). For the database, see if you can tell if the one you saved on OneDrive seems close to the dblock and dindex files in recentness. Maybe the external timestamp will be off, depending on whether your copy method kept it. You can look inside at the RemoteVolume table and match up latest files if you like. There might have been a few in progress when the backup was interrupted. This explains State values such as Uploading or Uploaded.
Should you prefer to carefully take your chances on moving Duplicati forward enough for it to make its partial backup available through normal means, you could build a new job, or change your old one if you imported it. Here is a technique which you could try, to change the job path to a copy (adding safety) of old job database. Alternatively just rename your copy of the old database into the future path before Duplicati puts its file there. Your trivial backup can be any little file you like. With luck, the new backup will add that and finish the backup, leaving you a backup with the old and new files that you can restore through the normal restore mechanisms.