ITPub博客

首页 > IT基础架构 > 服务器/存储 > 解析IBM x3850 RAID5服务器故障恢复方案

解析IBM x3850 RAID5服务器故障恢复方案

原创 服务器/存储 作者:北亚数据恢复 时间:2019-11-06 14:25:56 0 删除 编辑

【基本信息】

     服务器型号:IBM X3850 服务器,

     硬盘型号:73G SAS 硬盘,

     硬盘数量:5 块硬盘 其中 4 块组成一个 RAID5 ,另一块做为热备盘 (Hot-Spare)

     操作系统:linux redhat 5.3, 应用系统为构架于 oracle 的一个 oa

【故障表现】

    3 号盘早已经离线,但热备盘未自动激活 rebuild (原因不明),之后 2 号盘离线, RAID 崩溃。

    oracle 已经不再对本 oa 系统提供后续支持,用户要求尽可能数据恢复 + 操作系统复原。

【初检结论】

     热备盘完全无启用,硬盘无明显物理故障,无明显同步表现。数据通常可恢复。

【恢复方案】

    1 、保护原环境,关闭服务器,确保在恢复过程中不再开启服务器。

    2 、把故障硬盘编号排序,用以确保硬盘取出槽位后可以完全复原。

    3 、将故障硬盘挂载至只读环境,对所有故障硬盘做完全镜像 ( 参考 < 如何对磁盘做完整的全盘镜像备份 >) 。备份完成后交回原故障盘,之后的恢复操作直到数据确认无误前不再涉及原故障盘。

    4 、对备份盘进行 RAID 结构分析,得到其原来的 RAID 级别,条带规则,条带大小,校验方向, META 区域等。

    5 、根据得到的 RAID 信息搭建一组虚拟的 RAID5 环境。

    6 、进行虚拟磁盘及文件系统解释。

    7 、检测虚拟结构是否正确,如不正确,重复 4-7 过程。

    8 、确定数据无误后,按用户要求回迁数据。如果仍然使用原盘,需确定已经完全对原盘做过备份后,重建 RAID ,再做回迁。回迁操作系统时,可以使用 linux livecd win pe( 通常不支持 ) 等进行,也可以在故障服务器上用另外硬盘安装一个回迁用的操作系统,再进行扇区级别的回迁。

    9 、数据移交后,由我数据恢复中心延长保管数据 3 天,以避免可能忽略的纰漏。

【预估周期】

     备份时间:2 小时左右

     解释及导出数据时间:约4 小时

     回迁操作系统:约4 小时。

【过程详解】

    1 、对原硬盘进行完整镜像,镜像后发现 2 号盘有 10-20 个坏扇区,其余磁盘均无坏道。

    2 、通过对结构的分析得到的最佳结构为 0,1,2,3 盘序,缺 3 号盘,块大小 512 扇区, backward parity(Adaptec) ,结构如下图:

    3 、组好后数据验证, 200M 以上的最新压缩包解压无报错,确定结构正确。

    4 、直接按此结构生成虚拟 RAID 到一块单硬盘上,打开文件系统无明显报错。

    5 、确定备份包安全的情况下,经客户同意后,对原盘重建 RAID ,重建时已经用全新硬盘更换损坏的 2 号盘。将恢复好的单盘用 USB 方式接入故障服务器,再用 linux SystemRescueCd 启动故障服务器,之后通过 dd 命令进行全盘回写。

    6 、回写后,启动操作系统。

    7 dd 所有数据后,启动操作系统,无法进入,报错信息为: /etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied ,分析为此文件权限有问题。

    8 、用 SystemRescueCd 重启后检查,此文件时间、权限、大小均有明显错误,显然节点损坏。

    9 、重新分析重组数据中的根分区,定位出错的 /sbin/pidof ,发现问题因 2 号盘坏道引起。

    10 、使用 0 1 3 3 块盘,针对 2 号盘的损坏区域进行 xor 补齐。补齐后重新校验文件系统,依然有错误,再次检查 inode 表,发现 2 号盘损坏区域有部分节点表现为 ( 图中的 55 55 55 部分 )

    11 、很明显,虽然节点中描述的 uid 还正常存在,但属性,大小,以最初的分配块全部是错误的。按照所有可能进行分析,确定无任何办法找回此损坏节点。只能希望修复此节点,或复制一个相同的文件过来。对所有可能有错的文件,均通过日志确定原节点块的节点信息,再做修正。

    12 、修正后重新 dd 根分区,执行 fsck -fn /dev/sda5 ,进行检测,依然有报错,如下图:

    13 、根据提示,在系统中发现有多个节点共用同样的数据块。按此提示进行底层分析,发现,因 3 号盘早掉线,帮存在节点信息的新旧交集。

    14 、按节点所属的文件进行区别,清除错误节点后,再次执行 fsck -fn /dev/sda5, 依然有报错信息,但已经很少。根据提示,发现这些节点多位于 doc 目录下,不影响系统启动,于是直接 fsck -fy /dev/sda5 强行修复。

    15 、修复后,重启系统,成功进入桌面。启动数据库服务,启动应用软件,一切正常,无报错。

 

     到此,数据恢复及系统回迁工作完成。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31380569/viewspace-2662891/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
从事数据恢复工作,擅长服务器/虚拟机/数据库等方面的数据恢复

注册时间:2016-08-02

  • 博文量
    185
  • 访问量
    101665