While many customers are rushing to implement server virtualization projects with VMware ESX Server, very few are giving serious thought ahead of time to data protection of their new virtual servers. This oversight means that many customers have unanswered questions about the best backup method for their environment -- or worse, they may have taken a step in one direction only to learn it was the wrong direction. To help them avoid those problems, find out what the options are for VMware backup and how to decide which is best for a particular customer, in this Project FAQ with George Crump, president and founder of Storage Switzerland. George also examines other techniques and tools that make sense for VMware data protection. You can read the FAQ below or download the supplementary podcast, which expands on two key questions in the FAQ.
Download for later:
Listen to the supplementary podcast with George Crump
• Internet Explorer: Right Click > Save Target As
• Firefox: Right Click > Save Link As
When a customer implements VMware, data protection is often an afterthought or at best, the customer assumes that data protection can be handled just like it was before virtualization. No matter which camp a customer falls in, there are three options for VMware data protection. The most common is guest OS backup. This method essentially treats each virtual machine (VM) as if it were a physical host, with the backup software's agent deployed within each virtual machine.
The second option is console backup. This method backs up at the physical host layer as if the virtualization host were a Linux server, and a Linux agent is often deployed. The third option is VMware Consolidated Backup (VCB); it allows for off-host backup and recovery of the physical host and virtual machines.
Guest OS backups are the most popular approach with customers because the method most closely emulates what customers are familiar with, a (virtual) machine-by-machine backup.
Before you go down that road, though, you'll need to advise customers on the ramifications of this type of backup. First, it limits the number of virtual machines per host because if each backup job executes simultaneously, the performance on the host can be affected adversely and, in a worst-case scenario, the backup operation may cause a crash.
Second, even if the backup administrator carefully plans the backup schedule to limit the number of guest OS backups happening at the same time, it's extremely likely that new virtual servers won't be picked up by the backup administrator.
Third, guest OS backup does not protect the key VMware host files needed to recover the VMware host itself. An additional backup job will have to be created, monitored and maintained for full protection of the VMware environment.
Techniques like block-level incremental backups can aid significantly in guest OS backups by minimizing the client impact and the amount of data to be transmitted, making guest OS backup a viable option. But without block-level incremental, guest OS backup is too expensive administratively and too risky.
The Service Console is a special virtual machine based on Red Hat Linux that runs on each ESX server host. Backing up ESX servers via VMware's Service Console is the inverse to backing up using the guest OS backup method. The Service Console method backs up the ESX server as THE operating system, and the virtual machines are just "files" under that OS.
With this method, a Linux client is installed on the VMware Service Console. The Service Console has visibility to VMFS, the VMware File System, which contains VMDKs, various VM and ESX configuration files, and redo log files.
The challenge with this backup method is that you can't restore individual files within the virtual machines. While console backup will work for customers that have a Linux client and can't afford to invest in one of the other protection strategies, it's not the best option.
First of all, it's important for both you and the customer to understand that VCB requires a shared SAN environment; NAS-based VMware environments don't support VCB, nor does direct-attached storage (DAS). Second, the backup software a customer uses for all their servers needs to support VCB. Third, they'll need enough excess capacity on the SAN to store the backup Virtual Machine Disk Format (VMDK) images. Finally, VCB backups require a Windows server to act as a proxy. For many customers, these prerequisites may be prohibitive, while other customers might be ready for VCB from Day 1. For the latter group of customers, implementing VCB isn't very difficult; it will enable them to recover both individual files and full VMDKs and protect the VMware host's primary files.
Deduplication counts on repetitive data to be effective, and VMware delivers. Probably more so than any other file system, VMware has plenty of redundant data that can be eliminated; deduplication is one of the best processes to introduce into the VMware backup process. Not only are there redundancies between files, but also the files themselves are redundantly backed up. With a VMDK, the disk image of a virtual machine typically has to be backed up completely. There are limited ways to back it up granularly, and both of these factors make data deduplication a must-have addition to your customer's backup plans.
With deduplication, you can easily use some of the built-in VMware tools to protect both the VMDKs and VMware host configuration files. Deduplication appliances can also be used as a target for backups generated by VCB.
This efficiency and flexibility make deduplication an ideal addition to any VMware protection process.
In two ways: First, you can leverage the NAS' snapshot capabilities to provide granular restores of the files within the VMDK. Second, you can use Network Data Management Protocol (NDMP) to back up those hosts. This provides an ideal off-host backup option and is important because VMware's own VCB does not support NAS- or NFS-mounted VMDKs.
What is the best way to move VMware backups off-site for disaster recovery purposes?
There are several options here. First, you can use the array-based replication provided by a shared storage solution. If your storage solution supports VMware's Site Recovery Manager (SRM), it makes sense to talk to your customers about that as well. SRM provides DR workflow automation.
Second, you could leverage one of the data deduplication or block-level backup solutions to use their replication feature to move data to a DR site. The VMDKs could then be recovered on a regular basis, and you could even automate this for the customer and provide an inexpensive near-real-time updated DR site for your customer.
There are two primary tools provided for VMware: Vmkfstools and vcbMounter. When Vmkfstools is executed, a specific VMDK file can be copied from the VMware file system to a standard file system mounted by the Service Console. The VMDK files are separated into 2GB files to maintain compatibility with standard file systems.
Vmkfstools only works on VMDK files, and the VMware administrator must manage shutting down the VM or creating a redo log for the virtual disk. It is not as effective as vcbMounter for backup and recovery. This tool is more appropriate as a way to move a virtual machine between VMware platforms.
vcbMounter, on the other hand, is used to export a backup copy of the virtual machine. The command is also invoked at the command line or can be part of a script. With vcbMounter, you can indicate the name of the virtual machine to back up and the destination directory for the target backup.
All the files needed to re-create or restore the virtual machine are also exported by vcbMounter to produce a complete file-system-consistent backup copy of the virtual machine. As a result, vcbMounter is better suited for backup and disaster recovery than the Vmkfstools utility because it ensures this consistency.
Working alongside vcbMounter is vcbRestorer, which imports a copy of a virtual machine created by vcbMounter and can be used to completely recover a virtual machine to its original state to the original ESX server host. It can also be invoked on a separate ESX server in a disaster recovery situation.
These tools are ideal adjuncts to a network-mounted deduplication device.
Anything that is "on-host" for backup is likely to cause performance issues. As the number of virtual machines increases, these performance issues multiply. The number of virtual machines also limits your ability to schedule around those performance bottlenecks. Block-level incremental backup and source-side deduplication limit the amount of time each virtual machine is impacted by the backup; block-level incremental backups, in particular, require very little in the way of compute resources.
Most off-host backups have no impact on the number virtual machines, which explains why so many of your customers are considering the options. As virtual environments scale, you need to be prepared to offer either block-level incremental backup technologies or off-host backup technologies.
About the author
George Crump is president and founder of Storage Switzerland, an IT analyst firm focused on the storage and virtualization segments. With 25 years of experience designing storage solutions for data centers across the United States, he has seen the birth of such technologies as RAID, NAS and SAN. Prior to founding Storage Switzerland, George was chief technology officer at one of the nation's largest storage integrators, where he was in charge of technology testing, integration and product selection. Find Storage Switzerland's disclosure statement here.