Data recovery case for MySQL database removal under Linux ext3

Source: Internet
Author: User
Tags file size gz file mysql database backup linux

[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.


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.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.