Backup corrupted, need to rebuild a few dblock.zip files

For true CLI (which does not use Duplicati-server.sqlite and in fact does not use the Duplicati server at all), there’s a dbconfig.json file that (I think) maps the destination URL to a DB, so you don’t need to name one.

When trying to match a GUI job, GUI Commandline passes all the matching options (and potentially extra). Export As Command-line is another way to get a GUI-job-similar-already-hyphened-and-quoted starter line.

Why not backung up latest Database? is one such feature request, which I point to because it says how to do it yourself, if you really want it, and also why you might not want that. Databases can get huge, so a tiny incremental backup might upload very little actual file data, but a huge database (which has all the history).

One user who previously backed up the primary database with a second backup job (don’t try to backup a database in the job that’s also making the database) has now decided that Recreate is enough safeguard.

Don’t mix the above two, because Recreate is fairly fast because ideally it just needs dlist and dindex files which are pretty small, and attaching a DB to each dlist is going to make for some big dlist downloads that actually might not be so bad for your local drives, but would hurt a lot if somebody had slow Internet speed.

[Idea] Backup Duplicati database to avoid recreate is a feature request and some details on a two-job DIY.

My usual advice for redundancy is redundant backups, preferably to different places with different software.