北京数据恢复 北京 深圳数据恢复 深圳 上海数据恢复 上海 成都数据恢复 成都 重庆数据恢复 重庆 浙江数据恢复 浙江 沈阳数据恢复 沈阳 福建数据恢复 福建 昆明数据恢复 昆明 天津数据恢复 天津
北亚数据恢复中心
网站首页
Index
公司概况
Company
公司动态
Dynamic
服务项目
Service
成功案例
Case
服务报价
Price
技术专区
Technical
联系我们
Contacts
服务网点
Alliance
技术论坛
BBS
 
数据恢复案例导航
  服务器数据恢复案例
  RAID数据恢复案例
  数据库恢复案例
  EFS文件解密案例
  硬件故障数据恢复案例
  逻辑故障数据恢复案例
  您现在的位置是:首页>>成功案例>>数据库恢复案例>>正文
 
恢复UNIX误删除数据库文件(NODE已被清除)

作者:  来源: 日期:2007-2-9 15:22:11 点击:

[摘要]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无错误。

 
上一篇: 成功恢复一例软件恢复后打不开的SQL数据库
下一篇: SAN,LINUX EXT3 LUN,存储ORACLE数据库,FSCK后出错的数据恢复
返回首页 | 联系我们 | 关于我们 | 友情连接 | 网站地图 | RSS聚合