Restore accidentally deleted files in the ext2 File System

Sender: Sinbad <anonymous@anonymous.com>
Title: Restore accidentally deleted files in the ext2 File System
Mailing site: sinbada (Fri Sep 27 10:54:25 2002)

--------------------------------------------------------------------------------
Author: thhsieh
From: http://www.linuxaid.com.cn

Summary

Restore accidentally deleted files in the ext2 File System

---------------------------------------------------------------------

The BBS system in this series is really difficult (well... it is actually because of my negligence that it will be so difficult ..
...), Following the incorrect system time in the past few days, many people may mistakenly cut down their IDs.
And kill the important backup files of BBS. This is what the younger brother told me after discovering it. When I came to the station to see his ma
Il, When I was crying, I almost missed the wall.

At that time, it was around a.m. on Saturday. I was thinking about compiling a set of comments to explain to everyone that I could not restore my old emails.
While still wondering whether the situation can be recovered. As you know, Unix like systems are hard to be like M $.
The system is the same. When undelete is implemented, all network administrators have repeatedly warned us to be careful! Be careful! Before downgrading
Think twice, and then regret it. Although I have been thinking twice about downgrading my archive, this was a mistake.
It was scheduled by the system in the background. When I found out the cause, it was more than an hour after the file was cut down. I rely on a little bit
I think about the possibility of undelete in Linux ext2 filesystem on the Internet,
Most of what I see is a negative answer, but it seems that someone has done this, so what I did first is
Mount the original partition of the file to read-only to prohibit any write operations.
The archive has been mistakenly cut (because there is nothing to cut), but the new archive may be overwritten by the old archive.
The original magnetic block ). The only expectation we have now is to try to separate the original magnetic fields of the archives one by one.
Find them, and "hope" the old materials on these magnetic areas are still there, and then concatenate these magnetic areas into a file. Finally
I found it !! It turns out that this technical file exists in my own system :-))

/Usr/doc/howto/mini/Ext2fs-Undeletion.gz

So I followed the instructions in this document step by step, and finally saved an 8 Mb compressed file back to 99%.
There was a 1.1 MB compressed file that was completely saved. Thank God and the Linux designers for writing that article.
The author of the file, the people who once discussed this technology, and the ext2 filesystem, which is so good in Linux, gave me the opportunity
Rescue in the past. Now, I will sort out my rescue steps for your reference. I hope it will be useful (Oh
! No, it is best to hope that you will never have the opportunity to use the following steps :-)))

Here is a solemn statement !! The purpose of writing this article is to save those who are in desperate circumstances.
It does not mean that we can take things from now on. As mentioned above, I have an archive but cannot
100%. In fact, it is lucky that 8 MB of files can be saved to 99%.
70%-80% is about to smile. Therefore, do not expect undelete to save everything. Prevention is better than treatment! Please
We usually develop good habits. Please think twice before cutting files !!!

Theoretical Analysis

How many opportunities can we save? In the kernel-2.0.X series (the Kernel used on this site is 2.0.33)
, Depending on the following two points:

Is the original magnetic zone of the file not overwritten?

Is the file completely continuous?

First, we can compete with the time, that is, when an archive is accidentally cut down, umount needs
Ilesystem, or Remount the filesystem into read-only. In this case, the archive was accidentally cut.
Only one time in a day.
, Backup), so the first point is passed.

The second point is to let everyone go. The Kernel used on this site must be assumed to be occupied by the "long file ".
Block can be completely recovered only when it is completely continuous! A block is 1024 bytes, up to 8 MB
There are more than 8000 blocks in the file. In filesystems that are frequently read and written, it is difficult to imagine that long files are hard to complete.
Continuous, but in our system, this seems a bit more hopeful. At the same time, Linux ext2 is so good fi
Lesystem, can achieve the first 7950 blocks are continuous, this is also indispensable.

Now, let's take a look at my steps.

Rescue procedure I-mount filesystem readonly

The file was originally located under/var/hda/backup/home/BBS, And the filesystem configuration of our system
Yes:

