Monday
Feb012010

Quick and dirty VMware backups

There's a lot of different ways to backup VMware guests.  Each has its ups and downs.

I worked in a shop not so long ago that didn't have the money for an enterprise SAN, loved the idea of virtualization, and had a significant number of VM's that only needed to be up and running during daylight hours.

When a VM guest machine is powered off all pending reads and writes go away.  The VM is subsequently reduced to three files:  the .vmdk, the .vmx, and the .nvram.  Therefore if you want to backup your VM's and can accommodate a bit of downtime while you back them up you can simply copy these three files to a file server.  Once the copy is done you can power up your VM.

The backup you're taking is basically an image of the VM at the time the backup was taken.  If you need to restore the backup simply import the backup files onto a working ESX host.  Power the machine on and you'll have a full-fledged working VM as of the time you took the backup.  This is a full backup - no incrementals and no differentials to restore, you'll have everything you need.

The up-sides are simplicity and restore time.  Since the backups you took have the machine in its entirety there's no need to install an OS, restore a full, restore each incremental backup up to the point of failure, et cetera.  Rapid recovery and simplicity at its finest.

The down-side is the storage for taking the backups is huge.  The other down-side is the machine will have to be powered off until the backup is completed.  This doesn't lend itself well to 24/7 boxes and not well at all to databases.

Nevertheless I have had occasion to use this.  I wrote a script that

  1. Powers off the VM
  2. Mounts a share on a domain file server (in my case a Windows File server)
  3. Backs up the machine in its entirety to the file server in a series of 2GB files
  4. Powers on the VM when the backup is complete.

 

I've commented the code pretty well, but a couple of things are worth calling out:

You can schedule this backup job through cron via the service console on the ESX host. If you have a cluster of numerous ESX hosts the script checks for the existence of the VM you're backing up prior to continuing. In this way you can still have HA enabled on your cluster and still maintain identical crontabs across the ESX hosts in your cluster - no danger of a VM guest getting Vmoted and consequently the cron job isn't set up on the appropriate host.

There's a loop to ensure that the script will try multiple times to power up the guest. This isn't always foolproof depending on your environment. As noted in the comments if your eval license has expired, if there's locking contention on your filesystem, et cetera. As stated supplement this with good monitoring.

The VM's *must* have the same name as the directory in which they reside. So if your VM is called "VmSERVER1" in Virtual Center it must reside in the /vmfs/volumes/.../VmSERVER1 folder with a coinciding set of VmServer1.vmdk files. Note that the Red Hat distribution of Linux that ESX runs on is case-sensitive (nothing new here).

Since snapshots increment the file names you can't take snapshots of these VM's if you want to continue to back them up using this method. Honestly though the simplicity of restoration makes up for this, in my opinion.