e2undel(8)						      System Manager's Manual							e2undel(8)

NAME

       e2undel -- Undelete files on ext2 file systems interactively

SYNOPSIS

       e2undel -d device -s path [-a]  [-t]

COPYRIGHT

       e2undel (C) Oliver Diedrich e2undel@sourceforge.net; file type functionality from the file(1) program, (C) (1987) Ian F. Darwin

DESCRIPTION

       Read  this  entire section before continuing! This section contains the usage description, for a more technical overview see the NOTES sec-
       tion. 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:

	  o  The device from which you want to recover deleted files should not be mounted in order to minimize  the  risk  that  other  processes
	     overwrite data of deleted files.

	  o  If the device is mounted, the directory where you want to save the files should not reside on the same device. If it does, there is a
	     chance the recently restored files overwrite deleted data.

	  o  The sooner as you try to recover a deleted file the higher are chances that you will succeed.

OPTIONS

       e2undel accepts the following parameters:

	-d device
		 the file system where to look for deleted files (e.g.	/dev/hdb1  for the 1st partition on the 2nd IDE drive)

	-s path  the directory where recovered files are saved.

	-a	 work on all files, not only on those listed in undel log file (you need this if you don't use the undel library)

       -t	 try to determine type of deleted files without names, works only with -a.

       -l	 list 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 are stored and deleted on the same inode. You can use the tool compactlog(8) to
		 remove these redundant entries if the log file grows too heavy.

       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''.

EXAMPLE

       An example:

       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.

IMPORTANT

       As soon as you realize you lost data, unmount the partition as soon as possible.

BUGS

	  o  missing pager functionality when displaying the list of deleted files, you need a terminal with a scrollback buffer

	  o  no direct way to recover a file by name

	  o  some minor stuff, see BUGS (on Debian/GNU Linux system this file can be found in /usr/share/doc/e2undel).

SETUP

       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 infor-
       mation, 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.

SECURITY

       /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

       dd /dev/xxx

       reads the complete file system.

NOTES

       If you delete a file stored on an ext2 file system, its data is not instantly lost. What happens is:

	  o  ext2 marks the file's data blocks as available in its block bitmap

	  o  ext2 marks the file's inode as available in its inode bitmap

	  o  ext2 sets the deletion time in the file's inode

	  o  ext2 invalidates the file's name in the directory entry

       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 informa-
       tion.   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.

       libundel  The undelete 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 the library on a heavily loaded server.

		 libundel only works reliable 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(1) without a user name. The effect: 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 in
		 the deleted inode will be restored -- the data of the newer file is recovered under the name of the older one. This can be  some-
		 what confusing.

       e2undel	 The  program  does not manipulate any internal ext2 structures, requires only read access to the device 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.

       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.

AUTHOR

       This man page was written by Helge Kreutzmann kreutzm@itp.uni-hannover.de and later improved by Chris  Niekel   for  the  Debian  GNU/Linux
       project but may be used by others.

SEE ALSO

       debugfs(8), compactlog(8), file(1), /usr/share/doc/e2undel/recovery-howto.html,
	(link to URL http://e2undel.sourceforge.net/recovery-howto.html)

																	e2undel(8)