You should be able to restore directly from the destination without having to manually recreate the database however this uses a temporary database (presumably made for this restore). You eventually want a full one, however which way to go depends on the situation, and it wasn’t clear what was lost, reinstalled, or restored.
Restoring files from a backup is just an ordinary restore. Do you have any idea when Restore used to work?
Restoring files if your Duplicati installation is lost covers the case of severe loss, e.g. lost the source system.
Disaster Recovery is more aimed at problems within the backup than problems a sound backup means to fix.
What OS and Duplicati versions is this? Are destination files accessible? What suffix do their names end in?
If you are doing any operations from a shell or Command Prompt, be careful about special characters which might be part of the passphrase. Using the web UI (or the Commandline option in UI) should avoid the issue, and a quoted version can be obtained from the web UI using Configuration → Export → As Command-line. Rather than quote, you can use the –parameters-file option instead of placing everything on command line.
It’s important to match relevant backup settings of the UI, especially if running from a true command line not the one inside the UI which helpfully populates the settings from the backup job, then leaves it to you to get the operation adjusted exactly to the command syntax per “help” or Using Duplicati from the Command Line.
Your test for invalid passphrase adds some confidence however the date is also right on the file name, so it isn’t solid proof (without going through the code…). Better proof would be if you can select that backup and browse the files inside. The file list comes from the dlist file of the right date, and is encrypted if you encrypt.
You can also verify your passphrase using command line SharpAESCrypt.exe from the Duplicati installation, or https://www.aescrypt.com/ run on a copy of some file (maybe that dlist?) copied from the destination area.
It’s not clear exactly when the error happened. Various things are decrypted, and it would help to know what failed. A clearer view than the basic web UI provides can be obtained in the UI using About → Show log → Live in another tab (set to level Information or even level Profiling, but Profiling could make a LOT of output). Running on the command line also makes a nicer display, and can be done with web UI Commandline option after setting some options to get more output. It’s either –log-level or –console-log-level if on recent canary.
The enhanced logging settings can also be used on true command line, however the operation is separate from the web UI, and there are hazards to running independent copies of Duplicati to the same destination. For the already-launched seemed-stuck true-command line (correct?) tool, it might be best to look at it with other tools to see where it is. Depending on OS, this might include Task Manager, Process Explorer, ps, etc. Basically, stopping it in the middle of work might be bad, but if it’s truly stalled then it’s probably appropriate. You can also look for database progress, e.g. timestamps. Location depends on your OS and how Duplicati was installed, e.g. as Windows service or Linux service to start at boot, or using Tray Icon and starting later.
Hearing more about the situation and sequence of things done would also help, for example if you truly lost everything on the drive, then a “repair” would try to recreate the database, which can take a long time for a big backup, and as noted earlier isn’t immediately required if you’re in a hurry to restore files from a backup.