Last updated on Monday 28th of February 2022 08:52:48 PM

©XSIBACKUP Classic Man Page (Free & Pro)

 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.

Automated Backups for VMWare ESXi

33HOPS Free Software License
Copyright ©2013-2019 33HOPS, Sistemas de Información y Redes, S.L.
Developer: Daniel Jesús García Fidalgo
ALL RIGHTS RESERVED.

You are allowed to use this software for personal or commercial use. You are allowed to redistribute it without any modification. You can modify it's source code freely just as long as you do not redistribute the modified source code.

It is expressly forbidden to distribute derivative works without the written consent of the author.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY. USE AT YOUR OWN RISK.

CHANGE LOG:

http://33hops.com/xsibackup-change-log.html

DESCRIPTION:

© XSIBackup is a VMWare ESXi backup tool and Disaster Recovery solution, it uses the ESXi built in command line to create unattended backup solutions, this means you can create a backup schema that will for example backup all your running virtual machines every night, send you a detailed e-mail report after each backup operation and provision space once the backup disk is full by deleting the older backup folders. Only folders with the name format used by © XSIBackup will be deleted to provision space so older backups can coexist in the same disk by simply renaming the folder. © XSIBackup has built-in capabilities for SMTP e-mail submission and TLS. It is compatible with accounts at gmail.com, hotmail.com, yahoo.com, etc...

You can choose to carry out a "hot backup" (while the virtual machines are running) or a "cold backup" (switches off every virtual machine before copying it) by setting the option --backup-how=hot(default)|cold. If you choose "cold" © XSIBackup will issue a shutdown to the virtual machine instance and wait 30 seconds for the virtual machine to be shutdown cleanly. If after the initial 30 seconds period the VM continues to be on the program will wait 30 more seconds checking the VM state every 10 seconds after which © XSIBackup will consider the virtual machine can't be shutdown and it will be powered off. If the VM does not have © VMware Tools installed on it © XSIBackup will simply power it off.

XSIBACKUP (FREE & PRO) incorporates an additional form of backing up your VMs (warm option), it combines the advantages of a cold backup, as it turns off the VM completely and allows to consistently backup operating systems that do not support VMWare Tools or Open VM Tools, and a minimum downtime, as the VM is rebooted immediately and turned on while the backup is being made.

Please note that when a VM can't be shutdown cleanly most of the times it is a program or service that keeps it from being shut down in a proper way. Please, pay special attention to Windows VSS related problems read more here.

CONSTRAINTS - PLEASE DO READ

- XSIBACKUP-FREE cannot handle datastores with spaces in its name. XSIBackup-Pro can use datastores with spaces as a backup target, but cannot handle VMs stored in a datastore with spaces.
- XSIBACKUP (FREE & PRO) cannot handle special chars in data store names nor in e-mail subject: ()"|><
- XSIBACKUP (FREE & PRO) cannot handle VMs that have special characters in its name: ()"|><
- XSIBACKUP (FREE & PRO) use double hyphen as an argument prefix. Thus, double hyphens cannot be used inside any argument value, including VM names.

If you have a datastore with a space in its name and want to use XSIBACKUP-FREE, you'll have to rename it eliminating any space character. You must as well renounce to use special characters in VM names, paths and e-mail subject. Nothing out of usual.

USAGE (examples from the installation directory):

Example 1 (check the process and the e-mail submission before a hot backup):

# ./xsibackup --backup-point=/vmfs/volumes/backup --backup-type=running --mail-from=email.sender@yourdomain.com --mail-to=email.recipient@anotherdomain.com --smtp-srv=smtp.33hops.com --smtp-port=25 --smtp-usr=username --smtp-pwd=password --test-mode=true


Example 2 (backup all running VMs while on, --backup-how parameter is omited as hot backup is the default):

# ./xsibackup --backup-point=/vmfs/volumes/backup --backup-type=running --mail-from=email.sender@yourdomain.com --mail-to=email.recipient@anotherdomain.com --smtp-srv=smtp.33hops.com --smtp-port=25 --smtp-usr=username --smtp-pwd=password


Example 3 (hot backup 2 given VMs with interstitial spaces):

# ./xsibackup --backup-point=/vmfs/volumes/backup --backup-type=custom --backup-vms="New Virtual Machine,Newer Virtual Machine" --mail-from=email.sender@yourdomain.com --mail-to=email.recipient@anotherdomain.com --smtp-srv=smtp.33hops.com:25 --smtp-port=25 --smtp-usr=username --smtp-pwd=password


