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