Modifying ghettoVCB to run on VMware ESXi 5.1

On September 14, 2012, in Technology, by Mike Waldron

UPDATE: William Lam has put out a 5.1 compatible version of ghettoVCB.  Click here to download!

I went to roll out a new VMware server, grabbing the fresh ESXi 5.1 build. When implementing ghettoVCB I observed that the /bin/busybox location is no longer valid, and that rc.local is no longer editable. Not only that, but because William Lam hasn’t yet updated ghettoVCB to include the 5.1 version, the script won’t even run on 5.1. Turns out the rc.local injection needs to happen in “/etc/rc.local.d/local.sh”.  Also, because busybox has moved you need to change the injection script as follows:

/bin/kill $(cat /var/run/crond.pid)
/bin/echo "0 6 * * 0 /vmfs/volumes/backups/ghettoVCB/ghettoVCB.sh -a > /vmfs/volumes/backups/Logs/backup.log" >> /var/spool/cron/crontabs/root
/usr/lib/vmware/busybox/bin/busybox crond  

And you need to place the script above in “/etc/rc.local.d/local.sh” versus the old “/etc/rc.local” file.

Additionally you’ll need to modify the version check part of ghettoVCB.sh as follows (see bold portion):

        ESX_VERSION=$(vmware -v | awk '{print $3}')
	if [[ "${ESX_VERSION}" == "5.0.0" ]] || [[ "${ESX_VERSION}" == "5.1.0" ]]; then
		VER=5
        elif [[ "${ESX_VERSION}" == "4.0.0" ]] || [[ "${ESX_VERSION}" == "4.1.0" ]]; then
                VER=4
        else
                ESX_VERSION=$(vmware -v | awk '{print $4}')
                if [[ "${ESX_VERSION}" == "3.5.0" ]] || [[ "${ESX_VERSION}" == "3i" ]]; then
                        VER=3
                else
                        echo "You're not running ESX(i) 3.5, 4.x, 5.x!"
                        exit 1
                fi
        fi

The above steps got ghettoVCB running for me on 5.1.
 
UPDATE: William Lam has put out a 5.1 compatible version of ghettoVCB.  Click here to download!


Tagged with:  

ghettoVCB Log-2-Email, Version 1.00
Last Update: 2/1/2016

Download The Package

I developed the attached Windows batch file for use with VMware (I use ESXi 4/5/6) and ghettoVCB.  When used in conjuction with ghettoVCB’s log file, it will:

  1. Pull the logfile out of your ESXi datastore using WGET.EXE.
  2. Detect if:
    a. There is a “Final status: ERROR” message in the log (error condition).
    b. The backup process ran with no errors.
    c. The backup log contained neither a good or bad backup indication (blank/empty file handling).
  3. After checking the above, the script will e-mail you the log file/result using BLAT.EXE mailer.  It will clearly tell you in the subject if the backup was successful or not.  If your logfile does not exist (job never ran) it  sends an e-mail alerting you to this as well.
  4. After e-mailing, the logs are rotated and the script will keep up to 6 backups of past logs should you need to trace an older backup.  The filenames will be “Backup1.log” – “Backup6.log”.  “Backup1.log” being the newest backup log rotated, and “Backup6.log” being the oldest.

gvlog2em Installation and Setup Instructions:

  • Ensure that your ghettoVCB command line (cronjob) redirects to the same logfile using “>”, if you use “-L” or “>>” you are appending to the same file.  For instance my rc.local injection looks like this:
    — For ESXi 4 – 5.0
    /bin/kill $(cat /var/run/crond.pid)
    /bin/echo “0 6 * * 0 /vmfs/volumes/datastore1/Tools/ghettoVCB.sh -a > /vmfs/volumes/datastore2/Logs/backup.log” >> /var/spool/cron/crontabs/root
    /bin/busybox crond

    — For ESXi 5.1+
    /bin/kill $(cat /var/run/crond.pid)
    /bin/echo “0 6 * * 0 /vmfs/volumes/datastore1/Tools/ghettoVCB.sh -a > /vmfs/volumes/datastore2/Logs/backup.log” >> /var/spool/cron/crontabs/root
    /usr/lib/vmware/busybox/bin/busybox crond
  • Download the gvLog2Em package here.  Extract to a folder/directory of your choosing.
  • Edit the environment variables in gvlog2em.bat to match your environment.

