您当前的位置: 首页 » MySQL/MSSQL编程 » ext3下删除mysql数据库的数据恢复案例
ext3下删除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备份，确保数据恢复过程不会导致更严重的故障。
一台重要的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备份，确保数据恢复过程不会导致更严重的故障。