【故障描述】
华为S5300，12块FC硬盘，整个存储空间由450GB和600G FC的硬盘组成，其中11块硬盘组成一个RAID5的阵列，剩余1块做成热备盘使用。由于RAID5阵列中出现1块硬盘故障，热备盘成功激活，在进行同步的过程中又一块硬盘出现故障，因此导致RAID5阵列瘫痪，上层LUN无法正常使用。
【恢复过程】
一、检测磁盘
由于存储是因为RAID阵列中某些磁盘掉线，从而导致整个存储不可用。因此接收到磁盘以后先对所有磁盘做物理检测，检测完后发现一块硬盘有物理故障，其他硬盘没有物理故障。
二、备份数据
考虑到，数据的安全性以及可还原性，在做数据恢复之前需要对所有源数据做备份，以防万一其他原因导致数据无法再次恢复。使用dd命令或winhex工具将所有磁盘都镜像成文件。
三、故障分析
1、分析故障原因
由于前两个步骤并检测到磁盘有物理故障，由此推断可能是由于某些磁盘读写不稳定和物理故障导致故障发生。因为华为S5300控制器检查磁盘的策略很严格，一旦某些磁盘性能不稳定，华为S5300控制器就认为是坏盘，就将认为是坏盘的磁盘踢出RAID组。而一旦RAID组中掉线的盘到达到RAID级别允许掉盘的极限，那么这个RAID组将变的不可用，上层基于RAID组的LUN也将变的不可用，之后又新建RAID，有一块硬盘在同步的过程中被损坏，目前初步了解的情况为基于RAID组的LUN分配给linux系统使用，重要数据为Oracle数据库。
2、分析RAID组结构
华为S5300存储的LUN都是基于RAID组的，因此需要先分析底层RAID组的信息，然后根据分析的信息重构原始的RAID组。分析每一块数据盘，发现一块盘的数据同其它数据盘不太一样，初步认为可能是hot Spare盘。接着分析其他数据盘，分析Oracle数据库页在每个磁盘中分布的情况，并根据数据分布的情况得出RAID组的条带大小，磁盘顺序及数据走向等RAID组的重要信息。
3、分析RAID组被同步损坏盘
根据上述分析的RAID信息，尝试通过北亚自主开发的RAID虚拟程序将原始的RAID组虚拟出来。但由于整个RAID组中掉线两块盘并且有一块硬盘数据被同步损坏。仔细分析每一块硬盘中的数据，发现有一块硬盘在同一个条带上的数据和其他硬盘明显不一样，因此初步判断此硬盘可能是被同步掉损坏的硬盘，通过北亚自主开发的RAID校验程序对这个条带做校验，因此可以明确被同步损坏盘了。
4、分析RAID组中的LUN信息
由于LUN是基于RAID组的，因此需要根据上述分析的信息将RAID组最新的状态虚拟出来。然后分析LUN在RAID组中的分配情况，以及LUN分配的数据块MAP。因此只需要将LUN的数据块分布MAP提取出来。然后针对这些信息编写相应的程序，LUN的数据MAP做解析，然后根据数据MAP并导出LUN的数据。
四、解析EXT3文件系统
1、解析EXT3文件系统
由于是使用热备盘虚拟的RAID结构，EXT3文件系统无法正常挂载，所以只能提取oracle数据库文件，利用自主开发的文件系统解析程序对其进行文件系统的解析，导出oracle数据库文件，并把数据库文件移交给数据库工程师进行校验和验证
五、检测Oracle数据库文件及修复
1、检测数据库文件是否完整
使用Oracle数据库文件检测工具检测每个数据库文件是否完整，发现有错误。再使用北亚自主研发的Oracle数据库检测工具（检验更严格），发现有部分数据库文件和日志文件错误， system 和 sysaux表空间各存在100多坏块；3个控制文件都存在坏块许多坏块，控制文件全部损坏；eschoolspace表空间的3个文件的坏块更多，达到1000个；undotbs02丢失；数据库工程师对此类文件进行修复，如下图：
2、修复Oracle数据库
我们创建了控制文件，创建undo表空间，启动数据库到mount。system数据文件坏块使得数据库不能open。各种隐含参数也不能绕过system的坏块；搭建数据库环境。使用dmp文件还原数据库。使用3月9号之后的导入，都报错，大约只能导入10G左右的数据，如下图：
六、数据验证
由用户方配合，启动Oracle数据库，在本地虚拟机安装OA客户端。通过OA客户端对数据记录进行验证，并且用户安排不同部门人员进行远程验证。
七、数据恢复结论
由于故障发生后又重建RAID，导致一块盘的数据被同步损坏，对后期的数据恢复造成了困难。因为热备盘同步了一段时间写入了部分数据，所以使用热备盘里面的数据进行恢复，只能恢复部分数据，只有3月9日之前的数据。