快速业务通道

linux ext3下删除mysql数据库的数据恢复案例

作者 佚名技术 来源 Linux系统 浏览 发布时间 2012-05-03
作者:张宇,北亚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数据库.直接恢复其mydfrm数据文件,所有数据恢复成功. [其他]   1、LINUX EXT3数据删除后应尽快断掉文件系统IO,通常umount文件系统即可.   2、对故障卷做dd备份,确保数据恢复过程不会导致更严重的故障.

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢!

分享到: 更多

Copyright ©1999-2011 厦门凌众科技有限公司 厦门优通互联科技开发有限公司 All rights reserved

地址(ADD):厦门软件园二期望海路63号701E(东南融通旁) 邮编(ZIP):361008

电话:0592-5908028 传真:0592-5908039 咨询信箱:web@lingzhong.cn 咨询OICQ:173723134

《中华人民共和国增值电信业务经营许可证》闽B2-20100024  ICP备案:闽ICP备05037997号