VMware Consolidated Backup：是希望还是炒作？

面对备份的难题，VMware 给出的答案是 VMware Consolidated Backup。要使用 VCB，需要在 ESX Server旁边部署一台物理的 Windows 服务器，并使其能够访问ESX Server 下VMFS文件系统所在的存储设备。对该存储设备的访问可以基于块（光纤通道和 iSCSI）或者基于 NFS协议。这台物理服务器以一个Proxy备份代理的角色执行虚拟机的备份，这样备份数据流就不需要经过ESX server了。

备份软件与 VMware Consolidated Backup之间有两种互相响应的方式。第一种仅限于Windows平台的VMs. 备份软件通过VCB接口程序通知VMware发起备份。VMware 调用Windows虚拟机上的VSS (Shadow Copy Service) 做一份VMware层快照，然后经过VCB将快照交给Proxy备份代理服务器，并以虚拟卷标的方式挂载（例如VM上“C：”卷的快照在Proxy备份代理服务器上以“H：”卷命名）。而后，我们可以用备份软件对这个虚拟卷做标准的全备份和增量备份。

这种方式的主要优点是可以做增量备份，不足之处是仅支持Windows平台，也没有正式的对应用程序的支持（包括支持VSS 的应用），而且不能恢复 VM 自身，只能恢复虚拟机上的文件。

另一种使用VCB的方法是针对整卷做备份。跟上面提到的类似，VMware 即可以调用 VSS 快照，也可以为非windows平台的VMs做同步镜像。用这个方法，VMDKs 裸卷在 VMFS 存储和代理服务器的存储之间被物理拷贝（也就相当于staged）。尽管ESX Server本身不会产生I/O，但VMFS 所在的存储设备还是有I/O负荷，相当于做全备份。

在利用主流的备份软件将裸卷的这份拷贝备份到磁带或者磁盘之前，实际上已经经过了一次全备份过程，这意味着每个全备份过程实际上要经过两次全备份I/O操作。除非备份软件能做进一步的处理，否则很难实现增量备份。这意味着绝大多数情况下这种VCB备份每天会产生两次全备份的I/O负荷。

Symantec 和 CommVault 想出了做增量备份的办法。Symantec 可以针对整卷做全备份，然后在文件级实现增量备份，这都依赖于 Veritas NetBackup备份软件的 FlashBackup 技术。Symantec通过实现增量备份，明显地降低了存储设备端的I/O负荷；然而，在恢复时仍然需要很多的步骤。首先恢复整卷的全备份，然后再依次恢复它的每一次增量备份。至少可以说这种恢复方法比较麻烦。

CommVault 的解决方案是对裸卷做块级增量备份，与Symantec的方法相比，CommVault属于更精确的增量备份，能够提供更简单（也可能更快速）的恢复能力。然而，CommVault 的方法仍然需要在生产端存储设备和proxy备份代理服务器之间完整的拷贝整个卷，因此，在生产端存储设备上每天还会产生一次全备份的I/O负荷。

恢复一个 VM虚拟机也需要两步。首先用备份软件将相应的VM数据恢复到proxy备份代理服务器 ，然后利用 VMware vCenter Converter工具恢复到 ESX Server。如果备份软件支持VMware，通过安装在虚拟机上的Agent代理，可以直接做单个文件的恢复；但是，恢复整个 VM 则必须通过上面两个步骤完成。

所有的这些问题导致了只有相对有限的用户采用了VCB备份方案，当VMware宣称有相当广泛的客户群购买了VCB license的时候，经验告诉我，有很多持有license的用户其实还没有实施VCB。所以，我们期待VMware 的 vSphere有更好的备份方案。（参见“关于vSphere”）

本文选自《存储经理人》七八月刊，进入下载该杂志PDF。