ext3文件系统下oracle数据恢复案例
最新动态来源：本站原创点击数：193更新时间：2023/3/16
服务器故障&检测：
某公司一台IBM某型号服务器共16块硬盘，管理员某天巡检的时候发现该服务器的10号和13号硬盘灯显示黄色，服务器宕机，服务器上跑的业务终止。
通过IBM storage manager查询服务器状态，逻辑卷状态报告“失败”；6号盘的物理硬盘状态报告“警告”，10号和13号盘报告“失败”。通过IBM storage manager将当前服务器的日志进行完整备份，在备份的同时分析日志内容，获得部分逻辑卷信息用于后期数据恢复使用。
服务器数据恢复过程：
1、将故障服务器内所有硬盘编号并取出。对所有硬盘进行物理故障检测，16块盘均能正常识别。检测16块盘的SMART状态，结果发现6号盘的SMART状态为“警告”，和IBM storage manager中的报告一致。
2、将故障服务器中所有磁盘以只读方式进行扇区级别的镜像备份。在镜像过程中6号磁盘的镜像速度异常缓慢，结合6号盘SMART状态可以判断6号盘应该存在大量损坏的不稳定扇区，无法通过常规方式进行镜像。
3、使用专业设备对6号盘进行镜像，在镜像过程中发现6号盘的坏道并不多，只是存在大量不稳定扇区。调整镜像策略，修改“遇到坏道跳过扇区数”、“响应等待时间”等参数后继续对6号盘镜像。
4、所有磁盘镜像完成后查看日志，发现在IBM storage manager和硬盘SMART状态中均没有发现异常的1号盘也存在坏道，10号和13号盘也存在大量不规律的坏道分布。根据坏道列表定位到目标镜像文件，经过分析发现ext3文件系统的一些关键源数据信息被破坏。只能等所有硬盘镜像完成后，通过同一条带进行xor
以及根据文件系统上下文关系手动修复被损坏的文件系统。
5、虽然6号盘镜像完成，但是先前所做的镜像策略会自动跳过一些不稳定扇区，所以6号盘的镜像是不完整的。重新调整拷贝策略继续镜像被跳过的扇区，完成6号盘所有扇区镜像。
6、完成所有硬盘的镜像后，北亚企安数据恢复工程师对ext3文件系统进行逆向分析，结合对日志文件的分析，最终获取到16块盘的盘序，RAID块大小，RAID的校验走向和方式等RAID相关信息。
7、利用获取到的RAID相关信息虚拟重组RAID，重组完成后解析ext3文件系统，通过和用户沟通后提取出oracle的dmp文件并尝试进行恢复。在使用dmp文件进行恢复的过程中，oracle报告imp-0008错误。北亚企安的oracle工程师分析dmp文件的日志文件后发现提取出的dmp文件有问题。
8、重新分析raid结构，进一步确定ext3文件系统被破坏的程度。经过数据恢复工程师团队的不懈努力，终于重新提取出dmp文件和dbf原始库文件。将提取出来的dmp文件移交给用户，导入数据进行测试没有发现问题。对恢复出来的dbf原始库文件进行校验，所有文件均通过测试。本次数据恢复工作完成。