一、故障设备信息：

服务器： X3850 服务器

硬盘类型：SAS ，容量： 146G    4 块硬盘组成 RAID5

文件系统：R eiserfs

二、 R eiserfs 文件系统 故障分析：

1 、 经过分析发现了之前的硬盘数据组织结构是由一个不到100M 的 boot 分区，后接一个 271G 的 LVM 卷，之后是 2G 的 swap 分区。 LVM 卷中直接划分了一个 reiserfs 文件系统，作为根分区。

2 、 用户在使用的过程中，系统遭遇了未知的原因而瘫痪，经过系统的冲撞以后发现整个RAID 逻辑卷变成了前面 2G 的 boot 与 swap 分区，后接 271G 的 LVM 卷， LVM 卷中文件系统位置有个空的 reiserfs 超级块。

3 、 我们这次要恢复的数据就是原来271G 中文件系统里的所有用户数据，这些数据包含了数据库、网站程序与网页、单位 OA 系统里的所有办公文档。

三、 R eiserfs 文件系统 解决方案：

1 、 先通过对全盘reiserfs 树节点之间的关联确定了原来的 reiserfs 分区位置，发现原来存储数据的文件系统的前 2G 数据已经被覆盖， 判断 应该是用户在安装系统时错误地初始化了分区结构，所以装好系统无法导入LVM 卷而做过 reiserfsck 试图修复。

2 、 因reiserfs 文件系统对文件系统里所有的文件 ( 含目录 ) 线性化后，再以文件 key 生成 B+ 树，树不断增加节点会导致树的结构整体拉展后向整个磁盘的数据区做平滑迁移。这样一来顶级节点通常不会放在文件系统的最前面。因根目录的文件 KEY 号通常是最小的，所以，从空间上看，前 2G 中存储最多的应该是从根起始路径最近的 key 节点 。

3 、 这样，用户数据因目录层次较深，节点存在的可能性很高。前2G 覆盖的数据已经无法恢复，只能希望不要恰好覆盖用户数据。因文件系统前面对整个树的索引全丢失，加上 reiserfs 的树概念设计得很抽象，重搭建树会很困难。

4、 我们通过自主程序在整个原文件系统区域进行key 节点扫描并将所有节点导出。然后通过自主程序对所有叶节点重新排序、过滤 ( 去掉之前删除文件丢弃的节点 ) ，重新生成二级、三级、四级等叶节点。选择分区前面 2G 空间做为新树的结构区，并生成对应地址信息。

5、 应对目录命名问题，如遇到原树路径某节点丢失的情况，对其用自定义的key 节点编号命名，如无法确定其父目录，暂加入 /otherfiles 下。根据上面对，生成树索引信息，写入特定位置，再根据这些信息，生成超级块，设置 clear 标志。在 suse 虚拟机下，创建快照，挂载修复好的卷，已经可以看到文件了。 ( 注：虚拟机与快照的目的为了操作可加溯，同时因 bitmap 等元数据不影响数据，未做修正，故挂载前不可做 reiserfsck) 。

6、 在修复用的suse 虚拟机下，挂载用于 copy 数据的目标硬盘， mkfs 后将所有数据 cp 到目标盘。用户通过 find 命令整理所需数据，修正部分目录文件位置与名称。部分丢失的散文件，按大小与文件头标志查找，找到后移动及重命名。

四、 R eiserfs 文件系统 数据恢复结果：

    经工程师处理分析后，数据已成功恢复，且均可正常使用，至此数据恢复工作结束。