ＮＢＵ备份84号错误之实战解析

一台备份用的DELL TL4000磁带机（共2个驱动器）刚更换了一个出问题的驱动器，在NBU中发现很多备份策略执行时报84号错误。刚开始以为是硬件的问题，几经周折发现还是因故障处理过程中忽视的细节问题导致的，实际上是软件问题。下面就问题的处理过程做一个完整的分析总结。
1、NBU中的报错和日志查看
在NBU的备份过程中是通过调用各种备份脚本的方式进行备份数据库的，执行备份脚本的时候无论返回什么样的错误，都会返回给NBU的日志文件bphdb，然后NBU统一报出错误,通过查看错误日志信息，可以帮助我们来分析问题产生的原因。
报错截图：

2012/04/11 01:57:44 - mounted
2012/04/11 01:57:44 - positioning 0016L4 to file 15
2012/04/11 01:57:45 - positioned 0016L4; position time: 00:00:01
2012/04/11 01:57:45 - begin writing
2012/04/11 02:01:40 - Error bptm(pid=6636) cannot write image to media id 0016L4, drive index 0, ????????? 
2012/04/11 02:01:40 - Info bptm(pid=6636) EXITING with status 84 <----------       
2012/04/11 02:01:44 - end writing; write time: 00:03:59
media write error(84)
2012/04/11 02:01:49 - Info bphdb(pid=0) done. status: 84: media write error 

进一步查看/usr/openv/netbackup/logs/bphdb下日志中的错误信息
01:53:40.282 [5316768] <1> :  Backup of </oracle/PRD/oraarch/1_15067_781277969.dbf> is failed due to <Error 84 : ServerStatus:  media write error>.
01:53:40.283 [5316769] <1> :  Backup of </oracle/PRD/oraarch/1_15068_781277970.dbf> is failed due to <Error 84 : ServerStatus:  media write error>.
01:53:40.284 [5316770] <1> :  Backup of </oracle/PRD/oraarch/1_15069_781277971.dbf> is failed due to <Error 84 : ServerStatus:  media write error>.
01:53:40.285 [5316771] <1> :  Backup of </oracle/PRD/oraarch/1_15072_781277972.dbf> is failed due to <Error 84 : ServerStatus:  media write error>.
01:53:40.286 [5316772] <1> :  Backup of </oracle/PRD/oraarch/1_15074_781277973.dbf> is failed due to <Error 84 : ServerStatus:  media write error>.
01:53:40.287 [5316773] <1> :  Backup of </oracle/PRD/oraarch/1_15075_781277974.dbf> is failed due to <Error 84 : ServerStatus:  media write error>.

2、故障初步判断
NBU 84号错误一般是硬件读写方面的错误,通过上网查资料了解以下几种情况：
首先可以查看驱动器的状态，如果驱动器没有DOWN掉，开启备份任务时，从job monitor中看到磁带可以mounting，而write error有可能是驱动器的链路和通信状态不对；如果是不能mounting磁带，也没看到机械手抓磁带，出现这种情况时，机械手是不能控制驱动器的，所以备份任务调用该驱动器时会导致备份任务失败，那么驱动器硬件本身有问题；还有就是二代的驱动器抓到了三代的磁带进行lable和读写操作时，这时驱动器发现磁带不对，也会报出media error的错误；最后一种就是一启动备份任务驱动器就down掉，请及时检查驱动器的工作状态，考虑驱动器型号是否匹配磁带机。本例中，磁带是可以被mounting的，而过了几分钟就出现write error，因此需要检查驱动器的链路和通信状态，进而从NBU中具体分析解决。

3、磁带机和光纤交换机检查
首先在磁带机中检查驱动器的链路和通信状态，看是否和正常的那个驱动器状态信息一致。
 
更换驱动器后，发现驱动器2中出现Negotiating link状态，显然和正常的驱动器1状态信息不一致，经询问DELL技术方了解到此次更换的驱动器并不是完全和此前的型号一致。那么如何让新换的驱动器正常工作呢，DELL的一个工程师提出升级微码。磁带机升级微码截图：

经升级微码后，统一为BBH4。再查驱动器状态信息，发现两个驱动器一致了。
 
另外还有一种情况，就是要注意检查光纤交换机连接磁带机驱动器的光口和链路工作状态是否正常，因为这也是一个潜在的问题原因。

注：博科光纤交换机里面可以将端口设置成L-port,G-port，但是无法设置成F-Port，正常的情况应该是L-Port。在G-port的情况下，光纤卡是无法识别到的，链路也会不正常。

4、NBU中具体解决
在解决了磁带机的驱动器的链路和通信状态问题后，备份策略仍时不时报84号错误。在NETBACKUP7.0软件中，检查驱动器，如果有Needs Cleaning提示的需要清洗磁头。

结果清洗完后，再看备份策略的执行还有84错误，看来换一个新的驱动器并不是想象的那样简单，经咨询思考决定删除此前出问题的旧驱动器，重新加载新驱动器，再观察备份情况。用NBU的bin下的命令tpconfig -d查看一下系统识别的驱动器，然后用tpclean -M清除旧的驱动器信息。

再然后重新加载驱动器

点击configure storage devices, 会弹出一个向导,按照向导一步一步向下配置即可.

配置完,可以看到重加载的正常驱动器.

最后，再查看一下备份策略的执行情况，发现一切终于正常了。

注：在重新加载驱动器后，需要重启NBU的所有服务，一般情况下会把驱动器状态更正过来，如果没有成功，再关闭NBU的服务，做一下带库的自检操作，然后启动NBU的服务。
5、问题总结
处理问题的时候，要透过表象步步分析，深入思考不断尝试是很重要的。

本文出自 “滴水穿石孙杰” 博客，谢绝转载！