服务器数据恢复—存储上硬盘指示灯显示异常的数据恢复案例

服务器存储数据恢复环境&故障：

一台光纤服务器存储上有16块FC硬盘，上层部署了Oracle数据库。服务器存储前面板2个硬盘指示灯显示异常，存储映射到linux操作系统上的卷挂载不上，业务中断。

通过storage manager查看存储状态，发现逻辑卷状态失败。再查看物理磁盘状态，发现其中一块盘报告“警告”，硬盘指示灯显示异常的2块盘报告“失败”。

将当前存储的完整日志状态备份下来，解析备份出来的存储日志并获得了关于逻辑卷结构的部分信息。

将16块硬盘做好标记后从存储中移除，对16块FC盘进行测试发现16块盘均能正常识别。检测16块盘的SMART状态，结果和在storage manager中的报告一致。

服务器存储数据恢复过程：

1、以只读方式将所有磁盘进行扇区级别镜像操作。在镜像过程中发现其中一块磁盘的镜像速度很慢，结合先前检测结果综合判断，该盘应该存在大量损坏以及不稳定扇区。对该硬盘进行坏道镜像操作，在镜像过程中同时观察镜像的速度和稳定性，发现该盘的坏道并不多，但是存在大量的读取响应时间长的不稳定扇区。调整拷贝策略后继续对该盘进行镜像，同时观察剩余盘镜像的情况。

2、镜像完成后查看日志，发现在storage manager和硬盘SMART状态均没有报错的一块也存在坏道，硬盘指示灯显示异常的2块盘均存在大量不规律的坏道分布。

ext3文件系统部分关键源数据信息被坏道破坏，只能等待所有磁盘镜像完毕后，通过同一条带进行xor以及根据文件系统上下文关系的方式手动修复被损坏的文件系统。

3、虽然镜像速度很慢的那块盘镜像完成，但是拷贝策略导致现在的镜像是不完整的，调整拷贝策略，继续镜像被跳过的扇区，直到该盘所有扇区全部镜像完毕。

4、所有硬盘镜像完成后，将所有硬盘按照标记还原到原存储中，后续的数据分析和数据恢复操作都基于镜像文件进行。避免后续操作对原始磁盘数据造成二次破坏。将所有镜像文件全部发开，根据对ext3文件系统的逆向以及日志文件的分析，获取到16块FC盘在存储中的盘序，RAID的块大小，RAID的校验走向和方式等信息。利用这些信息虚拟重组RAID，RAID搭建完成后进一步解析ext3文件系统。和用户方沟通后提取出了一些oracle的dmp文件，尝试进行恢复。

5、在通过dmp文件恢复数据的过程中，数据库报告imp-0008错误。北亚企安数据恢复工程师分析导入dmp文件的日志文件后，发现恢复的dmp文件存在问题。

6、重新分析raid结构，进一步确定ext3文件系统被破坏的程度。重新恢复dmp文件和dbf原始库文件，将恢复出来的dmp文件移交给用户进行数据导入测试，测试结果顺利且没有发现问题。对恢复出来的dbf原始库文件进行校验检测，所有文件均能通过测试。

oracle数据库恢复过程：

1、拷贝数据库文件到原数据库服务器上的一个文件夹中作为备份。在根目录下创建了一个oradata文件夹，并把备份的整个文件夹拷贝到oradata目录下。更改oradata文件夹及其所有文件的属组和权限。

2、备份原数据库环境，包括ORACLE_HOME下product文件夹下的相关文件。

配置监听，使用splplus连接到数据库。尝试启动数据库到nomount状态。进行基本状态查询后，了解到环境和参数文件没有问题。 尝试启动数据库到mount状态，进行状态查询没有问题。启动数据库到open状态时出现报错。

北亚企安数据恢复—oracle数据恢复

3、经过进一步的检测和分析，北亚企安数据恢复工程师判断此故障为控制文件和数据文件信息不一致导致，这是一类因断电或突然关机导致的故障。

4、对数据库文件进行逐个检测，发现所有数据文件没有物理损坏。

5、在mount状态下，对控制文件进行备份;对备份的控制文件进行查看修改，取得其中的重建控制文件命令。把这些命令复制到一个新建脚本文件controlfile.sql中。

6、关闭数据库，删除备份文件夹下的3个控制文件。 启动数据库到nomount状态，执行controlfile.sql 脚本。

北亚企安数据恢复—oracle数据恢复

7、重建控制文件完成后直接启动数据库，仍然报错，需要进一步处理。

北亚企安数据恢复—oracle数据恢复

执行恢复命令做介质恢复，直到返回报告，恢复完成。

北亚企安数据恢复—oracle数据恢复

8、尝试open数据库，数据库启动成功。把原来temp表空间的数据文件加入到对应的temp表空间中。

9、对数据库进行各种常规检查，没有发现任何错误。

10、进行emp备份。全库备份完成，没有报错。将应用程序连接到数据库，进行应用层面的数据验证。

11、数据验证过程没有发现任何问题，数据库修复完成。本次数据恢复工作完成。