服务器故障环境：
HP MSA某型号存储，8块SAS的硬盘组建RAID5磁盘阵列，其中包括1块热备盘。故障存储中基于该RAID组的LUN均分配给HP-Unix小机使用，上层做的LVM逻辑卷，存储的数据为Oracle数据库及OA服务端。

服务器故障：
RAID5磁盘阵列中2块磁盘未知原因离线，阵列中的热备盘虽然成功激活，RAID5磁盘阵列瘫痪，上层LUN不可用。

服务器数据恢复过程：
1、由于存储中RAID阵列崩溃是由于磁盘掉线导致的，拿到磁盘后先由硬件工程师对故障存储中的所有磁盘做物理故障检测，检测后没有发现硬盘存在物理故障。使用坏道检测工具检测磁盘坏道，也没有发现坏道。
2、将故障存储中所有硬盘以只读方式做完整的镜像备份，后续的数据分析和数据恢复操作都基于镜像文件进行，避免数据恢复操作可能对原始数据造成二次破坏。
部分备份数据：

3、由于故障存储中所有磁盘不存在物理故障，也没有发现坏道，所以磁盘离线原因就是某些磁盘读写不稳定。因为该品牌存储的RAID控制器针对磁盘的检测策略比较严格，极大可能性把性能不稳定的磁盘认定为坏盘并踢出RAID组。一旦RAID组中掉线的磁盘数量超过该RAID级别允许掉盘的最大数量，这个RAID组就会崩溃，上层基于RAID组的LUN也将不可用。
4、分析RAID组的信息如条带大小，磁盘顺序及数据走向等，然后根据分析获取到的raid信息重构RAID组。经过分析发现其中一块盘的数据和其它盘不太一样，初步判断这块盘就是热备盘。分析其他数据盘（除了热备盘）的底层，搞清楚Oracle数据库页在每个磁盘中分布的情况。
5、分析数据盘中的数据发现有一块硬盘在同一个条带上的数据和其他硬盘不一样，初步判断此盘是先掉线的，通过北亚企安自主开发的RAID校验程序对这个条带做校验，最终确定这块盘就是最先掉线的那块硬盘。
6、由于LUN是基于RAID组的，将RAID组重构出来之后就开始分析LUN在RAID组中的分配情况以及LUN分配的数据块MAP。将每一个LUN的数据块分布MAP提取出来，然后针对这些信息编写程序解析所有LUN的数据MAP，然后根据数据MAP导出所有LUN的数据。

 

 

7、分析生成出来的所有LUN，发现所有LUN中均包含HP-Unix的LVM逻辑卷信息。尝试解析每个LUN中的LVM信息后发现一共有3个LVM：其中1个LVM中划分了一个LV，里面存放OA服务器端的数据；另外1个LVM中也划分了一个LV，里面存放临时备份数据；最后1个LVM也只划分了一个LV，里面存放Oracle数据库文件。北亚企安数据恢复工程师编写LVM解释程序解释每个LVM中的LV卷，但在解释过程中程序出错。
8、仔细分析程序报错的原因，由开发工程师debug程序出错的位置，并同时检测恢复出来的LUN，检测LMV逻辑卷的信息是否损坏。经过检测发现LVM信息已经损坏。尝试人工修复损坏的区域，并同步修改LVM解释程序重新解析LVM逻辑卷。
9、搭建HP-Unix环境，将解释出来的LV卷映射到HP-Unix并尝试挂载文件系统，结果挂载文件系统出错。尝试使用“fsck –F vxfs” 命令修复vxfs文件系统，修复完成后发现还是不能成功挂载。怀疑是底层vxfs文件系统的部分元数据已经破坏。
10、分析解析出来的LV并根据VXFS文件系统的底层结构校验此文件系统是否完整。分析结果发现底层VXFS文件系统有问题，存储设备瘫痪的时候文件系统正在执行IO操作，部分文件系统元文件损坏。北亚企安数据恢复工程师手工修复这些损坏的元文件，直至VXFS文件系统能够被正常解析。
11、再次将修复好的LV卷挂载到HP-Unix小机上，尝试Mount文件系统，文件系统成功挂载。
12、在HP-Unix小机上mount文件系统后，将所有用户数据均备份至指定的磁盘空间。
部分文件目录：

13、使用工具检测每个Oracle数据库文件的完整性，没有发现问题。使用北亚企安自主开发的Oracle数据库检测工具（检验更严格）进行检测，发现有部分Oracle数据库文件和日志文件校验不一致。数据库工程师对这部分文件进行修复并再次校验，直到所有Oracle数据库文件校验通过。
14、将恢复出来的Oracle数据库附加到原始生产环境的HP-Unix服务器中，启动Oracle数据库成功。

 

 

数据验证：
在用户方工程师的配合下，启动Oracle数据库和OA服务端。通过笔记本电脑上安装的OA客户端对最新的数据记录以及历史数据记录进行反复验证，并且安排用户方公司不同部门人员进行远程验证。最终确认数据无误，完整可用。本次数据恢复工作完成。