The --on-error and --on-success arguments allow to execute/trigger other backup jobs present in the /jobs folder or external programs upon backup completion.
You can trigger a job in the /jobs folder by referencing its Id, like this:
--on-success="backupId->009" (remember to enclose between double quotes).
Or you can execute any external program present in the ESXi shell like this:
Please, be aware that you can also treat external programs as if they were jobs by simply placing the script inside the jobs folder and assigning it a three digit file name. Then just call the script as if it were a regular job.
This more general approach, which has been introduced with version 11 will lead to deprecating the execProg-> switch in short. So you should place scripts inside the jobs folder and name them with a three digit string. It is recommended to name scripts 700 to 800 to better identify them when needed.
Is it possible to give parameters to a script run as the result of the --on-success or --on-error option ?
And would it be possible to directly give a 1 line script instead of a job id or a script file name ?
Those are in the end fake options for users not willing to understand the details of how the Bash shell works.
If you are planning to do more elaborated things like the ones you are describing, then forgetting about --on-* arguments is a must.
(c)XSIBackup-Pro Classic is in the end a shell script, you can interact with it as such and pass whatever arguments you want, or just query the outcome of the script execution and take appropiate action in each case: error | success
How would you recommend to query the outcome of the script execution ?
I understand that the exit code is always 137 because of the kill signal used at the end of the script, and therefore cannot be used to determine if any error occurred during the execution of the script.
(c)XSIBackup Classic is a script, you have full access to the code and permission to modify it, just as long as you don't redistribute the changes. Set your own flag based on your requirements or reuse/modify the very --on-* functions.