Registered users
Linkedin Twitter Google+

In order to improve user's experience and to enable some functionalities by tracking the user accross the website, this website uses its own cookies and from third parties, like Google Analytics and other similar activity tracking software. Read the Privacy Policy
33HOPS, IT Consultants Download XSIBackup
33HOPS ::: Proveedores de Soluciones Informáticas :: Madrid :+34 91 930 98 66Avda. Castilla la Mancha, 95 - local posterior - 28700 S.S. de los Reyes - MADRID33HOPS, Sistemas de Informacion y Redes, S.L.Info
Alert icon This post applies to ©XSIBackup Free & Pro Classic, which have been deprecated. Consider changing to use ©XSIBackup-DC, which also offers a Pro version as an intermediate product.

<< Return to index

XSIBACKUP - How to install and use the cron system

Alert!  We have written a new post that covers this topic for users of version 11.0.0 or above. You should only go on reading if you are a user of some older version.

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:

(*) 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 © 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.


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:

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:

And then making sure only that instance is running as a daemon:

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.
This page was last modified on 2018-08-14

Website Map
Resources & help
33HOPS Forum
Index of Docs

©33HOPS site relies on the following technologies and partners:
SSL Protocol PayPal Payment Gateway Stripe Payment Gateway

©33HOPS Sistemas de Información y Redes, S.L. | VAT No: ESB83583716 | Avda. Castilla la Mancha, 95, local posterior, 28701 San Sebastián e los Reyes (Madrid) Spain

Fill in to download
The download link will be sent to your e-mail.

            Read our Privacy Policy

(*) DC & Pro users, please login to your user area to download