一、 HP   MSA 存储 设备信息

1、 存储 空间 由8块 450 GB SAS的硬盘组成 。

2、 7块硬盘组成一个RAID5的阵列，1块 作为 热 备盘 。

二、 HP   MSA 存储 设备故障描述

1 、 RAID5 阵列中出现 2 块硬盘损坏，而此时只有一块热备盘成功激活，因此导致 RAID5 阵列瘫痪，上层 LUN 无法正常使用。

2 、 RAID 阵列中某些磁盘掉线，导致整个存储不可用。因此 需要 先对所有磁盘做物理检测，检测完后 确认硬盘无 物理故障。接着使用坏道检测工具检测磁盘坏道，发现也 无 坏道。

三 、 HP   MSA 存储 备份数据

考虑到数据的安全性以及可还原性，在做数据恢复之前需要对所有源数据做备份，以防万一其他原因导致数据无法再次恢复。使用dd 命令或 winhex 工具将所有磁盘都镜像成文件 。 备份完部分数据如下图：

四 、 HP   MSA 存储 故障分析

1 、分析故障原因

经 推断可能是由于某些磁盘读写不稳定导致故障发生。因为HP  MSA2000 控制器检查磁盘的策略很严格，一旦某些磁盘性能不稳定， HP  MSA2000 控制器就认为是坏盘，就将认为是坏盘的磁盘踢出 R AID 组。而一旦 R AID 组中掉线的盘到达到 RAID 级别允许掉盘的极限，那么这个 RAID 组将变的不可用，上层基于 RAID 组的 LUN 也将变的不可用。目前初步了解的情况为基于 RAID 组的 LUN 有 6 个，均分配给HP-Unix 小机使用，上层做的 LVM 逻辑卷，重要数据为 Oracle 数据库及 OA 服务端。

2 、分析 RAID 组结构

HP  MSA2000 存储的 LUN 都是基于 RAID 组的，因此需要先分析底层 RAID 组的信息，然后根据分析的信息重构原始的 RAID 组。分析每一块数据盘， 发现4 号盘的数据同其它数据盘不太一样，初步认为可能是 hot  Spare 盘。接着分析其他数据盘，分析 Oracle 数据库页在每个磁盘中分布的情况，并根据数据分布的情况得出 RAID 组的条带大小，磁盘顺序及数据走向等 RAID 组的重要信息。

3 、分析RAID 组掉线盘 先后顺序

根据上述分析的 RAID 信息，尝试通过北亚自主开发的 RAID 虚拟程序将原始的 RAID 组虚拟出来 。但由于整个RAID 组中一共掉线两块盘，因此需要分析这两块硬盘掉线的顺序。仔细分析每一块硬盘中的数据，发现有一块硬盘在同一个条带上的数据和其他硬盘明显不一样，因此初步判断此硬盘可能是最先掉线的，通过北亚自主开发的 RAID 校验程序对这个条带做校验，发现除掉刚才分析的那块硬盘得出的数据是最好的，因此可以明确最先掉线的硬盘了。

4、 分析RAID 组中的 LUN 信息

首先 分析LUN 在 RAID 组中的分配情况，以及 LUN 分配的数据块 MAP 。由于底层有 6 个 LUN ，因此只需要将每一个 LUN 的数据块分布 MAP 提取出来。然后针对这些信息编写相应的程序，对所有 LUN 的数据 MAP 做解析，然后根据数据 MAP 并导出 所有 LUN 的数据。

五 、 HP   MSA 存储 LV M 逻辑卷及VXFS 文件系统修复

1 、 解析LV M 逻辑卷

分析生成出来的所有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 卷都解释出来，但发现解释程序出错。

2 、修复 LV M 逻辑卷

仔细分析程序报错的原因，安排开发工程师debug 程序出错的位置，并同时安排高级文件系统工程师对恢复的 LUN 做检测，检测 LVM 信息是否会因存储瘫痪导致 LMV 逻辑卷的信息损坏。经过仔细检测，发现确实因为存储瘫痪导致 LVM 信息损坏。尝试人工对损坏的区域进行修复，并同步修改程序，重新解析 LVM 逻辑卷。

3 、 解析VXFS 文件系统

搭建HP -Unix环境，将解释出来的LV卷映射到HP-Unix，并尝试Mount文件系统。结果Mount文件系统出错，尝试使用“fsck –F vxfs” 命令修复vxfs文件 系统，但修复结果还是不能挂载，怀疑底层vxfs文件系统的部分元数据可能破坏，需要进行手工修复。

4 、修复 VXFS 文件系统

仔细分析解析出来的LV，并根据VXFS文件系统的底层结构校验此文件系统是否完整。分析发现底层VXFS文件系统果然有问题，原来当时存储瘫痪的同时此文件在系统正在执行IO操作，因此导致部分文件系统元文件没有更新以及损坏。人工对这些损坏的元文件进行手工修复，保证VXFS文件系统能够正常解析。再次将修复好的LV卷挂载到HP-Unix小机上，尝试Mount文件系统，文件系统没有报错，成功挂载。

六 、 检测Oracle 数据库文件并启动数据库

1 、恢复 Oracle 数据库文件

在HP-Unix 机器上 mount 文件系统后，将所有用户数据均备份至指定磁盘空间。所有用户数据大小在 1.2TB 左右。部分文件目录截图如下：

2 、检测 Oracle 数据库文件是否完整

使用Oracle 数据库文件检测工具 “dbv” 检测每个数据库文件是否完整，发现并没有错误。再使用北亚自主研发的 Oracle 数据库检测工具（检验更严格），发现有部分数据库文件和日志文件校验不一致，安排高级数据库工程师对此类文件进行修复，并在次校验，直到所有文件校验均完全通过。

3 、启动 Oracle 数据库

由于我们提供的HP-Unix 环境没有此版本的 Oracle 数据，因此 需要用户的原始环境 ，将恢复的Oracle 数据库附加到原始生产环境的 HP-Unix 服务器中，尝试启动 Oracle 数据库， Oracle 数据库启动成功。部分截图如下：

七 、 HP   MSA 存储 数据验证

由用户方 的积极 配合，启动Oracle 数据库，启动 OA 服务端，在本地笔记本安装 OA 客户端。通过 OA 客户端对最新的数据记录以及历史数据记录进行验证，并且有用户安排远程不同部门人员进行远程验证。最终数据验证无误，数据完整， 至此 数据恢复 工作结束 。