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