共计 1426 个字符，预计需要花费 4 分钟才能阅读完成。
服务器数据恢复环境：
某品牌服务器中有 4 块 SAS 硬盘组建了一组 RAID5 阵列，另外 1 块磁盘作为热备盘应用。下层操作系统为 redhat linux，部署了一个数据库是 oracle 的 OA。
服务器故障 & 初检：
RAID5 中一块磁盘离线后热备盘未主动激活 rebuild，之后另外一块磁盘离线，RAID5 阵列解体。因为 oracle 曾经不再对服务器中部署的 oa 提供后续反对，用户分割咱们数据恢复核心要求复原数据和还原操作系统。
将故障服务器中所有磁盘编号后取出，由硬件工程师对所有磁盘进行检测。通过检测发现热备盘基本没有启用，不存在物理故障，无显著同步体现。
服务器数据恢复 & 操作系统还原过程：
1、将故障服务器中所有磁盘以只读形式做残缺镜像，镜像过程中发现后离线的磁盘有十几个坏扇区，其余磁盘均没有发现有坏道。镜像实现后将所有磁盘依照编号还原到原服务器中，后续的数据分析和数据恢复都基于镜像文件进行，防止对原始磁盘数据造成二次毁坏。
2、基于镜像文件剖析 RAID5 构造信息，获取到盘序，块大小，backward parity(Adaptec) 等 RAID 相干信息。
3、依据上一步获取到的 RAID 相干信息虚构重组 RAID 并验证数据，发现 200M 以上的压缩包解压无报错，确定构造正确。
4、依照此 RAID 构造生成虚构 RAID 到一块单硬盘上，关上文件系统没有发现显著报错。
5、失去用户受权后在原盘重建 RAID（重建时曾经用全新硬盘更换发现坏道的后离线磁盘）。
6、将复原好的单盘用 USB 形式接入故障服务器，用 linux SystemRescueCd 启动故障服务器，而后应用 dd 命令全盘回写。
7、回写实现后启动操作系统，然而无奈进入零碎，报错信息为：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。
8、狐疑此文件权限有问题，用 SystemRescueCd 重启后查看，此文件工夫，权限，大小均有显著谬误，显然是节点损坏导致的谬误。
9、从新剖析重组数据中的根分区，定位出错的 /sbin/pidof，发现错误是由后离线的那块磁盘上的坏道所引起。
10、应用完整的 3 块盘对后离线的那块盘的损坏区域进行 xor 补齐。补齐后从新校验文件零碎依然呈现谬误。再次查看 inode 表，发现后离线磁盘损坏区域有局部节点体现异样。
尽管节点中形容的 uid 失常存在，但属性，大小和最后的调配块都是谬误的。依照所有可能进行剖析，然而没有找到办法找回此损坏节点。只能试图修复此节点或复制一个雷同的文件过去。
11、针对所有可能存在谬误的文件，北亚企安数据恢复工程师通过日志确定原节点块的节点信息，而后做修改。
12、修改后从新 dd 根分区，执行 fsck -fn /dev/sda5 仍然报错。
依据报错信息，北亚企安数据恢复工程师在零碎中发现有多个节点共用同样的数据块。按此提醒剖析底层，发现存在节点信息的新旧交加。
13、依照节点所属的文件进行辨别，革除谬误节点后再次执行 fsck -fn /dev/sda5，仍然有大量报错。依据报错信息，发现这些节点多位于 doc 目录下，不影响系统启动，于是间接执行 fsck -fy /dev/sda5 强行修复。
14、修复实现后重启零碎，胜利进入零碎桌面。
15、启动 oracle 数据库服务，启动 OA，一切正常无报错。
16、由用户方对复原的操作系统和数据（OA 和 oracle 数据库）进行检测，通过用户方多方检测，确认复原数据残缺无效。本次数据恢复工作实现。
