服务器数据恢复环境：

新网企业邮件服务器；

组建RAID5，文件系统为REISERFS；

一个数据分区，存放上百万企业用户的邮件。

服务器故障&分析：

服务器在正常运行过程中，RAID突然OFFLINE。管理员检查发现故障服务器有两块盘报警，将其中一块盘强制上线后却发现卷无法挂载，于是执行FSCK并REBULD TREE，完成上述操作后卷仍然无法挂载。咨询多家数据恢复服务商均无法提供可行的解决方案，最终新网选择我们数据恢复中心进行数据恢复。

这种RAID故障在我们数据恢复中心接到的cases中是很常见的。因为报警的两块盘并不是同时掉线，如果强制上线先离线的硬盘会导致数据区的新旧数据混在一起，文件系统结构不一致。强制上线会在读写过程中生成新的检验条带，会影响一部分数据。如果读写不多或根本无法MOUNT，情况的严重性会小很多。

本案例中最严重的问题在于REBUILD TREE，此操作相当于将一个混杂的文件系统连续化，结果会导致文件系统的所有结构体全面出错，这种情况通常是无法挽救的。加上用户的文件目录结构非常复杂，文件总数粗略估计上亿，恢复数据的机会很小。

服务器数据恢复过程：    

1、首先对故障服务器所有硬盘做镜像备份，后续的数据恢复操作都在备份文件上进行，避免对数据二次破坏。

2、服务器数据恢复工程师先试图将文件系统结构区单独提出来进行分析，但REISERFS文件系统区相对分散且无规律，通过北亚自主研发的程序对文件系统结构区进行提取和分析。在本案例中，仅1级节点提取出来的数据就有好几个G，可见本案例文件结构的复杂。

3、对文件系统区进行一致性检验，修正错误地方。本案例中好多文件系统节点区都因检验关系，使关键属性字节发生了改变。通过北亚自主研发的程序将所有节点状态统一初始化，对节点进行一致性处理。

4、完成上述两步操作后有2种方案恢复最终的数据：

第一种方案：在LINUX系统下再次执行FSCK，结果实施这种方案后发现效果不好，原因是LINUX FSCK的功能有限，如果在父节点稍有错误，其子节点便会被全部打入到LOST+FOUND里，无法还原原本的目录结构。

第二种方案：通过只读方式，在WINDOWS环境下用北亚自主研发的程序提取数据。在具体的实施过程中，需要不断修改程序并忽略一些错误，最终提取出数据。

5、由用户对恢复出来的数据进行检测，确认需要的数据基本都恢复出来，可以正常读取。

服务器数据恢复总结：

RAID5磁盘阵列两块硬盘先后离线，但是又不知道离线先后顺序的case很多。碰到这种情况需要我们谨慎处理。如果可以查询到日志，通过日志确定为好。如果强制上线出错，应马上停止操作，切不可做FSCK等操作。

LINUX的FSCK操作风险很大，做之前一定要看清楚提示，如果出错信息异常，应选择其他方案。