Home

Recovering deleted files on an ext3 filesystem

Submitted by specialj on Sat, 09/29/2007 - 21:33.

A few weeks back I had my first attempt at recovering files deleted on an ext3 partition. The operation was not trivial but in the end it was successful. I’ll recount a little about what I learned, and share some resources and tips.

So the situation was that I had accidentally erased a file which was recent and had not been backed up. Most of the data it contained had already been emailed so I could have reconstructed the document but still I thought it would be quicker to just undelete the file. Undelete is such a commonly desired feature that it is often well documented how to do it and what tools are available to use. It did not take long to learn that Ext3 did not share this behavior. From the Ext3 FAQ:

Q: How can I recover (undelete) deleted files from my ext3 partition?

Actually, you can’t! This is what one of the developers, Andreas Dilger, said about it:

In order to ensure that ext3 can safely resume an unlink after a crash, it actually zeros out the block pointers in the inode, whereas ext2 just marks these blocks as unused in the block bitmaps and marks the inode as “deleted” and leaves the block pointers alone.

Your only hope is to “grep” for parts of your files that have been deleted and hope for the best.

While I have known people who have actually used grep on the block device for the hard disk I did not find that I had to resort to such a measure. As I searched for information I came across a number of web pages that gave me an idea as to what the steps forward were. But the best read I found was Why Recovering a Deleted Ext3 File Is Difficult. I read through the article completely before beginning. It started easily enough using the program debugfs to show deleted files in a particular directory. The file I wanted to undelete showed up.

I chose to follow the procedure outlined for using file carving to recover the file. It required 3 programs that I did not have installed: fsstat, dls, and foremost. The former 2 are part of an Ubuntu package called sleuthkit; the latter has a package called foremost. I used apt-get to install both, and I would recommend that people have both installed just in case this scenario arises. As with all file undeletion routines it’s important to minimize changes to the filesystem until the files are recovered. In my case, installing these 2 packages did not harm my efforts.

I was able to follow the instructions on how to use debugfs, fsstat, and dls to discover where on the disk the file had been located and back up that section of disk to a file on another device. As stated above, it’s important to backup this data to a separate filesystem to avoid disk changes that may overwrite the location where the file resided prior to deletion. If the disk is overwritten any chance of recovery is lost.

The next step was to scan the backed up data with a most interesting program: foremost. The foremost program scans for file signatures for a number of common files. I wasn’t sure that the openoffice document I was recovering was supported. However, it appears that openoffice uses zip compressed xml files which were recognized by foremost. Upon checking the output directory I had my file, fully recovered. The whole procedure took only about 10-15 minutes, after quite a bit of research (on a different machine of course). Not that this is a procedure I’d care to repeat very often but it was at least a useful skill to learn.

Some tips I took away:

  • Have packages sleuthkit and foremost installed on all computers
  • Have package wipe installed and use it for deleting files that you don’t want to be undeletable.
  • Take care when moving or deleting files, particularly on the command line with mv and rm

Links to more information:

»
Creative Commons License Except where otherwise noted, content on this site is licensed under a Creative Commons by-nc-sa 3.0 License