Root @ BBS:/home/FTP/rescue # DF
Filesystem 1024-blocks used available capacity mounted on
/Dev/sda1 396500 312769 63250 83%/
/Dev/sda3 777410 537633 199615 73%/home
/Dev/hda1 199047 36927 151840 20%/var/hda
/Dev/hda2 1029023 490998 485710 50%/home/ftp

Therefore, the filesystem/var/hda should be immediately mounted to readonly (use the root identity below ):

Mount-O remount, RO/var/hda

You can also directly umount it, but sometimes some processes may be running in this filesystem.
You may not be able to umount it directly. Therefore, I chose Mount readonly. However, you can also use:

Fuser-v-M/usr

Let's take a look at the processes that are using this filesystem, and then cut them one by one, and then umount.

Rescue procedure II

Run

Echo lsdel | debugfs/dev/hda1 | less

Let's take a look at the inode (Files) recently hacked by the filesystem (why is it/dev/hda1? See
Top DF list )? Important information about the milk F file, such as size, time, and attribute. For our system
, Which are listed as follows:

Debugfs: 92 deleted inodes found.
Inode owner mode size blocks time deleted
........................................ ............................
29771 0 100644 1255337 14/14 sat Jan 30 22:37:10 1999
29772 0 100644 5161017 14/14 sat Jan 30 22:37:10 1999
29773 0 100644 8220922 14/14 sat Jan 30 22:37:10 1999
29774 0 100644 5431 6/6 sat Jan 30 22:37:10 1999

Please note! We must identify the archive to be rescued in the information such as the file size and cut-down time. Here
We need to save the inode 29773.

Rescue procedure III

Run

Echo "stat <29773>" | debugfs/dev/hda1

List all information about the inode, as shown below:

Debugfs: stat <29773>
Inode: 29773 type: regular mode: 0644 flags: 0x0 version: 1
User: 0 group: 0 size: 8220922
File ACL: 0 directory ACL: 0
Links: 0 blockcount: 16124
Fragment: Address: 0 Number: 0 size: 0
Ctime: 0x36b31916 -- sat Jan 30 22:37:10 1999
Atime: 0x36aebee4 -- wed Jan 27 15:23:16 1999
Mtime: 0x36adec25 -- wed Jan 27 00:24:05 1999
Dtime: 0x36b31916 -- sat Jan 30 22:37:10 1999
Blocks:
123134 123136 123137 123138 123140 131404 131405
131407 131408 131409 131 410 131411 131668
Total: 14

The point is that all the files referred to by the inode must be retrieved. Here it is? 14
Block? No! More than 8000 blocks are required! This is the "Taobao" of ilesystem.
The first 12 blocks listed in the above are the blocks that actually refer to the archives. They are called direct blocks. 13th
The first-order indirect block and the second-order indirect block. What does it mean? This file
The block location of the data is as follows:

Do you understand? 13th (131411) and 14th blocks are not data, but index, which indicates
The position of the next block. Because the size of a block is 1024 bytes, an int is in a 32-bit system.
It is 4 bytes, so a block can record 256 pieces of data. Taking the 131411 block as an example, it records
(Before the archive is cut ):

131412 131413 131414... 131667 (256 in total)

The 256 blocks actually record the archives, so we call it the first level. Likewise, the second-order has
Two-layer indexes, in 131668, may be recorded:

131669 131926 132182... (up to 256 pens)

131669 of the block records are:

131670 131671 131672... 131925 (256 in total)

The 256 blocks actually store the archives. What we need is the real storage of archives.
Block. In theory, we only need to read all the content of these index blocks, and then take the in
Dex reads all the blocks to the hand, and 100% of the files can be saved (assuming all these blocks are not updated ).
). The project is large but feasible. Unfortunately, in kernel-2.0.33, its design is if the file
If yes, all these index blocks will be set to zero, so what I read is

0 0 0 0 0... (256 in total)

Wow! There is no way to know where these data blocks are. So here we have made a lot of false
Set: the block of the entire file is continuous! That is, the example above. That's why only continuous
Block (indirect block in the back end) files can be completely recovered, and it is time to let it go.

Rescue procedure IV

