Last updated on Tuesday 16th of November 2021 08:30:50 PM

XSIBackup-Pro GUI Manual 6/7

Extended Backup Job Options

 Please note that this post is relative to old deprecated software ©XSIBackup-Classic. Some facts herein contained may still be applicable to more recent versions though.

For new instalations please use new ©XSIBackup which is far more advanced than ©XSIBackup-Classic.

The extended options are:
1/ Execute the backup job in a remote host (--host argument)

2/ Set remote XSIBackup installation path (--remote-xsipath)

3/ Set post backup events (--on-success and --on-error arguments)


1/ Remote execution

Remote execution is handled by the --host argument as you should already know. The GUI allows you to set this value in the following screen.

Set XSIBackup --host argument

When a job contains the --host argument it is treated differently, it first checks that there exists a remote installation of XSIBackup that can handle the execution. It compares all program modules and binaries to make sure they are up to date and it copies over whatever needs updating. Once this process finishes in the local host (the host where the crontab resides), it parses the command through an SSH tunnel to the other host, where the remote installation point retrieves it and executes it. All command arguments must be obviously relative to the remote host, so all VMs, datastores, etc... must exist in the remote host as described in the backup job.

Once the remote job finishes, the execution context has changed. Should the remote job contain --on-success and --on-error events, the subsequent jobs, in case they are a backup Id, will be sought in the remote server, not in the one where the backup job was originated.

2/ Setting remote installation path

When you launch remote jobs (--host), XSIBackup needs to know where the remote XSIBackup installation is. The license allows to install to one server and from there you can deploy to up to 20 servers, in fact XSIBackup takes care of that. How does it know where it has to copy its files. Well, you have a variable hardcoded at the conf/xsiopts file (xsidefaultpath). The path set there is where XSIBackup will copy its files when deploying to other servers, so you must make sure that the base datastore datastore1 exists or change that variable to something that you have available in every server. You don't need to create every xsi-dir folder, XSIBackup will take care of that, but you need a persisten datastore where to install XSIBackup files.

What if your datastore naming is different in every host and you don't have a datastore1 datastore available?: you can use the runtime --remote-xsipath argument to set this value per backup job. In any case this is very awkward and you should try to make your working environment as uniform as possible. Also remember that XSIBackup is licensed per filscal unit, so you cannot use one license to backup all your client's hosts.

Set --remote-xsipath parameter

3/ Set post backup events:

Arguments --on-success and --on-error are application level event handlers that describe what to do when a backup job finishes. There are three different types of actions to take:

a/ Send the backup job information to an HTTP server to be processed there.

b/ Launch a script existing in your ESXi host's FS. Not much else to say.

c/ Launch another backup job. This is known as backup chaining and is the most used type of event. For XSIBackup to be able to find your next backup job, you need to keep some facts in mind:
- The backup job file must exist by its Id in the /jobs directory and be executable.

- If you launch a remote job by means of the --host argument, you are transferring execution control to the other host, thus the subsequent backup job defined in the event handler will be sought in the remote server, not in the one you launched the job from.