服务器数据恢复环境：
一台IBM某型号服务器上有16块FC硬盘组建RAID阵列。上层linux操作系统，ext3文件系统，部署有oracle数据库。
服务器故障&检测：
服务器上跑的业务突然崩溃，管理员发现服务器上有2块磁盘的指示灯显示黄色。
通过IBM storage manager查询服务器状态，发现服务器报告逻辑卷状态失败。物理硬盘状态为：一块盘报告“警告”，指示灯显示黄色的2块盘报告“失败”。通过IBM storage manager将当前服务器的日志完整备份。北亚企安数据恢复工程师在备份服务器日志的同时分析日志内容，获取数据恢复所需要的逻辑卷信息。
服务器数据恢复过程：
1、将服务器中所有硬盘编号标记后从服务器内取出，由硬件工程师对所有硬盘进行硬件故障检测，经过检测发现16块盘均可以读取。针对16块盘的SMART状态进行检测，经过检测发现在IBM storage manager中报告“警告”的那块盘的SMART状态也报告为“警告”，结果一致。
2、在windows环境下将识别出来的FC盘在磁盘管理器中标记为脱机状态，然后对这些磁盘进行扇区级别全盘镜像，将原始磁盘中的所有物理扇区镜像到windows系统下的逻辑磁盘并以文件形式保存。在镜像过程中发现SMART状态报告为“警告”的磁盘镜像速度异常，windows环境下的一般应用软件无法对其进行操作，结合前面的检测结果可以判断该盘应该存在损坏/不稳定的扇区。
3、使用专业硬盘镜像设备对这块SMART状态报告为“警告”的磁盘进行镜像，在镜像过程中观察发现该盘的坏道并不多，但是存在大量的读取响应时间长的不稳定扇区，于是调整镜像策略，修改“遇到坏道跳过扇区数”和“响应等待时间”等参数后继续对该盘进行镜像。
4、所有其他磁盘（除了SMART状态报告为“警告”的磁盘）镜像完成后，查看镜像过程中生成的日志，发现在IBM storage manager和硬盘SMART状态中均没报错的另外一块磁盘中也存在坏道，指示灯显示黄色的2块盘也存在大量不规律的坏道分布，根据坏道列表定位到目标镜像文件分析发现，ext3文件系统的一些关键源数据信息已经被坏道破坏，只能等待SMART状态报告为“警告”的磁盘镜像完毕后，通过同一条带进行xor以及根据文件系统上下文关系手动修复被损坏的文件系统。
5、SMART状态报告为“警告”的磁盘镜像完成，但是之前为了最大限度做出有效扇区以及为了保护磁头而设置的拷贝策略会自动跳过一些不稳定扇区，所以该盘的镜像是不完整的。调整拷贝策略，继续镜像被跳过的扇区，直到该盘所有扇区全部镜像出来。
6、将服务器中16块硬盘的物理扇区镜像完成后，在windows平台下使用软件将所有镜像文件全部展开。经过对ext3文件系统的逆向分析以及对日志文件的分析，获取到16块FC盘的盘序，RAID的块大小，RAID的校验走向和方式等信息。
7、利用这些raid相关信息虚拟重组RAID，RAID重构完成后对ext3文件系统进行解析。
8、和用户沟通后，数据恢复工程师提取出了一些oracle的dmp文件，由用户尝试进行恢复。恢复的过程中oracle报告imp-0008错误。北亚企安数据库工程师仔细分析导入dmp文件的日志文件，发现提取出来的dmp文件存在问题。
9、重新分析raid结构，进一步确定ext3文件系统被破坏的程度。又经过数小时的努力，北亚企安数据恢复工程师重新提取了dmp文件和dbf原始库文件。将恢复出来的dmp文件移交给用户进行导入，这次导入一切顺利，没有报错。对恢复出来的dbf原始库文件进行校验，结果所有文件均通过测试。经过仔细核检测后，用户认可数据恢复结果，本次服务器数据恢复工作完成。
