[数据恢复故障描述]
一个重要的mysql数据库服务器，146GB*2，RAID1，约130GB数据量，存储约200~300个数据库。通常，在管理员转储每个数据库后，它被直接压缩成一个. gz包。
然后所有重要的。gz包组合压缩成一个总。tar.gz包，这些文件每天生成一次，覆盖原始备份。数据文件和备份文件都存储在数据卷上。
在一次系统维护中，管理员意外地锁定了数据卷下的所有文件。删除后，他立即停止系统，不做任何其他事情。但是，大量终端在删除时仍在访问服务器。
恢复mysql数据库文件，即myd、frm、myi(可重构)文件或。每个数据库的gz包，或总包。所有重要数据库的tar.gz备份包。
[数据恢复分析]
理论上，ext3下的数据删除会清除inode中除节点类型和日期之外的其他属性，比如文件大小、数据存储地址等。同时被删除的文件在目录表中会被目录项的长度屏蔽，但会保留节点号。
最后，位图中的空间占用标志将被改变。
即使被删除文件的节点号存在于目录表中，它也与数据区解耦，因为节点内容中不需要任何东西。
从数据的角度来看，大多数文件类型都会有一个特定的文件头标志。可以根据头文件标志找到被删除文件的起始位置，但是EXT3是分块组存储的，数据和索引混合在数据区，所以数据连续存储的可能性很小。这样一来，
按照文件格式处理也很困难。
唯一的算法就是结合以上特点，加上对日志的分析，加上对存储过程的模拟分析，尽可能接近真实的存储结构。
[数据恢复过程]
1.对故障卷进行完整备份。
2.总数。tar.gz被恢复和分析，但是恢复的文件在解压缩到大约50%时将被报告为错误，并且不能列出后续文件的列表。经分析，最大原因是删除时仍有数据写入破坏文件。
3.在分析分包合同的回收情况后。gz文件，大部分都恢复成功了。
4.给不成功的人。gz数据库。直接恢复其myd\frm数据文件，所有数据都恢复成功。
[其他]
1.删除LINUX EXT3的数据后，要尽快断开文件系统IO，通常是umount文件系统。
2.对故障卷进行dd备份，确保数据恢复过程不会导致更严重的故障。