Shulou(Shulou.com)06/02 Report--

There are several concepts to understand before the data recovery case begins

Block groups: the entire space of the Ext4 file system is divided into several block groups, each with roughly the same structure.

Block group descriptor table: each block group corresponds to a block group descriptor, which is uniformly placed at the front of the file system, called the block group descriptor table. 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 blocks (Superblock): used to store configuration parameters (such as block size, total number of blocks, number of I-nodes) and dynamic information (current number of free blocks and number of I-nodes) of the file system. The super block (Superblock) of the Ext4 file system starts at 1024 bytes, which is sector 2.

I node: describes the time information, size, block pointer and other information of the file.

The position of the block group descriptor and the super block in the block: when the block size is 2 sectors, block 0 is the bootstrap or reserved block, and the super block starts with block 1. When the block size is 4 sectors, the bootstrap program or the reserved block is located in the first two sectors of block 0 and the super block is located in the last two sectors of block 0. When the block size is 8 sectors, the bootstrap program or retains the block in sector 0-1 of block 0, and the super block in sector 2-3 of block 0.

The overall structure of the Ext4 file system and the specific structure of the first block group are shown in figure 1.

Preliminary examination and analysis of data recovery:

The umount of the Ext4 file system of a company failed, and the administrator checked the consistency by fsck, which resulted in the failure of the Ext4 file mount (and sometimes caused the directory to become a file). Error message: mount: wrong fs type, bad option,bad superblock

The overwriting of normal file system data due to inconsistency between logs and data occurs more frequently in Ext3 and Ext4 file systems. However, journal log files have buffered data. When data is recovered, you can find the corresponding information through joumal log files and rebuild the source file.

The first sector of the hard disk of the Linux system is the MBR sector. Through the observation of the MBR partition table, we can see that this case is divided into two partitions, namely the swap partition with the size of 7.8G and the file system with the size of 282G, with a total file size of 300g. After discussion, the data recovery engineer decided to recover the lost data through joumal log file analysis.

1. The block size is a fixed 4KB, that is, 8 sectors.

two。 The superblock (Superblock) starts at 1024 bytes, that is, sector 2, and has a size of 2 sectors.

3. The block group description table starts with the first block, that is, at 4096 bytes.

5. Data recovery process

First open the Ext4 file system with the data recovery tool, and you can see that the data in sectors 0-23 (including super blocks and block group descriptors) is overwritten by logging. The log pages of Ext3 and Ext4 file systems begin with C03B 3998.

As shown in figure 2.

Figure 2

Information about the block size can be reflected in the super block. Look up the backup of the super block from the .journal log and find the super block information through the data recovery tool. Its logo is "53ef". The way to find the super block is shown in figure 3. The block size method is shown in figures 4 and 5. Describe the block size at the super block 0x18-0x1B, and determine that the block size in this case is 4KB.

Figure 3

View the block size through the super block as shown in figure 4.

Figure 4

The block size can also be displayed through the template editor of the data recovery software as shown in figure 5.

Figure 5

The second step is to rebuild (restore) the super block; because the original file system super block is damaged, paste this part of the super block information back when restoring the file, that is, at the beginning of sector 2, or at 1024 bytes. After doing the above, some parts of the super block backup may be inconsistent with the actual super block values, which need to be modified through the template manager of the data recovery tool. This case modifies the block group in which the super block is located, which is in the 0th block group.

As shown in figure 6.

Figure 6

Step 3: rebuild (restore) the block group description table; because some of the block group description tables are corrupted, find all the block group description tables in the .journal log file and paste them back. In the .journal log file, as shown in figure 1, the block group descriptor table is stored after the super block. So when looking for a block group description table, you can find the super block first. Paste the contents of the block group descriptor table into 4096 bytes when found.

Step 4: rebuild (restore) the directory; when we want to restore the files in a folder, for example, we need to restore the data in the kyproc folder. We found that these folders cannot be opened in WinHex. As shown in figure 7. Obviously this directory is corrupted. Open its node information and find that the normal data is filled with logs, as shown in figure 8.

Figure 7

Figure 8

We found its upper directory, the var folder. Right-click "open" to open the directory information for all the files in the var file. Find information about the kyproc directory to restore, 12 32 EE 00 is its I-node number, 10 00 indicates its directory entry length, 06 indicates its file name length, 02 indicates its file type is directory. As shown in figure 9.

Figure 9

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

Figure 10

According to the block number, you can locate the location of the corresponding node in the kyproc directory. As manual patching nodes are cumbersome, we can open the .journal log file, find its node information from it, and paste the corresponding information back.

The above method can rebuild (restore) the directory, and the files in the recovery directory can also find the node information of the corresponding file from the .journal log file and paste it back to the original location to achieve the purpose of rebuilding (restoring) the file.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.