Example 4 (cold backup 2 given VMs):

# ./xsibackup --backup-point=/vmfs/volumes/backup --backup-how=cold --backup-type=custom --backup-vms=WINDOWSVM1,LINUXVM2 --mail-from=email.sender@yourdomain.com --mail-to=email.recipient@anotherdomain.com --smtp-srv=smtp.33hops.com:25 --smtp-port=25 --smtp-usr=username --smtp-pwd=password


Example 5 (hot backup 2 given VMs excluding two disks from the backup in one of the VMs):

# ./xsibackup --backup-point=/vmfs/volumes/backup --backup-type=custom --backup-vms="MyVM1,MyVM2!MyVM2_3.vmdk;MyVM2_4.vmdk" --mail-from=email.sender@yourdomain.com --mail-to=email.recipient@anotherdomain.com --smtp-srv=smtp.33hops.com:25 --smtp-port=25 --smtp-usr=username --smtp-pwd=password



Video tutorial: XSIBackup ::: first backup




What type of datastore should I choose?:

Click on the above title to have an overview of what different options you have at the time to use datastores in ESXi and how they will interact with XSIBackup.


Can I run multiple backup jobs simultaneously?:

No, in no way. XSIBackup is a backup program, it's aim is to backup your VMs as fast and reliably as possible. Concurrent massive data streams happen much more slowly than those same copy operations performed sequentially, in some cases, this kind of concurrent massive parallel copy operations, can clog your server so badly, that it will not only affect your VMs operation, but even hang your server. That's why you must use the --on-success and --on-error event handlers to chain backup jobs, instead of firing multiple cron lines at the same time. You can read the above post to get more details on how the XSIBackup PID management is handled.


General options - FREE & PRO:
You can check version hashes here


--use-smtp[=N]
XSIBackup-Pro the --use-smtp argument will use the specified registered SMTP server available in the conf/smtpsrvs file. You can add SMTP servers to the conf/smtpsrvs by adding the information requested in the mentioned file, and then check it's working by running:

# ./xsibackup --check-smtp=some@email.com --use-smtp=N


Once you have your newly added SMTP server ready, you can use it by combining a --mail-to address with an SMTP server like this:

# ./xsibackup ... --mail-to=some@email.com --use-smtp=N
--install-cron (watch at youtube.com)
ATTENTION:

- This command is run alone, without combining it with any other commands. It's a run once command.
- It is always run manually. --install-cron should never be included in a cron line.

This will install the cron system and create the crontab at /vmfs/volumes/xsi-dir/conf/root-crontab
Or at any combination of datastore plus subdirectory you may have chosen to install XSIBackup to.

A log file will hold all the XSIBackup output at /vmfs/volumes/datastore1/xsi-dir/var/logs/xsibackup.log (default location).

You can uninstall very easyly by running #./xsibackup --install-cron again.
--update-cron (v. 11.0.1 and above)
Copies the active contents of the <user name>-crontab file to the corresponding ESXi crontab file at /var/spool/cron/crontabs/<user name>.

In almost every case we will be talking abou the conf/root-crontab file copied to /var/spool/cron/crontabs/root. This command is also automatically executed when the host is rebooted.
--backup-point (just letters and numbers, no spaces allowed in DS names)
A) Full path to the backup mount point in the local server, it will tipically be under /vmfs/volumes, i.e. /vmfs/volumes/backup.

B) Full path in a remote ESXi host by using the following syntax: --backup-point="IP.OF.REMOTE.SERVER:PORT:/full/path/todatastore"

Example: --backup-point="192.168.1.200:22:/vmfs/volumes/datastore2:F METHOD (F,D): (F)ull or (D)elta. If F is chosen preexisting files will be deleted, if D is chosen or left blank (Delta is default option) only differential bits will be copied but can take longer under certain circumstances. Its up to you to decide wich one is best for you.

Take on account:

At the time of comparing files on both ends over IP (Rsync), we cannot use Rsync's size and timestamp simple check to decide if the file has not changed. Rsync cannot manage file attributes well under VMFS, thus the method to compare files is the following: .vmdk files are zero punched before transfer to make sure we do know the exact number of used blocks, then the number of used blocks is compared on both files. If the number of blocks is the same we calculate an MD5 checksum for both files and compare the result. If the checksums match the file is not transfered. It can take several minutes to calculate the MD5 checksums on both sides, in any case it is far less than what would take to do the same through a delta checksum. .vmdk files can only be hole punched when the VM is off, so you should perform a "cold" backup if you want to take advantage of this way of claiming unused blocks. See next option --backup-how.

