NetBackup 通过 VCB 备份 VI 3.x/vSphere 4 的虚拟机时，总会是不是的发现某些 VM 出现 156 号错误，显示快照建立失败，如何去处理呢？

典型的报错如: Creating a quiesced snapshot failed because the created snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine.

总的思路：确定真的是不能通过 VCB 成功备份再考虑传统的备份方法。

解决步骤(需要说明的是 VMware Tools 的安装和卸载需要重启服务器才能生效，需要慎重使用)：
1. 查看是否安装了最新的 VMware Tools，如果不是则尝试升级到最新版本；
2. 如果还是不行，则再次卸载 VMware Tools，然后将 sync driver 这个服务设置为 disable，同时设置 VSS 服务为 Automatic。之后再次安装 VMware Tools；
3. 如果还是不行，则尝试在需要备份的虚拟机负载较低的时候发起 VCB 备份，看看是否能够备份成功；
4. 如果还是不行，有两个选择：
1). 在 NetBackup 中设置对这台虚拟机备份的策略，在 Snapshot client options 中设定 disable VM quiesce 为 1，即在创建快照前不需要 quiesing 的动作，但需要强调的是如果不进行 quiesing 的动作，则不能保证备份的有效性，在恢复时有可能造成某些文件丢失和部分应用的出错；
2).  只能老老实实的安装传统的备份 Agent 通过传统方式备份了。不过还是有选择的，可以选择通过对文件系统（分区）级别的快照来加快备份速速，我在这里就不详细描述了。

#####
# 新的解决方法
######################################

上面所记录的是几个月前我对 NBU 通过 VCB 备份出现 156 错误的总结，今天看了两篇 VMware 的官方文档，有了新的认识。
文档一：Troubleshooting Volume Shadow Copy (VSS) quiesce related issues
文档二：Unable to take a quiesced VMware snapshot of a virtual machine

总的思路：

1. 卸载当前机器上的 VMware Tools，重启虚机；
2. 登录虚机，在重新安装 VMware Tools 之前，确保如下两个服务（其目的是为了安装 VMware Tools 时能够成功安装“VMware Snapshot Provider”服务）：
a. “COM+ System Application Service” 服务开启，设置其启动类型为 Manual;
b. “COM+ Event System Service” 服务开启，设置其启动类型为 Automatic;
如果符合上面的两个条件，开始安装 VMware Tools，之后重启虚机。
3. 重新尝试在 NBU 上发起 VCB 备份策略，在备份的时候查看如下几个服务：
a.  确保”COM+ System Application”服务当前开启，其启动类型为 Manual；
b.  确保“COM+ Event System Service”当前开启，其启动类型为 Automatic；
c.  确保 “Volume Shadow Copy Service”启动类型为 Manual；
d.  确保“Microsoft Software Shadow Copy Provider Service”启动类型为 Manual；
e.  确保“VMware Snapshot Provider”服务当前启动，启动类型为 Manual。

#####
# 要重复强调的几点
##################################

对于负载较高的虚拟机，如运行着 SQL, Exchange 的虚拟机，或者虚拟机是域控制器，使用 VCB 的快照方式备份不能保证应用的一致性，推荐使用传统的备份 Agent 方式备份。如果希望做到快速恢复，可以考虑系统本身通过快照方式备份和恢复，应用使用专门的备份客户端恢复。

关于 vStorage API 相比 VCB 的优点，可以参见我之前的一篇 blog http://xuming.info/2010/01/vcb-%E7%9A%84%E7%BB%88%E7%BB%93%E8%80%85-vstorage/

NetBackup 通过 VCB 备份 VI 3.x/vSphere 4 的虚拟机时，总会是不是的发现某些 VM 出现 156 号错误，显示快照建立失败，如何去处理呢？

总的思路：确定真的是不能通过 VCB 成功备份再考虑传统的备份方法。

解决步骤(需要说明的是 VMware Tools 的安装和卸载需要重启服务器才能生效，需要慎重使用)：
1. 查看是否安装了最新的 VMware Tools，如果不是则尝试升级到最新版本；
2. 如果还是不行，则再次卸载 VMware Tools，然后将 sync driver 这个服务设置为 disable，同时设置 VSS 服务为 Automatic。之后再次安装 VMware Tools；
3. 如果还是不行，则尝试在需要备份的虚拟机负载较低的时候发起 VCB 备份，看看是否能够备份成功；
4. 如果还是不行，有两个选择：
1). 在 NetBackup 中设置对这台虚拟机备份的策略，在 Snapshot client options 中设定 disable VM quiesce 为 1，即在创建快照前不需要 quiesing 的动作，但需要强调的是如果不进行 quiesing 的动作，则不能保证备份的有效性，在恢复时有可能造成某些文件丢失和部分应用的出错；
2).  只能老老实实的安装传统的备份 Agent 通过传统方式备份了。不过还是有选择的，可以选择通过对文件系统（分区）级别的快照来加快备份速速，我在这里就不详细描述了。

