managing vm backups - roll your own or buy the tools?

Question

We're a small shop operating over a dozen vmware instances across 3 host machines. As we've added more VMs to our deployment for our clients, the piecemeal way we've done backups of our vm's has been showing its cracks. This especially became clear as we added more host machines to our "farm" so to speak.

It's time for us to consider more robust solutions for managing our VM backups. I have found some nifty scripts on google code to do all sorts of backup and copying of VMs to a central server...but will that only delay future pain?

Currently we're using vmware server 2.0, and have no problem switching to ESX. How have people made the transition to ESX and some of the vSphere packages to manage their virtual machines? Are their backup solutions that much better than what a scripting ninja could put together?

Answer 1

My take on "roll it yourself" backup is something like this: Scripting is great, but backup is also something that you want to be sure is done right. If you can spend a bit of money and get something that works well it's probably better than spending a lot of time writing scripts. You're also a lot less likely to end up in a situation where a commercial offering leaves you in a lurch and loses your data. (You still should test, test, test your backups even if you're using commerical offerings.)

I've done my share of glue-and-tape solutions to backup with rsync, scp, etc, but a commercial product is going to be cleaner for the "next guy" to administer and that's a "win" for your business, even if it's not for your ego.

So, having said all that, here's what I'd consider doing. I'd have a look at Veeam Backup before you go off writing / modifying scripts.

Answer 2

Whatever solution you decide to implement, be it a purchased solution, someone else's script, or your own script... make sure it works!

Test it, test it, and then test it again... then... test it on a regular basis (weekly, monthly, you decide).

The biggest problem with VM backups (and backups in general) is that it works at first... then everyone forgets about them until the sky starts falling.

If you do go with a do-it-yourself approach, be sure to DOCUMENT it properly along with the RESTORE PROCEDURE so that 6 months from now you aren't under stress because something is crashed and banging your head against the wall because you can't quite remember how to restore this "mess".

Commercial software can certainly ease the burden of a lot of this but depending on your situation you might need more configuration. But whatever you do... TEST it. ;-)

Answer 3

Keep in mind that for VMs there are really two kinds of backups that matter.

The first would be your standard backups that run on the machine whether virtual or not. Typically these would include any configuration files and data beyond the basic OS install.

The second is a backup of the VM itself. This is the tricky one. It runs on the VMWare host machine (not the VM itself), copies the entire hard drive, and does not require a client on the VM at all. In order to ensure consistency, the backup must be made while the VM is down, or more commonly, a snapshot is made, the snapshot is backed up, and then deleted.

The 2nd kind of backup is ideal for disaster recovery situations, as it can get you up and running very quickly - however the backups are necessarily larger and slower, and harder to set up. And they are no good if you need to restore a single file or folder.

Any backup solution you come up with really needs to consider both of these kinds of backups.