Windows system >> Linux system Tutorial >> Linux Tutorial

Restore deleted files under Ext3

The following tutorial
will teach you how to recover files that are rm-dropped in the Ext3 file system.

Assuming we have a file named ‘test.txt’
$ls -il test.txt 15 -rw-rw-r– 2 root root 20 Apr 17 12:08 test.txt

Note:: The “-il” option indicates the i-node number of the display file (15). If you don't know the Unix/Linux file system's "I node", you need to add the relevant Know how. Simply put, the i-node is an identification number for the operation management file.

Let's take a look at the content:
$cat test.txtthis is test file

Okay, now we start deleting files:.
$rm test.txtrm : remove write-protected regular file `test.txt’? y

Recover using Journal and Inode numbers

Note that if you delete the file and restart the system, then the relevant The file journal will be lost and we will not be able to recover the file. Therefore, the premise of 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: 0User: 0 Group: 0 Size: 20File ACL: 0 Directory ACL: 0Links: 1 Blockcount: 8Fragment: Address: 0 Number : 0 Size: 0ctime: 0x48159f2d — Mon Apr 28 15:25:57 2008atime: 0x48159f27 — Mon Apr 28 15:25:51 2008mtime: 0x4806f070 — Thu Apr 17 12:08:40 2008Blocks: (0+1) : 10234No magic number at block 7247: end of journal.

Please note the line in the above message:
Blocks: (0+1): 10234

This is the address where the inode 15 stores the file (data block) ). Then, we know this address, we can use the dd command to extract the data from this address.
#dd if=/dev/sda5 of=/tmp/test.txt bs=4096 count=1 skip= 102341+0 records in1+0 records out

if is the input device

of is the output device.

bs specifies the size of a block

count shows how many blocks need to be dump

skip Description Skips 10234 from the beginning Block, and take the data from a block

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 we know about the file. In reality, we don't know this information. If we don't know the inode, can we recover? Yes, this is possible, let's see how to recover.

Using Journal and filename recovery

If we don't know the inode of the file we might recover? I can tell you that this is impossible. However, we have a way to know the inode number of the file. Let's take a look at how to do it:
$rm mytest.txtrm: remove write-protected regular file `mytest.txt’? y

Note, we don't know its inode number, but we can use debugfs Command to view (using its ls -d option).
debugfs: ls -d 2 (12) . 2 (12) .. 11 (20) lost+found 2347777 (20) oss<2121567> (20) mytest.txt

Look at the file name, Its inode number is <2121567>. Note that the inodes of the deleted files are wrapped in angle brackets.

When you know the inode number, then we can easily recover it (using the logdump option):
debugfs: logdump -i <2121567>Inode 2121567 is at group 65, block 2129985, offset 3840Journal Start 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: 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 File ACL: 2130943 Direc Tory 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 take a closer look, 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 file's timestamp below Blocks: 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 restore command again:
$sudo dd if=/dev/sda5 of=/home/hchen/mytest_recovered.txt bs=4096 skip =2142216 count=1

Let's check the contents of the file:
$ cat mytest_recovered.txtthis is my test file

Summary

Okay, here are some of our summaries: 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 very different ways to recover files on the Internet. Basically, they also use the debugfs command. Some of them also use lsdel. In fact, they are similar. This tutorial is what I saw on the Internet, although he said that it is only for Ext3 file system, but I always feel that it should be available for the Ext2 file system, but I have not tried it. Maybe Ext2 and Ext3 are not the same as the information output by debugfs. Everyone can try it.

(End of the article)