服务器数据恢复—raid5热备盘未激活导致阵列崩溃的数据恢复案例

服务器数据恢复环境：
某品牌X系列服务器，4块SAS硬盘组建了一组RAID5阵列，还有1块磁盘作为热备盘使用。服务器上层安装的linux操作系统，操作系统上部署了一个基于oracle数据库的OA（oracle已经不再为该OA系统提供后续服务支持）。

服务器故障：
raid5中一块磁盘离线，热备盘未自动激活rebuild（原因不明）。服务器在运行一段时间后，另一块磁盘离线，RAID5阵列崩溃。用户方要求尽可能恢复服务器操作系统和服务器中的数据。
将故障服务器中所有磁盘编号后取出，硬件工程师检测后没有发现有磁盘（包括离线的2块磁盘和热备盘）存在明显的物理故障。热备盘完全没有启用，无明显同步表现。

服务器数据恢复方案：
1、将所有磁盘以只读方式进行扇区级的全盘镜像，镜像完成后将所有磁盘按照编号还原到原服务器中，后续的数据分析和数据恢复操作都基于镜像文件进行，避免对原始磁盘数据造成二次破坏。
2、基于镜像文件分析RAID5结构，获取到RAID5条带规则、条带大小、校验方向、META区域等raid结构相关信息。
3、根据获取到的RAID结构信息虚拟重构RAID5。
4、解释虚拟磁盘及文件系统。
5、检测重构的raid5结构是否正确，如不正确，重复2-4过程。
6、检测raid5结构没有问题以及数据无误后，按用户要求回迁数据。

服务器数据恢复过程：
1、在对故障服务器中磁盘做镜像时，发现后离线的那块磁盘有十几个坏扇区，其余磁盘没有发现有坏道。
2、基于镜像文件分析获取raid5结构相关信息。

北亚企安数据恢复——Raid5数据恢复

3、根据获取到的raid结构信息虚拟重组raid5，重组完成后验证数据，发现200M以上的压缩包解压没有报错，由此可以确定分析出来的raid5结构正确。
4、按照该raid5结构生成虚拟RAID到一块单硬盘上，打开文件系统没有出现报错。
5、确定备份包没有问题和经过用户方的同意后，用新硬盘更换存在坏扇区的那块磁盘，然后对原盘重建RAID。
6、将恢复好的单盘用USB方式接入故障服务器，用linux SystemRescueCd启动故障服务器，然后使用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数据恢复

很明显，虽然节点中描述的uid正常存在，但属性、大小、最初的分配块全部是错误的。北亚企安数据恢复工程师按照所有可能性进行分析，确定无法找回此损坏节点。只能修复此节点或者复制一个相同的文件过来。
10、针对所有可能有错的文件，通过日志确定原节点块的节点信息，再做修正。
11、修正后重新dd根分区，执行fsck -fn /dev/sda5/进行检测，依然报错。

北亚企安数据恢复——Raid5数据恢复

12、根据报错提示，在系统中发现有多个节点共用同样的数据块。按照提示分析底层，发现存在节点信息的新旧交集。
13、按节点所属的文件进行区别，清除错误节点后，再次执行fsck -fn /dev/sda5进行检测，依然有极少量的报错信息。根据报错提示，发现这些节点多位于doc目录下，不影响系统启动。直接执行fsck -fy /dev/sda5/强行修复。
14、修复完成后重启系统，成功进入操作系统桌面。
15、启动oracle数据库服务，启动应用软件，一切正常，无报错。
16、用户方对操作系统，oracle数据库以及OA数据进行检测，经过多部门的反复检测，确认恢复数据完整可用。本次数据恢复工作完成。

审核编辑 黄宇