没有合适的资源?快使用搜索试试~ 我知道了~
嵌入式系统/ARM技术中的Linux EXT3下删除MySQL数据库的数据恢复
0 下载量 60 浏览量
2020-11-11
19:28:02
上传
评论
收藏 55KB PDF 举报
温馨提示
试读
1页
本文主要研究服务器及非WINDOWS平台下的数据灾难恢复。 [数据恢复故障描述] 一台重要的MYSQL数据库服务器,146GB*2,RAID1,约130GB DATA卷,存储了大约200~300个数据库。平时管理员对每个数据库dump出以后,直接压缩成.gz包,再将所有重要的.gz 包合起来压缩成一个总的.tar.gz包,这些文件每日产生一次,覆盖原来的备份。数据文件及备份文件全部存储于data卷上。 一次系统维护中,管理员不小心将data卷下的所有文件全部rm,删除后,马上停止系统,再未做其它操作,但删除时仍有大量终端在访问此服务器。 要求恢复mysql数据库文件,即
资源推荐
资源详情
资源评论
嵌入式系统嵌入式系统/ARM技术中的技术中的Linux EXT3下删除下删除MySQL数据库的数据库的
数据恢复数据恢复
本文主要研究服务器及非WINDOWS平台下的数据灾难恢复。 [数据恢复故障描述] 一台重要的MYSQL
数据库服务器,146GB*2,RAID1,约130GB DATA卷,存储了大约200~300个数据库。平时管理员对每个数
据库dump出以后,直接压缩成.gz包,再将所有重要的.gz 包合起来压缩成一个总的.tar.gz包,这些文件每日产
生一次,覆盖原来的备份。数据文件及备份文件全部存储于data卷上。 一次系统维护中,管理员不小心将
data卷下的所有文件全部rm,删除后,马上停止系统,再未做其它操作,但删除时仍有大量终端在访问此服务
器。 要求恢复mysql数据库文件,即
本文主要研究服务器及非WINDOWS平台下的数据灾难恢复。
[数据恢复故障描述]
一台重要的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数据库。直接恢复其mydrm数据文件,所有数据恢复成功。
[其他]
1、LINUX EXT3数据删除后应尽快断掉文件系统IO,通常umount文件系统即可。
2、对故障卷做dd备份,确保数据恢复过程不会导致更严重的故障。
资源评论
weixin_38715008
- 粉丝: 5
- 资源: 1017
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功