上周六接了一个从山西某市公安交通管理局汽车违章罚款系统存储故障数据恢复案例，故障现象比较典型，特意记录下来。
硬件环境是:
IBM DS4300存储,一共10块146GB光纤接口硬盘,做的是RAID10架构,就是每两块盘做成RAID1,一共5组RAID1,然后这5组RAID1 又配置成一个RAID0,这就是所谓的混合型RAID10.DS4300阵列挂接在IBM小型机上，划分成AIX JFS2文件系统。
原本以为这种RAID架构很安全,到头来还是出问题.
故障现象如下:
硬盘编号从1-10，其中1-2、3-4、5-6、7-8、9-10分别是5组RAID1，其中1-2这组RAID1以前更换过1号盘。现在出现了1号和2 号盘同时亮黄灯，在Server Raid管理软件中这两个盘状态是OFFLINE状态。在这种架构上，如果这5组RAID1中只要坏掉一组，整个阵列就不能正常访问，在AIX上 mount不上。
检测：
经过Server Raid管理软件分析阵列日志信息，发现2号盘在10年8月份就出现异常，不参与RAID工作，1号盘在近期才出现错误。经过对1、2号盘进行检测和镜像，发现2号盘有少量坏道，1号盘能正常读取。
恢复：
经过对1号盘和2号盘进行检测和镜像以后，我们尝试把1号盘留在DS4300阵列上，把2号盘拔出来，然后在Server Raid管理软件中尝试各种办法使1号盘状态变成ONLINE状态，最后终于把1号盘变成ONLINE，于是尝试在AIX下查看相关VG信息，发现VG信息已经被破坏。数据恢复陷入下一步困境，经过对比1号盘和2号盘的头部信息，发现2号盘的头部有相关VG信息，于是把2号盘VG信息Copy到1号盘相应位置，再次在AIX下查看VG信息、LV信息，这次VG信息完好，文件系统mount顺利，尝试启动oracle服务，发现oracle启动不了，报 redo1.log文件错误，最后经过几番努力，oracle终于能起来了，赶紧exp出oracle中的数据。到此数据恢复宣布成功！
本案例经验：
DS4300 上更换硬盘要注意，最好更换型号和固件版本跟原来一样的硬盘，本案例原1号盘坏过，现在的1号盘是替换原1号盘的新盘，型号和固件版本都跟原来的硬盘不一样，这样的硬盘在DS4300上运行时不稳定的，容易出现掉线的现象。DS4300对硬盘固件版本匹配要求比较高，更换硬盘千万要注意固件版本匹配问题。
LVM信息是本恢复的关键，1号盘LVM信息被破坏，我从2号盘看到良好的LVM信息，COPY到1号盘的相应位置，才能使整个恢复得以顺利进行。
经过大家的回复和要求，我整理一下，需求：
每个LV的PP号是相对于这个LV来说的，他的编号不是PV全局PP号，每个LV的PP号从1开始，到这个LV所包含的PP数，如果一个LV包含330个PP，那么PP号从1-330这些数字，如果PP MAP没有被改动，我们就可以从这个PP MAP编号知道这个LV包含的PP数。
再说一下PP编号：
# lspv -p hdisk4
hdisk4:
PP RANGE STATE REGION LV NAME TYPE MOUNT POINT
1-27 used outer edge oraclelv2 JFS2 N/A
28-54 used outer middle oraclelv2 JFS2 N/A
55-81 used center oraclelv2 JFS2 N/A
82-107 used inner middle oraclelv2 JFS2 N/A
108-108 free inner middle
109-135 free inner edge
PP RANGE 1-27这个数，这个1号PP是不是从硬盘0扇区开始呢？不是的。当你用readvgda查看VGDA信息的时候，有个参数pvh.psn_part1: 4352，这个参数就是PP编号的起始扇区（硬盘扇区编号从0开始），对于Big VG，这个参数可能不一样。
当一个LV建立以后，他的PP范围是确定了，那么这个LV中的PP编号就是可以从1到PP总数写到LV 的PP MAP里。
像你问的mylv00 PP编号，其实你知道mylv00 起始位置，他的PP编号就从这个起始位置算起，从1到mylv00包含的PP数。
其实你可以根据这个相对PP号，推算出他在哪个PV上的绝对PP号。
http://www.loveunix.net/viewthread.php?tid=76187&extra=page%3D5%26amp%3Bfilter%3Ddigest收起