This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Tools & Utilities

For those "oops" moments: ext3undel

By Kurt Edelbrock on July 10, 2008 (4:00:00 PM)

Share    Print    Comments   

The rm command can be a powerful tool for deleting data -- until you delete the wrong files or directories. Thankfully, the ext3undel utility can recover accidently removed data on ext3 filesystems. Users can recover a specific file by name, or they can restore all files marked as deleted (though the filenames won't be recovers, so they will have to look at the contents of the files to identify them).

Files on the ext3 filesystem have two parts. The file's metadata -- that is, the file name, size, and creation and access dates -- is stored in a Unix data structure called an inode. The actual file data is stored in blocks on the hard drive. Deleting a file destroys the link between the metadata and the filesystem blocks, eliminating the association between the file's information and content. Both the inodes and the data blocks are marked as free, and the operating system will use them to write new data when it needs to. But because the inodes and blocks are merely marked free and aren't overwritten, users can rescue data as long as new data hasn't been written there. That's why it is important to recover data to a new partition: any changes to the filesystem risk overwriting data users wish to recover. Until then, an application can "save" deleted data by marking the blocks as in use, and reconnecting the inodes and the blocks symbolically.

This is actually a complicated process, and ext3undel doesn't provide the core functionality for taking care of this. Instead, it is a wrapper for a few other applications that do the heavy lifting. ext3undel provides two different commands: gabi (get all back immediately), and ralf (recover a lost file).

Gabi relies on two recovery programs called Photorec and Foremost to get everything back. The advantage of using ext3undel over these programs is time: by using an automated process and avoiding configuration, you have a better chance of the file not being overwritten by new data. The gabi command asks you what partition you want to recover, what partition to use to store the recovered files, and what specific file types (or all file types) Photorec should focus on. Photorec will then scan the free blocks of your hard drive for "signatures" -- proof that a file once lived in that block. This process could take a long time for a big hard drive. Because the inode data cannot be recovered, you must sort the recovered files by hand to find specifically what you are looking for.

The ralf command uses forensic software called SleuthKit to recover a specific file. Basically, ralf uses SleuthKit to find the inode you're looking for. Then, it asks the filesystem for a list of the blocks that were once associated with the inode. Finally, SleuthKit stores the data to an image, which is then processed by Photorec (instead of the entire hard drive, as with gabi). This could recover more than just the file you specify. As with gabi, you need to sort through the recovered files to find the right one.

I tested the ext3undel wrapper in an updated version of Ubuntu 8.04 Server Edition in VMware by creating three different text files and a JPEG image file and deleting them with the rm command. I was able to recover the files without much hassle using both the gabi and ralf. Because this was a fresh install, I didn't have too many files to sort through (though it was interesting to see what the maker of the virtual appliance deleted before it was released).

You can download the latest version of ext3undel from the developer Web site. It is distributed in a .tar file, as well as in prebuilt .deb and .rpm packages. You must also install the dependencies -- Photorec, Sleuthkit, and Foremost. These are available in the repositories for most distributions.

ext3undel offers a great set of tools that recover data as efficiently as possible. But don't be cocky when it comes to your data; it's still necessary to make regular backups, because there are times when data can't be saved, even if you use ext3undel right after the data is deleted. If the deleted file is fragmented, the tools will be able to find only the first fragment. ext3undel also can't save data from corrupted or broken hard drives. But in the end, this tool is a great tool for emergency situations, and can minimize damage from accidents and mistakes.

Kurt Edelbrock is a technology journalist, blogger, and university student. He writes for a variety of open source publications, and serves as a technical consultant for a large public university.

Share    Print    Comments   

Comments

on For those "oops" moments: ext3undel

Note: Comments are owned by the poster. We are not responsible for their content.

For those "oops" moments: ext3undel

Posted by: Anonymous [ip: 88.76.40.33] on July 10, 2008 06:56 PM
If you're interested in ext3 file recovery you maybe want to have a look at http://code.google.com/p/ext3grep/ and http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html

#

Re: For those

Posted by: Anonymous [ip: 84.203.137.218] on July 16, 2008 11:07 AM
I tried ext3grep but it just crashed on me, so I reverted to standard grep to find my delete file:
http://www.pixelbeat.org/docs/disk_grep.html

#

For those "oops" moments: ext3undel

Posted by: Bob Mitchell on July 10, 2008 11:04 PM
Any indication of mainstream distro (or even 3rd-party repository) interest in it yet? (not that it's *that* much of a big deal to install an RPM manually)

#

For those "oops" moments: ext3undel

Posted by: Anonymous [ip: 63.231.83.119] on July 11, 2008 10:31 PM
Boy, I could've used that in college (circa 2003 I guess). I remember a particularly horrific homework assignment in which we coded a TCP implementation in C, including window scaling and congestion control. I was very nearly finished with the project, and did something like %rm -rf * ~ to delete the vi backup files - note the space! What a dummy. I spent most of the night trying to recover the data, unmounting the file system and doing string searches. Bleh.

#

For those "oops" moments: ext3undel

Posted by: Anonymous [ip: 72.40.18.176] on July 13, 2008 09:22 PM
That reminds me of my first major "OOPS" moment... I accidentally deleted a bunch of directories as root. I went online, searched for "root undelete", and found the following comment from someone:

1. Linux is Unix.
2. On Unix, 'root' is God.
3. God is perfect and incapable of making mistakes.
THEREFORE, if God deleted some files, He obviously intended for them to remain deleted.

:D

#

For those "oops" moments: ext3undel

Posted by: Anonymous [ip: 68.43.223.95] on July 14, 2008 04:23 AM
Midnight Commander (http://www.ibiblio.org/mc/) also has provisions for recovering deleted files on an
ext2/3 file system. No dependencies beyond the standard e2fsprogs libraries are needed. Furthermore,
the recovered blocks can be browsed within MC using the built-in file viewer and also copied directly
to another location. MC makes recovery simple, and as long as the file system has not been extensively
rewritten, there is a very good chance of complete recovery.

#

For those "oops" moments: ext3undel

Posted by: Anonymous [ip: 77.125.77.132] on July 14, 2008 05:27 AM
There is an error in the following sentence: "The file's metadata -- that is, the file name, size, and creation and access dates -- is stored in a Unix data structure called an inode": the file name is stored in a directory (which is also a file), not in the inode.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya