华为S5300存储瘫痪 Oracle数据库恢复解决方案

华为S5300存储阵列RAID瘫痪，Oracle数据库内有重要数据需要恢复，恢复数据的整个存储空间由450GB和600G FC的硬盘组成，共12块，其中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的数据。

 

1、解析EXT3文件系统

     由于是使用热备盘虚拟的RAID结构，EXT3文件系统无法正常挂载，所以只能提取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日之前的数据。