在服务器虚拟化处在一个何时需要而非是否需要的阶段，当以操作系统为中心(客户机层)的备份转变到基于主机(虚拟机监控器)的保护时，理解备份策略如何变化是非常重要的。更重要的是，并非所有基于主机的备份方法都一样，特别是对于一些事务型的应用诸如Microsoft SQL Server或Exchange.
根据企业战略集团(ESG)的研究，46%的IT环境仍给它们的虚拟化服务器进行基于客户机的备份。即便是对于所有基于主机和基于阵列方法备份的虚拟机，其中的20%仍将基于客户机备份视为主要的保护手段，这究竟是什么原因呢?
我并没有遇到太多固有地坚持在每一虚拟机(VM)中部署和管理备份代理的人，但他们通常都觉得不得不这么做。绝大部分的原因看起来都是具体应用的问题。例如，数据库如SQL Server在备份时必须是应用一致的，同时当备份结束时，它必须被告知以便其可以进行日志截断和其它数据库管理任务。
大多数的备份应用利用虚拟机监控器的能力来通知即将进行备份的基于客户机的应用，以便其将自身置于备份就绪的状态，这里我们将使用SQL Server作为例子，不过这也适用于其它的应用。
VSS入门
对于许多基于Windows服务器的应用，Microsoft提供称为卷影复制的服务(VSS)作为核心的基础设施来使能备份。除了Windows操作系统中的VSS基础外，还有三个主要的组件：
1. VSS请求者 包含的组件通常可以在启动备份流程的传统备份代理(通常来自第三方)中找到。
2. VSS Writer 位于应用中的组件(如SQL Server,Exchange或Windows文件系统)中，通过执行诸如清除转储基于内存的事务或其它备份工作来确保工作负载已经备份就绪。
3. VSS提供者 位于存储层的组件(基于操作系统软件或基于硬件)，为被保护的数据集拍摄快照。
本质上，基于VSS的备份任务可以分为八个相对简明的步骤：
1. 备份代理的VSS请求者询问具备可备份能力的工作负载。
2. VSS列举所有已注册其VSS Writer的工作负载。
3. 备份代理的VSS请求者要求工作负载为备份做好准备。
4. 工作负载的VSS Writer为将要备份的工作负载执行所需的特定工作。
5. 准备工作完成后，工作负载的VSS Writer通知VSS和VSS提供者其数据已经就绪。
6. VSS提供者为数据集拍摄快照并通知VSS请求者它已经得到数据。
7. VSS请求者引用VSS提供者的快照(通常是临时的)并将 适当的数据发送至备份服务器。
8. 一旦备份完成并得到备份服务器的确认，VSS会通知VSS提供者，告知其可以释放快照数据，以及告知VSS Writer它的数据是安全的。然后工作负载可以做备份后的维护工作。
这就是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”.
