Restore deleted files in Ext3 from CentOS

The following tutorial will show you how to restore the rm-dropped file in the Ext3 file system. Assume that we have a file named &lsquo=test.txt&rsquo=%ls-iltest.txt 15-rw-rw-r & ndash; 2rootroot20Apr1712: 08test.txt note: & ldquo;-il & rd

The following tutorial will show you how to restore the rm-dropped file in the Ext3 file system.

Suppose we have a file named 'test.txt'

$ Ls-il test.txt
15-rw-r-2 root 20 Apr 17 12:08 test.txt
 

Note: The "-il" option indicates the I-node number (15) of the file. if you do not know the "I node" of the Unix/Linux file system, you need to add relevant knowledge first. Simply put, the I node is an ID number of the operation management file.

 

Let's take a look at its content:

$ Cat test.txt
This is test file

Now let's delete the file :.

$ Rm test.txt
Rm: remove write-protected regular file 'test.txt '? Y

 

Use Journal and Inode to restore

Note: If you delete the file and restart the system, the related file journal will be lost, and we will not be able to restore the file. Therefore, the premise for restoring files is that Journal cannot be lost, that is, the system cannot be restarted.

Because we already know that the inode number of the test.txt file is 15, we can use the debugfs command to view it:

Debugfs: logdump-I <15>
FS block 1006 logged at sequence 404351, journal block 7241
(Inode block for inode 15 ):
Inode: 15 Type: regular Mode: 0664 Flags: 0x0 Generation: 0
User: 0 Group: 0 Size: 20
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
Ctime: 0x48159f2d-Mon Apr 28 15:25:57 2008
Atime: 0x48159f27-Mon Apr 28 15:25:51 2008
Mtime: 0x4806f070-Thu Apr 17 12:08:40 2008
Blocks: (0 + 1): 10234
No magic number at block 7247: end of journal.

Pay attention to this line in the above information:

Blocks: (0 + 1): 10234

This is the address (data block) where inode 15 stores files ). Then, when we know the address, we can use the dd command to obtain the data from the address.

# Dd if =/dev/sda5 of =/tmp/test.txt bs = 4096 count = 1 skip = 10234
1 + 0 records in
1 + 0 records out

• If is the input device
• Of is the output device.
• Bs specifies the size of a block
• Count indicates how many blocks need to be dumped.
• Skip indicates that 10234 blocks are skipped from the beginning and the data of the next block is retrieved.

Next let's take a look at the recovered file:

$ Cat/tmp/test.txt
This is test file

Of course, the above file recovery is based on the inode of the file we know. but in reality, we don't know this information. if we don't know the inode, can we recover it? Yes, this is possible. let's take a look at how to recover it.

Use Journal and file name recovery

If we do not know the inode of the file, can we restore it? I can tell you that this is impossible. But we have a way to know the inode number of the file. Let's see how to do this:

$ Rm mytest.txt
Rm: remove write-protected regular file 'mytest.txt '? Y

Note that we do not know its inode, but we can use the debugfs command to view it (using its ls-d option ).

Debugfs: ls-d
2 (12). 2 (12) .. 11 (20) lost + found 2347777 (20) oss
<2121567> (20) mytest.txt

Check the file name. The inode number is <2121567>. Note that inode of the deleted file is enclosed by angle brackets.

Now that we know the inode number, we can easily recover it (using the logdump option ):

Debugfs: logdump-I <2121567>
Inode 2121567 is at group 65, block 2129985, offset 3840
Journal starts at block 1, transcoding 405642
FS block 2129985 logged at sequence 405644, journal block 9
(Inode block for inode 2121567 ):
Inode: 2121567 Type: bad type Mode: 0000 Flags: 0x0 Generation: 0
User: 0 Group: 0 Size: 0
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
Ctime: 0x00000000-Thu Jan 1 05:30:00 1970
Atime: 0x00000000-Thu Jan 1 05:30:00 1970
Mtime: 0x00000000-Thu Jan 1 05:30:00 1970
Blocks:
FS block 2129985 logged at sequence 405648, journal block 64
(Inode block for inode 2121567 ):
Inode: 2121567 Type: regular Mode: 0664 Flags: 0x0 Generation: 913772093
User: 100 Group: 0 Size: 31
Files ACL: 2130943 Directory ACL: 0
Links: 1 Blockcount: 16
Fragment: Address: 0 Number: 0 Size: 0
Ctime: 0x4821d5d0-Wed May 7 21:46:16 2008
Atime: 0x4821d8be-Wed May 7 21:58:46 2008
Mtime: 0x4821d5d0-Wed May 7 21:46:16 2008
Blocks: (0 + 1): 2142216

There is a lot of information on it. let's check it carefully. you can see the following line of information:

FS block 2129985 logged at sequence 405644, journal block 9

And its type is:

Type: bad type

Take a closer look at the Blocks below the file's timestamp: nothing. So let's take a look at the next block:

FS block 2129985 logged at sequence 405648, journal block 64
(Inode block for inode 2121567 ):

This Journal has block information:

Blocks: (0 + 1): 2142216

This is the address of the deleted file. let's run the recovery command again:

$ Sudo dd if =/dev/sda5 of =/home/hchen/mytest_recovered.txt bs = 4096 skip = 2142216 count = 1

Let's check the file content again:

$ Cat mytest_recovered.txt
This is my test file summary

Well, here are some of our summary:
1) use debugfs: ls-d to find the inode number of the deleted file.
2) use debugfs: logdump to find the data block address of the file.
3) use the dd command to extract the data and save it as a file.

There are many other methods on the Internet to restore files. Basically, the debugfs command is used, and some also use lsdel. In fact, it is similar. I have seen this tutorial on the Internet, although he said it is only for the Ext3 file system, I always feel that it can be used for the Ext2 file system, but I have not tried it. Maybe Ext2 and Ext3 are output differently by debugfs. You can try it.