Data protection and virtualised machines

Let’s face it, we’re not very good at backups.

It’s nothing to be ashamed about. Few organisations could one hundred percent put their hands on their hearts and say, “Yup, we’ve got it covered!”

And as my esteemed colleague Tony Lock likes to point out, even places that think they have backups taped (if you’ll excuse the pun) may well still find issues if they actually try to recover the information they think they are protecting.

Data protection is more complicated than just taking a copy and storing it elsewhere, to be sure – particularly given that different information types have different requirements, both in terms of their value, and business risk should information be lost. No wonder perhaps that ‘keep everything’ is often the policy for information management, whether or not it’s actually legal to do so.

Complexity kills common sense, particularly in this sphere of data protection, where it can be just too damn hard to do things right. And then, enter virtualisation, which looks set to exacerbate the problem.

There are some very simple, yet far-reaching challenges to deal with when it comes to virtualisation backup – not least that virtual machines won’t necessarily be running when backups are scheduled. This factor is both a strength and a weakness – and it has resulted in a number of potential approaches to backing up the VM.

If a virtual machine is expected to be up-and-running for example, there is nothing to preclude treating it as a traditional physical machine and backing it up accordingly – running a backup agent inside the virtual machine. Potential challenges revolve mainly around bottlenecks. We know from Reg reader feedback that up-scaling server virtualisation hits issues of I/O bandwidth, which can only be exacerbated by the bandwidth requirements of the backup window.

Equally, given that the virtual machine has its own virtual disk file, a backup can be run on the host physical machine of said file – the VHD or VMDK in Microsoft and VMware parlance respectively. The main issue here is one of preserving state. If a virtual disk file is (say) 40Gb, in the time between the backup starting and finishing, the content of the file could well have changed.

Tools such as snapshots and cloning of VM’s can help (the running VM creates a delta of changes since the snapshot) but nobody is yet providing cast-iron guarantees about the consistency of the backup. Put bluntly, the restored image might boot, but information might also get lost, which is clearly not ideal. Understandably then, the advice here is often to shut down virtual machines before backing them up. Understandable, but hardly practical for many workloads.

Ultimately perhaps, the very flexibility offered by virtualisation may be its own worst enemy when it comes to backups. There are, indeed, plenty of options – but this also means plenty of complexity. Online vs. offline, streamed vs. snapshot, guest vs. host, it becomes difficult to decide on the best approach. The fact that a VM may be restored to a different machine, or indeed taken wholesale and moved outside the organisation, is a cause of data protection issues in itself.

There’s not going to be a right answer on this – perhaps we are still waiting for a vendor to come out with a cast-iron backup solution for the virtual environment. If it existed – perhaps it already does, but we’re not familiar – it would also support deduplication, otherwise we’re going to end up with rather large quantities of backed up VM files. Further features could include the management of backups – for example scheduling backups in a way that minimises bottlenecks across the virtualised environment – and perhaps most importantly, providing visibility on exactly how well the VMs have been protected.

We know that knowledge levels around virtualisation best practice are low – so this has to be an area of considerable risk if it goes untreated.