Data recovery case for MySQL database removal under Linux ext3

[Data recovery failure description]

An important MySQL database server, 146GB*2,RAID1, about 130GB data volumes, stores approximately 200~300 databases. At ordinary times, the administrator for each database dump, directly compressed into the. GZ package, and then all the important. GZ package together to compress into a total. tar.gz package, these files are generated once a day, overwriting the original backup. Data files and backup files are all stored on the volume.

Once system maintenance, the administrator accidentally all the files under the data volume RM, delete, immediately stop the system, and then did not do other operations, but there are still a large number of terminals to access this server.

Requires the recovery of MySQL database files, namely MyD, frm, myi (rebuilt) files, or the. gz package for each database, or all critical databases. tar.gz Backup package.

[Data Recovery analysis]

Ext3 data deletion, in theory, will clear the inode in addition to the node type, date and other attributes, such as file size, data storage address, and other attributes will be all clear 0, while the catalog table will be the length of the directory entries to screen out deleted files, but the node number will be preserved, Finally, it will change the space occupancy mark in the bitmap.

Even if there is a node number in the directory table that deletes the file, it is decoupled from the data area because the contents of the node are not what is needed.

From the data point of view, most file types have a specific header flag, and the header flag is likely to find the starting location of the deleted file, but EXT3 is stored in block groups, while data and indexes are mixed in the data area, so the likelihood of data continuous storage is very small, so Processing in a file format is also difficult.

The only algorithm combines the above features with the analysis of the log, coupled with the simulation analysis of the stored procedure, to approximate the real storage structure as much as possible.

[Data recovery process]

1, the failure to do a full backup of the volume.

2, the total. tar.gz for recovery analysis, but the recovered files extracted to about 50% will be an error, subsequent file list can not be listed. After analysis, the biggest reason is that there are still data written to destroy files caused by the deletion.

3, the subcontract of the. gz File Recovery analysis, most successful recovery.

4. GZ database for unsuccessful recovery. Restore its myd\frm data file directly, and all data recovered successfully.

Other

1, LINUX EXT3 data should be deleted as soon as possible, file system IO, usually umount file system can be.

2, the failure of the DD backup to ensure that the data recovery process will not lead to more serious failures.