NOTE: you need to previously link the remote server to this host by using --link-srv option.
--backup-how[=hot|warm|cold]
Hot backup is the default method, it makes a backup while the VM is on. You can chose to make a cold backup and the VM will be cleanly shutdown before backup and switched on right after. You must choose "cold" if you want XSIBackup to perform a hole punch on the .vmdk disks. This is how unused blocks are released. Take on account that Rsync transfers will clean this unused blocks on the fly, so if you run an IP Rsync transfer and then a second one right after, the remote .vmdk disks might have less used blocks than the replicated disks, and thus a new full delta sync would take place every time. So, to make sure your IP backups are as fast as posible, do make sure you do a cold backup to allow hole punching before comparing used blocks.
--backup-type[=custom|all|running]
• custom: if this method is chosen a list of the VMs must be passed to the --backup-vms option.
• all: backup -all- VMs.
• running: backup only running virtual machines.
--backup-vms[=VM1,VM2,VM3,...]
NOTE: if you host your VMs in datastores that contain spaces in their names you could get unexpected results. We encourage people to use concise names for their datastores/paths/devices when working with ESXi.

Only needed if "custom" is selected as the --backup-type. Please do remember to double quote this string if there are any VMs with spaces in its name. Parenthesys, brackets and special characters in VM names can raise errors as well as other special characters, which are not supported by XSIBackup.

Excluding disks:

If you want to exclude disks from the backup job, add a [!] sign after the VM the disks belong to, followed by the full disk names separated by a semicolon character [;]

# ./xsibackup --backup-point=/vmfs/volumes/backup --backup-type=custom \
--backup-vms="MyVM1,MyVM2!MyVM2_3.vmdk;MyVM2_4.vmdk" --mail-from=email.sender@yourdomain.com \
--mail-to=email.recipient@anotherdomain.com --smtp-srv=smtp.33hops.com:25 --smtp-port=25 \
--smtp-usr=username --smtp-pwd=password


In the above example we have excluded disks MyVM2_3.vmdk and MyVM2_4.vmdk from VM MyVM2.

Select VMs using REGEXP:

Basic regular expressions are allowed to select VMs. The regexp engine in use is that of grep utility built into Busybox, in turn bundled with ESXi, thus if you want to practice expressions before you use them in your --backup-vms argument, you can just use this one-liner.

vim-cmd vmsvc/getallvms | tail -n +2 | awk -F '[' '{print $1}' | awk -F ' ' '{for (i=2; i<NF; i++) printf $i " "; print $NF}' | grep -e '^W7'

In the above example we are using the regular expression "^W7", which means select all names that start by W7, thus, if your naming convention is W for Windows and 7 for Windows 7, then you would be selecting all OSs which are Windows 7 in your host. Whatever naming convention you use is up to you, you might use a different scheme, like naming VMs depending on the department that uses them, so ACCXXX are VMs used by the accounting department and HRRXXX VMs used by human resources.

Remember that the regexp engine that Busybox's grep uses is fairly limited in comparison to the full latest REGEXP especification, still powerful enough to virtually select any of your VMs based on its ESXi name.

You can use multiple REGEXP searches in one --backup-vms argument like this

--backup-vms="WS2012GPT,REGEXP(^W7),REGEXP(^XSI)"


In the above example we are selecting one explicit VM (WS2012GPT), plus the result of two different regular expressions: (^W7) which will select all Windows 7 VMs and (^XSI), that will select all VMs starting by XSI.
--date-dir[=yes|no]
Defaults to "no", if you set --date-dir=yes the backups will be made to a timestamped folder. XSIBACKUP-FREE can use it only for datastore backups, XSIBackup-Pro allows also to use it for over IP backups.
--backup-prog[=vmkfstools| onediff| rsync| xsitools| xsidiff]
You should explicitly set it, as latest versions of XSIBackup have progressively added more backup programs. This is a list of the backup programs and their available switches:

Vmkfstools: this is the classical VMWare disk copy utility, it's fast, but can only be used in a local context datastore to datastore backups. All backups are made to thin .vmdk disks. You can later easily expand them should you need to.

