Top five issues in VM backup

1. Don’t treat virtual machines as physical machines

The easiest way to secure virtual environments is to back them up using the same process as a physical server. Unfortunately, easiest isn’t always best, and continuing to use legacy backup processes can lead to many problems. These include:

• Resource constraints – Where backups are run using agents that follow the traditional method of moving data from disk, through the host and network to the backup server, bottlenecks are inevitably experienced. Where once one app was backed up from one physical server now many apps on many virtual servers contend for resources on host, network and storage.
• Licensing costs – Where backup software is licenced by the number of clients, backup costs can easily escalate. Also, assigning a licence to VMs that may be transient can become a management nightmare.
• VM portability – VMs can be dynamic, moving around the infrastructure, especially when features such as vMotion are used. Backing up VMs based on their physical location on the network can result in failed backups and manual effort to locate and resolve problems.

Traditional backup tools should be avoided unless they specifically support and perform backup of virtual environments using a hypervisor-based backup application programming interface (API), such as VMware vStorage API for Data Protection.

2. Make sure to manage application synchronisation

Virtualisation introduces another layer of complexity in the application stack. Data is often active in the storage layer (including in external arrays), the hypervisor, the operating system and the application, each of which maintain buffers of data to improve performance.

Unless these layers are synchronised during the backup process, it’s easy for uncommitted data not to be backed up correctly, resulting in an inconsistent backup state. Unfortunately, this issue will only become apparent at restore time, which is clearly too late.

A good example of this is hardware-based snapshots, which must be taken in conjunction with a quiesce and flush of hypervisor and application buffers. VMware Tools in the VM guest and Microsoft's Volume Shadow Copy Service  – both for VMware guests and on Microsoft Hyper-V – provide application support for taking consistent backups across the entire application stack.

Look for hardware-based systems that integrate with the hypervisor and the application, or software systems that are able to make use of hardware-based snapshots.

3. Manage snapshots efficiently

Over time, snapshots will grow and, in particular, highly active systems can see snapshots grow to the size of the original data. So, care needs to be taken to ensure snapshots are managed effectively.

Depending on the hypervisor platform, this will mean integrating or expiring snapshots in a timely fashion after an external backup has been taken. If snapshots are not managed correctly, systems will experience problems with datastore capacity and performance.

It’s worth remembering a snapshot is not an effective long-term backup. Snapshots depend on the original VM image – typically tracking and storing changed blocks from that image – and generally reside on the same physical media.

The VM and the snapshots can be easily lost if a hardware failure occurs. Snapshots should form part of an overall backup strategy and be used for short-term recoveries and as a way of isolating data and creating a consistent point-in-time image for backup outside the virtual environment.

4. Make sure to test restores

VMware recently revealed a bug in the Changed Block Tracking (CBT) process in ESXi meant backups of virtual machines more than 128GB in size were potentially corrupted.

Without regular testing, silent issues like this can have disastrous consequences when data needs to be restored. The restore process should be regularly tested against a set of virtual machine configurations to be sure the backup process is working correctly.

The restore process itself is a vital consideration when designing a VM backup strategy and choosing products.

Certain backup techniques require restoration of the entire VM to recover just a single file. This may not be practical, due to lack of disk space and time constraints, especially in distributed small office configurations where deployment cost is critical. So, it is important to ensure the restoration of data meets the requirements of the application and business users.

5. Track your virtual machines

Virtual machines are transient by nature and depending on the purposes of the environment may not last as long as their physical equivalent. Virtualisation enables systems to be upgraded by building out a new VM and migrating data. 

It’s a far cheaper and quicker system than could be achieved with physical servers. In development environments, virtual machines may last only days or weeks although the system and data may be needed for future use.

As a result of the way in which VMs are used, it can become very easy to lose track of where a virtual machine originally resided and which system performed the backup. This problem – a feature of VM sprawl – can be exacerbated in large environments that have many virtual platforms (and potentially many backup systems) run by a centralised team.

Administrators should look to maintain documentation or implement systems that track VMs in their inventory, even after the VM has been deleted from primary storage and isn’t part of the VM infrastructure. An alternative is to look for systems that permit VM archiving. Although this isn’t strictly backup, it does allow the VM to be retained for future use.