这就是VSS在物理服务器上是如何工作的。挑战在于，当通过基于主机的备份来保护虚拟机时，这些组件位于何处，以及它们之间如何互相配合。为使其能够工作，必须产生两个层面的数据会话：首先在备份服务器和虚拟机监控器（主机）之间，然后在客户操作系统和主机或备份服务器之间。

对于虚拟服务器的工作负载，Microsoft的 Hyper-V有其自身的VSS Writer。在Windows客户操作系统中自动安装的Hyper-V集成组件（IC） 中已包含有VSS请求者。

因此，考虑到这几点，让我们重新检查一下这八个步骤：

从主机的角度：

1 和 2. 备份软件的代理运行在Hyper-V 主机之上，并且由于主机上的VSS Writer，将Hyper-V识别为可被保护的对象。

3. 备份软件发出备份特定VM的请求

4. Hyper-V 主机的 VSS Writer为需要备份的工作负载执行所需的工作。在本例中，它使得VM就绪。

这就是其有趣的地方，由于主机的VSS Writer使需备份的虚拟机就绪的方式是告知客户机的Hyper-V IC的VSS请求者，让其作为备份代理，于是整个的过程转移到客户机内部，因此产生了术语“递归式VSS”。

在客户机内部：

1, 2 和 3. Hyper-V IC的 VSS 请求者发现具有 VSS能力的工作负载加以保护，诸如SQL Server 或 Exchange，通过它们的 VSS Writer，然后通知这些需要备份的工作负载 。

4. 基于客户机的应用为备份执行所需的准备工作（清除转储日志, 清除缓存等）。

5. 在工作负载宣称已经备份就绪后，工作负载的VSS Writer通知客户Windows操作系统的VSS提供者其数据已经就绪。

6. 在接受到工作负载的通知后，Windows 操作系统的 VSS 提供者为数据卷建立快照.

7. Hyper-V IC 的VSS 请求者随后通知其请求的备份服务器（实际上就是Hyper-V），VM已处于受保护状态，并包含一个应用一致的、基于软件的快照。

现在客户机内部处于保护状态，它的容器（逻辑的VM）也准备好接受保护。别忘了，在基于主机备份的模式中，整个VM就是作为备份的工作负载。因此和其它基于VSS的工作负载一样，一旦其就绪，原有的备份进程将继续。

现在主机进程继续：

5. Hyper-V主机的VSS Writer通知主机的 VSS OS以及底层的VSS 提供者，VM已经为快照做好准备。

6. VSS 提供者为VM的虚拟硬盘（VHD）所驻留的卷建立快照。

7. 发起备份的基于主机的备份代理被授予对快照的访问权限并为备份服务器提供VHD。

这就是递归式VSS如何工作的。这并非意味着所有启用VSS备份解决方案都是一样的，甚至仅对于Hyper-V而言。不同Hyper-V 备份解决方案的差异包括：

•可管理性和调度。

•对于VM之间的通用对象的重复数据删除，如Windows操作系统文件。

•与更高层管理功能的集成，无论是System Center 或 Hyper-V 控制台；这点对于动态创建的私有云场景尤其重要。

•从基于主机的备份中恢复单个项目的能力（无论是否通过VM中的代理）。

•清除VHD中额外的“垃圾”，来源于在客户机VSS提供者为逻辑文件系统建立应用一致的快照时以及主机VSS提供者为实际的VHD文件建立快照时，两个时间点之间产生的微小的差距。

•形成闭环，因此基于客户机的应用知道其已被成功备份，可继续其备份后的管理工作。

必须指出此流程之所以可以工作是由于从主机Hyper-V VSS Writer到客户机内部VSS组件的全程VSS启用。这些流程对于VMware和vSphere 5 vStorage 数据保护API（VADP）可能稍有不同。大多的VMware备份解决方案通过客户机的VSS机制可以实现相同的基于客户机的工作流程，不过它们基于主机的流程则有相当大的差异。

如果你选择采用基于主机的保护策略，请确保你理解主机/客户机交互的关键点，以及一些关键特性，如客户应用日志截断，以及递归过程中VHD的清理，这可能会导致两种不同的结果：成功的恢复或某些不可以的VHD和VMDK。

请回顾：为何递归式VSS有益于备份虚拟Windows服务器（一）：VSS 入门

作者简介：Jason Buffington，ESG数据保护高级分析师。他在IT行业已有超过20年的经验。

本文选自：存储经理人2012年6月刊：解密对象存储