Top 8 VMware vSphere backup best practices

1. Don't back up virtual machines at the guest OS layer

With traditional servers, you typically install a backup agent on the guest operating system that the backup server contacts when it needs to back up the data on the server. But this method isn't efficient in a virtual environment because it causes unnecessary resource consumption on the virtual machine (VM) that can impact its performance, as well as the performance of other VMs running on the host.

You should instead back up the data at the virtualization layer; this means using image-level backups that back up the large .vmdk file without involving the guest OS.

To do this, you must use a backup application that is designed to work with virtualization and that can back up the VM's virtual disk directly without involving the guest OS or the host. This will eliminate the resource consumption that normally occurs when backing up a VM at the guest OS layer and will ensure your VMs get all the resources they need for their workloads.

2. Leverage vStorage APIs

The vStorage APIs were introduced with vSphere as a replacement for the VMware Consolidated Backup framework that was released with VMware Infrastructure 3 to help offload backup processing from the host. Not only do they enable easier access to a VM's virtual disk file, but they also contain features that can improve backup speeds, such as the Changed Block Tracking (CBT) feature.

CBT is a feature that keeps track of any blocks that have changed since the last backup so a backup application can simply query the VMkernel to find the information. This operation means the backup application no longer needs to track changed data, which allows for a much quicker incremental backup.

The vStorage APIs provide a much more efficient mechanism for vSphere backup, and you should use applications that take full advantage of them.

3. Know how quiescing and VSS works

If you're backing up VMs that include transactional applications like database and email servers, it's critical that you quiesce them so they are in the proper state to be backed up.

This type of backup state is called an application-consistent backup -- before the backup begins, applications are paused so any outstanding writes and transactions can be written to disk. This ensures the server is in the proper state so no data is lost if a VM recovery is needed. This type of quiescing only works with applications that specifically support pausing and writing pending data when necessary. 

VMware Tools contains a driver that works with Microsoft Volume Shadow Copy Service (VSS) to quiesce applications before they are backed up. This VMware Tools driver hasn't always supported all the Windows operating systems in the past, so many vendors have come up with their own drivers instead.

Therefore, you should make sure you are using a supported VMware Tools driver or have installed the vendor-supplied driver on your VMs. Also, make sure that the VSS service isn't disabled and that everything is configured properly to perform an application-consistent backup.

4. Don't skimp on backup resources

To ensure that you have the shortest backup windows possible, make sure you have adequate hardware for your backup server so it doesn't become a bottleneck when performing backups. While having adequate network bandwidth is critical for vSphere backups, having enough CPU and memory resources is, too.

Your backup server is doing more than just moving data from a source server to a target storage device -- it's also doing things like data deduplication and compression to help reduce the size of backup sets. These processes require a lot of CPU and memory to help keep up with all the data that is flowing through the server.

Make sure you follow your backup vendor's hardware recommendations for the backup server. This is one area where it can't hurt to give the server more than it needs. Backups can slow down dramatically if the backup server does not have adequate resources.

There are many third-party tools that can help you with backups. For example, Veeam and Unitrends offer products designed for vSphere backup. Test them out and check user reviews, as products vary in broadness.

5. Snapshots are not backups

Virtual machine snapshots should never be used as the primary backup means. Snapshots are OK for short-term, ad hoc backups of VMs, but you incur penalties when you use them.

When a snapshot is created, all the writes to the VM's disk file are deflected to a new delta disk file and the original disk becomes read-only. The delta disk file grows in 16 MB increments as data is written to it, and each growth increment causes a lock on the LUN on which it resides that can degrade performance. The more snapshots you have running, the more you can impact the performance of all the VMs running on the LUN.

Snapshots also take up additional disk space on your data stores; each one can grow up to the size of the original disk. If you run out of disk space on your data stores, all of your VMs will shut down.

Merging snapshot data back into the original disk when you delete them is also a heavy I/O operation that can affect the performance of VMs. In addition, because snapshots are creating new virtual disks that link back to the original, some features may not be available. This can also cause problems with the mapping between the original disk and its snapshots. Use snapshots sparingly and delete them as soon as you no longer need them.

6. Schedule your vSphere backup carefully and test

Backups in a virtual environment can strain resources because of the shared virtualization architecture. As a result, you should plan your backup and restore schedule to avoid putting too much concentrated stress on a single resource.

For example, don't back up too many VMs on the same host or the same LUN concurrently. Try to balance your backup schedule to even out the resource usage so any one resource is not getting overused. Otherwise, your backups may slow down and degrade the performance of your VMs.

But you'll never know if your vSphere backup is ready for recovery unless you test. Testing your backups can help you figure out potential recovery issues, and you can troubleshoot from there. It also gives you a chance to analyze your backup tools and see if you may need to switch products.

7. Know your Fault Tolerance backup alternatives

Almost all virtualization backup products that use image-level backups utilize VM snapshots to stop writes to the virtual disk while backups are running. The VMware Fault Tolerance (FT) feature uses two VMs, a primary and a secondary, that are located on separate hosts, but they both share the same virtual disk file.

Currently, the Fault Tolerance feature doesn't support VM snapshots, which can make backing up FT-enabled VMs a challenge. To get around this limitation, you need to look at alternatives for backing up these VMs.

One way to back up FT-enabled VMs is to temporarily disable the FT feature while the backup is running, which allows snapshots to be taken. Disabling this feature preserves the secondary VM so it can be easily enabled again once the backup completes. It is possible to use PowerShell to automate this, and by using pre- and post-backup scripts, you can automate the whole process.

Another method is to create another copy of the VM by cloning it using either vCenter Server or the vCenter Converter. This creates a new copy of the VM that you can back up, and the clone can be deleted afterwards. You can also use storage-level snapshots or back up the VM using an agent installed in the OS.

8. Back up host and vCenter Server configs

If you ever lose a host or vCenter Server, you can easily rebuild it, but you'll lose all your configuration information. Therefore, it's a good idea to periodically back up the information.

When you have a backup host, you're typically only backing up the VMs and not any of the individual files that reside in the host's management console. While you shouldn't back up the files inside the management console, you should back up the configuration information to make it easier to rebuild the host.

For ESX hosts, you can use the esxcfg-info Service Console command, which will output a ton of configuration information into a text file. For ESXi hosts, you can use the vicfg-cfgbackup command that's part of the vSphere CLI to output configuration information to a text file.

With ESX hosts, you cannot restore the information from the esxcfg-info output, but at least you will know what you need to reconfigure. For ESXi hosts, you can also use the vicfg-cfgbackup command to restore a host's configuration.

For vCenter Servers, it's critical for you to back up the database that contains all the configuration information that is unique to the server. This includes configuration information on clusters, resource pools, permissions, alarms, performance data and much more. With a good database backup, you can simply reinstall vCenter Server and point it to the database and you'll be back up and running.

Also, make sure you back up the vCenter Server Secure Sockets Layer (SSL) certificate folder that is located in the vCenter Server data directory. This contains the SSL certificates vCenter uses to communicate securely with ESX and ESXi hosts, as well as clients.