Is there any solution to do this?
Problem in that fact that after restore I don’t remember all options of backup. So, how can I backup this?
Back up the file Duplicati-server.sqlite. Where it resides depends on which platform you are running Duplicati, and with which username. In teh same location, you also find the local databases that are job-specific; this would speed up a full restore when e.g. your local disk has crashed. You might also want to back them up, but this is a bit trickier, as the database of the currently-running job is actively updated during the run.
1 Like
Thank you for this answer. I have done it.
May be exists better solution to backup options without jobs metadata.
You can always save job-specific settings into json file. Or command line, but then not all info is saved. Save is one of the job-specific actions.
I want to autobackup job settings for example everyday.
Do you change the settings every day?
Take a look at GitHub - Pectojin/duplicati-client: A command line client for controlling the Duplicati Server.
Automatic configuration and database backup? gets into this, but feature request seemed to be more on DB. Features category is always open for input, but there’s a large backlog (mostly behind the large bug backlog).
1 Like
I’ve used the duplicati-client in a batch file to execute at the end of each back job a special non-scheduled backup job that only backs up the main config folder but excludes its own database and the lock file.
1 Like
Thank you. It’s the good solution. I think about it, but I don’t like to save my pass to another location. I want only backup “Sources” and “Filters” in each job.
But of course, with absence better solution, I choose that!
If the backup is encrypted, then passwords are safe
I don’t understand you duplicati-client export settings with passwords and anybody can see it through Notepad.
Ok… But better if such settings backup automatically with list of files in backup.
No I use duplicati-client to submit a back-up job that backs up the main folder, I do not export anything.
The method of @Taomyn has both pieces of the configuration and database backup mentioned above, however I’m curious why duplicati-client had to be used. It’s definitely one way to Export backups, which wouldn’t otherwise be possible without manual GUI work. Docs aren’t clear if export exports passwords.
Backing up the entire DB area will backup not only the job DBs but also the config, and it can encrypt all, however the backup could possibly be done instead using a scheduled GUI job or command line backup. Curious about the pros and cons.
Simple, I wanted the job to be executed after every back-up so a scheduled backup is no good.
Oh and a command-line back-up as I used to do it, exposes the credentials.
Thanks for the reply. Protecting credentials is remarkably hard, whether they’re in Duplicati-server.sqlite, or in a batch file, or in a process command arg, or in an environment variable. Sometimes the OS can help, using permissions to control file access or possibly limit seeing command line args or environment (haven’t tested).
–parameters-file with tight permissions might offer relief. I don’t know how duplicati-client protects its secrets, however it presumably faces the same issue Duplicati does. Ultimately it needs to pass them on to next step.
Well it just connects to the GUI, I don’t password it, and all I say in the batch file is “logon, run backup #4, logoff”
Open GUI can expose credentials. I think there’s a request somewhere for scoped login to seal that better, e.g. ordinary user can backup/restore but not get backend or email credentials. Security tightening is hard.
Apologies to OP for divert, but OP seemed interested in limiting credential exposure, so there’s some info. Probably not the place to try to design the perfect solution, so it’s just varying degrees of better or worse…
Thanks again for the input.