Note: Make sure NOT to use quotations (even for long file paths) in defining variables.
Also make sure there are NO SPACES between the variable and the string “var=string”.

set usewget=1    <– Use WGET.EXE to pull the LOG file?  If 0/no then we just parse and rotate.
set vmwserver=192.168.100.201   <– Your server IP
set vmwroot=root   <– root or user with access to browse datastores over HTTPS
set vmwrootpw=rootpassword
set logvmwdstore=datastore2    <– Logfile datastore
set logvmwpath=/VMBackups/Logs/backup.log     <– Path to logfile on datastore above

set progpath=c:\gvlog2em     <– The path to BLAT.EXE mailer & WGET.EXE / local or network
set logpath=c:\gvlog2em\log      <– The path to your logfiles (or to store them using WGET.EXE) / local or network
set logfile=backup.log  <– The name of your logfile (cosmetic if using WGET)
set temppath=%temp% <– Writable path to store temp mailbody text file.  Usually you can leave it as-is.

set emailfrom=vmware@yourdomain.com  <– Backup log “From” email address.
set emailto=you@yourdomain.com  <– Backup log “To” email address.

set emailsmtp=mail.yourdomain.com  <– Your SMTP server
set emailport=25  <– Your SMTP port

set emailauth=1  <– 1 = on, 0  = off
set emailauthu=username  <– SMTP auth username
set emailauthp=password  <– SMTP auth password

set esxiserver=myesxi.yourdomain.com  <– The name of your ESX(i) server, used in SUBJECT line (cosmetic).

  • Make sure the Windows machine running this script has read, write and execute access to the logfile path (usually a local path)
  • Test the operation of the script/batch in your environment, checking for errors in the console output.
  • Once confirmed working, schedule a Windows task to run after your ghettoVCB backup.  (I use an XP virtual machine running on my ESXi server).

Tip: To enable logging of the batch file so you can troubleshoot your automated process, simply redirect it to a file when scheduling the automated task (after interactive testing), like this:

gvlog2em.bat > \\computer\share\path\gvlog2em.log

or really get nuts and put a date stamp at the end:

gvlog2em.bat > \\computer\share\path\gvlog2em_%date:~12,2%-%date:~4,2%-%date:~7,2%.log

 

How I use it:

  • I run a LOCAL cronjob on the ESXi server calling William Lam’s ghettoVCB.sh
  • I scheduled a Windows task to run the script 6 hours after my ghettoVCB backup (mine takes approx 2 hours to complete).

My (current) environment:

  • VMware ESXi 5.5 & 6
  • ghettoVCB.sh (latest) running locally within ESXi via rc.local injection cronjob.
  • ghettoVCB backs up to a secondary hard drive/datastore.  My backup happens once a week on Sunday.
  • Windows XP Professional VM on same server runs the task at 6:00am on Sunday.

Please let me know if you experience any issues or have improvements in mind!  I will continue to update this script as I receive feedback.

Changelog:

1.00 – Final Release

0.99 – Redesigned functionality; added log pulling functionality to the script.

0.95 (3) – Added WGET instructions, program and sample batch file to pull log directly from datastore, via VMware web datastore browser.

0.95 (2) – Fixed minor issue with feature introduced in 0.95, where the log would not be included if error or success conditions were not found.

0.95 – Handling of blank log files that do not indicate good or bad backup – will send an error message email.  Usually blank logs are due to ghettoVCB version issues.

0.94 – Better handling of non-existant/offline NFS systems/logpath shares.  Changed failure e-mail body bug that would not send an error e-mail if the logpath was not found.  New variable introduced “tempvar”.  See revision in the parameters section of the installation tutorial above.

0.93 – Minor cosmetic changes.

0.92 – Changed find behavior to look for final status error messages only, so that NFS sleep errors are not reported for successful backups.

0.91 – Added SMTP high priority flag to BLAT.EXE command line for unsuccessful backups.  Succesful backups are sent with the normal priority.  5/11/2010

0.90 – Initial Release  5/11/2010

 

Thanks to:

  • William Lam for creating ghettoVCB.  The “Rolls-Royce” of ghetto VMware backup solutions.
  • BLAT, one of the handiest utilities for Windows in my toolbox.. and all the folks who brought it to fruition!
ERROR: Could not find the BLAT.EXE mailer at ..
ERROR: Without BLAT.EXE I can’t continue!


Tagged with:  
Web Hosting