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

服务器硬盘掉线的常规数据恢复方法

最新动态来源:本站原创点击数:66更新时间:2019/8/30

服务器出现故障需要数据恢复的情况通常都是因为硬盘掉线导致的服务器瘫痪和数据丢失,针对普通的服务器硬盘掉线数据恢复有一套常规的数据恢复方法,普通的硬盘掉线数据丢失都可以进行数据恢复。某客户一台服务器上有16块硬盘,某一天发现10号和13号硬盘亮黄灯,服务器业务崩溃。下面介绍一下使用服务器硬盘掉线的常规数据恢复方法进行数据恢复的全过程。
通过IBM storage manager/frombyte.com连接到服务器上进行服务器状态查询,发现服务器报告逻辑卷状态失败,物理硬盘状态为6号盘报告“警告”,10号和13号盘报告“失败”,通过IBM storage manager将当前服务器的日志进行完整备份,在备份的同时分析日志内容,获得部分逻辑卷信息用于后期数据恢复使用。
将服务内的所有硬盘按照一定的顺序和编号规则进行编号标记,然后将硬盘从服务器内移除,使用数据恢复镜像设备“DELL R510+SUN3510”对服务器内的所有硬盘检测发现16块盘均能正常识别,分别检测16块盘的SMART状态,结果6号盘的SMART状态为“警告”状态和在IBM storage manager中报告一致。
在windows环境下首先将设备识别出来的FC盘在磁盘管理器中标记为脱机状态,从而为原始磁盘提供了一个写保护功能,然后使用winhex软件对原始磁盘进行扇区级别镜像操作,将原始磁盘中的所有物理扇区镜像到windows系统下的逻辑磁盘并以文件形式保存。在镜像过程中发现6号磁盘的镜像速度很慢,结合先前对硬盘SMART状态检测时发现的问题综合判断,6号盘应该存在大量损坏以及不稳定扇区,导致在windows下的一般应用软件无法对其进行操作。
使用专业坏道硬盘镜像设备对6号硬盘进行坏道镜像操作,在镜像过程中同时观察镜像的速度和稳定性,发现6号盘的坏道并不多,但是存在大量的读取响应时间长等不稳定扇区,于是调整6号盘的拷贝策略,将遇到坏道跳过扇区数和响应等待时间等参数均作一些修改。继续对6号盘进行镜像操作。同时观察剩余盘在windows环境下使用winhex镜像的情况。
经过镜像操作后,在windows平台下使用winhex镜像的磁盘已经全部镜像完成,查看winhex生成的日志,发现在IBM storage manager/frombyte.com和硬盘SMART状态中均没有报错的1号盘也存在坏道,10号和13号盘均存在大量不规律的坏道分布,根据坏道列表使用winhex定位到目标镜像文件分析发现,ext3文件系统的一些关键源数据信息有的已经被坏道所破坏,只能等待6号盘镜像完毕后,通过同一条带进行xor以及根据文件系统上下文关系的方式手动修复被损坏的文件系统。
坏道镜像设备报告6号盘镜像完成,但是先前为了最大限度做出有效扇区以及为了保护磁头设置的拷贝策略会自动跳过一些不稳定扇区,所以现在的镜像是不完整的,于是调整拷贝策略,继续镜像被跳过的扇区,6号盘所有扇区全部镜像完毕。
得到了所有硬盘的物理扇区镜像,在windows平台下使用winhex将所有镜像文件全部展开,根据我们对ext3文件系统的逆向以及日志文件的分析,得到了16块FC盘在存储中的盘序,RAID的块大小,RAID的校验走向和方式等信息,于是尝试通过软件的方式虚拟重组RAID,RAID搭建完成后进一步解析ext3文件系统,通过和用户沟通提取出了一些oracle的dmp文件,用户尝试进行恢复。
在dmp恢复的过程中,oracle报告为imp-0008错误,联系北亚的oracle工程师,通过仔细分析导入dmp文件的日志文件,发现恢复的dmp文件存在问题而导致dmp导入数据失败。立刻重新分析raid结构,以及进一步确定ext3文件系统被破坏的程度,又经过数小时的工作,重新恢复dmp文件和dbf原始库文件,将恢复出来的dmp文件移交给用户进行数据导入测试,结果测试顺利没有发现问题,说明这次的数据恢复是成功的,接着对恢复出来的dbf原始库文件进行校验检测,所有文件均能通过测试。本次服务器数据恢复成功。

北京北亚数据恢复中心:4006505646