故障描述
HP FC MSA2000存储，由于RAID5阵列中出现2块硬盘损坏并离线，而此时只有一块热备盘成功激活，因此导致RAID5阵列瘫痪，上层LUN无法正常使用，用户联系联系北亚数据，整个存储空间由8块450GB SAS的硬盘组成，其中7块硬盘组成一个RAID5的阵列，剩余1块做成热备盘使用。
由于存储是因为RAID阵列中某些磁盘掉线，从而导致整个存储不可用。因此接收到磁盘以后先对所有磁盘做物理检测，检测完后发现没有物理故障。接着使用坏道检测工具检测磁盘坏道，发现也没有坏道。
解决方法：
1、备份数据
考虑到数据的安全性以及可还原性，在做数据恢复之前需要对所有源数据做备份，以防万一其他原因导致数据无法再次恢复。使用dd命令或winhex工具将所有磁盘都镜像成文件。备份完部分数据如下图：
2、分析故障原因
由于前两个步骤并没有检测到磁盘有物理故障或者是坏道，由此推断可能是由于某些磁盘读写不稳定导致故障发生。因为HP MSA2000控制器检查磁盘的策略很严格，一旦某些磁盘性能不稳定，HP MSA2000控制器就认为是坏盘，就将认为是坏盘的磁盘踢出RAID组。而一旦RAID组中掉线的盘到达到RAID级别允许掉盘的极限，那么这个RAID组将变的不可用，上层基于RAID组的LUN也将变的不可用。目前初步了解的情况为基于RAID组的LUN有6个，均分配给HP-Unix小机使用，上层做的LVM逻辑卷，重要数据为Oracle数据库及OA服务端。
3、分析RAID组结构
HP MSA2000存储的LUN都是基于RAID组的，因此需要先分析底层RAID组的信息，然后根据分析的信息重构原始的RAID组。分析每一块数据盘，发现4号盘的数据同其它数据盘不太一样，初步认为可能是hot Spare盘。接着分析其他数据盘，分析Oracle数据库页在每个磁盘中分布的情况，并根据数据分布的情况得出RAID组的条带大小，磁盘顺序及数据走向等RAID组的重要信息。
4、分析RAID组掉线盘
根据上述分析的RAID信息，尝试通过北亚自主开发的RAID虚拟程序将原始的RAID组虚拟出来。但由于整个RAID组中一共掉线两块盘，因此需要分析这两块硬盘掉线的顺序。仔细分析每一块硬盘中的数据，发现有一块硬盘在同一个条带上的数据和其他硬盘明显不一样，因此初步判断此硬盘可能是最先掉线的，通过北亚自主开发的RAID校验程序对这个条带做校验，发现除掉刚才分析的那块硬盘得出的数据是最好的，因此可以明确最先掉线的硬盘了。
5、分析RAID组中的LUN信息
由于LUN是基于RAID组的，因此需要根据上述分析的信息将RAID组最新的状态虚拟出来。然后分析LUN在RAID组中的分配情况，以及LUN分配的数据块MAP。由于底层有6个LUN，因此只需要将每一个LUN的数据块分布MAP提取出来。然后针对这些信息编写相应的程序，对所有LUN的数据MAP做解析，然后根据数据MAP并导出所有LUN的数据。
6、解析LVM逻辑卷
分析生成出来的所有LUN，发现所有LUN中均包含HP-Unix的LVM逻辑卷信息。尝试解析每个LUN中的LVM信息，发现其中一共有三套LVM，其中45G的LVM中划分了一个LV，里面存放OA服务器端的数据，190G的LVM中划分了一个LV，里面存放临时备份数据。剩余4个LUN组成一个2.1T左右的LVM，也只划分了一个LV，里面存放Oracle数据库文件。编写解释LVM的程序，尝试将每套LVM中的LV卷都解释出来，但发现解释程序出错。
7、修复LVM逻辑卷
仔细分析程序报错的原因，安排开发工程师debug程序出错的位置，并同时安排高级文件系统工程师对恢复的LUN做检测，检测LVM信息是否会因存储瘫痪导致LMV逻辑卷的信息损坏。经过仔细检测，发现确实因为存储瘫痪导致LVM信息损坏。尝试人工对损坏的区域进行修复，并同步修改程序，重新解析LVM逻辑卷。
8、解析VXFS文件系统
搭建HP-Unix环境，将解释出来的LV卷映射到HP-Unix，并尝试Mount文件系统。结果Mount文件系统出错，尝试使用“fsck –F vxfs” 命令修复vxfs文件系统，但修复结果还是不能挂载，怀疑底层vxfs文件系统的部分元数据可能破坏，需要进行手工修复。