©OneDiff: this is our propietary algorithm to perform differential backups. It stores differential data in a snapshot, it is transferred and data is integrated with the remote mirrored VM.

Rsync: this is the classical differential network copy Linux tool implementing the delta algorithm. It's relatively slow, especially since it's not zero aware, but you may still find it useful when transferring data over slow or fairly unstable connections.

©XSITools: this is our propietary backup program to store deduplicated sets of backups. It reaches a more than decent compression ratio, well over 90% and above for fixed sets of data, namely VM sets, which is the purpose for what it was designed, while creating very little overhead on your CPU and memory. So little that you can backup a VM and still use it as if nothing was going on. Activate CrontrolMaster directive to boost your XSITools backups, read this post to learn how.

©XSIDiff: this is a copy binary mainly used by ©OneDiff, although it can be used separately as an independent backup program. It works in a similar way as Vmkfstools, it's fast and can jump over zeros, but it can copy data over IP, It tunnels it through SSH so you can use the [l] switch to improve its transfer speed and take it very close to your NIC's theoretical limits.

Backup Program switches: All this switches apply to the SSH tunnel used by some backup programs like ©XSITools, ©OneDiff or Rsync.
z: enables mild compression on the SSH tunnel, this will only be useful when using Rsync through a slow network (< 3 mb/s)
l: causes the SSH tunnel to use Less Secure Cipher, which will improve data throughput (XSIBACKUP 11.2.3 and above).
f: forces the use of Rsync instead of ©XSIDiff to transfer snapshot files.
u: copies Rsync binary version shipped with ©XSIBackup (xsibackup-rsync) to the remote Linux server and uses it as the Rsync server. Please note that for this to work, your remote OS must be able to execute the binary. This will be useful when your remote Rsync version is not compatible with 3.1.0, which is Rsync version shipped with ©XSIBackup. Passing it when backing up to a remote ESXi server will have no effect.
--backup-room[=NNN(Gb)]
Space that will be used for backups in gigabytes. Once this limit is reached the eldest backup folders with XSIBackup folder mask will be deleted. If this argument is omitted all available space will be used. Pass just a number, do not append "Gb" string.
--snapshot[=values]
It accepts one of two possible values includememory and doquiesce, comma delimited in case two values are present.

• includememory: appending this value will include memory in the snapshots taken throughout the backup job, memory is excluded by default since v. 9.0
• doquiesce: this flag will instruct XSIBackup to quiesce the OS before taking a snapshot.
Usage:

--snapshot=includememory
--snapshot=includememory,doquiesce

--backup-id[=Id]
Backup UID, it must be a numeric string of three digits: 000, 001, 002 ... 999, it accepts values from 000 to 999.
--shell-warning[=(1)yes|(0)no]
This command is run alone. It accepts 0|1, yes|no as the only argument. Enables/ disables the shell warning in ESXi, as it can be annoying sometimes.
This command is available in version 10.0.0 and above.
--disable-vmotion
This command has no parameters. It tries to detect the VMotion Virtual NIC and disables it while the backup is taking place. Once the backup has finished VMotion is re-enabled for the interface.
This is an experimental feature by now. In spare ESXi servers outside of the scope of a vCenter it won't make any effect.
This command is available in version 10.0.0 and above.
--options
This arguments allows to pass some special options.

OPTIONS:

unreg-xsibak: unregisters an _XSIBAK VM once the OneDiff backup cycle finishes. It is usefull in case the VM is registered at a vCenter level, as duplicate MACs generate errors, even if the VM is switched off.
--smart-info[=yes|no]
no (default) | yes Adds a S.M.A.R.T. report for every disk in the backup e-mail.
--mail-from
E-mail address as from where the HTML e-mail report will be sent.
--mail-to
Comma delimited list of e-mail addresses to which the HTML e-mail report will be sent. The first valid e-mail in the list is the main recipient.
--subject
Now you can set your own subject.
--smtp-srv
SMTP server that we will use to send the HTML e-mail report through.
--smtp-port
SMTP server port.
--smtp-auth
Set this value to -none- (--smtp-auth="none") to avoid using a password when authenticating against an open relay.
--smtp-sec
Security scheme, set this argument to TLS if you want to use TLS security, default is no TLS
--smtp-usr
SMTP username we will use in the plain text SMTP authentication.
--smtp-pwd
SMTP password used for authentication against the SMTP server. Do not forget to enclose the password between double quotes if it has any special character.
--smtp-delay
Set number of seconds from 1 to 3. Since v. 6.0.9 the --smtp-delay is added between every line in the SMTP conversation and also after the e-mail body and before the QUIT command. May help as a workaround with some e-mail servers without the PIPELINING extension.
--link-srv[=IP(:port)]
This command needs an IP as argument like this --link-srv=192.168.0.100 It generates a DSA key (RSA from version 5.0.0) locally and adds it to the authorized_keys file at the remote host allowing to communicate without a password. This command has to be run manually for security reasons, putting it in the cron lines has no effect.

