Raid磁盘阵列数据恢复成功案例

最新动态来源：本站原创点击数：701更新时间：2018/4/12

客户的一台DS5020 光纤存储出现故障导致数据丢失，该存储使用了16块硬盘组成raid磁盘阵列。10号盘和13号盘掉线，6号盘警告，需要进行数据恢复。

Raid磁盘阵列故障情况：
通过IBM storage manager将当前存储的完整日志状态备份下来，解析备份出来的存储日志获得了关于逻辑卷结构的部分信息。将客户服务器中所有磁盘按照固定顺序排序移出槽位进行测试发现该磁盘阵列中除6号盘smart状态为“警告”外其他硬盘均正常。

磁盘阵列数据恢复过程：
工程师首先在windows环境下把raid阵列中状态正常的硬盘标记为脱机，然后对所有磁盘记性全盘操作，在备份过程中发现6号硬盘速度异常缓慢，初步推测原因可能是因为该盘中不稳定扇区和坏道较多导致，于是更换专业针对坏道硬盘进行镜像的设备单独对6号硬盘进行镜像操作，同时将设备中遇到坏道响应、等待时间和跳过坏扇区数据进行调整。

经过镜像操作后，在windows平台下使用winhex镜像的磁盘已经全部镜像完成，查看winhex生成的日志，发现在IBM storage manager/frombyte.com和硬盘SMART状态中均没有报错的1号盘也存在坏道，10号和13号盘均存在大量不规律的坏道分布，根据坏道列表定位到目标镜像文件分析发现该磁盘阵列中文件系统部分关键数据处于坏道区，于是转为通过6号硬盘的同条带xor手动修复。我们借助数据恢复软件将备份出来的raid中的所有数据展开，对ext3文件系统的逆向以及日志文件进行整理分析从而分析出raid磁盘阵列的盘序、raid块大小，raid的校验走向和校验方式等必要信息。
通过分析出来的raid信息虚拟重组raid磁盘阵列并接卸ext3文件系统提取数据库文件。在对数据库文件的提取过程中出现报错，数据库报告imp-0008错误，数据恢复工程师重新对raid结构进行分析，再一次进行dmp文件和dbf原始库文件进行提取，所有文件正常无报错。

数据库数据恢复流程
1.拷贝数据库文件到原数据库服务器，路径为/home/oracle/tmp/syntong.作为备份。在根目录下创建了一个oradata文件夹，并把备份的整个syntong文件夹拷贝到oradata目录下。然后更改oradata文件夹及其所有文件的属组和权限。
2.备份原数据库环境，包括ORACLE_HOME下product文件夹下的相关文件。配置监听，使用原机中的splplus连接到数据库。尝试启动数据库到nomount状态。进行基本状态查询后，了解到环境和参数文件没有问题。 尝试启动数据库到mount状态，进行状态查询没有问题。启动数据库到open状态。出现报错：

3.经过进一步的检测和分析，判断此故障为控制文件和数据文件信息不一致，这是一类因断电或突然关机等引起的常见故障。
4.对数据库文件进行逐个检测，检测到所有数据文件没有物理损毁。
5.在mount状态下，对控制文件进行备份，alter database backup controlfile to trace as ' /backup/controlfile'；对备份的控制文件进行查看修改，取得其中的重建控制文件命令。把这些命令复制到一个新建脚本文件controlfile.sql中。
6.关闭数据库，删除/oradata/syntong/下的3个控制文件。 启动数据库到nomount状态，执行controlfile.sql 脚本。 7.重建控制文件完成后，直接启动数据库，报错，需要进一步处理。 做介质恢复，直到返回报告，恢复完成。
8.尝试open数据库。
SQL> alter database open resetlogs;
9.数据库启动成功。把原来temp表空间的数据文件加入到对应的temp表空间中。
10.对数据库进行各种常规检查，没有任何错误。
11.进行emp备份。全库备份完成，没有报错。将应用程序连接到数据库，进行应用层面的数据验证。