[摘要]SCO OPENSERVER5分区损坏、分区内部3个重要的数据库文件NODE丢失。后据分析,文件在存储区有大范围碎片,后100%恢复。
接手后表现:
1、无分区,分区内部有55aa有效结束标志
2、市面上的所有数据恢复软件无法扫描了数据
3、客户需要BACKUP\DUMP\下的几个数据库文件,约几个G
1、无分区,分区内部有55aa有效结束标志
2、市面上的所有数据恢复软件无法扫描了数据
3、客户需要BACKUP\DUMP\下的几个数据库文件,约几个G
分析过程:
1、很快分析出第一个DIVVY PARTITION的所有卷,约4G左右。处理后,发现有3个DIVVY PARTITION.分别应该是EAFS(BOOT,约20MB) HTFS(ROOT或OS主卷,3.3GB左右) SWAP(500MB)。得到其中HTFS数据后,发现只有300M多数据。发现BACKUP目录(位于数据库目录下),但目录为空,猜测可能为某文件系统的挂载点。
2、继续分析得出约有3个DIVVY PARTITION,第2个PARTITION有3(?4)个分区,全部未MKFS.
3、第3个DIVVY PARTITION中只有1个11G的分区,为HTFS。遍历后发现只有6个文件(含根目录),LABEL为BAKUP,应该就是ROOT或OS主卷的挂载分区。下有DUMP目录,目录为空。df查看发现绝大部分空间为FREE。
4、定位DUMP目录,发现被现有6号节点的残留空间有3个DAT文件名称,可以清晰看到。应该为用户的文件。
5、定位NODE位置,发现7、8、9号NODE已经只剩下时间戳。查询后知:NODE不可再现。
6、通过自主软件经二次分析,得到99%的块链地址。根据分析结果,手工分析文件系统、100%确定文件其他块表。
7、更改目录节点、回复原先数据库文件的目录信息。按有关信息与块链对应、最大可能处理文件名与数据的对应关系(后经客户证实100%正确)
8、创建NODE。根据前面分析的结构
9、通过自有软件提取数据。
10、后测试直接挂载修复后的分析,MOUNT后可完全看到数据,访问正常,FSCK无错误。
1、很快分析出第一个DIVVY PARTITION的所有卷,约4G左右。处理后,发现有3个DIVVY PARTITION.分别应该是EAFS(BOOT,约20MB) HTFS(ROOT或OS主卷,3.3GB左右) SWAP(500MB)。得到其中HTFS数据后,发现只有300M多数据。发现BACKUP目录(位于数据库目录下),但目录为空,猜测可能为某文件系统的挂载点。
2、继续分析得出约有3个DIVVY PARTITION,第2个PARTITION有3(?4)个分区,全部未MKFS.
3、第3个DIVVY PARTITION中只有1个11G的分区,为HTFS。遍历后发现只有6个文件(含根目录),LABEL为BAKUP,应该就是ROOT或OS主卷的挂载分区。下有DUMP目录,目录为空。df查看发现绝大部分空间为FREE。
4、定位DUMP目录,发现被现有6号节点的残留空间有3个DAT文件名称,可以清晰看到。应该为用户的文件。
5、定位NODE位置,发现7、8、9号NODE已经只剩下时间戳。查询后知:NODE不可再现。
6、通过自主软件经二次分析,得到99%的块链地址。根据分析结果,手工分析文件系统、100%确定文件其他块表。
7、更改目录节点、回复原先数据库文件的目录信息。按有关信息与块链对应、最大可能处理文件名与数据的对应关系(后经客户证实100%正确)
8、创建NODE。根据前面分析的结构
9、通过自有软件提取数据。
10、后测试直接挂载修复后的分析,MOUNT后可完全看到数据,访问正常,FSCK无错误。
本文转自 张宇 51CTO博客,原文链接:http://blog.51cto.com/zhangyu/33858,如需转载请自行联系原作者