How to Back up VMware Virtual Machines

Although virtual servers are designed to mimic physical servers, the process of backing up a VMware virtual server differs considerably. In physical datacenters, backups are commonly enabled by installing a backup agent onto each physical server. Although this approach can work in a VMware environment, it is almost always better to protect virtual machines at the host level (the hypervisor level), rather than at the guest (virtual machine) level.

There are several different reasons why host-level backups are the preferred backup type, but there are three reasons that tend to be more important than the others. 

Three reasons to do host-level backups

The first of these reasons is that many organizations have large numbers of virtual machines. It is easier to manage backups for a relatively small number of host servers than it is to manage backups for each individual virtual machine.

The second reason has to do with the backup agent that is often required when performing a guest backup. The agent probably doesn’t consume many hardware resources by itself, but the cumulative effect of running an agent on every virtual machine can be significant. Since most organizations attempt to maximize virtual machine density, it is best to avoid installing software (such as backup agents) that unnecessarily consume hardware resources.

The third reason is the most important reason of all. When a guest backup is performed, the backup software behaves as if it were backing up a physical server. This means that the backup agent cannot see beyond the confines of the guest OS. Consequently, the virtual machine’s external elements – such as its hardware configuration and its snapshots – are not backed up.

The role of VMware APIs

VMware enables host-level backups as a function of the VMware vSphere Storage APIs (formerly known as the vStorage APIs for Data Protection). This collection of APIs allows VMware hosts to be backed up from a centralized backup server, as opposed to having to run backup software directly on a host or at the guest level. These APIs are not something that an administrator would typically use to back up a VMware host. Instead, backup vendors leverage the APIs as a way of adding VMware support to their products. The APIs are supplied by VMware, and handle all of the heavy lifting. The backup vendors simply integrate these APIs into their products.

The vSphere Storage APIs are designed to use changed block tracking when backing up hosts. Changed block tracking is a mechanism that keeps track of storage blocks that have been modified since the last backup. The backup application can reduce the amount of time required to create a backup by backing up only the blocks that have been modified since the last backup was run.

As helpful as the changed block tracking mechanism is, backups of application servers must be transactionaly consistent in order to be viable. In other words, the backup application must create an application consistent backup in order to avoid data loss or corruption. This can be accomplished through a process known as “quiescing”. 

Quiescing and how it works

The quiescing process works differently depending on the backup application that is being used, and on the operating systems and applications that are being run on the virtual machines. In the case of Windows virtual machines, the backup process typically leverages the Microsoft Volume Shadow Copy Services (VSS). VSS is able to create a point in time view of a volume, and can be used to create application consistent backups of supported applications. This is only possible however, if the VMware VSS component is able to use an application VSS writer for the application that is running on the virtual machine. Otherwise, the backup will be file system consistent, but not application consistent.

Most backup providers leverage the VMware VSS component within the VMware Tools in order to quiescence virtual machines. Of course, not every virtual machine runs Windows. Some backup vendors therefore provide a mechanism for quiescing non-Windows virtual machines. 

It’s important to be aware that there are limitations to host-level backups. For example, they are only possible when the backup provider has access to the hypervisor management layer; in the case of VMware this means access to vCenter of vCloud Director. However, when using virtual machines from an Infrastructure as-a Service (IaaS) provider, this is often not possible. In this case, a backup solution running within the virtual guest is still required, with the option to restore to the IaaS platform.

Regardless of which backup application an organization chooses to use, it is important to use an up-to-date version of the application. The backup application must support the specific version of VMware that you are running, and must also include support for the operating systems that are running on your virtual machines.

MAX Backup supports both backups at host-level and at virtual guest level. For managed service providers supporting a mix of systems, MAX Backup can be used in the following ways:

• Physical systems: Backup at physical system
• VMware/Hyper-V: Backup at host-level (and additional of course backup at virtual guest level)
• IaaS virtual systems: Backup at virtual guest level