当前位置:七道奇文章资讯数据防范MySQL防范
日期:2011-01-25 22:43:00  来源:本站整理

ext3下删除mysql数据库的数据恢复案例[MySQL防范]

赞助商链接



  本文“ext3下删除mysql数据库的数据恢复案例[MySQL防范]”是由七道奇为您精心收集,来源于网络转载,文章版权归文章作者所有,本站不对其观点以及内容做任何评价,请读者自行判断,以下是其具体内容:

    [数据恢复弊端描写]

  一台重要的MYSQL数据库服务器,146GB*2,RAID1,约130GB DATA卷,存储了大约200~300个数据库.平常管理员对每个数据库dump出今后,直接紧缩成.gz包,再将全部重要的.gz 包合起来紧缩成一个总的.tar.gz包,这些文件每日产生一次,覆盖本来的备份.数据文件及备份文件全部存储于data卷上.

  一次系统保护中,管理员不当心将data卷下的全部文件全部rm,删除后,即刻终止系统,再未做别的操作,但删除时仍有大量终端在拜候此服务器.

  要求恢复mysql数据库文件,即myd、frm、myi(可重建)文件,或每个数据库的.gz包,或全部重要数据库总的.tar.gz备份包.

  [数据恢复解析]

  ext3下的数据删除,理论上,会排除inode中除节点范例、日期外的其他属性,诸如文件大小、数据存储地址等属性会全部清0,同时目录表中会以目录条目长度的方法屏蔽掉已删除文件,但会保存节点编号,最后会改变BITMAP中的空间占用标志.

  即便是目录表中存在删除文件的节点编号,但因节点内容已经没有需求的东西,与数据区也是脱钩的.

  从数据角度,大大都文件范例城市有特定的文件头标志,按头标志是有大概找到删除文件的起始位置的,但EXT3以块组为单位举行存储,同时数据与索引是混合存储于数据区的,所以数据持续存储的大概性非常之小,这样,按文件格局举行处理也是很艰难的.

  唯一的算法是结合上述几个特点,加上对日记的解析,加上对存储历程的模拟解析,尽大概地逼近真实存储构造.

  [数据恢复历程]

  1、对弊端卷做完好备份.

  2、对总.tar.gz举行恢复解析,但恢复出来的文件解压到50%左右会报错,后续文件列表也无法列出.经解析,最大的缘由是删除时仍有数据写入破坏文件招致.

  3、对分包的.gz文件举行恢复解析,大大都恢复成功.

  4、关于未恢复成功的.gz数据库.直接恢复其myd\frm数据文件,全部数据恢复成功.

  [其他]

  1、LINUX EXT3数据删除后应尽快断掉文件系统IO,普通umount文件系统便可.

  2、对弊端卷做dd备份,确保数据恢复历程不会招致更严重的弊端.

    以上是“ext3下删除mysql数据库的数据恢复案例[MySQL防范]”的内容,如果你对以上该文章内容感兴趣,你可以看看七道奇为您推荐以下文章:

  • ext3下删除mysql数据库的数据恢复案例
  • 本文地址: 与您的QQ/BBS好友分享!
    • 好的评价 如果您觉得此文章好,就请您
        0%(0)
    • 差的评价 如果您觉得此文章差,就请您
        0%(0)

    文章评论评论内容只代表网友观点,与本站立场无关!

       评论摘要(共 0 条,得分 0 分,平均 0 分) 查看完整评论
    Copyright © 2020-2022 www.xiamiku.com. All Rights Reserved .