共计 1247 个字符，预计需要花费 4 分钟才能阅读完成。
服务器数据恢复环境：
文件系统是 reiserfs 的服务器；
4 块 146G SAS 硬盘组成的 RAID5；
分区构造：一个几十 M 的 boot 分区，一个 271G 的 LVM 卷，一个 2G 的 swap 分区，LVM 卷中间接划分了一个 reiserfs 文件系统作为根分区。
故障：
服务器在运行过程中因为未知起因零碎瘫痪，服务器管理员重装系统后发现整个 RAID 逻辑卷变成了：2G 的 boot 与 swap 分区，271G 的 LVM 卷，LVM 卷中文件系统地位有个空的 reiserfs 超级块。服务器管理员分割北亚数据恢复核心进行数据恢复。
本案例要复原的数据包含 271G 的 LVM 卷中文件系统里的所有用户数据，这些数据蕴含了数据库、网站程序与网页、单位 OA 零碎里的所有办公文档。
服务器数据恢复过程：
1、通过对全盘 reiserfs 树节点之间的关联确定原来的 reiserfs 分区地位，北亚服务器数据恢复工程师发现原来存储数据的文件系统的前 2G 数据曾经被笼罩，应该是服务器管理员在装置零碎时谬误地初始化了分区构造，装好零碎后无奈导入 LVM 卷，而后应用 reiserfsck 试图修复文件系统。
注：因 reiserfs 文件系统对文件系统里所有的文件 (含目录) 线性化后，以文件 key 生成 B + 树，树一直减少节点，树的构造整体拉展后会向整个磁盘的数据区做平滑迁徙，所以顶级节点通常不会放在文件系统的最后面。通常状况下，根目录的文件 KEY 号是最小的，所以，文件系统的前 2G 数据中最多的应该是从根起始门路最近的 key 节点，而用户数据目录档次较深，节点存在的可能性很高。前 2G 的数据曾经被笼罩无奈复原，所以文件系统对整个树的索引全失落，再加上 reiserfs 的树概念设计很形象，重搭建树很艰难。
2、北亚数据恢复核心工程师通过自主开发的程序对原文件系统区域进行 key 节点扫描并将所有节点导出。而后通过自主开发的程序对所有叶节点从新排序、过滤 (去掉之前删除文件抛弃的节点)，从新生成二级、三级、四级等叶节点。抉择分区后面 2G 空间(这部分数据没有用途了) 作为新树的构造区，并生成对应地址信息。
3、目录命名问题的解决方案：如遇到原树门路某节点失落的状况，对其用自定义的 key 节点编号命名；如无奈确定其父目录，暂退出到 /otherfiles 下。生成树索引信息，写入特定地位，再依据这些信息，生成超级块，设置 clear 标记。在 suse 虚拟机下创立快照，挂载修复好的卷，曾经能够看到文件了。
注：虚拟机与快照的目标为了操作可回溯，同时因 bitmap 等元数据不影响数据，未做修改，故挂载前不可做 reiserfsck。
4、在修复用的 suse 虚拟机下，挂载用于复制数据的指标硬盘，mkfs 后将所有数据 cp 到指标盘。服务器管理员整顿所需数据，修改局部目录文件地位与名称。对于局部失落的散文件，按大小与文件头标记查找，找到后挪动和重命名。
数据恢复后果：
因为树的不直观性加上程序的调试导致本案例的数据恢复工作充斥复杂性和不确定性。所幸的是，通过北亚数据恢复工程师团队的不懈努力，所有的重要数据都被找到。
