Virtual servers and desktops are now commonplace and they and their data all need backing up. But until recently, physical and virtual machine backup involved quite separate processes and products. It is possible, however, to carry out physical and virtual machine backup from a single screen. But what is the best way to do this and what questions do you need to ask backup product vendors?
Archana Venkatraman, datacentre editor at ComputerWeekly.com talks to Antony Adshead, storage editor at ComputerWeekly.com, about the key issues in physical and virtual machine backup, best practice for merging the two environments’ backup regimes and the kind of products that can help achieve this.
Archana Venkatraman: Why is treating physical and virtual machine backup separately an issue?
Antony Adshead: It’s an issue for a few reasons. Firstly, it’s because a mixed estate of physical and virtual servers is now becoming commonplace. Even those at the leading edge – the most virtualised organisations – tend to have a decent proportion of physical servers running apps for which they want to be certain about performance.
Secondly, physical and virtual machine backup is an issue because backing up in the two types of environment involves – when using best practice – two different ways of doing things. Having said that, organisations haven’t always adopted that best practice and we’ll look at the less than optimal ways people go about it in a minute.
Finally, there is the question of how you achieve best practice in physical and virtual machine backup and for this we’ll do a brief overview of products available that handle virtual and physical backup.
Venkatraman: What’s the difference between physical and virtual machine backup?
Adshead: First of all, let’s set out the key differences between physical and virtual machine backup.
Traditional physical server backup is something we’re all pretty familiar with. It involves agents on servers that track the metadata in files to see whether anything has changed and, if so, copies that changed data to the backup target. Of course, there are also full backups in which everything is copied to the backup target.
All of this happens outside working hours, hopefully, during the backup window, because we want to be certain the file is not in use and that we get integrity of data in the copy. The backup window is also a fact of life because the sheer load placed on the LAN during backup operations makes production operations difficult or impossible.
Virtual machine backup is – or should be – a quite different ball game. Because many virtual machines sit on one physical server, it’s not ideal to put an agent on each, not least because the uncoordinated copying of data from many virtual servers simultaneously puts a massive load on server I/O.
Instead, virtual server backup works at different levels, taking images of entire hosts and their multiple virtual servers, images of single virtual machines or of files that form part of these. The process is closely tied to the hypervisor operating system, working through APIs to gain image level copies and necessitating the quiescence of virtual machine operations to maintain integrity of the backup.
So, because we had an existing way of doing things – traditional backup with an agent on each server – and then virtual servers came along, we’ve ended up with a landscape in which organisations either a) backup virtual machines using traditional backup via agents on each server, or b) organisations have ended up with two backup infrastructures; one for physical and one for virtual.
Obviously neither situation is ideal. But when it comes to products that can pull things together, there has been some progress. Many mainstream backup product vendors have moved to embrace virtual server backup while some virtual server backup specialists have gone the other way to offer physical server backup functionality.
Venkatraman: What’s the best way to merge virtual and physical machine backup processes?
Adshead: The simple answer is to buy a product that will do both. In the past there was a rigid separation between the two fields. Mainstream backup products didn’t do virtual machine backup and so a small subset of specialised virtual machine backup vendors arose.
That division is now blurred. All the key enterprise and midrange backup products now support virtual machine backup. VMware integration is via the VMware vStorage APIs for Data Protection (VADP), which came out in 2009 and allows backup apps to talk directly to, and be managed from, the hypervisor. Microsoft allows similar backup app integration with Hyper-V. Not all backup apps support all hypervisors, however, so if you’re running Citrix, Red Hat etc, check to see if they are supported.
Such backup software products offer a range of options for virtual machine backup and recovery, from full to various flavours of incremental. For data recovery, options exist that range from file-level through virtual machine to hypervisor level, but be certain the vendor you’re looking at offers the granularity you need.
When it comes to the virtual machine backup specialists the field is more patchy. Not all of them support physical backup, so again check this in the early stages of evaluation. PhD Virtual does not and neither does Veeam. Quest, however – now owned by Dell – is set to add physical backup support to vRanger.
So, if you want to do virtual machine and physical server backup from one screen in the most efficient way, you need to get one of the products in which the two tasks are converged. Or you could move to an entirely CDP-based method of data protection, but that’s another story entirely.
This was first published in December 2012