需要进行数据恢复的是北京一家公司的IBM X3850服务器，服务器挂载了5块73G SAS硬盘组成raid5磁盘阵列，4号盘为热备盘(Hot-Spare)，由于未知原因2号盘离线后未能成功激活热备盘rebuild，后3号盘离线，RAID崩溃。
用户服务器的操作系统为linux redhat 5.3,服务器存储有oracle数据库，因oracle已经不再对基于数据库上的oa系统提供后续支持，用户要求尽可能数据恢复+操作系统复原。
Raid阵列中硬盘无明显物理故障，raid无同步表现。
1、关闭服务器并确保数据恢复过程中保持服务器关闭状态以保护故障服务器原始状态。
2、将故障硬盘标好序号，确保在拿出槽位后可以完全复原。
3、将需要进行数据恢复的硬盘挂载至北亚数据恢复中心只读环境中，对所有故障硬盘做完全镜像(参考<如何对磁盘做完整的全盘镜像备份>)。用于数据恢复操作使用。
4、分析备份磁盘的raid结构，得到原raid阵列的RAID级别，条带规则，条带大小，校验方向，META区域等必要信息并根据这些信息搭建虚拟raid5环境。
5、解释虚拟磁盘及文件系统，然后检测虚拟结构的正确性，如果虚拟结构不正确则重复上述步骤，直到成功为止。
6、数据检测正常后进行数据回迁，原则上不再使用原盘，如确实经客户认可需要使用原盘则需要确认原盘已经完整备份后再重建raid、回迁数据。可以使用linux livecd或win pe(通常不支持)等进行，也可以在故障服务器上用另外硬盘安装一个回迁用的操作系统，再进行扇区级别的回迁。
备份时间，约2小时。
解释及导出数据时间，约4小时。
回迁操作系统，约4小时。
1、对用户服务器进行镜像后发现除2号盘有坏扇区存在，其他盘均无坏道，坏道数量悦游20个左右。
2、分析结构：得到的最佳结构为0,1,2,3盘序，缺3号盘，块大小512扇区，backward parity(Adaptec)，结构如下图：
图一：
3、组好后数据验证，200M以上的最新压缩包进行测试性解压查看有无报错，确定结构是否正确，解压正常，结构正确。直接按此结构生成虚拟RAID到一块单硬盘上，打开文件系统无明显报错。
4、在对客户原盘进行备份后重建raid阵列（将存在坏道的2号硬盘以新盘替换），连接恢复好的数据盘后通过“dd”命令进行全盘回写操作。
5、通常情况下数据回写后数据恢复工作完成，数据恢复为成功，但是在这一步出现了小故障，影响了数据恢复进程。
使用“dd”命令进行全盘回写操作后启动操作系统却出现报错：/etc/rc.d/rc.sysinit:Line 1:/sbin/pidof:Permission denied ，系统无法进入
工程师预判报错原因为文件权限问题，于是用SystemRescueCd重启后检查文件时间、权限、大小均有明显错误。
对数据中的根分区进行了重新分析，将出错的/sbin/pidof定位出来发现问题的原因再于2号盘的坏道。。
通过没有坏道的0号盘，1号盘，3号盘进行对2号盘的损坏区域xor补齐后校验文件系统依然有错误，再一次对iNode表进行检查发现2号盘损坏区域有部分节点表现为(图中的55 55 55部分)：
图二：
问题显而易见，节点中描述的uid还正常存在，但属性，大小，以最初的分配块均不正确。此种情况下是没有办法找回损坏的节点了，只能希望修复此节点，或复制一个相同的文件过来。对所有可能有错的文件，均通过日志确定原节点块的节点信息，再做修正。
修正后重新dd根分区，执行fsck -fn /dev/sda5，进行检测，依然有报错，如下图：
图三：
根据提示，在系统中发现有多个节点共用同样的数据块。按此提示进行底层分析，发现，因3号盘早掉线，帮存在节点信息的新旧交集。
按节点所属的文件进行区别，清除错误节点后，再次执行fsck -fn /dev/sda5,依然有报错信息，但已经很少。根据提示，发现这些节点多位于doc目录下，不影响系统启动，于是直接fsck -fy /dev/sda5强行修复。
修复后，重启系统，成功进入桌面。
启动数据库服务，启动应用软件，一切正常，无报错。
到此，数据恢复及系统回迁工作完成。
原文地址：http://blog.51cto.com/sun510/2116552