It may accept a port number after a colon should it be different than 22. If you don't pass a port number 22 will be used as a default value.
--shutdown-wait
Set the time in seconds you want XSIBackup to wait for a VM to shutdown cleanly before a power off command is issued when performing a cold backup.

Example: --shutdown-wait=120
--save-job
This argument allows to save a command line job to a job file. You should first try your jobs out in the shell and then append this argument to have them saved to a file. You must define the --backup-id=NNN for the job to be saved as /jobs/NNN

Options exclusive to XSIBackup-Pro:
------------------------------------------------------------------------------------

--check-smtp[=e-mail]
XSIBackup-Pro set this argument to an e-mail address to check an SMTP server that you added to the conf/smtpsrvs file previously. Always use in combination with --use-smtp=N
--check-xsitoolsrepo[=path]
XSIBackup-Pro this command accepts a path to the root of an XSITools repository, or a full path to a VM stored in an XSITools repository. It can be used alone or in combination with --mail-to and/or --del-badblocks to have the check report be sent to the specified e-mail address and all detected bad blocks deleted. In case you pass a path in the type of the former option, the full XSITools repository will be checked. All physical data chunks will be counted and the amount compared to the number of registered blocks in the .xsitools repository. Then the SHA-1 checksum will be recalculated for every chunk of data and compared to the stored one, to verify its integrity. When using the --mail-to argument, the first registered SMTP server will be used to send these messages.

Example:

./xsibackup --check-xsitoolsrepo=/vmfs/volumes/backup/20181200000000/20181115024514/W702 --mail-to=you@yourdomain.com


If you append :f to the path to be checked, the check will be "fast", which means that the checksum of the stored data chunks will not be recalculated and thus only the existence of the block will be checked.

Example:

./xsibackup --check-xsitoolsrepo=/vmfs/volumes/backup/20181200000000/20181115024514/W702:f --mail-to=you@yourdomain.com
--del-badblocks[=yes|no(default)]
XSIBackup-Pro this argument can be optionally used along with --check-xsitoolsrepo to automatically delete any bad blocks in the data folder of an XSITools repository. Deletion of corrupt bad blocks is the best practice, this way XSITools will replace them in the following backup cycle if the block still exists.
--check-repo[=yes|vms|full] (updated in v 10.2.8)
XSIBackup-Pro This will check an ©XSITools repository upon backup completion. It accepts three possible values: 1) yes, 2) vms, 3) full. The first two values (yes and vms) will check the VMs backed up via ©XSITools once the backup job copy phase reaches its end. The third value (full) will make the check transverse all the repository contents, thus it will take much longer.
--backup-how
XSIBackup-Pro adds an additional option to the --backup-how argument: warm. Warm backups allow to consistenltly backup any type of OS, even those in which VMWare Tools or Open VM Tools cannot be installed to. It reboots the VM, but only the time necessary to take a snapshot and bring it back on again, thus the VM is off only for some seconds.
--backup-prog[=vmkfstools|rsync(:zuf)|onediff(:z)|borg(:z)|xsitools(:z)]
OneDiff --backup-prog=onediff(:z)

XSIBackup-Pro allows extra values like: OneDiff. By setting this string XSIBackup-Pro will make use of OneDiff technology, that will transfer only changed bytes since the last backup. Read this post to learn more about how OneDiff can help you minimize data transfer and reduce backup windows to minutes, even for terabyte VMs.

Since XSIBackup-Pro version 7.0.0 OneDiff is available when backing up over IP too.

Borg --backup-prog=borg(:z)

