[This is an excerpt from our Six Fairy Tales of VMware and Hyper-V Backup whitepaper. Download the full whitepaper for instant gratification.]
A couple of days ago, I discussed the fairy tale that VMware host-level backup works with all VMware host environments. There are two other common fairy tales about VMware host-level backup going around. The first is that VMware host-level backup works with all deduplication strategies. The other is that VMware host-level backup has problems when you operate it on Microsoft Windows guest operating systems. Both are absolutely false. Let’s break down the first fairy tale.
Although the word “deduplication” sounds fancy, deduplication simply refers to the elimination of redundant data so that you get more backup storage per dollar spent. There are two primary forms of deduplication: source-level and target-level. Source-level deduplication has the advantage of potentially utilizing less network bandwidth. However, it uses much more processor, memory, and other resources from the computer that you are protecting. Target-level deduplication does not use the resources of the computer that you are protecting, but it has the potential disadvantage of using more network bandwidth.
Source-level deduplication does not typically work well with VMware host level backups for two reasons. The first is that VMware host-level backup has less redundant data through the use of CBT (Changed Block Tracking) – a technology that allows the backup of only the changed blocks within VMware. The second, and more important, is that source-level backup takes precious resources away from the computer running VMware that is hosting the virtual machines. This is one of the reasons for the “sprawl and stall” phenomenon seen in virtualization projects today – increasing numbers of virtual machines are created, all underlying host-level computer resources are consumed, and the virtualization project grinds to a halt. If you use deduplication strategies with VMware that use less, not more, computer resources on the computer hosting VMware, then you’ll avoid getting eaten by the wicked witch of sprawl and stall.
The second fairy tale is that VMware host-level backup has problems when it is operated on Microsoft Windows guest operating systems. Although this used to be true, with the introduction of VMware 4.1, it is no longer. Prior to VMware 4.1, Microsoft applications running within a Windows virtual machine hosted by VMware had an issue with something called application-level quiescing. Because of application-level quiescing, when you used VADP to protect your VMware environment, the backup did not always produce crash-consistent backups for applications such as Exchange or SQL. Furthermore, when you wanted to recover applications within these virtual machines, you’d have to perform integrity tests and repair in order to attempt to recover data for these applications. VMware 4.1 introduced support for application-level quiescing.
Coming up next Tuesday, I’ll introduce two Hyper-V environment fairy tales. I’ll first disprove the idea that Hyper-V host-level backup is efficient, and then I’ll tackle the belief that source-level deduplication is an effective technique to use in a Hyper-V environment.