NBU 作为一款很成熟的备份工具,支持多种类型的备份,备份文件可以存储在普通的磁盘、磁带、物理带库、虚拟带库、MSDP以及OST类型的重删池。本次只是拿一简单的备份,说明,在NBU处理故障中,可能会遇到的一种情况。
本例:通过NBU备份普通的文件,测试客户端和NBU master通信以及能否正常备份。当然NBU 客户端和MASTER通信在有防火墙的情况下,需要开通一些端口,在仅就不展开进行了说明。
如下:
通过NBU master 进行 storget unit,也就是说创建一个普通的备份介质,本地磁盘,在此需要给各位说明一下,我们常见的备份软件,都支持本片开头所讲的各种类型。但是这个备份介质在备份软件都需要在media server中创建,也就是说备份介质是在介质服务器media server中的,在COMMVAULT,以及VEEAM备份软件中也是同样的叫法。
直接引出错误信息如下,通过如下的信息,我们可以判断出备份介质有问题了。
2021-1-18 15:42:41 - Info nbjm (pid=3063) starting backup job (jobid=52) for client zsdb, policy ora_policy, schedule Default-Application-Backup
2021-1-18 15:42:41 - Info nbjm (pid=3063) requesting STANDARD_RESOURCE resources from RB for backup job (jobid=52, request id:{BED2B3FA-5960-11EB-90CF-4CBC00194C92})
2021-1-18 15:42:41 - requesting resource db_pool
2021-1-18 15:42:41 - requesting resource nbuser.NBU_CLIENT.MAXJOBS.zsdb
2021-1-18 15:42:41 - Error nbjm (pid=3063) NBU status: 2074, EMM status: Disk volume is down
Disk volume is down (2074)
根据给出的提示信息,然后从备份软件备份台上,去找相关的报错了。本例检查storage unit
当我们确认本地文件系统/dbackup挂载正常时,注意如上 打勾提示,当你备份到系统盘,或者跟文件系统时,将打勾钩选后就可以了。
但是,有可能会遇到一种情况,当你当你确定后,手动发起备份时,还是不成功。这里提醒一个,这种情况在NBU故障处理中,很常见,也就是说,当你正确修改配置后,
还是不成功,此时只需要将nbu java console 退出重新登录即可,这算一个BUG吧,自己在实际项目中经常遇到这种情况,每次处理类似问题,都一次次疑自己能力了。
PS: 当我们处理一些故障时,甚至一些大招都使用上时,最后发现还是没有解决问题,此时停下来,有可能只是需要退出,再重新登录一下就OK了,一些东西无须纠结过深。