您所在的位置:首页 > 成功案例 > RAID数据恢复

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

最新动态来源:本站原创点击数:56更新时间:2022/11/9

服务器数据恢复环境:
MYSQL数据库服务器,2块硬盘组建RAID1;
DATA卷存储了200多个数据库;
每天将每个数据库dump出后直接压缩成.gz包,然后将所有重要数据库的.gz 包放在一起压缩成一个总的.tar.gz包,覆盖原来的备份;
数据文件及备份文件全部存储于DATA卷上。
 
服务器故障&分析:
在一次常规的维护中,管理员不小心将DATA卷下的所有文件全部rm,删除后管理员马上关闭系统,再未做其它操作,但在删除那一刻有大量终端在访问此服务器。
管理员联系我们数据恢复中心要求恢复mysql数据库文件(如myd、frm、myi(可重建)文件),或者每个数据库的.gz包,或者所有重要数据库总的.tar.gz备份包。
 
理论上,在ext3文件系统下删除数据会清除inode中除节点类型、日期外的其他属性如文件大小、数据存储地址等,这些属性会全部清0。同时目录表中会以目录条目长度的方式屏蔽掉已删除的文件,但会保留节点编号,最后会改变BITMAP中的空间占用标志。即使是目录表中存在删除文件的节点编号,但因节点内容已经没有需要的东西,与数据区也是脱钩的。
从数据角度来说,大多数文件类型都会有特定的文件头标志,通过文件头标志是有可能找到删除文件的起始位置的。但EXT3文件系统以块组为单位进行存储,同时数据与索引是混合存储于数据区的,所以数据连续存储的可能性非常小,所以按照文件格式进行处理可行性不大。
唯一的方案是结合上述几个特征,加上对日志和存储过程的模拟分析,尽可能地还原真实的存储结构。
 
服务器数据恢复过程:
1、首先对故障服务器的所有硬盘做完整镜像备份。
2、基于镜像文件对总的.tar.gz进行分析并尝试恢复,但恢复出来的文件解压到一半左右就报错,后续文件列表也无法列出。经过数据恢复工程师的分析,发现出现这种情况是因为在删除DATA卷下的所有文件时仍有数据写入破坏了文件。
3、对每个数据库的.gz包进行分析并尝试恢复,大多数数据库的.gz包恢复成功。
4、对于未恢复成功的数据库.gz包,直接恢复其myd\frm数据文件,最终将所有数据库的.gz包恢复成功。
5、经过用户亲自验证,恢复出来的数据完整可用。
 
服务器数据安全Tips:
1、LINUX EXT3文件系统下数据删除后应尽快断掉文件系统I/O,通常umount文件系统即可。
2、对故障卷做dd备份,确保数据恢复操作不会对原始数据进行二次破坏。