关于数据恢复:服务器数据恢复IBM服务器硬盘不稳定导致宕机的数据恢复案例

44次阅读

共计 1168 个字符,预计需要花费 3 分钟才能阅读完成。

服务器故障 & 检测:
某公司一台 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 原始库文件进行校验,所有文件均通过测试。本次数据恢复工作实现。

正文完
 0