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了，一些东西无须纠结过深。
