Free ESXi Backup Solution for Windows

[ChrisInTexas]

I have spent the last few days trying to find a free backup solution to the newly free ESXi for windows only enviroments (in particular Windows XP). The solution for me was the following:

1. Installing Windows Services for UNIX (WSFU)

2. Copying the ESXi Server password and group files to Windows

3. Configuring WSFU for accepting ESX Server connections

4. Sharing the Windows folder for NFS compatibility

5. Configuring the ESXi Server to mount the Window NFS Share as Datastore.

6. Setup Backup Script

Attached is the complete steps.

I take NO credit for any of this. This is just a complation of others work formated to suit my needs and felt others could benift from it as I have.

by Jason Mattox from Vizioncore (direct copy of his work, I just added more information to make it work in Windows XP)

(NFS Server port information)

by robink (The backup script)

(ssh on ESXi)

[lamw]

I thought you said just putting in a comment would break the system? You said all your configurations have been reverted? I would do further testing to ensure it won't break anything, then yes you could do what I had suggested by re-creating your cron entry.

If you go down that route, you'll want to see if your cron entry is valid, depending on when /etc/rc.local gets executed and normally it's the last statement that's executed via init then your cron daemon would have started. You'll need to create your cron entry and restart the cron daemon:

echo "05 * * * * /ghettoVCBni.sh" >> /var/spool/cron/crontabs/root
busybox crond -b

I think 2nd line will just re-run the cron daemon, and if you want to see more options you can always do :

/etc # busybox crond -h
BusyBox v1.2.1 (2008.06.26-17:58+0000) multi-call binary

