服务器故障：
某公司的一台某品牌x3850服务器raid5中两块磁盘先后掉线，服务器解体。故障服务器的操作系统为linux redhat，利用为公司oa，数据库采纳oracle。因oracle曾经不再对此oa提供后续反对，管理员分割咱们数据恢复核心要求尽可能复原数据和零碎。
数据恢复工程师对故障服务器进行检测，发现热备盘没有启用，硬盘无显著物理故障，无显著同步体现。
服务器数据恢复计划：
1、爱护原环境，敞开服务器，确保在复原过程中不再开启服务器。
2、将故障硬盘标好序号，确保在拿出槽位后能够齐全还原。
3、将故障硬盘挂载至只读环境，对所有故障硬盘做齐全镜像(参考<如何对磁盘做残缺的全盘镜像备份>)。备份实现后交回原故障盘，之后的复原操作直到数据确认无误前不再波及原故障盘。
4、对备份盘进行RAID构造剖析，失去其原来的RAID级别，条带规定，条带大小，校验方向，META区域等。
5、依据失去的RAID信息搭建一组虚构的RAID5环境。
6、进行虚构磁盘及文件系统解释。
7、检测虚构构造是否正确，如不正确，反复4-7过程。
8、确定数据无误后，按用户要求回迁数据。如果依然应用原盘，需确定曾经齐全对原盘做过备份后，重建RAID，再做回迁。回迁操作系统时，能够应用linux livecd或win pe(通常不反对)等进行，也能够在故障服务器上用另外硬盘装置一个回迁用的操作系统，再进行扇区级别的回迁。
9、数据移交后，由北亚数据恢复核心缩短保存数据3天，以防止可能疏忽的纰漏。
服务器数据恢复过程：
1、对故障服务器中的所有硬盘进行残缺镜像，镜像后数据恢复工程师发现2号盘有10-20个坏扇区，其余磁盘没有发现坏道。
2、剖析构造：获取到的最佳构造为0,1,2,3盘序，缺3号盘，块大小为512扇区，backward parity(Adaptec)，构造如下图：
3、组好后进行数据验证，200M以上的最新压缩包解压无报错，确定构造正确。
4、间接按此构造生成虚构RAID到一块单硬盘上，关上文件系统无显著报错。
5、确定备份包平安的状况下，经管理员批准后，北亚数据恢复工程师对原盘重建RAID，重建时曾经用全新硬盘更换损坏的2号盘。将复原好的单盘用USB形式接入故障服务器，再用linux SystemRescueCd启动故障服务器，之后通过命令进行全盘回写。
6、回写后，启动操作系统。失常状况下，这时候所有工作应该实现了，不巧的是，问题还没有解决。
上面是后续的数据恢复过程：
1、接前文：回写完所有数据后，启动操作系统报错，报错信息为：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。
2、依据错误信息得悉此文件权限有问题，用SystemRescueCd重启后查看，发现此文件工夫，权限，大小均有显著谬误，显然节点损坏。
3、从新剖析重组数据中的根分区，定位出错的/sbin/pidof，发现问题产生起因是2号盘的坏道。
4、应用0，1，3这3块盘，针对2号盘的损坏区域进行xor补齐。补齐后从新校验文件零碎，仍然有谬误，再次查看inode表，发现2号盘损坏区域有局部节点体现为下图中的55 55 55局部：
5、尽管节点中形容的uid还失常存在，但属性，大小，最后的调配块全副是谬误的。依照所有可能进行剖析，数据恢复工程师确定无奈找回此损坏节点，只能心愿修复此节点，或复制一个雷同的文件过去。
6、对所有可能有错的文件通过日志确定原节点块的节点信息，再做修改。
7、修改后从新dd根分区，执行fsck -fn /dev/sda5，进行检测，仍然有报错，如下图：
8、依据提醒，在零碎中发现有多个节点共用同样的数据块。按此提醒进行底层剖析，发现因3号盘早掉线，存在节点信息的新旧交加。
9、按节点所属的文件进行区别，革除谬误节点后，再次执行fsck -fn /dev/sda5，仍然有极少量的报错信息。依据提醒，发现这些节点多位于doc目录下，不影响系统启动，于是间接fsck -fy /dev/sda5强行修复。
10、修复后，重启零碎胜利进入桌面。
11、启动数据库服务，启动应用软件，一切正常，无报错。数据恢复及零碎回迁工作实现。