按照上面提到的步骤一步步走下来，就算是结束了，两个vpar也能够正常引导起来。从发生故障到解决故障，时间严重耽误了五个多小时，这个时候就应该总结一下了，如果一开始在卸载vpar之前将vparenv调整到npar模式下，系统重启自然进入到npar模式下，就不会出现接踵而至的这么一大堆麻烦。
与此同时，我产生了一个疑问，那就是vparenv这个命令执行完成之后究竟把脚本写入到什么地方？按说如果写入到磁盘中，通过更换磁盘的方式应该可以解决，实际不是这么回事，所以排除了脚本是写到磁盘中这个假设。在十秒中断后的FS0:/EFI/HPUX目录下查看配置文件，发现无论怎样更换磁盘，一个含“vparconfig”关键字的文件始终存在，这就有理由相信配置信息实际并不是存在于磁盘上。而之后通过NPAR的合并、拆分，又一致解决了不能进入到NPAR中进行修复这一问题，那么vparenv设置后，信息很有可能是驻留在cell，或者是某某东西的缓存中，与磁盘无关。
NPAR的分拆合并势必会破坏掉被合并分区的配置信息，也就无怪乎被分拆出来之后，配置信息发生了变化，之前通过命令vparenv得到的结果很可能就不复存在了，原有的vpar环境变量被破坏，启动到npar下就是很顺利的事情。暂且这样认为着吧。
再有，使用什么磁带恢复什么系统也显得很重要，最好做到一一对应，也就是用备份了npar分区的磁带来恢复npar分区，用备份了vpar分区的磁带来恢复vpar分区，用备份了VM分区的磁带来恢复VM分区，这就不容易混淆了。用备份了VM分区的磁带来恢复vpar分区，还是存在着一些缺陷的，就好比这次操作中忽略了备有VM系统并不包含有vpar软件，一不小心就铸成大错了。
暂时总结到这里，虽然这次因为失误多加了近五个小时的工作量，但也收获不小，收获知识的同时也要像老大解决问题那样从多个角度出发去分析问题，而不是在一颗树上吊死。比如像换磁盘、合并拆分NPAR这些我连想也没去想过，而这些想法当中却正隐藏着解决问题的方法。纸上得来终觉浅，绝知此事要躬行，经验的积累还是很重要的，潜移默化中就会培养出一整套解决问题的方法论来。
阅读(1601) | 评论(0) | 转发(0) |
