删除MySQL数据库在ext3数据恢复案例

{数据恢复错误描述}
一个重要的MySQL数据库服务器，146gb×2，RAID1，约130gb数据量，存储约200 ~ 300数据库。通常，当管理员出来每个数据库的转储，它直接压缩成。广州包，然后都重要。广州套餐组合压缩total.tar.gz包。这些文件一天生成一次，覆盖原始备份。数据文件和备份文件都存储在数据卷上。
在一个系统维护中，管理员不小心从数据卷中删除所有文件，然后立即停止系统，然后不做任何其他操作。但是，当RM被删除时，仍然有许多终端访问服务器。
它需要恢复MySQL数据库文件，即MyD，FRM，我（重建）文件，或。广州包每个数据库，或所有的important.tar.gz备份包重要数据库。
{数据恢复分析}
ext3删除的理论数据，除此之外的其他节点将删除属性节点类型、日期、文件大小等，数据的存储地址的属性0、在屏蔽文件的目录条目长度的内容表中的同一时间已被删除，但会保留节点数，最后将改变空间占用标志位图。
即使有一个节点号在目录表中删除一个文件，它也与数据区域解耦，因为节点内容没有任何需要。
从数据来看，大多数的文件类型将头特异性体征，根据第一次的标志是有可能找到被删除文件的起始位置，但ext3存储在块为单位，同时存储在数据区的数据指标是混合的，所以连续数据存储的可能性是非常小的，所以根据文件格式，处理是非常困难的。
唯一的算法是将这些特征与日志分析相结合，增加存储过程的仿真分析，并尽可能接近实际的存储结构。
{数据恢复过程}
1。故障体积的完全备份。
2、对total.tar.gz回收分析，但该文件50%恢复将是错误的，后续的文件列表不能上市，分析最大的原因是，还有写数据破坏文件的删除。
3、该分包。广州文件恢复分析，大部分恢复成功。
4、对广州数据库还没有恢复成功，MYD FRM的数据文件直接恢复，所有数据恢复成功。
{等}
1、Linux Ext3数据应尽快删除文件系统的IO删除后，通常umount文件系统。
2，对故障体积进行DD备份，以确保数据恢复过程不会造成更严重的故障。
更高质量的数据，在调试编辑：ZJ