Ideal solutions don’t exist. You must decide what level of risk you want to accept, and do accordingly.
Typically for serious backing up, best practice is multiple backups, at least one offsite and one onsite, possibly using different software. A time to recovery need is also a factor that can guide the direction.
You’re trading off the variables, including whether or not a stale backup is good enough if newer fails. Personal backups can sometimes stand this less-than-ideal situation. Business accounts might not… Serious backups get tested in various scenarios, for example whether a restore works when needed.
Good practices for well-maintained backups asked a great question, and there are lots of ideas there. Possibly you won’t want to do all, because it can be a lot, but how far you go depends on your needs.
shows that you already use multiple methods although I’m not clear on exactly what that’s backed up.
If that did the basic recovery and fine-tuning it with latest data is desired but not essential, I’d suggest following the cited disaster recovery method, or maybe a variation which is putting back configuration, using your Export To File which you saved somewhere safe, or using some guesswork if there’s none. Regular database recreate from destination will (unlike Direct restore from backup files) leave you the permanent local database if the goal was to just keep going on new drive with prior historical backups.
Everybody’s needs are different. Some (perhaps for business) have more time-critical recovery needs.
Some may have more critical reliability needs. If so, add backups and methods in case one falls short.
If you want to avoid destroying new backups, avoid the mistake of running repair with an old database, which is pretty much the only way one can get Duplicati to do that, and it’s generally user work unless auto-cleanup is set AND you’ve put back the stale database from an image restore which opens a risk.
Basically anything other than in paragraph above, but “CORRECT” does not mean guaranteed to work. Recreating the database may be faster, slow, or slow-then-fail, but it doesn’t risk the files at destination.