Registered users
Linkedin Twitter Facebook Google+
  This website uses its own cookies or from third parties Close
33HOPS, IT Consultants
33HOPS ::: Proveedores de Soluciones Informáticas :: Madrid :+34 91 663 6085Avda. Castilla la Mancha, 95 - local posterior - 28700 S.S. de los Reyes - MADRID33HOPS, Sistemas de Informacion y Redes, S.L.Info

<< 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 (http://33hops.com/xsibackup-help-man-page.html) 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/local.sh (1)

1 - /bin/kill $(cat /var/run/crond.pid)
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...

/var/spool/cron/crontabs/root

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

ATENTION:

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.

TROUBLESHOOTING

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/crond.pid) && 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/local.sh 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/...

REMEMBER...

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

Or...

verify error:num=27:certificate not trusted

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

ADVANCED TROUBLESHOOTING

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.

PROCEDURE:



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.



Website Map
Consultancy
IT Manager
In Site
Resources & help
Index of Docs
33HOPS Forum

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


            Read our Privacy Policy