Every once in a while I do something really, really stupid. Like, say, for instance, delete a whole directory of very important code that I'm working on and my last backup is a couple of weeks old (because of a server move and my failure to re-setup my cron backup). How did this happen? Well, for one, I was coding at about 5:30 a.m. before my caffeine had set in, and, secondly, I was rm -rf'ing with tab-completion. Almost instantly after I pressed Enter I realized what I had done. Tragedy. Or so I thought…

In Linux, you can undelete files if you are using the ext2 file system. A very handy tool called debugfs allows you to list files marked as deleted. I'm using the ext3 file system (ext2's successor), so I thought the debugfs solution would work. Unfortunately, ext3 actually zeros out the block pointer (the pointer to the file's data), so reconstructing the file becomes impossible with debugfs.

So, what to do? I had seen some mailing list posts refering to 'grepping' the data from the disk drive. Most everything I lost was code (specifically, Ruby). I attempted to use grep to search my hard disk device (/dev/sda7 in my case), but grep kept erroring out with "memory exhausted" errors. Hrrm.

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

Note: It is probably a good idea to put the big text file on a separate partition. Otherwise, you risk writing over some of your deleted files on the partition you are attempting to recover from.

I was now able to open the big_text_file in vim and recover all of my deleted code by searching for particular code snippets. It's not ideal, but I was able to recover everything. Instead of losing several days worth of work, I only lost a couple of hours.

And, of course, my backup is re-setup.