Data recovery record: LINUX EXT3 hard drive bad track data failure

[Data recovery failure description]

A Linux Web server, DELL R200, manages about 50 sites and uses a single SATA 160GB hard drive. In the normal use of sudden downtime, try to start failed again, the hard drive removed detect the existence of about 100 bad sectors.

After a data recovery company repaired the bad way, it tried for about 3 days and did not return to success.

[Data recovery process]

After receiving the disk, the failure disk is fully mirrored by pc3k with DE, and the data is analyzed in the mirror.

The entire hard disk consists of two partitions: 100M boot partition and remaining space/partition (through LVM management), file system is EXT3.

Root partition super block normal, view the first Group description table according to Super Block normal, but the node area is all 0.

According to the Block Group description table, we found that the first 27 blocks were all 0, but the data area before and after block group obviously had user data.

Intermediate block Group Area metadata Normal (description table, node, bitmap, etc.)

The last part of the block group has a metadata area of 0.

An attempt was made to find the root directory.

In the root directory as a clue, restore the root node area, successful.

The file system tree is generated with the generated root node area and the root directory record, and a large amount of data can be seen successfully, and the file system is structurally normal. However, the nodes of some files or folders are 0, and the node area is located in the front and back part of the file system through node tracking.

Attempting to restore the files and folders with a node area of 0, most of the folders were restored successfully, but most of the files were unrecoverable.

Trying to restore what the user has done. TAR. GZ Backup package, the recovery was successful, but prompted error on the open, the intermediate data is corrupted, only limited export part of the site.

The final estimate of about 70% of the data recovery was successful.

[Data recovery failure reason inference]

The reasons for the failure of data recovery are often not clearly known, in this case only inferred as follows:

1, after the bad way, the user may try to do automatic or manual fsck operation, resulting in further disaster.

2, the partial block group all is 0 to look, may have done the unfinished mkfs.

3, repair data recovery company is not professional, there is the possibility of destroying data.

[Suggestions to the user]

1, important data must not use a single disk to do the storage environment, the current framework of a simple raid does not require a lot of input.

2, must do a good job backup, at least, the backup package should not be placed on the same storage body, the next step, also must not put to the same partition.

3, after the failure of the hard drive, must not repeatedly try to deal with, should do a full backup operation as soon as possible.

4, as far as possible to choose a professional data recovery company to deal with, not professional companies or individual companies are quite shameless, unintentional or intentional failure of the disk to damage (the intention is to increase the price coerce or maintain reputation).