服务器数据恢复环境:
文件系统是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的树概念设计很抽象,重搭建树很困难。

北亚服务器数据恢复——reiserfs文件系统数据恢复

2、北亚数据恢复中心工程师通过自主开发的程序对原文件系统区域进行key节点扫描并将所有节点导出。然后通过自主开发的程序对所有叶节点重新排序、过滤(去掉之前删除文件丢弃的节点),重新生成二级、三级、四级等叶节点。选择分区前面2G空间(这部分数据没有用处了)作为新树的结构区,并生成对应地址信息。

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

4、在修复用的suse虚拟机下,挂载用于复制数据的目标硬盘,mkfs后将所有数据cp到目标盘。服务器管理员整理所需数据,修正部分目录文件位置与名称。对于部分丢失的散文件,按大小与文件头标志查找,找到后移动和重命名。

数据恢复结果:
由于树的不直观性加上程序的调试导致本案例的数据恢复工作充满复杂性和不确定性。所幸的是,经过北亚数据恢复工程师团队的不懈努力,所有的重要数据都被找到。

北亚服务器数据恢复——reiserfs文件系统数据恢复

更多相关文章

  1. Android出现“Read-only file system”解决办法
  2. linux ,Android基础知识总结
  3. android文件系统制作教程
  4. android linux 最全的基础知识总结
  5. android 实用sax 读取xml文件内容
  6. Android(安卓)中文API (37) —— AbsoluteLayout
  7. android gradle多渠道打包配置
  8. Android布局优化
  9. Android内核的根文件系统

随机推荐

  1. ListView小知识整理:滑动背景、Item间隙等
  2. Android学习笔记6——基本布局
  3. ContentProvider详解
  4. android 录像/打开video文件
  5. Android曲线绘制demo
  6. Android 设备指纹
  7. Jenkins构建时’Users/Mac/Library/Andro
  8. Android: android source code online
  9. Android之MVP 模式:简单易懂的介绍方式
  10. android上的i-jetty