服务器数据恢复环境：

IBM X系列服务器；

操作系统为linux redhat；

5块73G SAS硬盘，4块组成RAID5，1块作为热备盘(Hot-Spare)。

故障：

3号盘最早离线，热备盘未自动激活rebuild（原因不明），然后2号盘离线，RAID崩溃。用户联系北亚数据恢复中心进行

数据恢复。

应用是基于oracle数据库的一个OA系统。因oracle已经不再对本OA系统提供后续支持，用户要求尽可能恢复数据和操作

系统。热备盘完全无启用，硬盘无明显物理故障，无明显同步表现。

服务器数据恢复方案：

1、关闭服务器，将故障硬盘标好序号。

2、将故障硬盘挂载到北亚数据恢复备份服务器，对所有故障硬盘做完全镜像。备份完成后交还原故障盘。

3、通过对备份盘进行RAID结构分析，北亚数据恢复工程师获取到其原来的RAID级别，条带规则，条带大小，校验方向，

META区域等。

4、根据得到的RAID信息，由北亚数据恢复工程师搭建一组虚拟的RAID5环境。

5、进行虚拟磁盘及文件系统解释。

6、检测虚拟结构是否正确，如不正确，重复3-6的过程。

7、确定数据无误后回迁数据。如果仍然使用原盘，需确定已完全对原盘做过备份，重建RAID，再做回迁。回迁操作系统时

，可以使用linux livecd或win pe(通常不支持)等进行，也可以在故障服务器上用另外硬盘安装一个回迁用的操作系统，再进

行扇区级别的回迁。

服务器数据恢复过程：

1、对原硬盘进行完整镜像，北亚数据恢复工程师发现2号盘有10-20个坏扇区，其余磁盘，均无坏道。

2、分析结构，得到的最佳结构为0,1,2,3盘序，缺3号盘，块大小512扇区，backward parity(Adaptec)，结构如下图：

3、组好后进行数据验证，200M以上的最新压缩包解压无报错，确定结构正确。

4、直接按此结构生成虚拟RAID到一块单硬盘上，打开文件系统无明显报错。

5、确定备份包安全的情况下，经用户同意后，对原盘重建RAID，重建时已经用全新硬盘更换损坏的2号盘。将恢复好的单

盘用USB方式接入故障服务器，再用linux SystemRescueCd启动故障服务器，之后通过dd命令进行全盘回写。

6、dd所有数据后，启动操作系统，无法进入，报错信息为：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied  

。怀疑此文件权限有问题，北亚数据恢复工程师用SystemRescueCd重启后检查，此文件时间，权限，大小均有明显错误

，显然节点损坏。

7、北亚数据恢复工程师重新分析，重组数据中的根分区，定位出错的/sbin/pidof/datahf.net，发现问题因2号盘坏道引起。

8、使用0，1，3这3块盘针对2号盘的损坏区域进行xor补齐。补齐后重新校验文件系统，发现依然有错误，再次检查inode

表，发现2号盘损坏区域有部分节点表现为(图中的55 55 55部分)：

很明显，虽然节点中描述的uid还正常存在，但属性、大小和最初的分配块全部是错误的。按照所有可能进行分析，北亚数

据恢复工程师判断无法找回此损坏节点，只能修复此节点，或复制一个相同的文件过来。

9、对所有可能有错的文件，均通过日志确定原节点块的节点信息，再做修正。修正后重新dd根分区，执行

fsck -fn /dev/sda5/datahf.net，进行检测，依然有报错，如下图：

10、根据提示，在系统中发现有多个节点共用同样的数据块。按此提示进行底层分析，北亚数据恢复工程师发现因3号盘早

掉线因而存在节点信息的新旧交集。

11、按节点所属的文件进行区别，清除错误节点后，再次执行fsck -fn /dev/sda5依然有报错信息，但已经很少。根据提示

，发现这些节点多位于doc目录下，不影响系统启动，于是执行fsck -fy /dev/sda5/datahf.net强行修复。

12、修复完成后重启系统，成功进入桌面。启动数据库服务，启动应用软件，一切正常，无报错。

至此，数据恢复及系统回迁工作完成，经过用户检测后数据完整，正常可用，数据恢复成功。