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 方式备份。如果希望做到快速恢复，可以考虑系统本身通过快照方式备份和恢复，应用使用专门的备份客户端恢复。

在点击 Activity Monitor 时，出现如下报错：

在点击 Media 时，出现如下错误：

故障原因： NetBackup Master Server 的数据库所在的分区空间使用满了，为保证数据库的数据完整性，关闭了 Media Manager server 数据库。

仔细查看，可以发现某些服务器在 Netbackup\db\images\ 的文件特别大，如下图：

两种方法解决：
1. 压缩 catalog
定位到 Host Properties/Master Server/Golbal Attributes/，选择 compress catalog interval after x days。
2. 使用 ALTPATH 修改 images 这个目录的路径，这个没有具体去研究

上述两种方法是官方推荐的方法，注意第一种方法压缩 catalog 时需要注意，如果您的 Master Server 版本是 6.0.3 之前的，会存在一个问题，具体查看 http://seer.entsupport.symantec.com/docs/283528.htm

不过以上两种方法，我目前都没有采用，我只是零时将一些 catstore 文件迁移到其他地方，然后使用 nbdb_admin -start 命令启动 NetBackup 的数据库，如下图：

之后，NetBackup Database server 恢复正常。目前在考虑迁移 Master Server 到一台新的服务器上，采用备份和恢复 catalog 的方法。

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 以及相关服务器，甚至会撤出在中国的办公机构。

C:\Documents and Settings\Administrator>tpconfig -l     # 通过这个命令可以查看 Drive 状态
Device Robot Drive       Robot                    Drive                 Device

Type     Num Index  Type DrNum Status  Comment    Name                  Path

robot      1    -    TLD    -       -  -          -                     ntbbkp05

drive    -    5  hcart    2      UP  -          HP.ULTRIUM4-SCSI.017  {2,0,1,0}
drive    -    6  hcart    4      UP  -          HP.ULTRIUM4-SCSI.019  {2,0,2,0}
drive    -    7  hcart    1      UP  -          HP.ULTRIUM4-SCSI.016  {3,0,1,0}
drive    -    8  hcart    3      UP  -          HP.ULTRIUM4-SCSI.018  {3,0,2,0}
robot      2    -    TLD    -       -  -          -                     {5,0,0,0}
drive    -    0  hcart    1    DOWN  -          HP.ULTRIUM1-SCSI.000  MISSING_PATH:{3,0,1,0}:HU75C0121
drive    -    1  hcart    2      UP  -          HP.ULTRIUM1-SCSI.001  {5,0,2,0}
drive    -    2  hcart    3    DOWN  -          HP.ULTRIUM1-SCSI.002  MISSING_PATH:{6,0,3,0}:HUB6C03WA
drive    -    3  hcart    4    DOWN  -          HP.ULTRIUM1-SCSI.003  {6,0,4,0}
drive    -    4  hcart    1      UP  -          HP.ULTRIUM1-SCSI.004  {5,0,1,0}
drive    -    9  hcart    3    DOWN  -          HP.ULTRIUM1-SCSI.005  {6,0,3,0}

可以看到 robot 2 下面多出了两个状态为 Missing path 的 drive，其实那个是 MSL 5060 的老带库，只有一个机械手和四个 Drive，多出了两个莫名其妙的 Missing Path 的 Drive.

直接在 NBU Console 中的 Media and Device Management/Devices/Drives 里面删掉状态为 missing_PATH 的 Drive，然后再重新 Define robots and drives。如果 tpconfig -l 里面还有状态为 Down 的 Drive，使用 vmoprcmd -up 的命令 up 这个 drive，然后再在 NBU console 里面刷新，可以看到状态为 Up 了。

C:\Documents and Settings\Administrator>tpconfig -l    # 再次查看状态，有两个为 Down
Device Robot Drive       Robot                    Drive                 Device

Type     Num Index  Type DrNum Status  Comment    Name                  Path

robot      1    -    TLD    -       -  -          -                     ntbbkp05

