您所在的位置:首页 > 成功案例 > RAID数据恢复

x3850 服务器RAID5数据恢复过程(raid5两块硬盘离线)

最新动态来源:北亚数据恢复中心点击数:834更新时间:2017/11/21

这次做数据恢复的故障发生在一台X3850服务器上,一共涉及了5块硬盘,这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),结构如下图:
图一:
数据恢复_raid数据恢复_北亚数据恢复

  尝试着组了一下进行数据验证发现最新压缩包解压没有报错的数据量在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部分
图二:
数据恢复_raid数据恢复_北亚数据恢复

  看了图片中的情况一切都明了了,节点中描述的uid虽然看起来是正常的存在,但是大小及属性、最初的分配块都是错误的。我们分析了所有一切的可能性都没有办法把这个损坏的节点找回来,只能尝试修复或者以相同文件代替,通过日志把一切可能有错的文件原节点块的节点信息确定出来然后再进行修正。修正之后重新dd了根分区,执行fsck -fn /dev/sda5居然还有报错,这个时候真心崩溃啊!整个人都不好了。
图三:
数据恢复_raid数据恢复_北亚数据恢复

  数据恢复工作还要继续,客户还在催进度。只好根据报错提示重新查找,发现系统中有多个节点共用同样的数据块,原来是3号盘掉线最早所以出现了节点信息新旧交集的情况。问题似乎清晰了许多,我们把错误节点进行了清除之后再次执行fsck -fn /dev/sda5依然报错(此时语言已经无法形容我的心情了)。不过我们发现这些节点大多是在doc目录下,是不影响系统启动的,于是直接强行修复重启系统,进入桌面启动数据库和应用软件,没有报错,一切正常。至此,这个一波多折的raid5数据恢复项目圆满结束。

本案例为北亚数据恢复中心真实案例