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