|
Note: If you just want to recover a recently deleted file, the deleted file recovery howto might be just what you're looking for. After having recovered this file, come back and read on to understand what else e2undel can do for you.
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 simply can recover the file by using Ted Ts'o's debugfs 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.
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. After selecting a deleted file, e2undel assembles its data by reading the data blocks (whose numbers are still stored in the inode), and writes the data to a new file.
Inluded in the package is the undel library. 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 in the deleted file recovery howto), but you lose the functionality to recover deleted files by name if you don't use libundel - maybe the best part of this tool.
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.
In general, ext2 and ext3 are compatible file systems: You can mount an ext3 fs as ext2 and even use the ext2 low level utilities like debugfs. However, ext3 behaves in a different manner in one crucial point: If a file is deleted, its inode data are removed, too. Especially, the list of data blocks is lost; so it is not possible to recover any deleted file.
See the installation instructions.
You can build e2undel in two different versions by issuing either a make e2undel-file or a make e2undel. The latter one does not contain the code for file type determination, reducing the file size of the binary from more than 200 to about 80 kByte. This can be interesting if you want to include the tool on a space limited rescue floppy. In this case, however, you might consider linking the ext2fs library statically to the binary. If you don't understand what I'm talking about, a make e2undel-file is probably what you want.
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 undel 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 see the security notes later in this file). Of course, you can only recover files by name that were deleted after installing e2undel. 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 file or must add these users to the raw disk access group. See the security notes below.
e2undel is started by
e2undel -d device -s path [-a] [-t]with
e2undel -d /dev/hdb2 -s /tmptries to restore deleted files on /dev/hdb2 and saves them in /tmp. Deleted files with no name entry in the log file are ignored.
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".
user name | 1 <12 h | 2 <48 h | 3 <7 d | 4 <30 d | 5 <1 y | 6 older
-------------+---------+---------+---------+---------+---------+--------
foo | 2 | 72 | 33 | 11 | 384 | 0
bar | 0 | 83 | 48 | 35 | 114 | 0
Select user name from table or press enter to exit:
After selecting a user and a time interval (e.g., "foo" and "4"), 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.
inode size deleted at name ----------------------------------------------------------- 9041 170 Nov 16 17:23 2001 /home/foo/.netscape/cache/19/cache3BA36B790500577.htm 9042 1100 Nov 16 17:23 2001 /home/foo/.netscape/cache/1A/cache3BA36B7A0510577.htm 9051 25560 Nov 16 17:23 2001 /home/foo/.netscape/cache/05/cache3BA36CE508F0577.gif 111354 12962 Nov 13 23:58 2001 /home/foo/texte/ext2.txt 216271 23072 Nov 18 21:20 2001 /home/foo/ext2/e2undel-0.73/e2undel-file.o 216272 31040 Nov 18 21:21 2001 /home/foo/ext2/e2undel-0.73/find_del.o 216273 35444 Nov 18 21:23 2001 /home/foo/ext2/e2undel-0.73/log.o 216275 32820 Nov 18 21:23 2001 /home/foo/ext2/e2undel-0.73/ascmagic.o 216276 22508 Nov 18 21:23 2001 /home/foo/ext2/e2undel-0.73/is_tar.o 216277 32792 Nov 18 21:23 2001 /home/foo/ext2/e2undel-0.73/softmagic.o 216279 3968 Nov 19 23:34 2001 /home/foo/ext2/e2undel-0.73/profile.e2undelEnter 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 to build 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". For an example of using e2undel without the undel library, see the deleted file recovery howto.
To explore the content of the log file,
e2undel -llists all non-redundant entries in the libundel log file, sorted by file systems. Redundant entries can exist after using the undel library for some time if several files were stored and deleted on the same inode. You can use the included tool compactlog to remove these redundant entries if the log file grows too heavy. compactlog -? gives a short useage information.
libundel: The undel library uses standard mechanisms provided by the glibc to hook into the system calls. On several systems, there were no problems using the library. However, I did not test it on a heavily loaded server.
e2undel: The program does not manipulate any internal ext2 structures, requires only read access to the devices it works on, and uses Ted Ts'o's ext2fs library for all ext2 low level operations. I never observed any damage to a file system treated with e2undel.
/var/log/e2undel: Each process on the system requires write access to this file. You might consider 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 'dd /dev/xxx' reads the complete file system.
libundel only works reliably if each process uses the library. Problems arise from programs started by scripts that overwrite the $LD_PRELOAD variable (like Netscape does on some distributions); from processes that are started by init scripts (i.e., before $LD_PRELOAD is set); by using "su" without a user name. The effect is always the same: Not all deleted files are logged which might lead to confusion.
For example: A process using libundel deletes a file: inode and name are logged in /var/e2undel/e2undel. A new file is stored on this inode and deleted by a process that does not use the undel library. e2undel now finds this inode deleted, finds the (older) entry in the libundel log, and concludes that both belong together. When recovering the file, however, the recent information of the deleted inode will be restored - the data of the newer file is recovered under the name of the older one. This can be somewhat confusing.
Files that were overwritten by 'mv' 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; so they are not displayed when trying to recover files on other file systems.
e2undel is useable only with Linux and the ext2 file system. It is only tested on the Intel IA32 platform.