[数据恢复故障描述]
一台IBM X3850服务器，由4块146G SAS硬盘组成 RAID5作为存储介质，操作系统为SUSE LINUX，文件系统全部是reiserfs。
分析后得知：之前的硬盘数据组织结构为: 一个不到100M的boot分区， 后接一个271G的LVM卷，之后是2G的swap分区。LVM卷中直接划分了一个reiserfs 文件系统，作为根分区。
用户在使用过程中，系统未知原因瘫痪。
重装系统后，整个RAID逻辑卷变成了前面2G的boot与swap分区，后接 271G的LVM卷，LVM卷中文件系统位置有个空的reiserfs超级块。
要求恢 复原来271G中文件系统里的所有用户数据，数据分别是MYSQL数据库、PGSQL数据 库、网站程序与网页、单位OA系统里的所有办公文档。
[数据恢复分析]
1、通过对全盘reiserfs树节点之间的关联，确定了原来的reiserfs分区 位置，以此断定，原来存储数据的文件系统前2G被覆盖。
2、应该是用户 在安装系统时错误地初始化了分区结构，之后装好系统后，发现无法导入LVM卷 ，曾做过reiserfsck试图修复。
3、因reiserfs文件系统对文件系统里所 有的文件(含目录)线性化后，再以文件key生成B+树，树不断增加节点，会导致 树的结构整体拉展后向整个磁盘的数据区做平滑迁移，这样，顶级节点通常不会 放在文件系统的最前面。因根目录的文件KEY号通常是最小的，所以，从空间上 看，前2G中存储最多的应该是从根起始路径最近的key节点，这样，用户数据因 目录层次较深，节点存在的可能性很高。
4、前2G覆盖的数据无法恢复， 只能希望不要恰好覆盖用户数据。
5、因文件系统前面对整个树的索引全 丢失，加上reiserfs的树概念设计得很抽象，重搭建树会很困难。
[数据 恢复过程]
1、通过自主程序在整个原文件系统区域进行key节点扫描，将 所有节点导出。
2、通过自主程序对所有叶节点重新排序、过滤(去掉之 前删除文件丢弃的节点)，重新生成二级、三级、四级等叶节点。选择分区前面 2G空间做为新树的结构区(反正这部分数据是没用的了，重装系统已经装得满满 的)，并生成对应地址信息。应对目录命名问题，如遇到原树路径某节点丢失的 情况，对其用自定义的key节点编号命名，如无法确定其父目录，暂加 入/otherfiles下。
3、根据上面对，生成树索引信息，写入特定位置， 再根据这些信息，生成超级块，设置clear标志。
4、在suse虚拟机下， 创建快照，挂载修复好的卷，已经可以看到文件了。(注：虚拟机与快照的目的 为了操作可加溯，同时因bitmap等元数据不影响数据，未做修正，故挂载前不可 做reiserfsck)。
5、在修复用的suse虚拟机下，挂载用于copy数据的目 标硬盘，mkfs后将所有数据cp到目标盘。
6、用户通过find命令整理所需 数据，修正部分目录文件位置与名称。
7、部分丢失的散文件，按大小与 文件头标志查找，找到后移动及重命名。
[数据恢复结果]
1、所 幸重要数据100%恢复成功。
2、树的不直观性加上程序的调试，使得整个 恢复工作历时3天之久，在繁乱的信息树中跟来跟去，真是烦人得很，幸好撑下 来了。
[随笔]
繁锁的数据恢复分析工作真不是人干的。
。。。
应该让机器干 ^_^