Virtual backup explained

Roy Illsley, senior research analyst at Butler Group, speaks about backing up a virtual server environment, some of the biggest issues that arise in backing up virtual machines, and what users can do to make virtual machine backup easier.

Why is backing up in a virtual server environment different from backing up in a physical environment?

When you back up in a virtual server environment it's significantly different from the physical environment that you are used to. Primarily because in the physical environment what you found was that you had very underutilised servers -- typically operating at 10% to 15% maximum -- which meant there was a large amount of time available to back them up, and to perform the backup in a fairly comfortable and easily scheduled way.

In the virtual environment, however, this utilisation rate has increased to about 70% or 80%; as a result, you find you have significantly less time to back up data.

Another issue to consider is that this reduced time window may force you to look at different ways of doing the backup. This can mean looking at the new technologies such as snapshotting or continuous data protection [CDP]. Both of these are very useful and sensible options, but they both require new techniques and new technology.

If you decide you're not going to go down that road and instead stick with traditional backup, you may need to increase the number of tape decks because if you try and run with two tape decks that served you well in the past, you may not be able to rotate those tape desks on the servers in sufficient time in the new virtualised world.

One of the big challenges if you choose the newer methods of data protection is what is the impact on licensing, and can I back up what I want to back up and run with it live, or do I consider the backup as purely a copy? Now when you look at normal backup procedures you normally back up and can recover the file, but if you're using, say, snapshots, can you back up at the file level? And if you can, can you recover at the file level while that virtual machine is still running? Or do you need to take the virtual machine offline to do the restore? Because if you're running virtualisation, live migration and the ability to run a live machine between different physical servers it may be something that your users have gotten used to.

What issues arise when backing up in a virtual server environment?

Some of the biggest issues that arise in backing up virtual machines relate to CPU and I/O bottlenecks. If you look at doing your normal backup across a 1 Gbps network and you assume that doing that means you get about 85% of your current performance, which may seem significant, but when you compare it to SATA disk technology that can get 150 Mbps through, you aren't looking at something that's very fast, so your I/O bottleneck is something that needs to be considered. That could come down to the matter of whether the network is big enough to cope or is the disk technology caching big enough?

This brings us to a second issue, which is that most virtual environments rely on NAS [network-attached storage] or SAN [storage-area networks]. This isn't a major problem, except if you're used to working with direct-attached storage [DAS], you'll find the cost of networked storage devices is significantly greater. Therefore, if you're planning your backup, you may want to plan your strategies on a tiered approach because the disk is more expensive and so you might want to have tier 1 as disk, tier 2 as tape.

It all amounts to you having to change the way you do your backups, and you need to do that in advance.

Building on this approach -- whether you're doing disk-to-disk or disk-to-disk-to-tape -- there isn't any real, clear advice that can be given because most of this boils down to organisational choice. There's no one size that fits all.

And if you're using storage virtualisation as well -- which people who do server virtualisation find very useful -- then making sure your backup strategy fits with your storage virtualisation is another major impact.

That brings us back to the I/O bottlenecks and how you can ensure that your LUNs [logical unit numbers] are shared correctly, and your backups can be done in a meaningful and sensible approach.

What can users do to make backing up virtual machines easier?

The first thing is to look at capacity planning and understanding where the CPU is being used and what's causing the spikes. Then mapping out -- if those spikes are caused by scheduled backup jobs running -- and planning them to be run more optimally by placing the virtual machines (if you're using a technology like live migration) on the server that needs to be backed up.

Again, it comes back to knowing where your virtual machine is, what your backup strategy is, and what capacity and throughput in terms of CPU and I/O you've currently got. This all requires planning tools, and those such as CiRBA and PlateSpin are identical and ideal tools for doing this sort of work.

Whether this option is going to make life easier depends on your point of view, because the one thing that virtual environments provide is more options and opportunities in terms of data protection and continuous data availability.

What this means from the IT perspective is a more complex approach to how this information is maintained, delivered and restored. So, from the IT perspective making it easier is probably the wrong term. It will make the business easier to operate and function and live with any outages so they're not losing data, whereas for you in IT it probably means it'll be more complex and difficult. But, ultimately, the business users are going to be much happier with the service they're getting.

Butler Group's advice in this area is quite simple. If you want to make the backups easier, then you need to consider backups as an integral part of any server virtualisation project. You need to plan the architecture for implementing backups. You need to understand what sort of backups and what sort of recovery your users want. And don't get carried away with all the wonderful things that can happen in terms of CDP, disaster recovery, etc., that are sold as add-on values to any virtualisation project. Yes, they're great and they bring business benefits, but don't run before you can walk. In this environment, if you try and do too much you're highly likely to fall flat on your face because there are lots of little 'gotchas' in backup and recovery when it comes to virtualisation.