What you will learn in this tip: The architecture and operation of a virtual environment is much different than a traditional backup environment and demands specific data backup techniques. In this tip, you'll learn the top VMware vSphere backup best practices.
When it comes to backing up virtual machines in VMware vSphere, you need to leverage the strengths of virtualization to maximize your backup efficiency. You also need to know what to back up as well as how to back it up. In addition, you can't use the same principles that you use in a traditional environment to back up a virtual environment. The following are eight vSphere backup best practices.
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 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 designed to work with virtualization, and can back up the VM's virtual disk directly without involving the guest OS and/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 can for their workloads.
Leverage the vStorage APIs
The vStorage APIs were introduced with vSphere as a replacement for the VMware Consolidated Backup (VCB) framework that was released with VI3 to
help offload backup processing from the host. Not only do they allow for 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 out. This quick operation means the backup application no longer needs to track this, which allows for much quicker incremental backups. The vStorage APIs provide a much more efficient mechanism for backing up VMs and you should use backup applications that take full advantage of them.
Know how quiescing and VSS works
If you're backing up VMs that have 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 where before the backup begins applications are paused so any outstanding writes and transactions can be written to disk. This ensures the server is in a proper state so no data is lost if a restore is needed. This type of quiescing only works with applications that specifically support being told to pause and write 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 Windows operating systems in the past, so many vendors have come up with their own driver instead. Therefore, you should make sure you are using a supported VMware Tools driver or have installed the vendor supplied driver on you VMs. Also make sure that the VSS service isn't disabled and everything is configured properly to perform an application-consistent backup.
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, 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 backups. These types of 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 the backup vendor's hardware recommendations for the backup server. This is one area where it can't hurt to give it more than it needs -- backups can slow down dramatically if the backup server does not have adequate resources.
Snapshots are not backups
Virtual machine snapshots should never be used as a primary backup means. Snapshots are OK for short-term ad hoc backups of VMs but there are penalities that are incurred when using them. When a snapshot is created, all 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 that it resides on that can degrade performance. The more snapshots you have running, the greater you can impact the performance of all the VMs running on the LUN. Snapshots also take up additional disk space on your datastores -- each one can grow up to the size of the original disk. If you run out of disk space on your datastores, 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 the VM. In addition, because snapshots are creating new virtual disks that link back to the original, this can cause some features to not be available, and can also cause problems with the mapping between the original disk and its snapshots. As a result, use snapshots sparingly and delete them as soon as you no longer need them.
Schedule backups carefully
Backups in a virtual environment can strain resources because of the shared virtualization architecture. As a result, you should plan your backup 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 overutilized. If you do not, your backups may slow down and also degrade the performance of your VMs.
Know your Fault Tolerance backup alternatives
Almost all virtualization backup solutions that use image-level backups utilize VM snapshots to stop writes to the virtual disk from happening while backups are running. The VMware Fault Tolerance (FT) feature uses two VMs, a primary and a secondary 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 the VM. One way is to temporarily disable the FT feature while the backup is running, which allows snapshots to be taken. Disabling preserves the secondary VM and 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 either through vCenter Server or using the vCenter Converter. This creates a new copy of the VM that can be backed up with the clone deleted afterwards. You can also use storage-level snapshots or back up the VM using an agent installed inside the OS.
Don't forget to back up host and vCenter Server configs
If you ever lose a host or vCenter Server, you can easily rebuild them, but you lose all your configuration information. Therefore, it's a good idea to periodically back up the information. When you back up a host, you're typically only backing up the VMs and not any of the 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 a 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. For ESX hosts you cannot restore the information from the esxcfg-info outout but at least you will know what you need to reconfigure. For ESXi hosts, you can also use the vicfg-cfgbackup command to restore configuration to a host. For vCenter Servers, it's criticial to back up the database it uses that contains all the configuration information that is unique to vCenter 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 SSL certificate folder that is located in the vCenter Server data directory. This contains the SSL certificates that are used to communicate securely with ESX and ESXi hosts as well as clients.
As you can see, although VMware has eased virtual machine backup in the latest version of vSphere, but there are a number of things to watch out for. These eight vSphere backup tips will help make vSphere backup a little less painful.
About this author: Eric Siebert is an IT industry veteran with more than 25 years experience covering many different areas but focusing on server administration and virtualization. He is a very active member in the VMware Vmtn support forums and has obtained the elite Guru status by helping others with their own problems and challenges. He is also a Vmtn user moderator and maintains his own VMware VI3 information website, vSphere-land. In addition, he is a regular blogger and feature article contributor on TechTarget's SearchServerVirtualization and SearchVMware websites.
This was first published in January 2011