[Server data recovery] A case of data recovery when the Ext4 file system cannot be mounted and an error is reported after fsck

Server data recovery environment:
A company's Linux system server;
There are two partitions: the first partition is the swap partition, and the second partition is the Ext4 file system.

Server failure & analysis:
The Ext4 file system cannot be umount. The administrator performs the fsck operation to check the consistency. As a result, the Ext4 file cannot be mounted.Error message: mount: wrong fs type, bad option, bad superblock.The administrator contacts our data recovery center for data recovery.
The normal file system data is overwritten due to inconsistency between logs and data. This kind of failure often occurs in Ext3 and Ext4 file systems. Fortunately, the .journal log file in this case has a buffer, which can be found in the .journal log file.Corresponding information and paste it back to the corresponding location to achieve the purpose of rebuilding the original file.
Ext3 and Ext4 file systems have journal functions. In this case, we consider finding lost data from .journal log files.

Server data recovery plan:
After consultation with Beiya server data recovery engineer, the following data recovery plan was finally finalized:
1. Find the super block backup through the super block backup in the .journal log file.block, which determines the block size.
2. Find the super block through the super block backup in the .journal log file and rebuild the super block information.
3. Find the directory node through the .journal log file and rebuild (restore) the directory.
4. Find the directory node through the .journal log file, find the node information of the file to be restored, and rebuild (restore) the file.

Server data recovery process:
First open the Ext4 file system with a tool, you can see that the data in sectors 0-23 (including super block and block group descriptors) are overwritten by log records.The log pages of Ext3 and Ext4 file systems start with C0 3B 39 98.As shown below.

1. Determine the block size:
There is information about the block size in the super block. You can find the backup of the super block from the .journal log.Use the tool to find the information of the super block in the .journal log, and its flag is "53ef".The way to find super blocks is shown in the figure below.The method of viewing the block size is shown in Figure 4 and Figure 5.The block size is described at the super block 0x18-0x1B, and the block size in this case is determined to be 4KB.

View the block size through the super block as shown below.

The WinHex Template Editor can also display block sizes, as shown in the image below.

2. Rebuild (restore) super block;
Since the original file system super block is damaged, it is necessary to paste this part of the super block information back when restoring the file, that is, put it at the beginning of sector 2, or 1024 bytesplace.
After completing the above operations, some parts of the super block backup may be inconsistent with the actual super block value, which needs to be modified through the template manager of WinHex.In this case, the block group where the super block is located is modified, which is in the 0th block group.As shown below.

3. Rebuild (restore) the block group description table:
Since part of the block group description table is damaged, find all the block group description tables in the .journal log file and paste them back.In the .journal log file, the block group descriptor table is stored after the superblock.So when looking for the block group description table, you can first find the super block.Once found, paste the contents of the block group descriptor table at 4096 bytes.

4. Rebuild (restore) directory:
When you want to restore the files in a certain folder, such as the data in the kyproc folder, it is found that these folders cannot be opened in WinHex, as shown in the following figureShow.Obviously this directory is damaged, open its node information and find that normal data is filled with logs, as shown in Figure 2 below.

We find its parent directory, the var folder, right-click and click "open" to open the directory information to see all the files in the var file.Find the information of the kyproc directory to restore, 12 32 EE 00 is its i-node number, 10 00 is its directory entry length, 06 is its file name length, and 02 means its file type is directory.As shown below.

Then look for the location of the kyproc directory under the directory block of the var folder, as shown in the figure below, the location marked in red is the result of the finding.This location shows the block number as 62399108.

According to the block number, the location of the corresponding node in the kyproc directory can be located.Since it is cumbersome to manually supplement the nodes, the Beiya data recovery engineer opened the .journal log file, found its node information from it, and pasted the corresponding information back.

The above method can rebuild (restore) the directory, and the files in the recovery directory are also used to find the node information of the corresponding file from the .the goal of.

5. After completing all data recovery operations, the administrator will verify the recovered data in person to confirm that the recovered data is complete and correct, and this data recovery is successful.