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

©XSIBackup Classic Cron

How to install and use the cron system

 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.

Installing the cron system is fairly easy. As stated in the man page ( the first thing to do is running the following command => "./xsibackup --install-cron", by running it you can install the cron system or uninstall it if it has been previously installed.

You will see something like this:

This command will install XSIBackup cron to your ESXi > 5.1 BOX
xsibackup-cron will be installed to the current working directory
You should cd to the desired directory before installing the cron
Do you wish to continue? (y/n)

If you accept and continue XSIBackup will add the following three lines to the ESXi OS startup script: /etc/rc.local.d/ (1)

1 - /bin/kill $(cat /var/run/
2 - /bin/echo "*/1 * * * * [XSIBackup install dir]/xsibackup-cron >> [XSIBackup install dir]/xsibackup-cron.log 2>&1" >> /var/spool/cron/crontabs/root
3 - /usr/lib/vmware/busybox/bin/busybox crond

The startup script will add a line like this (the base dir will change depending on the dir where you installed XSIBackup to)...

*/1 * * * * [XSIBackup install dir]/xsibackup-cron >> [XSIBackup install dir]/xsibackup-cron.log 2>&1

To the root crontab on every reboot, as the crontab is not persistent...


So..., once installed your root crontab will invoke the file [XSIBackup install dir]/xsibackup-cron every minute.


XSIBackup has been programmed to deal with interstitial spaces in paths, in any case do not complicate your life and choose a path without spaces, at least to store XSIBackup files. Something like /vmfs/volumes/datastore1/xsi-dir is very convenient. The busybox binary that comes with ESXi has some little bug that can cause problems with spaces, per instance.

UNDERSTANDING xsibackup-cron FILE:

When you edit xsibackup-cron file you will see something like this:

# This is your XSIBackup crontab, you can add your backup sechedules here
# You can use regular XSIBackup commands appending the parameter --time="Day HH:mm", i.e. --time="Mon 21:57"
# The --time format is compounded by three letters weekday acronym (Mon,Tue,Wed,Thu,Fri,Sat,Sun) + space + hh:mm
# You can add multiple "moments" in a --time argument separated by a pipeline | like: Mon 17:31|Tue 21:33|Sun 19:21
# Example:
/vmfs/volumes/datastore1/xsibackup-dir/xsibackup --time="Mon 01:59|Tue 14:58|Wed 17:23|Thu 01:59|Fri 21:59|Sat 10:33|Sun 04:51"
--backup-point="/vmfs/volumes/backup" --backup-type=custom --backup-vms="XP01,W701!W701_2.vmdk;W701_3.vmdk;W701_4.vmdk,LIN02,BSD03" --smtp-port=587 --smtp-sec=TLS --smtp-pwd=mypassword

(*) You must parse full disk names after the [!] sign to exclude them.

Before adding a schedule to the xsibackup-cron file you should test it in the command line to make sure it works. Once you are confident that the command line arguments do work, you only have to paste the full line into your xsibackup-cron file and add the --time="day1 hh:mm|day2 hh:mm" parameter.

You can add as many cron lines as you want and each line can contain any number of -day hh:mm- points in time.


If for any reason your XSIBackup cron system is not working you should take the following steps:

1 - Check that ESXi cron service is running by executing this command:

cronpid=$(cat /var/run/ && ps | grep "$cronpid"

If you get an output like this:
1179842 1179842 busybox /usr/lib/vmware/busybox/bin/busybox
Then your ESXi cron service is running.

2 - Edit /var/spool/cron/crontabs/root and check that a line like this is present and points to the right xsibackup-cron file path.

*/1 * * * * [XSIBackup install dir]/xsibackup-cron >> [XSIBackup install dir]/xsibackup-cron.log 2>&1

3 - If your ESXi cron stopped working after a reboot next step is to make sure that XSIBackup has in effect modified the startup script. Execute this command vi /etc/rc.local.d/ and do make sure you see the lines mentioned at (1) appear as described.

4 - Check that the xsibackup-cron file has execute permission for the root user. This is normally not needed as XSIBackup assingns this permissions when the cron system is installed.

If you passed all checks then XSIBackup Cron is working. The problem resides most probably in the argument list, copy and paste each xsibackup-cron uncommented line, remove the time parameter and execute it in the ESXi command line. Remember that every cron line should be preceded by the full path to the xsibackup program, you should see something like this:

/[XSIBackup install dir]/xsibackup --time="Mon 02:00|Tue 02:00|Wed 02:00|Thu 02:00|Fri 02:00|Sat 02:00|Sun 02:00" --date-dir=yes --backup-point="/vmfs/volumes/...


That the weekday abbreviations are: Mon,Tue,Wed,Thu,Fri,Sat,Sun and that you must provide a leading zero for one digit times like 01:33.

Also do check the [XSIBackup install dir]/xsibackup-cron.log file for error messages in case you don't find where the problem is.

Run this command and check for errors.

cat xsibackup-cron.log | grep error

You can discard certificate errors like:

verify error:num=20:unable to get local issuer certificate


verify error:num=27:certificate not trusted

As you probably don't have a signed certificate in your ESXi box.


The crond daemon included in ESXi is a bit primitive and error prone when managed manually. ESXi uses the cron facility provided by  nbsp;Busybox. In very rare occasions, if you don't start and stop the service manually, and let it start with the host, it may be loaded more than once, and that will lead to an erratic behaviour. As commented before, the cron system is very primitive, it's just an executable that is loaded into the ESXi memory, but it lacks any control code that just checks whether the daemon is already running thus, if you load it manually with the following command:

/usr/lib/vmware/busybox/bin/busybox crond

and the daemon is already running, ESXi will simply load it into memory again with a different pid, but if you check the pid file, it will still hold the elder process number, which will be still running too. We won't delve into the details of finding out which are the exact unwanted effects of two or more crond daemons running at the same time. That would require the source code, and on top of that would be useless, as the fix would be to create or use a proper service manager. The thing is that when multiple instances of this daemon are loaded into memory, the server might not run the crontab, or might run it more than once per scheduled execution. The way to troubleshoot this situation and to give remedy to it is to: reboot the host or (if you run mission critical servers) check whether the described problem is actually happening, manually kill all instances of the crond daemon and load it once, checking afterwords that you only have one instance loaded.


# ps -c | grep cron
65850 65850 busybox /usr/lib/vmware/busybox/bin/busybox crond
77167 77167 busybox /usr/lib/vmware/busybox/bin/busybox crond
90829 90829 busybox /usr/lib/vmware/busybox/bin/busybox crond
90841 90841 busybox /usr/lib/vmware/busybox/bin/busybox crond

In this case the sysadmin got nervous and ended up with four instances of the crond daemon running. We need to unload all processes in the lines above. The easiest way is to run this command:

# kill -9 $( ps -c | grep cron | awk '{print $1}' )

It will grab the first column in the four line example and kill all processes. Next step is to load just one instance by running:

# /usr/lib/vmware/busybox/bin/busybox crond

And then making sure only that instance is running as a daemon:
# ps -c | grep crond
100063 100063 busybox /usr/lib/vmware/busybox/bin/busybox crond
194876 194876 grep grep crond

The first line in the example is the crond daemon, the second line is the very same command that produces the output, that also contains the keyword crond by which we are filtering the ps -c output.