【服务器数据恢复】RAID5第一块硬盘离线但热备盘未激活,第二块硬盘离线导致RAID5崩溃的数据恢复案例

时间:2022-10-20 13:59:32

服务器数据恢复环境:

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信息,如下图:


【服务器数据恢复】RAID5第一块硬盘离线但热备盘未激活,第二块硬盘离线导致RAID5崩溃的数据恢复案例


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部分):


【服务器数据恢复】RAID5第一块硬盘离线但热备盘未激活,第二块硬盘离线导致RAID5崩溃的数据恢复案例


很明显,虽然节点中描述的uid还正常存在,但属性、大小、最初的分配块全部是错误的。确定无法找回此损坏节点后只能修复此节点,或复制一个相同的文件过来。

10、对所有可能有错的文件通过日志确定原节点块的节点信息,然后由北亚数据恢复工程师修正。

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


【服务器数据恢复】RAID5第一块硬盘离线但热备盘未激活,第二块硬盘离线导致RAID5崩溃的数据恢复案例


12、根据报错提示,在系统中发现有多个节点共用同样的数据块。通过底层分析发现存在节点信息的新旧交集问题。

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

14、启动oracle数据库服务和OA应用软件,一切正常无报错。

15、让用户亲自对恢复出来的数据和操作系统进行检测,确定没有问题,本次数据恢复工作完成。