服务器数据恢复背景

本次恢复数据的服务器为一台IBM DS4700 光纤存储，该公司管理员提供的信息如下：服务器型号为IBM DS4700 存储，挂载14块硬盘，存储oracle数据库，两块硬盘报黄灯错误，目前raid组崩溃/卷无法挂载/业务全部瘫痪，需要进行紧急数据恢复处理。

服务器数据恢复检测过程

服务器数据恢复工程师首先对服务器进行检查，通过IBM storage manager/frombyte.com连接存储查看服务器存储当前状态，存储报告逻辑卷状态失败。然后对物理磁盘状态进行查看，发现13号磁盘状态为“警告”，10号和11号磁盘状态为“失败”，继续使用IBM storage manager对当前存储的全部日志进行备份解析逻辑卷结构信息，以备后期数据恢复使用。
客户管理员在服务器数据恢复工程师的帮助下将服务器全部磁盘进行编号标记，按各自槽位登记并移除服务器移交硬盘数据恢复工程师进行物理检测。工程师通过PC盘镜像设备对全部硬盘进行简单检测，所有硬盘可以正常识别，13号盘SMART状态为“警告”，状态和在IBM storage manager中报告一致。

服务器全盘备份

服务器数据恢复工程师在windows环境下首先将设备可以识别的磁盘在磁盘管理器中标记为脱机状态，从而为原始磁盘提供了一个写保护功能，然后使用数据恢复软件软件对原始磁盘进行扇区级别镜像操作，将原始磁盘中的所有物理扇区镜像到windows系统下的逻辑磁盘并以文件形式保存。（在镜像过程中13号硬盘的镜像速度极其缓慢，初步判断该盘存在大量不稳定扇区及损坏，需要使用坏道硬盘镜像设备进行备份）使用专业坏道硬盘镜像设备对13号硬盘进行坏道镜像同时观察镜像的速度和稳定性，发现13号盘的坏道并不多，但是存在大量的读取响应时间长等不稳定扇区，于是调整该磁盘的拷贝策略，将遇到坏道跳过扇区数和响应等待时间等参数均作一些修改。继续对该磁盘进行镜像操作。同时观察剩余盘在windows环境下使用winhex镜像的情况。
经过镜像操作后，在windows平台下使用winhex镜像的磁盘已经全部镜像完成，查看winhex生成的日志，发现在IBM storage manager/frombyte.com和硬盘SMART状态中均没有报错的1号盘也存在坏道，10号和11号盘均存在大量不规律的坏道分布。使用数据恢复工具结合坏道列表情况进行分析，EXT3文件系统中的部分关键性源数据处于坏道区域已被破坏，目前的数据恢复方案只能使用13号硬盘的镜像文件进行同一条带的xor并且根据文件系统的上下关系进行手动修复损坏的文件系统（13号盘不稳定扇区极多，硬盘数据恢复工程师为尽可能拷贝有效扇区并保护磁头，在镜像时对拷贝策略进行了部分自动跳过坏扇区的调整，镜像文件也可能存在缺损）。

重组raid阵列

服务器数据恢复工程师在windows平台下借助数据恢复工具将所有镜像文件全部展开，通过我们对ext3文件系统的逆向以及日志文件的分析得出服务器中所有磁盘在存储中的盘序信息以及raid校验方向、raid块大小、raid校验方式等信息，通过数据恢复工具对原raid进行虚拟重组、解析EXT3文件系统，将oracle数据库中的dmp文件进行部分提取，尝试进行数据恢复。

恢复oracle数据库

在dmp恢复的过程中，oracle数据库出现报错，内容为“imp-0008”错误，数据库数据恢复工程师对数据库进行分析，导致数据库报错的原因为dmp文件有问题。服务器数据恢复工程师重新对raid结构进行分析重组，重新导出dmp文件和dbf原始库文件并测试，接着对恢复出来的dbf原始库文件进行校验检测，所有文件均能通过测试。
数据库工程师到达现场，和用户沟通后决定使用恢复出来的dbf原始库文件进行操作，以确保能把数据恢复到最佳状态。

数据库恢复过程

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

IBM ds4700存储硬盘离线数据恢复-北亚案例