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

【基本信息】
服务器型号：IBM X3850服务器，
硬盘型号：73G SAS硬盘，
硬盘数量：5块硬盘 其中4块组成一个RAID5，另外一块作为热备盘(Hot-Spare)，
操做系统：linux redhat 5.3,应用系统为构架于oracle的一个oa。

【故障表现】
3号盘早已经离线，但热备盘未自动激活rebuild（缘由不明），以后2号盘离线，RAID崩溃。
oracle已经再也不对本oa系统提供后续支持，用户要求尽量数据恢复+操做系统复原。

【初检结论】
热备盘彻底无启用，硬盘无明显物理故障，无明显同步表现。数据一般可恢复。

【恢复方案】
一、保护原环境，关闭服务器，确保在恢复过程当中再也不开启服务器。
二、把故障硬盘编号排序，用以确保硬盘取出槽位后能够彻底复原。
三、将故障硬盘挂载至只读环境，对全部故障硬盘作彻底镜像(参考<如何对磁盘作完整的全盘镜像备份>)。备份完成后交回原故障盘，以后的恢复操做直到数据确认无误前再也不涉及原故障盘。
四、对备份盘进行RAID结构分析，获得其原来的RAID级别，条带规则，条带大小，校验方向，META区域等。
五、根据获得的RAID信息搭建一组虚拟的RAID5环境。
六、进行虚拟磁盘及文件系统解释。
七、检测虚拟结构是否正确，如不正确，重复4-7过程。
八、肯定数据无误后，按用户要求回迁数据。若是仍然使用原盘，需肯定已经彻底对原盘作过备份后，重建RAID，再作回迁。回迁操做系统时，可使用linux livecd或win pe(一般不支持)等进行，也能够在故障服务器上用另外硬盘安装一个回迁用的操做系统，再进行扇区级别的回迁。
九、数据移交后，由我数据恢复中心延长保管数据3天，以免可能忽略的纰漏。

【预估周期】
备份时间：2小时左右
解释及导出数据时间：约4小时
回迁操做系统：约4小时。

【过程详解】
一、对原硬盘进行完整镜像，镜像后发现2号盘有10-20个坏扇区，其他磁盘均无坏道。
二、经过对结构的分析获得的最佳结构为0,1,2,3盘序，缺3号盘，块大小512扇区，backward parity(Adaptec)，结构以下图：

三、组好后数据验证，200M以上的最新压缩包解压无报错，肯定结构正确。
四、直接按此结构生成虚拟RAID到一块单硬盘上，打开文件系统无明显报错。
五、肯定备份包安全的状况下，经客户赞成后，对原盘重建RAID，重建时已经用全新硬盘更换损坏的2号盘。将恢复好的单盘用USB方式接入故障服务器，再用linux SystemRescueCd启动故障服务器，以后经过dd命令进行全盘回写。
六、回写后，启动操做系统。
七、dd全部数据后，启动操做系统，没法进入，报错信息为：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied，分析为此文件权限有问题。
八、用SystemRescueCd重启后检查，此文件时间、权限、大小均有明显错误，显然节点损坏。
九、从新分析重组数据中的根分区，定位出错的/sbin/pidof，发现问题因2号盘坏道引发。
十、使用0，1，3这3块盘，针对2号盘的损坏区域进行xor补齐。补齐后从新校验文件系统，依然有错误，再次检查inode表，发现2号盘损坏区域有部分节点表现为(图中的55 55 55部分)：

十一、很明显，虽然节点中描述的uid还正常存在，但属性，大小，以最初的分配块所有是错误的。按照全部可能进行分析，肯定无任何办法找回此损坏节点。只能但愿修复此节点，或复制一个相同的文件过来。对全部可能有错的文件，均经过日志肯定原节点块的节点信息，再作修正。
十二、修正后从新dd根分区，执行fsck -fn /dev/sda5，进行检测，依然有报错，以下图：

1三、根据提示，在系统中发现有多个节点共用一样的数据块。按此提示进行底层分析，发现，因3号盘早掉线，帮存在节点信息的新旧交集。
1四、按节点所属的文件进行区别，清除错误节点后，再次执行fsck -fn /dev/sda5,依然有报错信息，但已经不多。根据提示，发现这些节点多位于doc目录下，不影响系统启动，因而直接fsck -fy /dev/sda5强行修复。
1五、修复后，重启系统，成功进入桌面。启动数据库服务，启动应用软件，一切正常，无报错。

到此，数据恢复及系统回迁工做完成。