This article assumes that you have a basic understanding of ext3 and the inner workings of filesystems. It is important to note that there is a certain amount of risk associated with this process. When performed improperly, the data you are attempting to recover, or other data stored on the system, could be permanently lost. While this technique is quite accurate most of the time, and very useful in any number of different situations, it is not "forensically sound" and will not hold up legally for use in court. Special software, hardware, and procedures -- or professional services -- are a must in situations when legal action is required.

The tools used in this article are freely available and can be downloaded from their respective websites.

The basic recovery process

In this section we will go step-by-step through the data recovery process and describe the tools, and their options, in detail. We start by listing a directory below.

In the listing above we can see that there is a file named weimaraner1.jpg in the test directory. This is a picture of my dog. I don't want to delete it. I like my dog.

Here we can see I am deleting it. Whoops! Sorry buddy. Let's gather some basic information about the system so we can begin the recovery process.

Here we see that the full path to the test directory (which is /home/abe/test) is part of the / filesystem, represented by the device file /dev/sda2.

Using su to gain root access, we can start the debugfs program giving it the target of /dev/sda2. The debugfs program is an interactive file system debugger that is installed by default with most common Linux distributions. This program is used to manually examine and change the state of a filesystem. In our situation, we're going to use this program to determine the inode which stored information about the deleted file and to what block group the deleted file belonged.

After debugfs starts, we cd into /home/abe/test and run the ls -d command. This command shows us all deleted entries in the current directory. The output shows us that we have one deleted entry and that its inode number is 1835328 -- that is, the number between the angular brackets.

The next command we want to run is imap, giving it the inode number above so we can determine to which block group the file belonged. We see by the output that it belonged to block group 56.

Running the stats command will generate a lot of output. The only data we are interested in from this list, however, is the number of blocks per group. In this case, and most cases, it’s 32768. Now we have enough data to be able to determine the specific set of blocks in which the data resided. We're done with debugfs now, so we type q to quit.