Improvements for --run-script-before/after options

planned

#1

from the runscript helptext of --run-script-before-required:

If the script returns a non-zero error code or times out, the operation will be aborted.

The ParsedResult will always be Failed if the script returns an errorlevel other than 0. There is no way to just skip the backup when a specific condition has met.

This can be improved by allowing multiple error levels:

Errorlevel 0: Everything is OK, start backup task
Errorlevel 1: Everything is OK, but don't run the backup
Errorlevel 2: There is something wrong, raise ParsedResult to Warning, add script output to Warning section in Result file. Run the backup.
Errorlevel 3: There is something wrong, raise ParsedResult to Warning, add script output to Warning section in Result file. Don't run the backup.
Errorlevel 4: There is something wrong, raise ParsedResult to Failed, add script output to Error section in Result file. Run the backup.
Errorlevel 5: There is something wrong, raise ParsedResult to Failed, add script output to Error section in Result file. Don't run the backup.

This makes --run-script-before-required unnecessary, because this way --run-script-before combines both options, but it could be kept for compatibility reasons.

Duplicati could parse the errorlevels the same way for --run-script-after (0,1=OK, 2,3=Warning, 4,5=Failed) to raise the ParsedResult value to Warning or Failed after a backup job has run.


Backup only when host is reachable; retry backup that was missed due to connection issues
Specify network interface to use
#2

+1 for more distinctions in exit codes. I use run-script-before in this context: Backup only when host is reachable; retry backup that was missed due to connection issues

I wish ErrorLevel 1 would be available to use …


#3

This is an execellent suggestion!

An extention could be to give all parameters to the script! So it would be possible to make a general script that checks e.g. the target and one script can do that for all file jobs, another for webdav jobs. So no need to make an extra script for each job.

If we have a job

"C:\Program Files\Duplicati 2\Duplicati.CommandLine.exe"
backup
"file://blabla" 
"\\source1" 
"\\source2" 
"\\pathtodatabse\Duplicati-server.sqlite" 
--backup-name="name" 
--dbpath="name.sqlite" 
--encryption-module="aes" 
--compression-module="zip" 
--dblock-size="10MB" 
--passphrase="xxxxxxxxxxxxxxxx" 
--allow-missing-source="true" 
--disable-module="console-password-input" 
--run-script-before-required="myscript.cmd"

It should call

myscript.cmd 
backup
"file://blabla" 
"\\source1" 
"\\source2" 
"\\pathtodatabse\Duplicati-server.sqlite" 
--backup-name="name" 
--dbpath="name.sqlite" 
--encryption-module="aes" 
--compression-module="zip" 
--dblock-size="10MB" 
--passphrase="xxxxxxxxxxxxxxxx" 
--allow-missing-source="true" 
--disable-module="console-password-input" 
--run-script-before-required="myscript.cmd"

Then myscript can check //file:blabla or it can decide (eg. on the jobname or if the target starts with file:) what to check and also write a meaningful logfile.


#4

Almost all of this information is available in environment variables that you can check in your script.
More info here:


#5

I really like the idea of the errorlevel handling when returning to duplicati from the run before script. +1