You are not logged in.
Pages: 1
I'm trying to get success/error scripts to work with backup jobs defined from the GUI, and I can't seem to get them to work... Maybe I'm misunderstanding how this should work?
When creating/modifying a backup job I can enter the path to the success/error script in the GUI, and the GUI seems to find the script (because when I let the path point to a non-existing script it complains that it can't find the file). However, on running the backup job, I get the message "Tip: no chained backups scheduled, set --on-success and/or --on-error arguments to chain a backup", and neither the success nor the error script is run.
Then, when I re-edit the job, both the success/error paths now show "execprog-" in both fields, not the path to the script files entered previously.
Here is the configuration of the job:
"/vmfs/volumes/local-ssd/xsi-dir/xsibackup" \
--backup-prog=Vmkfstools \
--snapshot=includememory,doquiesce \
--backup-point=/vmfs/volumes/NFS-Backup/esxi/script_test/xsibackup_export \
--backup-type=Custom \
--backup-vms="vm1" \
--backup-how=Hot \
--backup-id=004 \
--description="Script Test" \
--del-dirs=+14d \
--on-success="execprog->/vmfs/volumes/local-ssd/scripts/success.sh" \
--on-error="execprog->/vmfs/volumes/local-ssd/scripts/error.sh" \
--exec=yes >> "/vmfs/volumes/local-ssd/xsi-dir/var/logs/xsibackup.log"
Both the success.sh and error.sh files exist and are executable, running them from the commandline works fine.
Is there any way to get the scripts to work?
Thanks, Mike
Edit: forgot to add: I'm running xsibackup Pro 11.2.0
Last edited by mikei (2018-12-31 06:43:20)
Offline
You can do something even easier since v. 11.0.0, which is to just place your script inside the job file and chain as if they were regular backup jobs.
To know why your scripts aren't executing we would need to debug your setup. Post the relevant part of the log or contact support.
Offline
Thanks for your feedback - I'll try the script inside a job file tomorrow.
One thing I just noticed is that running the backup job with a --on-success/--on-error script defined wipes the scriptfile - that is, it becomes an empty file - I'm not sure how I missed that.
So I'm wondering: since re-editing the backup job in the gui gives the string "execprog-" instead of the script (note the missing ">"), could it be that when executing the script, xsibackup does not fully remove the "execprog->" placeholder from the --on-success/--on-error content, thus the command becomes
>/vmfs/volumes/local-ssd/scripts/success.sh
(leaving the ">" at the begining of the command string) - effectively overwriting/wiping the script file place instead of executing it?
So, a related question - should I contact 33hops directly regarding this possible bug (via the contact form?) or do they frequent these forums too?
In the meantime, happy new your to everyone,
Mike
Offline
We have checked the [b]--on-success[/b]/[b]--on-error[/b] behaviour and it works O.K. in multiple versions/builds, the hyphen issue that you comment should not happen. In any case, since we renovated most of the execution and job management in version 11.0.0, we will soon deprecate the [b]execprog->[/b] modifier, it's now an unnecessary twist, as job files are self contained and can contain any arbitrary script too.
Contact the support department with the job full log to dig a bit more into your issue.
Happy New Year!
Offline
Hmm, must be something on my install then...
But if you're going to deprecate the execprog modifier anyway, then I will go the route of putting the script inside a jobfile - I tested this yesterday and that way it works as intended without a problem. Thanks for pointing me in this direction.
Offline
Could be something in your build if it's outside of our test range, which covers all versions, but not all builds. Contact support if you need some further help.
Offline
There are some circumstances that could lead to some broken values when editing jobs in the GUI. This would be self evident in the GUI field and would require re-entering the value. Should you use the GUI rapidly, this could pass inadverted. Maybe this is the clue, we are these days improving the GUI to make job editing more reliable in version 11.2.1
Offline
Pages: 1