linux ext3下mysql数据库被误删除的数据恢复案例
最新动态来源：本站原创点击数：178更新时间：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：
１、LINUX EXT3文件系统下数据删除后应尽快断掉文件系统I/O，通常umount文件系统即可。
２、对故障卷做dd备份，确保数据恢复操作不会对原始数据进行二次破坏。