By setting this value, XSIBackup-Pro will connect to a Borg Backup backend through an SSH tunnel. For this feature to work you need Borg Backup installed in the backend server. Installing borg is very easy if you just take on account that it depends on a recent version of Python. Thus, the straightest way to a working Borg Backup server is to choose a Linux/Unix distro that comes with a recent version of Python (>= 3.0) bundled with the OS, or has it available in its main repositories. CentOS 7 is a good choice (even though this version has a poorly written installer), any of its equivalent versions: Red Hat, or Fedora will be a good choice too. If you prefer BSD OSs like FreeBSD (a great choice), Borg offers a pre-built binary that you will only need to copy to its path. Learn how to use Borg Backup with XSIBackup-Pro

Rsync --backup-prog=rsync(:zuf):

XSIBackup-Pro adds support for other type of Rsync backends than a counterpart ESXi system. It always makes use of Rsync through an SSH tunnel. It will detect the type of OS and copy the xsibackup-rsync binary to the other side if it detects another ESXi OS or if the "u" option is passed to the --backup-prog argument (--backup-prog=rsync:u). Take on account that the xsibackup-rsync binary will only work in some Linux distros like CentOS, RHEL or Fedora. You are free to try in other distros too.

If the remote OS is not ESXi and the :u option is not passed, XSIBackup-Pro will try to locate the rsync binary in the remote system and use it as the remote binary. If it cannot find an Rsync binary in the other end, then execution will halt.

THE z OPTION.

Compression is available as an argument to the "rsync", "onediff" and "borg" progs. Use this way: --backup-prog=rsync:z (separate from the prog name by using a colon). This will set compression on the SSH tunnel, but will be counterproductive in most cases, unless using a WAN connection.

The f option allows to force Rsync usage over XSIDiff, there are some cases in wich this might be useful, like when transfering .vmdk disks over the Internet.

Read more...

XSITools --backup-prog=xsitools(:z)

XSIBackup-Pro 9.0 introduces a new backup program: XSITools. This new program uses a simple yet powerful block level de-duplication algorithm to store backups in repositories; folders that contain the block chunks and the backup files. To use this new program you just have to create an empty folder and set the --backup-prog argument to xsitools, pointing the --backup-point argument to this newly created empty folder. XSITools will initialize a repository and store backups in timestamped sub-folders. You can use the --restore-vms argument to restore backups created with XSITools.

If you add the (:z) option, blocks will be compressed using the LZO algorithm, resulting in even smaller repositories. Recommended to maximize storage usage.

Use the --check-repo argument for the XSITools repository be checked upon an XSITools backup, an excerpt will be added to the e-mail backup report.
--on-error
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:

--on-success="execProg->/vmfs/volumes/datastore1/xsi-dir/my-script.sh"

Since the GUI was launched, it takes care to properly formatting job chaining for you, so this information is for your reference, just in case you need to edit the backup job manually.

Alert! 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.
--on-success
It works the same as --on-error. It is useful to trigger aditional XSIBackup executions by referencing a backupId stored as a job file in the xsi-dir/jobs folder. Thus you can chain multiple backups and make sure they don't overlap in time and interfere one with the other.

IMPORTANT: you do need to wrap --on-success and --on-error values between double quotes ["]
Why?: because they might contain some special caracters like "->"
--debug-info=yes
Lets you append detailed debug information to your backup report. Required to request support.
--watch
Allows to watch the ongoing backup jobs in a remote server from the master, or in the current server by using the keywords [localhost] or [this] Make this parameter equal to the IP or keyword of the server you want to monitor, that will bring the current activity on screen, being stored in xsibackup-cron-www.xxx.yyy.zzz.log or in xsibackup-cron.log in case of the local server

./xsibackup --watch=192.168.100.33


./xsibackup --watch=this
--host
Set the IP address or resolvable DNS name of any ESXi host to launch a remote backup job from the cron file xsibackup-cron.

NOTE: you need to allow your master server authenticate by public key to be able to run remote commands, see --link-srv
--img-list
You can add a list of images|links to customize the look&feel of your e-mail report.

More at: Customize e-mail report
--certify-backup(=yes(sha1)|fast|quiet)
Calculates checksums for data files and compares them before sending the e-mail report, this is done on top of the previous checksums done by the copy programs: vmkfstools, Rsync, Borg, ensuring 100% certainty about the contents of the backed up disks.

Possible arguments: yes(sha1), fast, quiet.

If you choose yes, the sha1 algorithm will be used to verify the contents of the backup. It will take some time to calculate the checksums, specially on bigger files, use at your discretion. Use of other hashing algorithms has been deprecated, as sha1 is faster than sha and md5 and more reliable.
Read more...

The fast option affects ©XSITools exclusively, it will check the deduplicated chunk existence and that its uncompressed size is equal to the deduplication block size.

Quiet option disables automatic certification options in ©OneDiff. When this parameter is not used, the ©OneDiff replicas will be tested: total size, used megabytes and trivial check. If any of the quick tests fails, the ©OneDiff mirror will be reinitialized and a full copy will be performed again. Depending on the target file system and some other particular conditions, you may get a used size mismatch, even though the mirror is in a good condition. Use at your own risk if you are confident that your hardware is O.K. and want to prevent thorough lower level checks.

If you don't want to renounce to those thorough checks. Turn the production VM off and run: vmkfstools -K your-vitual-disk.vmdk. That will punch zeros in the virtual disk and help to minimize mismatches. This situations are quite seldom, they are more frequent when you use mixed environments.

Quote: Paranoia is a mental desease, but it helps to live longer ;-)
--restore-vms=[path]
This argument accepts a path (local or remote) to a backup location (a folder containing a .vmx file) or a folder containing multiple backup locations, just one level below. The path can be a local directory or a remote directory in the style of XSIBackup [IP or FQDN]:[port]:[remote path]. The remote directory can also be a Borg Backup repo, the restore module will detect whether the provided path is a Borg repo or a regular VM backup folder.

