e2undel -d device -s path [-a] [-t]
e2undel (C) Oliver Diedrich email@example.com; file type functionality from the file(1) program, (C) (1987) Ian F. Darwin
Read this entire section before continuing! This section contains the usage description, for a more technical overview see the NOTES section. Please have a look at the SETUP section if you want to use the ``recover deleted files by name'' feature or if you want to give users other than root the ability to undelete.
e2undel searches all inodes marked as deleted on a file system and lists them assorted by owner and time of deletion. Additionally, it gives you the file size and tries to determine the file type in the way file(1) does. If you did not just delete a whole bunch of files with a 'rm -r *', this information should be helpful to find out which of the deleted files you would like to recover.
e2undel does not actually undelete a file (i.e., does not manipulate ext2 internal structures like inode, block bitmap, and inode bitmap). Instead it recovers the data of a deleted file and saves it in a new file.
The following general rules should be kept in mind when undeleting files:
e2undel accepts the following parameters:
Deleted files are displayed in a table user name by deletion interval. The deletion intervals are less than 12 hours/48 hours/one week/one month/one year, with for example ``one month'' meaning ``older than one week, but less than one month ago''. After selecting a user and a time interval, a list of matching files is displayed with inode number, owner, deletion date, and name. If you used the -a and the -t options, deleted files not found in the log file are displayed with their file type instead of name, starting with a '*' (to have a visual difference between file names and file types). Files printed in red are partially overwritten. Enter the inode of a file to recover. Its data is stored in the directory given with the -s option. If the name of the file is known, it will by used for the name of the recovered file, replacing all "/" in its path by "_". If the name is not known, the name will be built from the inode number and -- if available -- its file type in the way ``inode-xxx-file_type''.
e2undel -d /dev/hdb2 -s /tmp
tries to restore deleted files on /dev/hdb2 and saves them in /tmp. Deleted files with no name entry in the log file are ignored.
As soon as you realize you lost data, unmount the partition as soon as possible.
Included in the e2undel package is the undel library. This package is currently not build for Debian/GNU Linux. This library, loaded by the $LD_PRELOAD mechanism, hooks into the system calls unlink(2) and remove(3). libundel logs the device (like /dev/hdb7 etc.), the inode number, and the name of each file that is deleted by these system calls in a log file (/var/e2undel/e2undel by default). With this information, it is possible to recover deleted files by name. Of course, e2undel also works without the undel library (as outlined above), but you lose the functionality to recover deleted files by name if you don't use libundel -- maybe the best part of this tool.
First, if you want to use the ``recover deleted files by name'' feature, you need read access to libundel's log file /var/e2undel/e2undel (and, of course, the undelete library must be installed). When following the installation instructions, read access to the libundel log is granted only for root. If ordinary users are allowed to use e2undel, you must change the rights of the libundel log file accordingly (but read the SECURITY section first !). Of course, you can only recover files by name that were deleted after installing the undelete library. Other deleted files, however, are displayed when using the -a option.
Second, you need read access to the raw file system device (like /dev/hdb3 or /dev/sda9). Most distributions grant read access to file system devices only to root and to a special group (called "disk" on Red Hat systems, for example). If other users are allowed to use e2undel, you either have to change the access rights of the device or must add these users to the raw disk access group but first see the SECURITY section below.
/var/log/e2undel: Each process on the system requires write access to this file. You might consider this before using the undel library on a real multi user system.
If you give all users read access to the log (needed to use e2undel), every user can access each deleted file. Access rights and owner of deleted files are ignored. This can be considered a problem in a multi user environment. This also holds true if every user has read access to the file system device files. You can't have the one without the other: If a user can recover deleted files on a file system, he can read all data on this file system. Even without e2undel, a simple
reads the complete file system.
If you delete a file stored on an ext2 file system, its data is not instantly lost. What happens is:
So, the file's data is not actually deleted (but it might be overwritten in the future); and the crucial information in the inode (owner, access rights, size, data blocks occupied by the file and some more) is not touched. If you know the inode number, you can recover the file by using Ted Ts'o's debugfs(8) tool.
What is lost however is the association between the file name and the inode: You can't restore the former file name from the inode information. To recover the data of a deleted file, you must completely rely on the information in the inode like file size, owner, deletion time, etc. ext3 behaves different from ext2 in one regard: When a file is deleted, the information in the inode is also removed. Tools like e2undel (or Ted T'so's debugfs(8)) that rely on this information when undeleting files don't work anymore.
Files that were overwritten by mv(1) and friends can't be recovered.
Processes that create and delete a lot of temporary files can flood the log file with senseless information. The /tmp directory might be concerned, but also other directories like the user's Netscape cache directories. In order to avoid these confusing entries, it might be useful to shift these directories on an own file system.
This man page was written by Helge Kreutzmann firstname.lastname@example.org and later improved by Chris Niekel for the Debian GNU/Linux project but may be used by others.
debugfs(8), compactlog(8), file(1), /usr/share/doc/e2undel/recovery-howto.html, (link to URL http://e2undel.sourceforge.net/recovery-howto.html)