您所在的位置:首页 > 成功案例 > Linux数据恢复

IBM服务器ext3文件系统数据恢复案例

最新动态来源:本站原创点击数:309更新时间: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原始库文件进行校验,所有文件均通过测试。本次数据恢复工作完成。