IBM x3850X5服务器硬盘离线数据恢复的过程

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了IBM x3850X5服务器硬盘离线数据恢复的过程相关的知识,希望对你有一定的参考价值。

服务器数据恢复背景介绍:

客户的一台ibm x3850X5服务器上有两块硬盘由于未知故障离线,导致服务器数据丢失,需要进行数据恢复。数据恢复中心安排服务器数据恢复工程师对客户的故障服务器进行初检,客户服务器由5块硬盘组成raid5磁盘阵列、linux redhat 5.3操作系统、存储一个oracle数据库。阵列中有两块硬盘处于离线状态,热备盘未激活。硬盘无物理故障,无明显同步表现。

数据恢复中心数据恢复方案:

将故障服务器关机并保证在数据恢复过程中保持服务器关机状态,将故障盘进行标记后取出槽位挂载至数据恢复的备份服务器环境进行镜像备份。完成后恢复原故障服务器。
分析备份盘中的raid结构,得到原阵列中的raid界别、条带大小、校验方向、条带规则以及meta区域等信息。
根据分析出来的raid信息虚拟搭建一组raid5环境对磁盘文件系统进行解释,对虚拟结构的正确性检测,数据无误即可回迁数据。

服务器数据恢复及系统复原过程:

  1. 对原硬盘镜像后发现除了2号盘有10-20个坏扇区外其他硬盘均正常。
  2. 对raid结构进行分析,最佳盘序结构是0-1-2-3,缺失3号盘,结构如下图:
    技术分享图片
    组好后数据验证,200M以上的最新压缩包解压无报错,按照这一结构将虚拟raid生成到一块硬盘上,通过USB的方式把恢复后的单盘接入原服务器,通过linux SystemRescueCd启动故障服务器后使用dd命令进行全盘回写。
  3. 数据回写完成后无法进入操作系统,报错信息为:/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。工程师使用SystemRescueCd重启后检查发现文件的权限、时间、大小都有明显错误,对根分区再次分析定位出错的/sbin/pidof/datahf.net,得出问题原因是2号盘坏道。
  4. 通过其他盘针对2号盘的损坏区域进行xor补齐并重新校验文件系统,依然有错误,工程师只好再次对inode表进行检查,发现2号盘损坏区域有部分节点表现为(图中的55 55 55部分):
    技术分享图片
    可以看出虽然节点中描述的uid还正常存在,但大小、属性、最初的分配块全部是错误的。通过日志确定原节点块的节点信息后进行修正,重新dd根分区,执行fsck -fn /dev/sda5/datahf.net检测,报错情况如下图:
    技术分享图片
    经过分析发现,原来3号盘最先离线,节点信息新旧交集导致有多个节点共用数据块,工程师按节点所属的文件进行区别,清除错误节点后,再次执行fsck -fn /dev/sda5,依然有部分位于doc目录下的节点报错,由于不影响启动所以强行修复后重启系统,系统正常,启动数据库正常。

服务器数据恢复结论:

由客户方工程师对服务器数据进行验证,数据正常,数据恢复100%成功。

以上是关于IBM x3850X5服务器硬盘离线数据恢复的过程的主要内容,如果未能解决你的问题,请参考以下文章

北亚数据恢复IBM3650服务器raid5硬盘故障离线rebuild过程中遭遇坏道导致服务器崩溃的数据恢复

IBM ds4700存储硬盘离线数据恢复-北亚案例

服务器数据恢复IBM存储服务器硬盘坏道离线oracle数据库损坏的数据恢复案例

IBM服务器多块硬盘离线数据恢复方法

服务器数据恢复IBM服务器中SAP应用数据恢复案例

北京某公司IBM X3650M3存储崩溃的解决过程