共计 1673 个字符，预计需要花费 5 分钟才能阅读完成。
服务器数据恢复环境：
IBM X 系列服务器；
操作系统为 linux redhat；
5 块 73G SAS 硬盘，4 块组成 RAID5，1 块作为热备盘(Hot-Spare)。
故障：
3 号盘最早离线，热备盘未主动激活 rebuild（起因不明），而后 2 号盘离线，RAID 解体。用户分割北亚数据恢复核心进行数据恢复。
利用是基于 oracle 数据库的一个 OA 零碎。因 oracle 曾经不再对本 OA 零碎提供后续反对，用户要求尽可能复原数据和操作系统。热备盘齐全无启用，硬盘无显著物理故障，无显著同步体现。
服务器数据恢复计划：
1、敞开服务器，将故障硬盘标好序号。
2、将故障硬盘挂载到北亚数据恢复备份服务器，对所有故障硬盘做齐全镜像。备份实现后交还原故障盘。
3、通过对备份盘进行 RAID 构造剖析，北亚数据恢复工程师获取到其原来的 RAID 级别，条带规定，条带大小，校验方向，META 区域等。
4、依据失去的 RAID 信息，由北亚数据恢复工程师搭建一组虚构的 RAID5 环境。
5、进行虚构磁盘及文件系统解释。
6、检测虚构构造是否正确，如不正确，反复 3 - 6 的过程。
7、确定数据无误后回迁数据。如果依然应用原盘，需确定已齐全对原盘做过备份，重建 RAID，再做回迁。回迁操作系统时，能够应用 linux livecd 或 win pe(通常不反对)等进行，也能够在故障服务器上用另外硬盘装置一个回迁用的操作系统，再进行扇区级别的回迁。
服务器数据恢复过程：
1、对原硬盘进行残缺镜像，北亚数据恢复工程师发现 2 号盘有 10-20 个坏扇区，其余磁盘，均无坏道。
2、剖析构造，失去的最佳构造为 0,1,2,3 盘序，缺 3 号盘，块大小 512 扇区，backward parity(Adaptec)，构造如下图：
3、组好后进行数据验证，200M 以上的最新压缩包解压无报错，确定构造正确。
4、间接按此构造生成虚构 RAID 到一块单硬盘上，关上文件系统无显著报错。
5、确定备份包平安的状况下，经用户批准后，对原盘重建 RAID，重建时曾经用全新硬盘更换损坏的 2 号盘。将复原好的单盘用 USB 形式接入故障服务器，再用 linux SystemRescueCd 启动故障服务器，之后通过 dd 命令进行全盘回写。
6、dd 所有数据后，启动操作系统，无奈进入，报错信息为：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied。狐疑此文件权限有问题，北亚数据恢复工程师用 SystemRescueCd 重启后查看，此文件工夫，权限，大小均有显著谬误，显然节点损坏。
7、北亚数据恢复工程师从新剖析，重组数据中的根分区，定位出错的 /sbin/pidof/datahf.net，发现问题因 2 号盘坏道引起。
8、应用 0，1，3 这 3 块盘针对 2 号盘的损坏区域进行 xor 补齐。补齐后从新校验文件零碎，发现仍然有谬误，再次查看 inode 表，发现 2 号盘损坏区域有局部节点体现为 (图中的 55 55 55 局部)：
很显著，尽管节点中形容的 uid 还失常存在，但属性、大小和最后的调配块全副是谬误的。依照所有可能进行剖析，北亚数据恢复工程师判断无奈找回此损坏节点，只能修复此节点，或复制一个雷同的文件过去。
9、对所有可能有错的文件，均通过日志确定原节点块的节点信息，再做修改。修改后从新 dd 根分区，执行 fsck -fn /dev/sda5/datahf.net，进行检测，仍然有报错，如下图：
10、依据提醒，在零碎中发现有多个节点共用同样的数据块。按此提醒进行底层剖析，北亚数据恢复工程师发现因 3 号盘早掉线因此存在节点信息的新旧交加。
11、按节点所属的文件进行区别，革除谬误节点后，再次执行 fsck -fn /dev/sda5 仍然有报错信息，但曾经很少。依据提醒，发现这些节点多位于 doc 目录下，不影响系统启动，于是执行 fsck -fy /dev/sda5/datahf.net 强行修复。
12、修复实现后重启零碎，胜利进入桌面。启动数据库服务，启动应用软件，一切正常，无报错。
至此，数据恢复及零碎回迁工作实现，通过用户检测后数据残缺，失常可用，数据恢复胜利。