一些值得期待的新功能：
1. 全集成的重复数据删除功能（Fully Integrated Deduplication），实现 Backup Client 和 Media Server 上的重复数据删除，不再需要一台单独的服务器控制 dedupe；
2. 支持 vSphere 4.0 最新的 vStorage API，改善原有的 VCB 的不足，如不再需要部署 VCB Proxy，支持 Block Level Incremental Backup (BLIB)，并实现文件级的恢复；
3. 扩展对 Hyper-V 环境的备份支持，支持对 VHD 格式文件的增量备份；
4. 支持 Windows 7 和 Windows 2008 R2 作为 Client，支持 Windows 2008 R2 作为 Server；
5. BMR 升级到 WinPE 2.1 环境。

注释：
什么是 First Avaiability (FA) Program ?
First Availability software is production ready GA software that has passed stringent Symantec release and quality criteria.   This is not an Alpha or Beta program and we encourage and fully support FA code in production environments.  The First Availability program provides GA quality software to you as soon as it becomes available.

详细内容请看：http://seer.entsupport.symantec.com/docs/336166.htm

VCB – VMware Consolidated Backup 是  VI3 时代推出的针对虚拟机备份的一个组件，目前也适用与 vSphere 4.0 的备份，可以和其他备份软件相结合，实现 Lan-Free 和 Off-Host 的备份，和新的虚拟化环境相适应，与传统的 Backup Agent 方式的备份相比，不需要在每一台 Client 上安装 Agent 了，备份时数据流不通过 VM 和 ESX Host，减少了备份对应用的影响。

但是 VCB 的缺点是：
1. 备份时产生的 Snapshot会出现各种各样的问题，如 Snapshot 创建失败，Snapshot 删除失败，某些应用程序不支持 Snapshot 在其存续期间应用会产生故障；
2. 需要一台 VCB Proxy，安装 VCB 组件，以 NetBackup 为例，一般推荐安装在 NBU Media Server 上；
3. VCB 备份需要一个大的磁盘空间，用于放置虚拟机的快照，特别是进行 Full VM 的备份时，如果同时发起多个备份，需要考虑这个 staging disk 的空间一定要足够大，不然会出现 156 错误。

随着 vSphere 的推出，引出了 VMware vStorage API 的概念，可以替换 VCB。相比 VCB，VMware vStorage API 具有如下优点：
1. 不再需要 VCB Proxy 的角色，备份服务器可以支持从存储上 ESX Host 上看到 Datastore 中备份虚拟机；
2. 不再需要一个磁盘空间用作备份时的 staging disk；
3. 提供了 changed block tracking 功能，可以实现 block 级别的差别变化，大大缩短 image-level 增量备份的时间。

vStorage API 的限制：
1. ESX Host 必须是 4.0 以上版本 (也有一种说法是支持 ESX 3.5，但未经官方证实)；
2. VM 的硬件版本必须是 7 以上；
3. 至少目前看来，支持的厂商还比较少，只有新兴的如 Veeam 等厂商的备份产品支持，NetBackup 要等到 7.0 版本才会支持，而 NetBackup 7 目前还没有正式发布。

注：有一种说法［http://www.vnotion.com/?p=181］是 vStorage 支持 ESX 3.5，只是不具备 changed block tracking 等新功能，这个功能在进行增量备份的时候还是很有用的。

名词解释:
Changed Block Tracking – CBT is a new feature in vSphere that can keep track of the blocks of a virtual disk that have changed since a certain point in time. This is extremely useful for backup and replication applications that can use this information to greatly improve incremental backup and replication times. Without CBT these applications have to figure out changed blocks on their own so being able to get this information for free using the vStorage advanced programming interfaces is extremely valuable to them.

新搭了两台 Media Server，同时作为 VCB 备份的 proxy，后端分别挂接了一台 VTL，每个 VTL 分配 16 个 Drive，磁带嘛慢慢加喽。郁闷的是，两台服务器，按照同样的步骤，但就是有一台在建立 Flash-backup 类型的备份策略时，最终总会提示“Snapshot could not be created with VMware method”。

折腾了好久，最终发现原来是名称解析问题，因为这台 Media Server 使用的 IP 之前被另外一台服务器使用过，WINS 名称和 DNS 名称不一致所致，临时通过修改 Host 文件，最终策略可用了。

之前在使用 BMR 恢复服务器时也出现过因为名称解析导致在 BMR 恢复时提示备份校验失败的现象，最终也是通过在备份服务器端手工写 host 文件的方式规避。

很多问题表现的现象都不是问题根本原因的直接体现。

两则小道消息：

1. 垃圾百度昨天不能访问，据说是因为域名没有续费；

2. Google 今天发表了公开信，考虑有可能关闭 google.cn 以及相关服务器，甚至会撤出在中国的办公机构。