[申明]
转载请保留原作网站：http://www.sjhf.net 关键字[LINUX数据恢复] [摘要]
新网，企业邮件服务器，存储于146G×6 RAID5中，有上百万企业用户的邮件，数据区，只分一个区，文件系统为REISERFS，正常工作中，RAID突然OFFLINE，管理员到机房检查时，发现有两块盘报警，将其中一块强制上线后发现卷无法MOUNT，于是强行FSCK 并REBULD TREE，历时4天，完成后仍无法MOUNT。无奈之下，向数据恢复公司求救，大多数公司无法提供可行的解决方案。新网在多方比较及评估后，选择让我们完成。
[分析]
这种RAID的问题事实上是很常见的，通常是因为亮灯的两块盘并不是同时掉线，而恰巧的是，强制上线了早离线的硬盘，导致数据区新鲜的和陈旧的混在一起，文件系统结构不一致。本身强制上线后，会在读写过程中生成新的检验条带，所以会影响一部分数据，但如果读写不多或根本无法MOUNT的话，这种灾难的严重性将会小得多，此例中最为严重的问题在于REBUILD TREE，相当于试图将一个混杂的文件系统连续化。这样的结果将会导致文件系统的所有结构体全面出错，通常这是无法挽救的。加上用户的文件目录结构非常复杂，文件总数粗略估计上亿，更是机会渺茫。 [解决方案]
1、应试图将文件系统结构区单独提出来进行分析，这样工作量会小很多，也给反复查找分析提供了可能。但REISERFS的文件系统区相对较散且无规律，需通过自主程序进行提取及分析，此例中，光1级节点提出的大小达6G之大，文件结构可谓复杂。（用户也是因EXT3面对这样的结构崩溃才选用REISERFS的，可见其结构复杂程度）
2、对文件系统区进行一致性检验，相当于手工FSCK，修正错误地方，此例中，好多文件系统节点区都因检验关系，使关键属性字节发生了改变。通过程序将所有节点状态统一初始化，完成节点一致性处理
3、完成上述两步后有两种做法，一是在LINUX系统下再次FSCK，此例效果不好，(因LINUX FSCK的功能有限，在父节点稍有错误，其子节点便会全部打入LOST+FOUND里，无法还原原本的目录结构)，二是通过只读方式，用自主程序在WINDOWS下提取数据，需忽略许多错误，修改程序后，使用此法，所有数据已可提取。 [后记]
最近这种两块硬盘离线，不知道哪块先离、哪块后离的例子很多。希望RAID用户可以在两块硬盘离线后谨慎对待，如果可以查到日志，通过日志确定为好。如果强制上线出错，应马上停止操作，切不可做FSCK等操作。
另外，老生常谈的事，LINUX的FSCK风险很大(实际WINDOWS也会有)，做之前请尽量看清提示，如果出错信息异常，应选择其他途径。
|
