EXT4 File System fsck post-corruption repair method-linux Data Recovery case

There are several concepts that need to be understood before data recovery cases begin

Block group: The entire space of the Ext4 file system is divided into block groups, and the structure within each block group is roughly the same.
Block Group Descriptor Table: each block group corresponds to a block group descriptor, which is uniformly placed in the front of the file system, called the Block group descriptor tables. The size of each block group descriptor is 32 bytes, which mainly describes the block bitmap, the I-node bitmap, and the address of the I-node table.
Super Block (Superblock): The configuration parameters used to store the file system (such as block size, total block count, I-node count), and dynamic information (number of currently idle blocks and I-nodes). The Ext4 file system's Super block (Superblock) starts at 1024 bytes, which is the sector number 2nd.
I node: Describes the file's time information, size, block pointers and other information.
The Block group descriptor and the position of the Super block in the Block: when the block size is 2 sectors, block No. 0 is a bootstrapper or a reserved block, and the Super Block starts at Block 1th. When the block size is 4 sectors, the bootstrapper or reserved block is located in the first two sectors of block No. 0, and the Super Block is located in the last two sectors of block No. 0. When the block size is 8 sectors, the bootstrapper or the reserved block is located in the number 0-1 sector of block No. 0, and the Super Block is located in the number 2-3 sector of block No. 0.
The overall structure of the Ext4 file system and the concrete structure of the first block group are shown in 1.

Data Recovery initial inspection and analysis:

A company EXT4 file system Umount failed, the administrator performed the fsck operation check consistency, resulting in the Ext4 file mount is not on (and sometimes appear to cause the directory to become a file). Error message: Mount:wrong FS type, Bad Option,bad superblock
Because the log and data inconsistency causes the normal file system data to be overwritten in the EXT3, EXT4 file system, the frequency is higher, but the journal log file has buffer data, the data can be recovered by Joumal log file to find the appropriate information and rebuild the source file.
The first sector of the hard disk of the Linux system is the MBR sector, which is observed through the MBR partition table that this case is divided into two partitions, the size of 7.8G swap partition and the size of 282G file system, a total of 300G file size. After the data recovery engineer discusses the decision to retrieve lost data through Joumal log file analysis.
1. The block size is fixed 4KB, which is 8 sectors.
2. The Super Block (Superblock) starts at 1024 bytes, which is the 2nd sector, with a size of 2 sectors.
3. Block Group Description table starts with the first block, which starts at 4096 bytes.
5. Data recovery process
First, the Ext4 file system is opened with the data Recovery tool, and you can see that 0-23 sectors of data (including the Super Block and block Group descriptor) are overwritten by the log records. The log page of the EXT3, Ext4 file system begins with C0 3B 39 98.
As shown in 2.

Figure 2
Information about the block size can be reflected in the Super block. From the. Journal Log, the Super block backup is found and the super block information is searched by the data recovery tool. Its logo is "53ef". Find Super Block mode 3 as shown. Look at the block size Method 4 and Figure 5. The Super Block 0x18-0x1b describes the block size and determines that the case block size is 4KB.

Figure 3
View the block size as shown by the Super Block 4.

Figure 4
The template editor for the data Recovery software can also display block size 5 as shown.

Figure 5
The second step, rebuild (Restore) Super block, because the original file system Super block corruption, so when recovering the file, you want to paste this part of the Super block information back, that is placed in the 2nd sector start, or 1024 bytes. After doing this, the Super block backup may be inconsistent with the actual super block values and needs to be modified by the template manager of the Data Recovery tool. This case changes the block group where the super Block is located, which is in the NO. 0 block group.
As shown in 6.

Figure 6
The third step: Rebuild (Restore) block Group description table; As part of the Block Group description table is corrupted, find all the block group description tables in the. Journal log file and paste them back in. In the. Journal log file, 1 shows that the Block Group Descriptor table is stored behind the Super block. So to find a block Group description table, you can find the Super block first. When found, pastes the block Group Descriptor list contents to 4096 bytes.
Fourth, rebuild (Restore) The directory, when we want to restore files in a folder, such as we need to recover the data in the Kyproc folder. We found that these folders are not open in the Winhex. As shown in 7. Obviously this directory is corrupted, open its node information, and find that the normal data is populated by the log, as shown in 8.

Figure 7

Figure 8
We found it in the top level directory, the Var folder. Right click on "Open" to open the directory information to see all the files in the Var file. Locate the information for the Kyproc directory that you want to recover, and 00 EE is its I-node number, 10 00 for its directory entry length, 06 for its file name length, and 02 for its file type as a directory. As shown in 9.

Figure 9
Then find the location of the Kyproc directory under the directory block of the Var folder, as shown in 10, where the red position is the result found. This location shows that the block number is 62399108.

Figure 10
Depending on the block number, the location of the corresponding node of the Kyproc directory can be located. Because the artificial node is cumbersome, we can open the. Journal log file, find its node information from inside, paste the corresponding information back.
The above method can reconstruct (restore) The directory, restore the directory of files in the same way from the. Journal log file to find the corresponding file node information, find and paste back to the original location, to achieve the purpose of the reconstruction (recovery) file.

EXT4 File System fsck post-corruption repair method-linux Data Recovery case