山东鼎际信息技术有限公司
知识库  /  Knowledge base
IBM aix+tsm崩塌抢修过程记录
来源: | 作者:advertising-100 | 发布时间: 2021-06-25 | 485 次浏览 | 分享到:

系统异常不能登录,错误代码0555,文件系统损坏,6点找系统备份带,6-11点尝试各种恢复,1、通过磁带备份,HDISK0引导系统,hd2文件系统的超级块全都损坏,尝试磁带恢复系统,由于硬件

存在不稳定性,在磁带引导是出现不读磁带设备,识别不到硬盘情况,其中占用很多时间在等待启动识别重启操作,在7点钟左右就发现硬件的异常,IBM定配件,10点30,配件送到,更换主板、硬盘背板、磁带机背板,更换后设置system name,vpd信息等,这时在1点左右,准备两种方案,1.570新环境搭建,2,旧环境恢复,4点20左右旧环境开始恢复,大约要2个多小时

故障机修复后,通过光盘引导,以hdisk1导入,rootvg中逻辑卷信息都能看到,access rootvg and start shell before mount filesystem,rootvg可以激活,各文件系统超级块能够fixed是干净的,cd /tmp

创建临时目录tusr,mount /dev/hd2 /tmp/tusr,使用绝对路径执行/tmp/tusr/bin/ls报命令not found, df发现 /dev/hd2使用率1%,显然不对,没有数据量。然后通过磁带恢复,恢复很忙,大约3个小时,最终报错media surface error ,系统能启动,文件系统mount点都成了 /mnt/home    /mnt/usr ......,

NAS数据导入数据库,5点30开始准备

凌晨20分钟备机570到现场

4点钟TSMserver搭建完成,数据库未回复

4点50 570备机上架,准备回复数据库数据

loopmount -i TSMCLI.iso -o "-V cdrfs -o ro" -m /isomount

~

手册恢复步骤

LED 551, 555, and 557 - Corrupted file system, corrupted JFS log, and so on.

1. Follow the procedure described in Section 3.3.3, “Accessing a system that will not

boot” on page 37, to access the rootvg before mounting any file systems (Option 2

on the Maintenance screen).

2. Verify and correct the file systems as follows:

fsck -y /dev/hd1

fsck -y /dev/hd2

fsck -y /dev/hd3

fsck -y /dev/hd4

fsck -y /dev/hd9var

3. Format the JFS log again by using the command:

/usr/sbin/logform /dev/hd8

4. Use lslv -m hd5 to find out the boot disk.

5. Recreate boot image by using the command:

bosboot -a -d /dev/hdiskn

Where n is the disk number of the disk containing boot logical volume.

~

恢复时的几张截图

下面截图是第一次用磁带机恢复系统,恢复启动时很慢,有时识别不到磁带机还有硬盘,下面截图应该是没有识别到磁带机。

 

~

当晚更换了主板、磁带机笼子背板、硬盘背板,通过磁带引导,通过hdisk0加载rootvg,报hd2的primary superblock 和secondary superblock都已经损坏,无法修复。更换主板、笼子、背板后,

通过磁带引导,access rootvg and start shell before mount filesystem,rootvg,hdisk1加载rootvg,报如下做图所示,rootvg可以varyon,很高兴,lg_dumplv 逻辑卷控制块lvcb损坏到时没影响,

通过access rootvg and start shell引导,进入下右图所示,不能启动shell

 

hdisk1加载时所有文件系统显示都是好的。在tmp目录下建新目录挂载点,mount /dev/hd2 /tmp/tusr,df显示tusr使用率为1%,显然不对,

最后恢复操作系统,如下右图所示,提示media surface error,恢复了3个小时左右,但是最后提示报错,恢复完成启动,df输出入下下左图

   

上边这个状态是不是能恢复好了,没有验证

~

M48调整,由于换了新的机器,新的HBA卡,WWWN换了,zone要做调整,所有有旧HBAwn的zone调整下即可

zoneshow找到之前HBA卡所在的zone

zoneshow|grep oldwn

aliasadd "tsmserv1","newwn"

aliasremove "rsmserv1","odlwn"

其实就是更新alias,有这个alias的zone就不需要zoneadd了,没有的需要zoneadd "zone","tsmserv1"

cfgsave

cfgenable

~

恢复数据库,报时间戳的错误,后来是升级一个TSM小版本,其实是重新安装了,6.2.2,然后通过修改一个参数,把最后一条报错屏蔽掉,(bug),数据库恢复成功。


恢复成功后启动TSM,会报若干信息错误,无非是之前的信息没有了,因为没有回滚db2日志,不影响备份

虚拟带库四个机械臂识别不到,通过在虚拟带库里边,取消机械臂-保存-然后选择,在服务端就识别到了,相当于对这个磁带机文件(设备)复位一下。

定义所有path

~

3584驱动用的是12.8.8,执行tapeutil没有这个命令,不知道为什么,新版本取消了?

~

library重新定义,volu要重新审计一遍,audit volu stg=ods_vpool,时间很长,不重新审计会影响到过期处理,迁移这些操作,对继续备份没有影响,library重新定义后,volume状态有很多变成了

private,需要update成scratch状态。

~

周六,下午1点到客户

有几个虚拟带库及物理带库的path定义不上,errpt报,unable to obtain reserving host information,errno ebusy

有被占用,lanfree path已经删除,然后再把lanfree节点的agent进程kill掉,把unknown状态的驱动器删除掉,物理带库的驱动器路径就可以定义了,看来是驱动器被什么给占用了.

但是虚拟带库的几个还是不行

errpt报错如下

 

然后重启虚拟带库,10.141.6.191 root/admin   #menu reboot system


最后决定重启虚拟带库

客户虚拟带库IP 10.141.6.191

root/admin

#menu

 

重启操作系统。

重启虚拟带库后,定义path正常,至此所有path都正常了

很多节点都是missing状态,由于server从新安装了,密码更新了,虽然还是admin,客户端进程很多都停止了,有的还需要dsmc验证下密码。

完了做了些收尾工作,db2备份的转移,tsmdata的镜像,

tsm 中有ods ods2两个节点,对应IP都是2.5同一个,../../api/bin64/dsm.sys文件定义了两个节点,要分别启动,

 

../../api/bin64/dsm.opt中定义了

servername   tsmserver

../../ba/bin/dsm.opt中定义了

servername  tsmods