This article can also be found in the Premium Editorial Download "Storage magazine: Everything you needed to know about object-based storage."
Download it now to read this article plus other related content.
That’s how a recursive VSS operation works. This doesn’t mean all VSS-enabled backup solutions are the same, even just for Hyper-V. Differentiators among Hyper-V backup solutions include:
- Manageability and scheduling.
- Deduplication of common objects across VMs, such as Windows OS files.
- Integration with higher level management functions, whether it’s System Center or the Hyper-V console; it’s especially important as part of a dynamically created private cloud scenario.
- Ability to recover individual items from within a host-based backup (with or without an agent in the VM).
- Cleaning up the extra “junk” within the VHD during the minor gap between the time the guest VSS Provider snapped its logical file system with application-consistency and when the host VSS Provider snapped the actual VHD file.
- Closing the loop so the guest-based application knows it’s been successfully backed up and can proceed to its post-backup management tasks.
It should also be noted this process works because it’s VSS-enabled all the way from the host’s Hyper-V VSS Writer through the VSS components inside the guests and back again. The process is somewhat different with VMware and the vSphere 5 vStorage APIs for Data Protection (VADP). Most VMware backup solutions achieve the same guest-based workflow because they leverage the guests’ VSS mechanisms, but their host-based processes
If you choose to adopt a host-based protection strategy, be sure to understand the key aspects of the host/guest interchange, as well as important features such as enabling guest-application log truncation and cleanup of the VHDs during the recursive process. That could be the difference between a successful recovery and some unusable VHDs or VMDKs.
This was first published in June 2012