Virtual Machine Backup and Restore: What’s Your Strategy?

Can you do backups on a shoestring without sacrificing their integrity? Do it with the tools you have but be careful -- there are some gotchas.

You’d think at this late date that backups would be just another boring topic — boring but necessary. There’s much controversy surrounding backups in virtual environments and it seems there are many vendors out there wanting to sell you a solution. The real question is do you need to buy a third-party solution or can you use the built-in tools to do the job just as well? The answer may surprise you.

How often do you think about backups or your backup strategy? Most of us only think about such things during or after a failure occurs — because that’s then you need them. A good virtual machine (VM) backup strategy is a costly endeavor financially and in labor — or is it? It doesn’t have to be because your best backup strategy is part of your existing virtualization solution. Both VMware and Citrix provide the tools you need to create and maintain a successful backup strategy with supplied tools.

For backups, you have the following options:

  • Treat VMs as if they are Physical Machines
  • Treating VMs as Files
  • Using an Internal VLAN for Client/Server Backup
  • Snapshots1 and VM Copy
  • Built-in Backup Tools
  • VM Cloning

Any method you choose has its drawbacks and not every method will work for every VM. You’ll probably have to use more than one backup method to satisfy backup requirements for your systems. For example, if you have an application server VM that cannot be shutdown or paused, then your best option is to treat this VM as if it were a physical system — meaning that you’ll install a backup client on it and backup its files over the network or to local disk or tape. Most of the other techniques require that the VM is quiescent, shutdown, or can tolerate decreased performance during the backup procedure.

For VMs whose services can go offline temporarily, treating the VMs as files is the traditional backup method. The VM disk images and configuration files are copied to storage media (Tape, Disk, SAN, NAS).

A generally non-supported strategy is to use an internal VLAN for backups. In this scenario, you run a backup client on your VM of interest and a backup server on another VM connected to a backup device and allows the backup to run. Both VMs must exist on the same host server so that the data isn’t transmitted over the physical network. This procedure takes its toll on the VM host system but the backup is very fast since no data flows over the LAN.

I like the Snapshot capability in VMware. A Snapshot is a hot copy of an entire VM while the VM stays up and running. For a very busy system, there may be a momentary disruption in service but the advantage of being able to grab a Snapshot far outweighs this minor downside. There’s no equivalent yet for Xen* users but the Snapshot is due for a future release. A VM copy (vm-copy) is the current Xen way to make a Snapshot of a VM. The downside is that the VM has to be shutdown (powered off) before making the copy.

Cloning is another oft-used backup method. For VMware and Xen alike, you’ll have to power off the VM to make a clone. For VMware, there is no direct clone creation tool. You’ll have to create the clone yourself by using a script, making a copy of the VM, or using the Snapshot method. Xen has a cloning tool (vm-clone) that’s used specifically for the job.

I don’t really like to say, “I love you, but” — or to take sides on a particular product but for backups, I’ll take the VMware road on backups alone. Xen, you’ve got a great product — a nice interface, a second-to-none Templating schema, world-class I/O but your backup technology is lagging behind. After all, what’s more important than backups for a company’s data and resources? Nothing except the data and resources themselves.

The second thing you should build into any software product, behind basic functionality, is the ability to backup, save, archive, or manage data versioning. It’s hard to believe that the only way to create true backups is to completely power off a virtual machine. Can you imagine powering off a physical machine when you need to do a backup? It isn’t very practical, is it?

If we are to move our valued infrastructure to a virtual one, then we need the same set of tools in those virtual environments that we have in the physical one. So, this discussion brings us back to the question, do you need to buy a third-party solution or can you use the built-in tools to do the job just as well? The answer is that if you’re running virtual machines that can’t be shut down for backups on VMware, you’re probably safe with the VMware-supplied tools. If you’re using Xen however, consider a third-party backup solution that doesn’t require shutting down your VMs.

1 No SnapShot utility available as of XenServer version 4.1.

Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62