在服务器虚拟化处在一个何时需要而非是否需要的阶段，当以操作系统为中心（客户机层）的备份转变到基于主机（虚拟机监控器）的保护时，理解备份策略如何变化是非常重要的。更重要的是，并非所有基于主机的备份方法都一样，特别是对于一些事务型的应用诸如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它的数据是安全的。然后工作负载可以做备份后的维护工作。[page]
    这就是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.

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。