服务器数据恢复—RAID5多块磁盘掉线导致崩溃的数据恢复案例

服务器数据恢复环境&故障：
某公司的一台服务器中的raid5磁盘阵列有两块磁盘先后掉线，服务器崩溃。故障服务器的操作系统为linux，操作系统部署了oa，数据库为oracle。oracle数据库已经不再对该oa系统提供后续支持，用户要求尽可能恢复操作系统和数据。
经过北亚企安数据恢复工程师检测，发现热备盘完全无启用，所有硬盘不存在明显物理故障，无明显同步的表现。

数据恢复及操作系统还原过程：
1、对故障服务器中所有硬盘以只读方式进行完整镜像，镜像过程中后发现raid中2号盘有少量坏扇区，其余磁盘均无坏道。
2、基于镜像文件分析raid结构，获取到条带规则、条带大小、校验方向、META区域等信息。raid最佳结构为0,1,2,3盘序，缺3号盘，块大小512扇区，backward parity(Adaptec)。

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

3、按照上面获取到的raid信息重组raid后验证数据，发现200M以上的最新压缩包解压无报错，确定raid结构正确。
4、按照此结构生成RAID到一块单硬盘上，打开文件系统无明显报错。
5、经客户同意后，用全新硬盘更换损坏的2号盘，然后使用原盘重建RAID。将恢复好的单盘接入故障服务器，再用linux SystemRescueCd启动故障服务器，之后通过dd命令进行全盘回写。
6、回写后启动操作系统。如果正常进入系统，则所有工作就完成了。不巧的是，dd所有数据后，启动操作系统，无法进入，报错信息为：“/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied”。
7、怀疑此文件权限有问题，用SystemRescueCd重启后检查，此文件时间，权限，大小均有明显错误，显然节点损坏。
8、重新分析重组数据中的根分区，定位出错的/sbin/pidof，发现问题是由raid中的2号盘坏道引起。
9、使用0号，1号，3号这3块盘对2号盘的损坏区域进行xor补齐。补齐后重新校验文件系统，依然有错误。再次检查inode表，发现2号盘损坏区域有部分节点表现为下图中55 55 55部分。

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

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

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

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

审核编辑 黄宇