Read more...

--show-sizes[=real(default)|disk]
VM sizes and derived figures, like space needs, will be calculated based on the real size used in the sparse files (default), or on the nominal size of the disks.

Read more...

--override[=xsibakfilter]
Removes the filter for VMs ending in "_XSIBAK", generated by the OneDiff program. This may be useful when you want to backup a VM resulting from a OneDiff backup, in order to keep a set of historic VM states, per instance.
--run-backup[=backupId]
Allows you to run some backup job stored in the xsibackup-cron, or any other alternative file, by using the backupid. Obviously, the --backupid=XX... argument needs to be specified in the backup job for it to be invokable this way. This is just a helper to invoke commands stored in text files from the command line, do not use it as a backup job invoking method in production.

You may add the additional parameter --file=/absolute/path/to/any/file, to look for the backup job command inside any other text file in your system.

© copy;XSIBackup will look for any line containing --backupid=XX and will then try to execute it. It will expect the command to be a correctly formatted backup job, if not, it will simply return the corresponding errors
--backup-as[=username]
Allows you to set the username to be used when authenticating to remote systems per backup job. It overrides the hardcoded value defremusr at conf/xsiopts
--remote-xsipath
Allows to set the remote XSIBackup installation dir per backup job. Use this argument if the automatic detection on XSIBackup on the remote server takes too long. This could happen in loaded servers, or servers with a huge file system with a lot of deep paths. Needless to say your remote server must have just one XSIBackup installation dir (xsi-dir).
--del-dirs=[+-][N]d(introduced in v. 10.2.9)
This new argument allows to delete folders older than, or newer than N days. It takes three arguments: the sign, which indicates older than [+] or newer than [-], [N] which is a number up to 3 digits (max 999) and the "d" constant, which indicates days to consider.

Alert: We provide the --backup-room argument to allow automatic storage provision for maintenance-less backups. If you use --del-dirs instead, you will be relying on a conceptually wrong argument, as your data may grow inside your guests as time passes, and your backups may stop operating due to lack of space.

Attention:
* Only folders that meet the conf/xsiopts datedirmask variable are considered for deletion.
** Should some error be raised during the backup cycle, the --del-dirs argument will be ignored to preserve data.
*** If you use the --date-dir argument to store the backups in a timestamped folder, that folder will not be deleted when deleting folders newer [-] than N days.
--prune-xsitoolsrepo=[/path/to/xsi-repo/YYYYMMDDhhmmss]
Allows to prune blocks pertaining to a given ©XSITools backup. This will obviously just delete blocks that are exclusive to that deduplicated backup, thus, it might not liberate much space. In any case, the bigger your block size is the more space you will free.
You must point this argument to a timestamped subfolder in any ©XSITools repository.
--ssh-ciphers=[aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se...]
You can pass your preferred algorithm list by using this option, it will supersede any inner calculated cipher usage and be used by XSIBackup when invoking the SSH client. You will need the same algorithm available on the remote end, namely the SSH server.