服务器数据恢复环境：
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、让用户亲自对恢复出来的数据和操作系统进行检测，确定没有问题，本次数据恢复工作完成。