系统异常不能登录，错误代码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