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

RAID5热备盘未激活导致RAID崩溃的数据恢复案例

最新动态来源:本站原创点击数:82更新时间:2022/10/20

服务器数据恢复环境:
IBM某型号服务器,5个SAS硬盘组建RAID5(4个数据盘,1个热备盘);
linux redhat操作系统;
上层应用为oa,数据库为oracle;oracle已经不对本案例中的oa提供后续支持。
 
服务器故障&初检&恢复方案:
RAID5中有一块盘离线,但热备盘由于未知原因未被激活rebuild,直到另外一块盘离线导致RAID崩溃。用户联系我们数据恢复中心要求恢复数据和操作系统。
经过数据恢复工程师检测,发现热备盘完全没有启用,没有发现有物理故障,也没有同步的表现。
经过北亚数据恢复工程师团队会诊,确定最终的数据恢复方案:
1、关闭服务器,将硬盘标好序号取出。
2、将硬盘挂载到只读环境对所有硬盘做镜像备份。后续的数据恢复操作都在镜像文件上进行,避免对原始数据造成二次破坏。
3、基于镜像文件分析故障RAID5的结构,获取RAID级别、条带规则、条带大小、校验方向、META区域等RAID信息。
4、根据获取到的RAID信息搭建虚拟的RAID5环境。
5、解释虚拟磁盘及文件系统。
6、检测虚拟结构是否正确,如不正确,重复3-5步骤。
7、最终确定数据没有问题后按照用户要求回迁数据。如果仍然使用原盘,需确定已经完全对原盘做过备份之后再重建RAID,然后做回迁。可以使用linux livecd回迁操作系统,也可以在故障服务器上用另外的硬盘安装一个回迁用的操作系统,再进行扇区级别的回迁。
 
服务器数据恢复过程:
1、对故障服务器中所有硬盘进行完整镜像,镜像过程中发现后掉线的那个硬盘有10-20个坏扇区,其余磁盘均没有发现坏道。
2、分析RAID得到RAID最佳结构、块大小、校验方向等RAID信息。
3、根据第2步获取到的信息虚拟重建RAID后进行数据验证,200M以上的压缩包解压无报错,确定结构正确。
4、直接按此结构生成虚拟RAID到一块单硬盘上,打开文件系统无明显报错。
5、确定备份包安全的前提下经用户同意后利用原盘重建RAID,重建时已经用全新硬盘更换那块后掉线的已经损坏的硬盘。将恢复好的单盘用USB方式接入故障服务器,用linux SystemRescueCd启动故障服务器。
6、通过dd命令进行全盘回写,启动操作系统。
7、dd所有数据后,启动操作系统但是无法进入,报错:/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。数据恢复工程师怀疑此文件权限有问题,使用SystemRescueCd重启后检查,结果发现此文件时间、权限、大小均有明显错误,这意味着节点损坏。
8、重新分析重组数据中的根分区,定位出错的/sbin/pidof,发现问题是后掉线的那块硬盘坏道所引起的。
9、使用其他完好的3个数据盘对后掉线硬盘的损坏区域进行xor补齐。补齐后重新校验文件系统依然报错误,再次检查inode表,发现后掉线硬盘损坏区域有部分节点表现为55 55 55部分。
很明显,虽然节点中描述的uid还正常存在,但属性、大小、最初的分配块全部是错误的。确定无法找回此损坏节点后只能修复此节点,或复制一个相同的文件过来。
10、对所有可能有错的文件通过日志确定原节点块的节点信息,然后由北亚数据恢复工程师修正。
11、修正后重新dd根分区,执行fsck -fn /dev/sda5命令进行检测,依然报错。
12、根据报错提示,在系统中发现有多个节点共用同样的数据块。通过底层分析发现存在节点信息的新旧交集问题。
13、按节点所属的文件进行区别,清除错误节点后执行fsck -fn /dev/sda5,依然有报错但已经很少。根据错误提示发现这些节点多位于doc目录下,不影响系统启动,于是直接使用fsck -fy /dev/sda5命令强行修复。修复后重启系统,成功进入系统桌面。
14、启动oracle数据库服务和OA应用软件,一切正常无报错。
15、让用户亲自对恢复出来的数据和操作系统进行检测,确定没有问题,本次数据恢复工作完成。