服务器数据恢复环境：
某公司一台服务器中组建一组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、由用户方工程师亲自验证，通过重复验证，确认复原后果无效。至此，本次数据恢复工作实现。