服务器数据恢复—存储映射的卷无法挂载故障，多场景数据完整恢复实操解析

服务器存储数据恢复环境：
某品牌服务器存储上有16块FC硬盘，存储设备前面板的10号硬盘指示灯和13号硬盘指示灯亮黄灯，存储设备映射到服务器redhat linux系统上的卷无法挂载，业务中断。

服务器存储数据恢复过程：
1、通过存储设备厂商的管理程序storage manager连接到服务器存储上查看当前存储状态，逻辑卷状态failed。查看物理磁盘状态，6号盘报告“警告”，10号和13号盘报告“失败”。
通过storage manager将故障存储的完整日志状态备份，解析备份出来的存储日志获取逻辑卷结构的部分信息。
2、北亚企安数据恢复工程师将故障存储中16块FC盘做好标记后，从存储设备中取出。使用专业镜像设备对16块FC盘进行初步测试。经过测试发现16块盘均能正常识别。分别检测16块盘的SMART状态，结果6号盘的SMART状态为“警告”，和storage manager中的报告一致。
3、北亚企安数据恢复工程师在windows环境下将识别出来的FC盘在磁盘管理器中标记为脱机状态，然后对原始磁盘进行扇区级别完整镜像。将原始磁盘中的所有物理扇区镜像到windows系统下的逻辑磁盘并以文件形式保存。
在镜像过程中服务器数据恢复工程师发现6号磁盘的镜像速度极慢，结合先前检测结果综合判断，6号盘应该存在大量损坏以及不稳定扇区，导致windows环境下的一些软件无法对其进行操作。
4、使用专业镜像设备对6号硬盘进行坏道镜像操作，在镜像过程中观察镜像的速度和稳定性。在镜像过程中发现6号盘上的坏道并不多，但是存在大量读取响应时间长的不稳定扇区。于是服务器数据恢复工程师调整6号盘的拷贝策略，将“遇到坏道跳过扇区数”和“响应等待时间”等参数作一些调整后继续对6号盘进行镜像操作。同时观察剩余盘在windows环境下镜像的情况。
5、镜像完成后查看日志，发现在storage manager和SMART状态中均没有报错的1号盘也存在坏道，10号和13号盘均存在大量不规则的坏道分布。
根据坏道列表使用工具定位到目标镜像文件进行分析后发现，ext3文件系统的一些关键源数据信息被坏道破坏。只能等6号盘镜像完毕后，通过同一条带进行xor以及根据文件系统上下文关系手动修复被损坏的文件系统。
6、6号盘镜像完成，但是为了最大限度做出有效扇区和保护磁头所设置的拷贝策略，会让这次完成的镜像在镜像过程中自动跳过一些不稳定扇区，所以现在的镜像是不完整的。于是服务器数据恢复工程师调整拷贝策略，继续镜像被跳过的扇区，直到6号盘所有扇区全部镜像完成。
7、所有硬盘镜像完成后，基于镜像文件分析所有硬盘底层数据。根据北亚企安数据恢复工程师对ext3文件系统的逆向研究和对日志文件的分析，获取到16块FC盘的盘序、RAID块大小、RAID的校验走向和方式等重组RAID的必要信息，根据获取到的信息虚拟重组RAID。RAID搭建完成后进一步解析ext3文件系统。
8、和用户方沟通后提取出一些oracle数据库的dmp文件，用户方尝试通过dmp文件恢复数据库。
在dmp恢复的过程中，oracle数据库报告imp-0008错误。北亚数据恢复中心的oracle数据库工程师分析导入dmp文件的日志文件后，发现恢复的dmp文件存在问题，从而导致dmp导入数据失败。
9、服务器数据恢复工程师重新分析raid结构，进一步确定ext3文件系统被破坏的程度，重新恢复dmp文件和dbf原始库文件。
10、将恢复出来的dmp文件移交给用户方进行数据导入测试，这次测试顺利，没有发现问题。对恢复出来的dbf原始库文件进行校验检测，所有文件均能通过测试。
11、数据库工程师到达现场，和用户沟通后决定使用恢复出来的dbf原始库文件进行操作，以确保把数据恢复到最佳状态。

oracle数据库恢复过程：
1、拷贝数据库文件到原数据库服务器作为备份，备份文件所在文件夹路径为/home/oracle/tmp/syntong。在根目录下创建一个名为“oradata”的目录，把syntong文件夹拷贝到oradata目录下。更改oradata文件夹及其所有文件的属组和权限。
2、备份原数据库环境，包括ORACLE_HOME下product文件夹下的相关文件。配置监听，使用原机中的splplus连接到数据库，尝试启动数据库到nomount状态。进行基本状态查询后，了解到环境和参数文件没有问题。 尝试启动数据库到mount状态，进行状态查询没有发现问题。当启动数据库到open状态，出现报错：
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: '/oradata/syntong/system01.dbf'
ORA-01207: file is more recent than control file - old control file
经过进一步的检测和分析，判断此故障为控制文件和数据文件信息不一致，这是一类常因断电或突然关机引发的故障。
3、对数据库文件进行逐个检测，检测到所有数据文件都不存在物理损毁的情况。
4、在mount状态下，对控制文件进行备份。alter database backup controlfile to trace as ' /backup/controlfile'。对备份的控制文件进行查看修改，取得其中的重建控制文件命令。把这些命令复制到一个新建脚本文件controlfile.sql中。
5、关闭数据库，删除/oradata/syntong/下的3个控制文件。 启动数据库到nomount状态，执行controlfile.sql 脚本。
SQL>startup nomount
SQL>@controlfile.sql
6、完成重建控制文件后，启动数据库报错，需要做进一步处理。
SQL> alter database open
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/free/oracle/oradata/orcl/system01.dbf'
然后执行恢复命令：
recover database using backup controlfile until cancel
Recovery of Online Redo Log: Thread 1 Group 1 Seq 22 Reading mem 0
Mem# 0 errs 0: /free/oracle/oradata/orcl/redo01.log
…
做介质恢复，直到返回报告，恢复完成。
7、尝试open数据库。
SQL> alter database open resetlogs
8、成功启动数据库。把原来temp表空间的数据文件加入到对应的temp表空间中。
9、对数据库进行各种常规检查，没有发现任何错误。
10、进行emp备份。全库备份完成也没有报错。将应用程序连接到数据库，进行应用层面的数据验证。经过验证没有发现问题。本次数据恢复工作完成。

审核编辑 黄宇