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

The following tutorial will teach you how to recover files dropped by rm in Ext3's file system.

Suppose we have a file called '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 that the i-node number (15) of the file is displayed. If you do not know the "I node" of the Unix/Linux file system, you need to add some relevant knowledge first. To put it simply, the I node is an identification number of the operation management file.

Let's take another look at its contents:

$cat test.txt

This is test file

Okay, now let's delete the file:.

$rm test.txt

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

Restore using Journal and Inode number

Note that if you delete the file and restart the system, the related file journal will be lost and we will not be able to recover the file. Therefore, the premise of restoring files is that the Journal cannot be lost, that is, the system cannot be rebooted.

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

Debugfs: logdump-I

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: (031): 10234

No magic number at block 7247: end of journal.

Notice this line in the information above:

Blocks: (031): 10234

This is the address (data block) where inode 15 holds the file. Then, when we know the address, we can use the dd command to fetch 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 block require dump

Skip says to skip 10234 block from the beginning and fetch the data from one block.

Let's take a look at the recovered files:

$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 inode, can we recover it? Yes, it's possible. Let's take a look at how to recover.

Restore using Journal and filename

If we don't know the inode of the file, can we recover it? I can tell you that it 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 don't know its inode number, but we can use the debugfs command to see it (using its ls-d option).

Debugfs: ls-d

2 (12). 2 (12).. 11 (20) lost+found 2347777 (20) oss

(20) mytest.txt

You see the name of the file, its inode number is, note that the inode of the deleted file is wrapped in angle brackets.

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

Debugfs: logdump-I

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: 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 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: (031): 2142216

There is a lot of information above. Let's take a closer look at it. You can see the following line of information:

FS block 2129985 logged at sequence 405644, journal block 9

And the type is:

Type: bad type

Take a closer look at the Blocks under the timestamp of the file: nothing. So, let's look at the next block:

FS block 2129985 logged at sequence 405648, journal block 64

(inode block for inode 2121567):

This Journal will have the block message:

Blocks: (031): 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 again:

$cat mytest_recovered.txt

This 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 block address of the file.

3) use the dd command to take the data out and save it as a file.

There are many other different ways to recover files online, basically using the debugfs command, and some also use lsdel, in fact, this tutorial is more or less the same, I saw this tutorial on the Internet, although he said it was only for the Ext3 file system, but I always feel that it should be able to be used for the Ext2 file system, but I have not tried it. Maybe Ext2 and Ext3 are not the same information output by debugfs. You can try it.

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.