Usage: crond -d[#] -c <crondir> -f -b

        -d [#] -l [#] -S -L logfile -f -b -c dir
        -d num  debug level
        -l num  log level (8 - default)
        -S      log to syslogd (default)
        -L file log to file
        -f      run in foreground
        -b      run in background (default)
        -c dir  working dir

or to see all busybox options do:

/etc # busybox
BusyBox v1.2.1 (2008.06.26-17:58+0000) multi-call binary

Usage: busybox [function] [arguments]...
   or: [function] [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use and BusyBox
        will act like whatever it was invoked as!

Currently defined functions:
        [, [[, ash, awk, basename, bash, busybox, cat, chgrp, chmod, chown, chvt, cksum, clear, cp, crond, cut, date,
        dd, df, diff, dirname, echo, egrep, env, expr, false, fdisk, fgrep, find, ftpget, ftpput, getty, grep, groupadd,
        groupdel, groups, gunzip, gzip, halt, head, hexdump, hostname, id, inetd, init, kill, ln, loadkmap, lockfile,
        logger, login, ls, md5sum, mkdir, mkfifo, mknod, mktemp, mount, mv, nohup, nslookup, od, passwd, patch, ping,
        poweroff, printf, readlink, reboot, rm, rmdir, sed, seq, setsid, sh, sha1sum, sleep, sort, stat, stty, su, sum,
        sync, syslogd, tail, tar, tee, telnetd, test, time, touch, true, udhcpc, uname, uniq, uptime, useradd, userdel,
        usermod, usleep, vi, wc, wget, which, whoami, xargs, zcat

Good Luck and look forward to your findings

[Dave_Mishchenko]

You could put the modified file in oem.tgz and that will overwrite the default file (and you could use any tgz file name - you would just have to append the filename to the kernel boot command in isolinux.cfg on the Hypervisor0 partition).

[lamw]

Correct, but I don't think they're using a stateless ESXi setup (installed ESXi), and if they have to modify the oem.tgz, it would mean they would need to customize their image prior to installation? I agree that would work perfect with the stateless model which is what I'm using and either editing the oem.tgz, environ.tgz or your backup.tgz would work to keep files through a reboot.

[alusrc]

lamw,

Yes I edited that post after I double checked my work, I probably should have just written a new one. I'll check this out and get back to you to see how it works.

Thanks again.

[alusrc]

Dave,

Any idea how I would update the tgz file in esxi's busybox? It doesn't look like it can update a file with a -u.

[Dave_Mishchenko]

If one wanted oem.tgz to take affect after the first post install reboot, then you would have to edit the DD image within install.tgz on the install media. Otherwise you can overwrite the file after the install. Personally I would avoid changing environ.tgz as it would get over written by a patch which changes to oem.tgz will survice a patch.

Great job with the backup script. If you don't mind me asking, it seems that you have a number of servers that are booting in stateless mode. What were the driving factors for you to go in this direction?

[lamw]

Which ever .tgz file you're updating, extract it out using:

tar zxvf envrion.tgz

make your changes, then tar it back up

cd dir
tar cvf * ../environ.tgz

This is just an example, substitute back in with whichever folders get extracted back out.

[Dave_Mishchenko]

I have some sample instructions here - http://www.vm-help.com/esx/esx3i/customize_oem_tgz.php.

[blueivy]

Hi JoSte,

Thanks again. After my last post I played around with the script. I'm not a Bash script person so it's a bit new to me but the main problem I hit was the same as you suggested. The other problem is the poor output from getallvms command.

I'll take a look at what you suggested and see if that furthers me any.

One thing that has been bugging me - can you (or anybody else) tell me the advantage of running the script directly on the ESXi boxrather than a remote machine? I assume that if you are backing up from a remote machine then the backups will need to be dragged from the ESXi->remote machine->NAS (or whatever)? Therefore it means that the commands, run from the remote machine, don't execute on the ESXi box?

Because of the limitations with ESXi scripts (from the other posts here there seems to be lots of issues post-reboot) my plan would be to run a Linux VM and run the backups scripts from that - this would allow me to use Perl and have more power to get around the 'spaces in the VM names' problem. Can somebody point out the pro's and con's of doing this?

[lamw]

Hi Dave,

Thanks.

Currently we're in development mode, and what sparked for some ESXi stateless boots was actually from one of your articles and the various documents out there. There's some possibly some use cases for the client I'm working with but I think one that might be useful is a quick DR scenario. We have few ESX 3.5u3 running on some BL460c and connected to HP SAN. If they lose any of the physical servers or their "micro" datacenter they have, and they can run backups to an NFS Server via the ghettoVCBni.sh script. With that they can quickly bootup a stateless ESXi Server and mount the NFS Server and bring their Virtual Machines online while either the physical server or the dc is being maintenanced. We have not discussed other implementations of ESXi, but personally for me, quick development work, it's great without much hassle and I only have access to a few systems and having the ability to reboot a normal host installed with ESX 3.5 w/SC and just pxeboot the system into ESXi is great if I need to test something without having to install it.

I'll be putting up some the work I've done on this in the coming weeks, just been occupied with other things in the last few weeks.

Agreed with your comment it would override the files after an update, but I was seeing that if you uses a stateless model, that any new updates would require any of those tarballs to be validated / updated and I guess you can ensure those set of file(s) are maintained prior to using.

[lamw]

You can execute local scripts on a remote host and have the work be done on the remote host itself. When doing things like a backup, I would say the benefit that it's isolated on that host. If you SSH into the ESXi Server from your LinuxVM and you execute the script, if you lose your connection you could severe the backup script. There are methods around that, but in general with backups, I would prefer leaving the script and automating it within the system. Not to say you can't have a cron entry on a remote system system that goes in executes the script and returns the shell and exists and just let the backup kick off on the ESXi host. There's plenty of options, you can even use SSH keys to automate this job but some organizations are not using it in that fashion or deny the use of SSH keys or if you have users administrating the system only via the VIC and want to keep login access to a minimal.

[blueivy]

I think I've got a hold of the wrong end of the stick.

When I said remotesystem I assumed that a Linux VM with the RCLI tools on there would beablt to execute the CLI tools(from say a Perl script) and backup the VM's that way rather than having to execute the script from the ESXi box itself. OR is this the only way to do it?

I haven't tried any of this yet. I was on the verge of doing so when I saw your script and went down that road instead.

[alusrc]

OK so maybe this is another stupid question but how do I mount the Hypervisor1 partition? I booted to the server with a Slax CD and I can see the partitions, they just won't mount properly.

[lamw]

You can do either, but transferring the backups via your SSH connection could be slow and I think someone had mentioned you might be capped off a certain limit with SCP, don't quote me.

If I'm understanding what you're saying, you want to have a LinuxVM installed with RCLI (VIMA could be an alternative and it's a free virtual appliance download from VMware which includes RCLI + VI Perl Toolkit) and you want to execute the local CLI tools (vim-cmd, vmkstools)? and backup through that initial SSH connection? Or did you want to run the RCLI local tools such as vmkfstools.pl and do a remote backup, which I believe is also possibly. The problem with doing that, from the limited testing that I've done with VIMA, it's not the fastest at pulling the data about the Virtual Machines, you'll have to spend some time with the RCLI or VI Perl Toolkit to get what you need and then either adapt or re-write a similar backup script. This would all you to not touch the ESXi host itself and just use the RCLI to do all you work remotely and I think its probably where VMware will be going with single pane of management where the SC does not live on the ESX(i) Server but as a Virtual Machine.

In terms of the "spaces" issue that's been in discussion, I'll have an update for you guys tonight. Though as a side note, this is a very bad practice to allow spaces in your naming convention, whether on your ESX Host, Datastore, vSwitch, etc. in my opinion. It makes parsing things so much more difficult and if you would like to separate the words, you should be using under-scores or dashes. Most organization will have design specifications stating the naming conventions for your environment and usually they'll agree it should be dashes or underscores to separate key words in a name in general.

[alusrc]

Good news, I added the modified /var/spool/cron/crontab/root to oem.tgz and it kept changes through a reboot. The only outstanding question is did it replace the file after cron was started or beforehand? Anyone know?

[lamw]

Good to hear that Dave's suggestion works! I believe it might be before, easiest way is to just setup a small script that echos a statement and see if the modification took place before the daemon started.

If not I think you can restart the crond by:

busbyx crond -b

or find the PID of crond and just start it back up.

[alusrc]

I'm pretty sure busybox crond -b works too, but if we do find it's starting before the modification, what do you think would be the best way to automatically restart crond?

Also, I'm not sure where I'd see the echo.

Anyway, it looks like we're almost there. I really appreciate the help.

[lamw]

Look at my previous post, find the PID of the crond and do kill -HUP

In terms of the echo, you could just echo to a file every 1minute say to /temp/blah and see if the cron entry is being modified prior to the daemon starting.

[adeelsheikh]

Greetings. I think I've done it.

First of all, Thank You lawm for your script and your time to the community.

I wanted to schedule the backups, have them run on the esxi console with Lawm's script NOT the rcli, and not mess with the crontab as it seems complicated since the settings don't persist after reboot.

I have created a cmd file and placed in Windows task scheduler. It kicks off lawm's script automatically on the esxi server and exits after launch; doesn't wait for it to finish. This way, the script will cycle through the commands and kick off the backups on all the esxi servers...

The missing link for me was plink.exe which is a command line ssh.

I had to place lawm's script and vms.txt on /vmfs/volumes/Datastore1.

Here's the command. This setup is working for me. Hope this helps others.

plink.exe root@10.248.2.140 -pw pwdhere "nohup ./vmfs/volumes/datastore1/ghettoVCBni.sh /vmfs/volumes/datastore1/vms.txt >/vmfs/volumes/datastore1/backuplog.txt &"

if you want to see what's happening, remove the nohup, the >backuplog.txt and the ampersand.

(google for plink.exe - from same people as putty)

also, the first time you run this, it will ask to save / cache the keys, select yes. It will not ask again.

[lamw]

Great to hear, I've used "plink" in the past to kick off a job that had to come from a Windows system, works great.

btw, it's "lamw" =]