There are sometimes situations when one wants to have all scheduled jobs disabled by a single on/off switch without having to touch the scheduling settings of each job separately. Duplicati doesn’t have a global switch, but is there any chance of doing it manually?
The most obvious situation of course is when one is restoring local databases onto a new computer that has not been furnished for backups yet, or not in the manner they were on the old computer that is not available anymore. Other situations involve trouble-shooting.
The pause button will disable scheduling on all jobs but may also disable some manual things you want. Limited testing suggests you can still set up the jobs. That seems to be one of the main objectives here.
The phrase concerns me. Be absolutely sure that the database is current with destination, and not stale, because stale database plus Repair may mean consistency is gained by deleting newer destination files.
Pause might help, but may be more likely to get in your way if troubleshooting requires operations to run. Simply looking at logs might work. You can test to see how well the intended work goes when on pause.
I use a simple job structure and don’t mind missing a few hourly backups, so I just un-check current day when I see (e.g. on status bar) an upcoming backup that might interfere with something I want to look at. This at least makes it a little easier to turn things back on (if I remember) at the usual time of the hour…
If it’s so unfurnished that there are no jobs (e.g. Duplicati-server.sqlite has not been moved in), then it will have no scheduled jobs to run. You can manually move in all the job databases before the jobs are there.
Moving in Duplicati-server.sqlite with Duplicati down will possibly cause some jobs that missed schedule times during the migration to all get in line for a run. I’m pretty sure that putting a pause into Settings from previous computer before migration would be in server database, so would postpone the big startup rush.
Cannot pause when restoring the one backup that has my local databases.
Yes, I am very very sure.
The “not been furnished” has to do about the arrangement of folders on the new machine that replaces the old that crashed. For example, the crashed laptop had two internal disks (SSD and HDD), but the new laptop has only one (SSD), and I don’t want the jobs to run before I have modified the job specs accordingly.
But you are right – I don’t have to restore the databases directly into the right folder, which means I don’t have to use the old Duplicati-server.sqlite at all; I can create a new one. In a crash situation, that is a solution. The solution perhaps.
In trouble-shooting situation though, moving away the job spec database is not helpful. I might make a feature request for the global switch.
I use a “before” script for all my jobs. In this script, I check for the existence of a marker file and I’ll return a non-zero exit code if the marker is present.
if /i not "%DUPLICATI__OPERATIONNAME%"=="BACKUP" exit /b 0
if exist C:\YOUR_MARKER_FILE (
exit /b 5
) else (
exit /b 0
If you need extra info do decide, you can use “DUPLICATI__backup_name”. It will be the job’s name.
This script should be run-before, but this bug is preventing it from working properly: Run-script-before with exit 1 saves metadata of aborted backup to statistics · Issue #4344 · duplicati/duplicati · GitHub
So I use it just with run-before-required instead. The only issue is that it will show errors/warnings in the web UI.
The possible exit codes for run-before are those:
0: OK, run operation
1: OK, don't run operation
2: Warning, run operation
3: Warning, don't run operation
4: Error, run operation
5: Error don't run operation
Any other non-zero code: don't run the operation
For run-before-required, any non-zero exit code will abort.
But, when that bug is fixed, you can have better codes with run-before.
Yeah, that would work as a catch-it-at-the-verge. Almost too late, yet in time.
Except in the case of restoring backups from a computer forever lost, unless that was already added to all jobs earlier. Plus it’s a hassle to add it to all jobs.
It’s a process to work out, and I don’t know the entirety of your backup process. It sounds like you have a secondary Duplicati job to backup the database of the primary backup. Disaster recovery could begin by Restoring files if your Duplicati installation is lost but maybe for the database to maybe speed file restore.
Alternatively if you have a job Export To File,of the database that could bootstrap work on primary restore.
For me, there is no moving away. I just turn off the rest of the day’s schedule while I look at some issues.
Anybody can make these in forum or GitHub, but ultimately Duplicati needs developer volunteers to code.
To any with interest in doing features or fixing issues, please do. Thanks to @sugoidev for forum input. Duplicati takes a community effort, and there are lots of ways that people can contribute to make it better.
There are probably some fine points to a switch, like are being discussed here, e.g. the usage sequence. Sometimes I know a job that missed its schedule is going to start at Duplicati start, but Duplicati must be started before a global switch to say don’t-do-that can be used. That’s one nice thng about the script plan.
Probably not quite what you want but the PowerShell script I wrote does give you the ability to enable or disable scheduling via Task Scheduler. The script controls which jobs run and if the scripts task is disabled, no backups will run. Not exactly a built-in option but it may serve your purpose for the time being.
PowerShell script to run Duplicati GUI jobs.