Restore deleted files under ext3)

Preface

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

 

Delete an object

Suppose we have a file named 'test.txt'

 

 
$Ls-Il test.txt15-RW-r-2Root20APR17 12:08Test.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:

$CatTest.txt this is testFile
 

Now, let's delete the file:

 
$RmTest.txtRm: RemoveWrite-Protected regularFile'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: 0 × 0 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 =4096Count =1Skip =102341+0RecordsIn1+0Records outIfIs the input device of is the output device. BS specifies the size of a block. Count indicates the number of blocks that need dumpskip. It indicates that the blocks are skipped from the start.10234Blocks, and the data from the next block is retrieved.
 

 

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

 
$Cat/Tmp/Test.txt this is testFile
 

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:

 
$RmMytest.txtRm: RemoveWrite-Protected regularFile'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-D2(12).2(12)..11(20) Lost + found2347777(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 , Transaction 405642  FS Block  2129985 Logged at Sequence 405644 , Journal Block 9  (Inode Block  For Inode 2121567 ): Inode:  2121567 Type: Bad type mode: 0000 Flags: 0 × 0 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:  0 × 00000000 -Thu Jan 1   05 : 30 : 00   1970  Atime: 0 × 00000000 -Thu Jan 1   05 : 30 : 00   1970  Mtime:  0 × 00000000 -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: 0 × 0 Generation: 913772093 User:  100 GROUP: 0 Size: 31  File 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 Block2129985Logged at Sequence405644, Journal Block9
 

And its type is:

 
Type: Bad type
 

Take a closer look atBlocks:Nothing. So let's take a look at the next block:

 
FS Block2129985Logged at Sequence405648, Journal Block64(Inode BlockForInode2121567):
 

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 =4096Skip =2142216Count =1
 

Let's check the file content again:

 
$CatMytest_recovered.txtthis is my testFile 
 

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.

 

From http://coolshell.cn/articles/1265.html#more-1265