drive    -    5  hcart    2      UP  -          HP.ULTRIUM4-SCSI.017  {2,0,1,0}
drive    -    6  hcart    4      UP  -          HP.ULTRIUM4-SCSI.019  {2,0,2,0}
drive    -    7  hcart    1      UP  -          HP.ULTRIUM4-SCSI.016  {3,0,1,0}
drive    -    8  hcart    3      UP  -          HP.ULTRIUM4-SCSI.018  {3,0,2,0}
robot      2    -    TLD    -       -  -          -                     {5,0,0,0}
drive    -    1  hcart    2      UP  -          HP.ULTRIUM1-SCSI.001  {5,0,2,0}
drive    -    3  hcart    4    DOWN  -          HP.ULTRIUM1-SCSI.003  {6,0,4,0}
drive    -    4  hcart    1      UP  -          HP.ULTRIUM1-SCSI.004  {5,0,1,0}
drive    -    9  hcart    3    DOWN  -          HP.ULTRIUM1-SCSI.005  {6,0,3,0}
C:\Documents and Settings\Administrator>vmoprcmd -up 3        # 使用这个命令将 index 为 3 的 Drive Up
C:\Documents and Settings\Administrator>vmoprcmd -up 9
C:\Documents and Settings\Administrator>tpconfig -l
Device Robot Drive       Robot                    Drive                 Device

Type     Num Index  Type DrNum Status  Comment    Name                  Path

robot      1    -    TLD    -       -  -          -                     ntbbkp05

drive    -    5  hcart    2      UP  -          HP.ULTRIUM4-SCSI.017  {2,0,1,0}
drive    -    6  hcart    4      UP  -          HP.ULTRIUM4-SCSI.019  {2,0,2,0}
drive    -    7  hcart    1      UP  -          HP.ULTRIUM4-SCSI.016  {3,0,1,0}
drive    -    8  hcart    3      UP  -          HP.ULTRIUM4-SCSI.018  {3,0,2,0}
robot      2    -    TLD    -       -  -          -                     {5,0,0,0}
drive    -    1  hcart    2      UP  -          HP.ULTRIUM1-SCSI.001  {5,0,2,0}
drive    -    3  hcart    4      UP  -          HP.ULTRIUM1-SCSI.003  {6,0,4,0}
drive    -    4  hcart    1      UP  -          HP.ULTRIUM1-SCSI.004  {5,0,1,0}
drive    -    9  hcart    3      UP  -          HP.ULTRIUM1-SCSI.005  {6,0,3,0}

Ok，现在似乎 Drive 状态都是 OK 了。

NetBackup Master Server Version: 6.5.3

今天在尝试通过 BMR 方式恢复系统时，在创建引导光盘时，出现：“Failed to update the shared resource tree information in the database”的报错。

#####
# 解决思路
##########################

BMR
database 出错，一个方法是重建 database，这样做会导致清空当前的 BMR 信息，但是服务器在客户端下次发起 BMR 备份时会更新 BMR 信息。

#####
# 完整解决过程
######################

C:\Documents and Settings\Administrator>bmrsetupmaster

9/3/2007 2:46:11 PM - Error bpbrm(pid=5732) from client ntbtts01: ERR - failure reading file: E:\!Check\NTBTTS01_20060726.blg (WIN32 5: Unknown error)
9/3/2007 2:46:11 PM - Error bpbrm(pid=5732) from client ntbtts01: ERR - Snapshot Error while reading file: Volume{6f4c932e-3f1e-46aa-8256-e6efb6d359db}\!Check\NTBTTS01_20060726.blg
9/3/2007 2:46:11 PM - Critical bpbrm(pid=5732) from client ntbtts01: FTL - Backup operation aborted!
9/3/2007 2:48:36 PM - end writing; write time: 00:36:35
snapshot error encountered(156)
9/3/2007 2:48:37 PM - Error bpsched(pid=4420) backup of client ntbtts01 exited with status 156 (snapshot error encountered)

查看了一下官方资料，显示这和用于备份 open file 文件的 VSP 或 VSS 配置有关。NetBackup 在备份 open file 的时候，需要利用 VSP 或 VSS（ VSS 只适用于 WIN2003 ）生成的缓存创建一个 snapshot 文件。

登陆到服务器上发现 C 盘空间严重不足，在清理了硬盘空间后，备份成功。

附：

1. 对于 Client 上 VSP 的配置（不出问题不要随便修改，因为 NetBackup 一般会根据空间大小设定合理的 cache 大小）：

NetBackup Administration Console/NetBakcup Management/Host Properties/Clients/Choose one client/Properites/Windows Client/VSP

2. 对于 Client 上的 VSS 配置

compmgmt.msc/右键 Shared Folderss 选择 All Tasks/Configure Shadow Copies/Select the volume on which to make changes, and then click the Settings button/In the Settings dialog box, change the Maximum Size setting to either No Limit or a size large enough to suit the requirements of the installation and usage of VSS