Linux EXT3下删除MySQL数据库的数据恢复

运维 系统运维
一次系统维护中,管理员不小心将data卷下的所有文件全部rm,删除后,马上停止系统,再未做其它操作,但删除时仍有大量终端在访问此服务器。

[数据恢复故障描述]

一台重要的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备份,确保数据恢复过程不会导致更严重的故障。

【编辑推荐】

  1. fedora下bridge和nat设置(LINUX上网问题)
  2. Linux系统核心源程序文件组织结构介绍
  3. 计算机中装有双系统的用户如何卸载Linux
责任编辑:赵宁宁 来源: IT专家网
相关推荐

2009-06-27 21:41:55

Linux

2009-08-17 08:39:41

2009-06-10 08:49:05

LinuxExt3恢复

2009-08-04 08:28:10

2011-03-30 14:08:27

MySQL数据库删除恢复

2011-04-14 15:12:10

Linux恢复

2017-04-01 18:30:47

MySQL误删除数据库

2023-09-21 09:31:24

MySQL数据库

2009-03-26 17:46:53

LinuxExt3Reiserfs

2018-04-28 15:28:44

数据库MySQL误删除

2013-05-24 13:24:46

Mysql数据库自动备份

2011-04-07 15:02:02

LinuxMySQL数据库

2010-03-15 16:30:53

Ubuntu Linu

2010-10-15 13:45:20

安装MySql数据库

2012-05-08 10:56:15

Linux

2010-06-04 18:12:17

MySQL 数据库启动

2011-06-10 10:31:57

QT mysql linux

2009-10-27 12:47:29

linux Ext3文

2010-08-25 10:16:48

DB2备份Linux

2010-06-11 14:46:13

MySQL数据库
点赞
收藏

51CTO技术栈公众号