Data protection in the virtual world

Organisations large and small have recognised the benefits of shifting their IT to a virtual environment. The cost-benefits are compelling. While only five per cent to 10 per cent of a non-virtualised application server may be used, a virtual server hosting multiple virtual machines (VMs) may reach 50 per cent to 80 per cent utilisation.

With more virtual machines hosted on fewer physical servers, there are significant savings on hardware and maintenance, and further reductions on energy and cooling. Furthermore, virtual environments are more efficient to manage and can free up IT teams to be more proactive and less reactive. In essence, VMs allow you to do a great deal more with less.

While the transition to VMs can yield many benefits, it does not circumvent the need to protect and backup your data. While legacy backup systems may seemingly be able to recognise and backup VMs, IT managers will very quickly encounter major problems due to the different characteristics of virtual and physical environments.

In many ways VMs behave just like a physical machine and many applications don't distinguish between VMs and physical machines. Yet the dynamic environment VMs afford, means the landscape of the system to be backed up is fluid. This dynamic virtual environment allows new VMs to be readily and quickly added and moved around the system. Backup applications used to dealing with static, physical servers can struggle to even locate new VMs, let alone ensure they preserve the integrity of the data therein.

So the shift to a virtual environment requires a dedicated backup application. How do you begin evaluating VM backup applications and narrow the search?

First, it is vital that any backup application leverages the virtualised environment. It must integrate closely with the control centre of the virtual environment, the hypervisor. The application itself should also be embedded in the virtualised environment. It is counterintuitive to require an additional discrete physical server for the purpose of backing up VMs. Any application worth its salt will also enable grouping of different VMs and the capacity to apply different backup policies to different groups.

Secondly, the only reason you do backups is to perform restores, so how a backup application restores is pivotal. Does it enable you to recover and restore individual user files as well as an entire VM? Additionally, you need to consider how the application actually does this and what it takes to run the restore. Can you simply identify a discrete file, click on it and restore? Equally, can you restore an entire VM with the same ease or is it a two-step process, requiring additional agents? Enabling these simple functionalities will deliver faster backup and faster restores.

Thirdly, the format of the backup files is also worth considering. Historically backup applications have stored data in a proprietary format, which means the data is locked away in the backup. In this environment, restoring data requires a two-step process: extraction of the file with the backup app and then opening the file with the original native application. It can be very handy having the data stored in its native format to enable direct access to data in the backup file. In this situation you can then access data at sites where the backup application is not installed and restores happen quickly.

Another factor to contemplate is how the backup application handles the extra data associated with VMs. VMs tend to get a little “fat” with redundant data for two reasons. There is a tendency for administrators to over provision VMs and dead data tends to hang around through expired files, redo logs and unassigned data.

Despite its intent to reduce data requiring backup, change block tracking (CBT) can also leave behind dead data. If your backup app is not “familiar” with this environment, it will backup this redundant data, costing you time, server space and even bandwidth if you are replicating offsite. So it's valuable to have an application that can screen out empty space, skip expired files and ignore unassigned data. Moreover, is useful if the application can work effectively with CBT to achieve the intended outcome of reducing the volume of data that is backed up.

For many organisations it will be difficult to move away from legacy backup systems, such as those bound by compliance regimes that require them to store data for statutory periods. Backup tapes, for instance, still have a place in long-term data storage. Additionally, many organisations are already achieving valued efficiencies with dedupe appliances, which compress data eliminating duplicate copies of repeating data.

So it is worth asking the question: how does the VM backup app work with legacy apps and existing dedupe appliances? Do they not only integrate in a single step process but do they add additional value? A smooth integration between these apps and appliances will ensure a better ROI on existing infrastructure and processes, avoid adding additional administration and maintain existing compliance policies.

Lastly, it is important to consider whether the VM backup application itself is easy to install and maintain. IT managers need the assurance that their backup application is not going to add additional unnecessary workloads; after all they exist to make your life easier, not more complex. Ideally, the application comes with support if it's needed.

Michael Sykes is a Senior Technical Consultant Quantum's Australia and New Zealand division.