博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
成功恢复UNIX误删除数据库文件(NODE已被清除)
阅读量:6712 次
发布时间:2019-06-25

本文共 896 字,大约阅读时间需要 2 分钟。

[摘要]SCO OPENSERVER5分区损坏、分区内部3个重要的数据库文件NODE丢失。后据分析,文件在存储区有大范围碎片,后100%恢复。
接手后表现:
    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无错误。
本文转自 张宇 51CTO博客,原文链接:http://blog.51cto.com/zhangyu/33858,如需转载请自行联系原作者
你可能感兴趣的文章
golang后端库gin笔记
查看>>
数据如何埋点?Mob统计分析电商类APP埋点需求
查看>>
一些SAP Partners能够通过二次开发实现打通C/4HANA和S4HANA
查看>>
python leveldb
查看>>
需要https域名,不会配置?给我5分钟,手把手教你
查看>>
Runtime中的 isa 结构体
查看>>
Java面试问题,如何避免Java线程中的死锁?
查看>>
在网上不但不给下分还把我的老本给骗了咋办?
查看>>
如何设计npm包的开发和发布流程
查看>>
[工具] Mac 安装 protobuf
查看>>
剑指 offer (1) -- 数组篇
查看>>
从源码看Spring中IOC容器的实现(二):IOC容器的初始化
查看>>
20181023
查看>>
LeetCode 42 javascript解决方案
查看>>
开发一对一直播系统您需要注意的内容
查看>>
开源|ns4_frame分布式服务框架开发指南
查看>>
用Vue封装Swiper实现图片轮播很简单
查看>>
Android Sensor源码分析总结
查看>>
(基础系列)object clone 的用法、原理和用途
查看>>
图片 文件 转base64
查看>>