服务器数据恢复环境：
某公司一台服务器中组建一组 raid5 磁盘阵列；
下层操作系统为 linux redhat，部署 OA 零碎，后端数据库为 oracle。
服务器故障 & 初检：
raid5 中有 2 块磁盘先后掉线，服务器解体。oracle 曾经不对该 OA 零碎提供后续技术支持，用户方要求复原数据和操作系统。
通过初步检测，发现热备盘没有启用，硬盘无显著的物理故障和同步体现。
服务器数据恢复过程：
1、将故障服务器中所有硬盘做好标记，取出后挂载至只读环境，对所有硬盘以只读形式做齐全镜像备份，镜像过程中发现有一块磁盘（2 号盘）有大量坏扇区，其余磁盘均没有发现坏道。镜像实现后将硬盘依照编号还原至原服务器，之后的数据分析和数据恢复操作都基于镜像文件进行，防止对原始数据造成二次毁坏。
2、基于镜像文件剖析 RAID 构造，获取到原 RAID 级别，条带规定，条带大小，校验方向，META 区域等 RAID 相干信息。剖析构造：失去的最佳构造为 0,1,2,3 盘序，缺 3 号盘，块大小 512 扇区，backward parity(Adaptec)。
raid 构造：
3、检测虚构重构的 RAID 构造是否正确，通过检测发现 200M 以上的最新压缩包解压无报错，确定构造正确。间接按此构造生成虚构 RAID 到一块单硬盘上，关上文件系统无显著报错。
4、确定备份包平安的前提下，经用户方批准后，北亚企安数据恢复工程师用全新硬盘更换损坏的 2 号盘，而后对原盘重建 RAID。将复原好的单盘用 USB 形式接入故障服务器，再用 linux SystemRescueCd 启动故障服务器，之后通过 dd 命令进行全盘回写。
5、实现回写后启动操作系统，后果发现无奈进入零碎并报错，报错信息为：“/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied”。狐疑此文件权限有问题，用 SystemRescueCd 重启后查看发现此文件的工夫，权限，大小均有显著谬误，显然是节点损坏。
6、从新剖析 & 重组数据中的根分区，定位出错的 /sbin/pidof，发现问题是由 2 号盘坏道导致的。
7、通过 raid 中的另外 3 块盘对 2 号盘的损坏区域进行 xor 补齐。补齐后从新校验文件零碎，仍然有谬误，再次查看 inode 表，发现 2 号盘损坏区域有局部节点体现为下图中的 55 55 55 局部。
8、很显著，尽管节点中形容的 uid 还失常存在，但属性，大小和最后的调配块全部都是谬误的。依照所有的可能进行剖析后，的确没有任何方法能找回此损坏节点。只能尝试修复此节点或复制一个雷同的文件过去。
9、北亚企安数据恢复工程师对所有可能有谬误的文件通过日志确定原节点块的节点信息并做修改。
10、修改后从新 dd 根分区，执行 fsck -fn /dev/sda5 进行检测，呈现报错：
报错提醒在零碎中发现有多个节点共用同样的数据块。按此提醒进行底层剖析，发现因 3 号盘早掉线，存在节点信息的新旧交加。
11、按节点所属的文件进行区别，革除谬误节点后再次执行 fsck -fn /dev/sda5 进行检测，仍然有极少量的报错信息。依据报错信息的提醒，发现这些节点多位于 doc 目录下，不影响零碎的启动，于是间接执行 fsck -fy /dev/sda5 强行修复。
12、修复实现后重启零碎，胜利进入零碎桌面。启动数据库服务，启动 OA 零碎，一切正常，无报错。
13、由用户方工程师亲自验证，通过重复验证，确认复原后果无效。至此，本次数据恢复工作实现。