Podcast: Virtual server backup fundamentals

Virtualisation is disruptive to backup

Setting the scene with regard to backup and virtual machines, the key thing to note is that the advent of the virtual server is disruptive to existing backup practice.

It is disruptive because now many virtual servers are active in one physical machine, where before there was usually one application to each server. What this means is that virtual servers can’t be backed up like physical ones, with an agent per virtual machine, because of the I/O and CPU bottlenecks created.

The second key disruptive fact about virtual machines is that they are much harder to track for backup purposes. Previously a physical server hosted an application and that one-to-one relationship was almost never broken. Now, it is possible for virtual machines (VMs) to be created, deleted and migrated in a matter of seconds or minutes. That means keeping an up-to-date inventory of VMs is near impossible, with the distinct possibility they may not be backed up at all.

For these reasons, specialised VM backup products arose that sat alongside the existing physical server products. But now the market has changed and VM backup is near ubiquitous among midrange and enterprise backup software, with features that include autodiscovery of virtual machines, the ability to backup at hypervisor, VM or sub-VM level, among other things.

Determining your virtual server backup needs

So, what are the key steps in deciding your backup needs and choosing a virtual server backup product?

The first thing to determine is your mix of virtual to physical servers. It is still common for most organisations to be running some physical servers, especially for their most critical apps. It is important to think about this so you can determine to what extent backup product procurement should be skewed toward the physical, the virtual or both.

All the mainstream backup software products now support virtualised environments, but not all hypervisors. Most of the specialised backup products only work with virtual machines.

Next, you need to determine required service levels.

What recovery time objective (RTO) and recovery point objective (RPO) do your apps require? Many organisations don't bother with formal RPOs and RTOs, but that is not a good approach. You need to know what your requirements are so you can fulfil them, and to help you choose from a range of products that offer different service outcomes, from near continuous to periodic data protection.  

Next, you need to think about your current backup environment. In all likelihood you are already running at least one backup product, maybe more. Best practice suggests it is best not to have more than two backup products deployed, so that management and operations are not overly complicated. One is obviously optimum.

What issues have you experienced with the current backup product? You don’t have to settle for existing pain points and could make life smoother by moving to a new product. Look for the root cause of any failures, which might be in product features or wider system compatibilities.

You will also need to take into account the hypervisors you use, as this can determine which backup software will work in your environment. Most support VMware and Microsoft Hyper-V, but the less popular hypervisors such as Citrix and Red Hat are less well supported.

Virtual server backup must-haves and nice-to-haves

Finally, let’s look at the must-have features of a backup product in virtual machine environments, as well as the nice-to-have but not essential ones.

The key features you can’t do without include:

• Multiple hypervisor support if you have more than one hypervisor deployed. Far better than having a separate product for VMware and Hyper-V, although that may be justified if you need one product to be especially suited to a particular workload profile;
• Crash consistency, to ensure data is not lost if a VM fails or is migrated during backup operations;
• Multiple, simultaneous VM backup without performance impact is also required;
• Platform support, so that the product supports your infrastructure, virtual or physical and including OS, hypervisor and firmware/driver versions.

Nice-to-have features include things like data deduplication, which may be better carried out at the target by a dedicated device. That depends on your backup environment. The presence of many remote offices might benefit from source data deduplication before sending data over the wire, but if traffic is just within the datacentre then a target device might fit the bill.

Encryption also may also be best carried out at a target device so that the CPU isn’t overloaded at the source and also after deduplication has taken place. Encrypted data doesn’t deduplicate well because encryption masks the duplicate elements that deduplication removes.

Other features that might be good to have are: snapshots capability and/or the ability to manage array snapshots; whether the supplier is particularly good at a particular aspect of backup that is important to you, such as endpoint or BYOD protection; being able to create synthetic full backups for point-in-time recovery or compliance purposes; self-service portals and recovery wizards that allow users to recover items; and tape support, which is often a still a requirement for many organisations.

So, we’ve talked about what different about virtual server backup compared to the old ways and some key things to examine about your needs and what features you might expect in a backup product for virtual servers. Look out for more in-depth articles and breaking news on the subject of virtual machine backup on ComputerWeekly.com. That’s the end of the podcast.