一个备份问题的处理（三）

今天加班了，就为了这个问题。又查了很多资料，做了很多操作，做过的操作我直接贴上来吧，懒得总结了。

1、在serverB上登录rman上做了这个：
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE 'SBT_TAPE' TO 1;
2、修改了bp.conf文件。
# vi /usr/openv/netbackup/bp.conf
"/usr/openv/netbackup/bp.conf"［只读取］ 2 行，36 字符
SERVER = b2000
CLIENT_NAME = yncdma
CLIENT_CONNECT_TIMEOUT = 600
CLIENT_READ_TIMEOUT = 600
在服务器端和客户端增加了几个日志目录，位置都是/usr/openv/netbackup/logs下
3、在serverB的/etc/services中加入了
bpdbm   13721/tcp       bpdbm
4、在主服务器上
# cd /usr/openv/netbackup/bin
# ls -l bptpcinfo
-r-xr-xr-x   1 root     bin        71200 Oct 24  2004 bptpcinfo
# ./bptpcinfo
The results have been written to /usr/openv/volmgr/database/3pc.conf
# more /usr/openv/volmgr/database/3pc.conf
# devid  [a=wwpn:lun] [c=client] [p=devpath]  [P=clientpath] [s=sn] [l=lun]  [w=wwpn] [W=wwpn]  [i=iddesc]
  0 p=/dev/rdsk/c1t1d0s2 s=FUJITSU:MAP3735FSUN72G:000404Q07PF4 l=0 i=103500000E01071B0E0
  1 p=/dev/rmt/0cbn s=HP:Ultrium2-SCSI:HUL4D09977CSIH00 l=0 i=10350060B0000289A0D
  2 p=/dev/rmt/1cbn s=HP:Ultrium2-SCSI:HUL4F02895CSIH00 l=0 i=10350060B000028C3CA
# ls -l /usr/openv/volmgr/database/3pc.conf
-rw-r--r--   1 root     other        360 Feb 17 14:49 /usr/openv/volmgr/database/3pc.conf

在serverB上

# /usr/openv/netbackup/bin/bptpcinfo
bptpcinfo failed: Unable to open output file /usr/openv/volmgr/database/3pc.conf

# cd /usr/openv/volmgr
bash: cd: /usr/openv/volmgr: 无此文件或目录
# cd /usr/openv/
# ls
bin            lib            script         script1_c.tar  share          var
java           netbackup      script1        script_g.tar   test.tar
# mkdir volmgr
# cd volmgr
# mkdir database
# /usr/openv/netbackup/bin/bptpcinfo
The results have been written to /usr/openv/volmgr/database/3pc.conf
# more /usr/openv/volmgr/database/3pc.conf
# devid  [a=wwpn:lun] [c=client] [p=devpath]  [P=clientpath] [s=sn] [l=lun]  [w=wwpn] [W=wwpn]  [i=iddesc]
  0 p=/dev/rdsk/c0t0d0s2 s=FUJITSU:MAP3367NSUN36G:00N07KH4 l=0
  1 p=/dev/rdsk/c0t1d0s2 s=FUJITSU:MAP3367NSUN36G:00N07KEJ l=0
  2 p=/dev/rdsk/c4t60003BA68F2D10004304AB8D0001FE6Ad0s2 l=0 i=10360003BA68F2D10004304AB8D0001FE6A
  3 p=/dev/rdsk/c4t60003BA68F2D10004304AB6F0009FD8Fd0s2 l=0 i=10360003BA68F2D10004304AB6F0009FD8F
  4 p=/dev/rdsk/c4t60003BA68F2D10004304AB58000CCAA3d0s2 l=0 i=10360003BA68F2D10004304AB58000CCAA3
  5 p=/dev/rdsk/c4t60003BA68F2D10004304AB9F00000108d0s2 l=0 i=10360003BA68F2D10004304AB9F00000108
  6 p=/dev/rdsk/c4t60003BA68E30C000441CB599000C9EF8d0s2 l=0 i=10360003BA68E30C000441CB599000C9EF8
  7 p=/dev/rdsk/c4t60003BA68E30C000441D2A1200017AA9d0s2 l=0 i=10360003BA68E30C000441D2A1200017AA9
  8 p=/dev/rdsk/c4t60003BA68E30C000441D2A000003CD95d0s2 l=0 i=10360003BA68E30C000441D2A000003CD95
  9 p=/dev/rdsk/c4t60003BA68E30C000441D29DF0002E904d0s2 l=0 i=10360003BA68E30C000441D29DF0002E904

5、按照NBU5.0的trouble shooting关于返回码25、54的检查方法检查了一遍，还是没有效果。

6、最后查看activity jobs，发现调度的状态一直在mounting和connecting，一直没有writing，估计驱动器有问题，把serverB所有策略的驱动器改到serverA所用的驱动器，手动起备份，不一会儿就开始写了。

先到这，等明天上班了让项目组去带库旁边看看具体是怎么回事。