I recently found myself in a tough situation when I accidentally typed rm * <dir_name>/ as opposed to rm <dir_name>/* , deleting the current project I was working on. Having instantly realized my mistake, I quickly unmounted my drive and powered down the machine I was working on. As I frantically searched the net for some way to undo what I had just done, it seemed as though my month’s hard work was slipping further and further down the drain. Almost every post and response I found seemed to point towards the horrible truth that I might have to rebuild my entire project from scratch. This, of course, was not a suitable solution.

So why can’t I use normal undelete tools like the ones available for ext2?

According to the many posts I found on this topic, undelete is not possible because ext3 incorporates journaling which in turn zeros out the disk’s block pointers during the rm process. The only solution proposed was the use of the ‘grep’ command to search for the missing data. This isn’t exactly ideal because I need to know at least something about all the code I was recovering to find it all. Luckily, I found a blog post by Curtis Summers who came to the same conclusion and was able to suggest a better solution.

A rethink of the problem led me to the ‘strings’ program, which extracts text from files, stdin, or even a disk device. I dumped all text from the disk partition to a text file like so:

#strings /dev/sda7 > /path/to/big_text_file

This worked much better and was much easier than using ‘grep’. Unfortunately, the strings program outputs a raw dump of all the text it finds and doesn’t seem to follow filesystem pointers I guess, because the text came back was in chunks spread throughout the output file it created. Since I didn’t have the time to go through and piece all the bits of code together, I decided to continue searching for more viable option. After running the shareware tool ‘Quick Recovery’ which claimed could undelete data from the ext3 filesystem, I stumbled upon Brian Carrier’s Why Recovering a Deleted Ext3 File Is Difficult… article. This article explains two approaches to data recovery: “File Carving Recovery” which uses application type of the deleted file and “Journal-Based Recovery” which uses the filesystem journal.

I decided to go the File Carving approach and while I could not get the configuration for foremost working properly, since I had limited time to correct my mistake, I was still able to fully recover my entire project. The techniques outlined in the article for locating and extracting raw blocks of data on the disk gave me similar output to Curtis Summers ‘strings’ approach, but the text I found was much more contiguous and required very minimal puzzle solving on my part. I must tip my hat to Brian for creating this very helpful and I am sure needed how-to guide.

Moral of the story: always make sure you have backups… preferably in different directories and/or on different partitions.