home *** CD-ROM | disk | FTP | other *** search
/ BURKS 2 / BURKS_AUG97.ISO / BURKS / LINUX / HOWTO / mini / e2fsundl.txt < prev    next >
Text File  |  1997-07-07  |  42KB  |  897 lines
  1.                Ext2fs Undeletion mini-HOWTO
  2.                ****************************
  3.  
  4. by Aaron Crane <aaronc@pobox.com>
  5. v1.0, Sat Jan 18 1997
  6.  
  7. Contents
  8. ========
  9.  
  10. 0.  Introduction
  11. 1.  How *not* to delete files
  12. 2.  What recovery rate can I expect?
  13. 3.  So, how do I undelete a file?
  14. 4.  Unmounting the filesystem
  15. 5.  Preparing to change inodes directly
  16. 6.  Preparing to write data elsewhere
  17. 7.  Finding the deleted inodes
  18. 8.  Obtaining details of the inodes
  19. 9.  Recovering data blocks
  20. 10. Modifying inodes directly
  21. 11. Will this get easier in future?
  22. 12. Are there any tools to automate this process?
  23.  
  24. Appendices
  25. ----------
  26.  
  27. A.  Colophon
  28. B.  Credits
  29. C.  Bibliography
  30. D.  Legalities
  31.  
  32.  
  33. 0.  Introduction
  34. ================
  35.  
  36. This mini-Howto attempts to provide hints on how to retrieve deleted files
  37. from an ext2 filesystem.  There is also a limited amount of discussion of
  38. how to avoid deleting files in the first place.
  39.  
  40. I intend it to be useful certainly for people who have just had, shall we
  41. say, a little accident with `rm'; however, I also hope that people read it
  42. anyway.  You never know -- one day, some of the information in here could
  43. save your bacon.
  44.  
  45. The text assumes a little background knowledge about Unix filesystems in
  46. general; however, I hope that it will be accessible to most Linux users.
  47. If you are an outright beginner, I'm afraid that undeleting files under
  48. Linux *does* require a certain amount of technical knowledge and
  49. persistence, at least for the time being.
  50.  
  51. You will be unable to recover deleted files from an ext2 filesystem without
  52. at least read access to the raw device on which the file was stored.  In
  53. general, this means that you must be root.  You also need `debugfs' from
  54. the `e2fsprogs' package.  This should have been installed by your
  55. distribution.
  56.  
  57. Why have I written this?  It stems largely from my own experiences with a
  58. particularly foolish and disastrous `rm -r' command as root.  I deleted
  59. about 97 JPEG files which I needed and could almost certainly not recover
  60. from other sources.  Using some helpful tips (see Appendix B, `Credits')
  61. and a great deal of persistence, I recovered 91 files undamaged.  I managed
  62. to retrieve at least parts of five of the rest (enough to see what the
  63. picture was in each case).  Only one was undisplayable, and even for this
  64. one, I am fairly sure that no more than 1024 bytes were lost (though
  65. unfortunately from the beginning of the file; given that I know nothing
  66. about the JFIF file format I had done as much as I could).
  67.  
  68. I shall discuss further below what sort of recovery rate you can expect for
  69. deleted files.
  70.  
  71.  
  72. 1.  How *not* to delete files
  73. =============================
  74.  
  75. It is vital to remember that Linux is not MS-DOG.  For MS-DOG (including
  76. Windoze 95), it is generally fairly straightforward to undelete a file --
  77. the `operating system' (I use the term loosely) even comes with a utility
  78. which automates much of the process.  For Linux, this is not the case.
  79.  
  80. So.  Rule number one (the prime directive, if you will) is:
  81.  
  82.      *** KEEP BACKUPS ***
  83.  
  84. no matter what.  I know, I'm a fine one to talk.  I shall merely plead
  85. impoverishment (being a student must have *some* perks) and exhort all
  86. right-thinking Linux users to go out and buy a useful backup device, work
  87. out a decent backup schedule, and to *stick to it*.  For more information
  88. on this, see Frisch (1995).
  89.  
  90. In the absence of backups, what then?  (Or even in the presence of backups:
  91. belt and braces is no bad policy where important data is concerned.)
  92.  
  93. Try to set the permissions for important files to 440 (or less): denying
  94. yourself write access to them means that `rm' requires an explicit
  95. confirmation before deleting.  (I find, however, that if I'm recursively
  96. deleting a directory with `rm -r', I'll interrupt the program on the first
  97. or second confirmation request and reissue the command as `rm -rf'.)
  98.  
  99. A good trick for selected files is to create a hard link to them in a
  100. hidden directory.  I heard a story once about a sysadmin who repeatedly
  101. deleted /etc/passwd by accident (thereby half-destroying the system).  One
  102. of the fixes for this was to do something like the following (as root):
  103.  
  104.     # mkdir /.backup
  105.     # ln /etc/passwd /.backup
  106.  
  107. It requires quite some effort to delete the file contents completely: if
  108. you say
  109.  
  110.     # rm /etc/passwd
  111.  
  112. then
  113.  
  114.     # ln /.backup/passwd /etc
  115.  
  116. will retrieve it.  Of course, this does not help in the event that you
  117. overwrite the file, so keep backups anyway.
  118.  
  119. Some people advocate making `rm' a shell alias or function for `rm -i'
  120. (which asks for confirmation on *every* file you delete).  Personally, I
  121. cannot stand software which won't run unattended, so I don't do that.
  122. There is also the problem that sooner or later, you'll be running in
  123. single-user mode, or using a different shell, or even a different machine,
  124. where your `rm' function doesn't exist.  If you expect to be asked for
  125. confirmation, it is easy to forget where you are and to specify too many
  126. files for deletion.  Likewise, the various scripts and programs that
  127. replace `rm' are, IMHO, very dangerous.
  128.  
  129. A slightly better solution is to start using a package which handles
  130. `recyclable' deletion without using any variant of the `rm' command.  For
  131. details on these, see Peek, et al (1993).
  132.  
  133.  
  134. 2.  What recovery rate can I expect?
  135. ====================================
  136.  
  137. That depends.  Among the problems with recovering files on a high-quality,
  138. multi-tasking, multi-user operating system like Linux is that you never
  139. know when someone wants to write to the disk.  So when the operating system
  140. is told to delete a file, it assumes that the blocks used by that file are
  141. fair game when it wants to allocate space for a new file.  (This is a
  142. specific example of a general principle for Linux: the tools and kernel
  143. assume that the users aren't idiots.)  In general, the more usage your
  144. machine gets, the less likely you are to be able to recover files
  145. successfully.
  146.  
  147. Also, disk fragmentation can affect the ease of recovering files.  If the
  148. partition containing the deleted files is very fragmented, you are unlikely
  149. to be able to read a whole file.
  150.  
  151. If your machine, like mine, is effectively a single-user workstation (mine
  152. doesn't even have a net connection yet; maybe next year), and you weren't
  153. doing anything disk-intensive at the fatal moment of deleting those files,
  154. I would expect a recovery rate in the same ball-park as detailed above.  I
  155. retrieved nearly 94% of the files (and these were binary files, please
  156. note) undamaged.  If you get 80% or better, you can feel pretty pleased
  157. with yourself, I should think.
  158.  
  159.  
  160. 3.  So, how do I undelete a file?
  161. =================================
  162.  
  163. The procedure principally involves finding the data on the raw partition
  164. device and making it visible again to the operating system.  There are
  165. basically two ways of doing this: one is to modify the existing filesystem
  166. such that the deleted inodes have their `deleted' flag removed, and hope
  167. that the data just magically falls back into place.  The other method,
  168. which is safer but slower, is to work out where the data lies in the
  169. partition and write it out into a new file.
  170.  
  171. Sections 4 through 6 detail some steps you need to take before beginning to
  172. attempt your data recovery.  Sections 7 through 10 discuss how to actually
  173. retrieve your files.
  174.  
  175.  
  176. 4.  Unmounting the filesystem
  177. =============================
  178.  
  179. Regardless of which method you choose, the first step is to unmount the
  180. filesystem containing the deleted files.  I strongly discourage any urges
  181. you may have to mess around on a mounted filesystem.  This step should be
  182. performed *as soon as possible* after you realise that the files have been
  183. deleted.
  184.  
  185. The simplest method is as follows: assuming the deleted files were in the
  186. /usr partition, say:
  187.  
  188.     # umount /usr
  189.  
  190. You may, however, want to keep some things in /usr available.  So remount
  191. it read-only:
  192.  
  193.     # mount -o ro,remount /usr
  194.  
  195. If the deleted files were on the root partition, you'll need to add a `-n'
  196. option to prevent mount from trying to write to /etc/mtab:
  197.  
  198.     # mount -n -o ro,remount /
  199.  
  200. Regardless of all this, it is possible that there will be another process
  201. using that filesystem (which will cause the unmount to fa