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

Features
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.

6 Likes
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 …

1 Like
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:

2 Likes
5

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

6

Another vote for this feature.

I use a script to decline backups outside daytime hours so I can use night for maintenance.
And it is kind of annoying to have all these marked as failed.

They arent failed, it is supposed to not backup at that moment.

7

Thanks for bumping this back up.

@kenkendk, unless there is a particular reason we would NOT want to handle script return codes as @kees-z proposed in the original post I think I’ll try to create a GitHub issue requesting it…

8

Yes, sounds as a simple and great improvement.
I will add it asap.

9

Done: Added support for multiple exit codes, and added a unittest to verify… · duplicati/duplicati@494fccd · GitHub

2 Likes
10

Thank you!

You did in 3 hours what I probably would have taken 3 weeks to approximate - if there was a way to “like” a post more than once, I’d be sure to do it!

1 Like
11

So can this be “Solved” and taken out of Planned mode based on this release?

For the record it looks like the acceptable return codes are:

  • 0 (run the job)
  • 1 (abort job silently)
  • 3 (abort job with warning)
  • 5 (abort job with error)
1 Like
12

Yes. This is now in the beta release.

1 Like