Okay, now we have to assume that all the archives are in a continuous block, please use http://archie.n now
Cu.edu.tw find this tool: fsgrab-1.2.tar.gz and install it. Because the steps are simple
I will not talk about it more. We need to use it to capture all the required blocks. Its usage is as follows:

Fsgrab-C count-s skip Device

Here, Count refers to the number of consecutive reads, and skip refers to the number of reads starting from, for example
The following command reads 256 consecutive records starting from 70:

Fsgrab-C 256-s 131670/dev/hda1> recover

Now let's start saving the archives! We must use the following command to save the above headers:
The 12 blocks are not completely continuous !!!)

Fsgrab-C 1-s 123134/dev/hda1> recover
Fsgrab-C 3-s 123136/dev/hda1> recover
Fsgrab-C 1-s 123140/dev/hda1> recover
Fsgrab-C 7-s 131404/dev/hda1> recover

This is the first 12 blocks. For the first-order indirect, the data seems to be continuous :-))

Fsgrab-C 256-s 131412/dev/hda1> recover

Note that Skip 131411 because it is an index block. For the second-order indirect, WE * assume * It
Are continuous:

Fsgrab-C 256-s 131670/dev/hda1> recover
Fsgrab-C 256-s 131927/dev/hda1> recover
Fsgrab-C 256-s 132184/dev/hda1> recover
........................................ ....

Keep doing it until the recover size exceeds the size of the file we want to save (8220922. Note
I 'd like to skip the index blocks (such as 131668,131 669, 131926,132 183,...) here.
.

Rescue procedure v

The last step is to cut out the file and see how much we have saved. Here we repeat the above steps.
, The size of the recover file is 8294400, And the size we want is 8220922, so run the following command:

Split-B 8220922 recover rec

Two files are created. One is recaa, the size is 8220922, and the other is recab, and the other is the remaining size,
The latter is rubbish. Just throw it. Now, we can check whether this file is the "complete" file that has been mistakenly cut.
. Because our file is in the .tar.gz format, we use this method to check:

MV recaa recaa.tar.gz
Zcat recaa.tar.gz> recaa.tar

If there is no error message, it indicates that it is successful! Completely saved. But unfortunately, if we fail
After the recaa.tar is renamed and then gzip, the size of the recaa.tar.gz is 1% less than that of the original recaa.tar.gz,
Indicates that 1% of the blocks in which the file was originally located are not consecutive (or are overwritten by the newly written file),
This is an unfortunate fact.

Postscript

For the * required * assumption that all blocks are continuous during undelete, The howto file says Linus
We are working with other kernel designers to see if this problem can be overcome, that is, when the file is cut down, do not
Zero index block. I just tried the kenrel-2.2.0 environment, found that has done !! Below is a cut
Inode data of the file (read by debugfs ):

Debugfs: inode: 36154 type: regular mode: 0600 flags: 0x0 version: 1
User: 0 group: 0 size: 2165945
File ACL: 0 directory ACL: 0
Links: 0 blockcount: 4252
Fragment: Address: 0 Number: 0 size: 0
Ctime: 0x36b54c3b -- mon Feb 1 14:39:55 1999
Atime: 0x36b54c30 -- mon Feb 1 14:39:44 1999
Mtime: 0x36b54c30 -- mon Feb 1 14:39:44 1999
Dtime: 0x36b54c3b -- mon Feb 1 14:39:55 1999
Blocks:
147740 147741 147742 147743 147744 147745 147746 147747 147748 147769
147770 157642 157643 157644 157645 157646 157647 157648 157649 157650
157651 157652 157653 157654 157655 157656 157657 157658 157659 157660
157661 157662 157663 157664 157665 157666 157667 157668 157669 157670
157671 157672 157673 157674 157675 157676 157677 157678 157679 157680
157681 157682 157683 157684 157685 157686 1 ...................
...... 9745 159746 159747 159748 159749 159750 159751 159752 159753
159754 159755 159756
Total: 2126

It's perfect !! This means that in the kernel-2.2.X environment, we don't have to assume that all blocks are
Continuous, and all cut blocks can be retrieved percent! Therefore, the second risk does not exist.

The above information is for your reference.

References: Ext2fs-Undeletion mini howto