-4006-505-646 -4006-505-646 北亚小编今天分享的是5块硬盘中有4块组成一个RAID5，另外一块是热备盘。这组RAID中的3号硬盘最早离线，但是硬盘离线后却没有自动激活rebuild，随后2号盘也发生故障离线导致RAID崩溃。
由于用户使用的Linux Redhat5.3操作系统，应用系统是一个OA系统，架构于oracle。所以用户的需求是不仅要进行RAID数据恢复同时还要求尽可能的还原操作系统。幸运的是客户的硬盘并没有明显的物理故障，也没有明显的同步表现，数据恢复的可能性还是很大的。
【数据恢复过程】
客户在我们的协助下首先关闭了服务器并且确保在恢复RAID数据的过程中不再开启服务器，然后把故障盘按照排列顺序取出槽位并且挂在到一个只读环境上开始对所有的故障盘进行完全镜像备份，两个小时后备份完成交回原盘，备份完成后我们在2号硬盘发现了10到20个的坏扇区，其他硬盘都没有坏道。接着继续分析硬盘结构发现最佳结构为0,1,2,3盘序，其中3号盘缺盘，块大小512扇区，backward parity(Adaptec)，结构如下图：
图一：
尝试着组了一下进行数据验证发现最新压缩包解压没有报错的数据量在200M以上，说明结构是正确的。按照这个思路和结构在一块单盘上生成虚拟RAID并尝试打开，没有明显报错。跟客户沟通客户随即要求我们对原盘重建RAID（当然损坏2号盘已经被一块新的硬盘替换掉了）。重建RAID的过程就比较简单了，先把我们恢复好的这一块单盘用USB接入到原来的故障服务，再用linux SystemRescueCd启动，最后通过dd命令进行全盘回写，启动操作系统。但是在启动操作系统时候出现了报错/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied，我们认为原因在于这个文件权限出了问题。于是SystemRescueCd进行重启之后检查发现果然如此，文件的权限、大小、时间都有非常明显的错误，节点损坏。
分析出了问题的所在之后对重组数据中的根分区进行重新分析定位出了出错的/sbin/pidof，发现根本原因还在于2号硬盘的坏道。我们只好使用0号盘、1号盘、3号盘这三块硬盘针对损坏了的2号盘区域进行xor补齐，可是补齐之后校验文件系统依然报错。再一次检查iNode表发现2号盘损坏区域有部分节点表现为下图中的55 55 55部分
图二：
节点中描述的uid虽然看起来是正常的存在，但是大小及属性、最初的分配块都是错误的。我们分析了所有一切的可能性都没有办法把这个损坏的节点找回来，只能尝试修复或者以相同文件代替，通过日志把一切可能有错的文件原节点块的节点信息确定出来然后再进行修正。修正之后重新dd了根分区，执行fsck -fn /dev/sda5出现报错。
图三：
数据恢复工作还要继续，客户还在催进度。只好根据报错提示重新查找，发现系统中有多个节点共用同样的数据块，原来是3号盘掉线最早所以出现了节点信息新旧交集的情况。问题似乎清晰了许多，我们把错误节点进行了清除之后再次执行fsck -fn /dev/sda5依然报错（此时语言已经无法形容我的心情了）。不过我们发现这些节点大多是在doc目录下，是不影响系统启动的，于是直接强行修复重启系统，进入桌面启动数据库和应用软件，没有报错，一切正常。
【数据恢复结果】
数据恢复用时4天，经客户验证，数据没有问题，本次数据恢复成功。
北京北亚数据恢复中心：4006-505-646
官方网址：www.frombyte.com