UNdeleting files

[Jonathan I. Kamens]

In article <6905 at helios.TAMU.EDU>, peram at cs.tamu.edu (Suresh B Peram) writes:
|>    I have lost a whole directory containing
|>    important information while running a shell-script
|>    which deleted it.  We have a SUN OS 4.0.3 here running
|>    on a sparc server.  The entire disk was immediatly
|>    unmounted and has been left unchanged.  I wish to
|>    recover these files as soon as possible.  Does
|>    anybody know the best way to proceed ? Unfortunately,
|>    I do not have the source code  of Unix.

  Two good ways to proceed in the long-term:

1. Use recoverable file-deletion utilities when important data is at
   stake.  For example, the "undel" package written by me in the
   comp.sources.unix archives.

2. Keep regular back-ups of important data.

  Having said that, I'll add the following which is more relevant to the
question immediately at hand:

1. What kind of filesystem were you working on when you deleted the
files
   (e.g. were you working locally on the server and therefore in UFS, or
in
   NFS, or what)?  This is only tangentially relevant, I'd say.

2. Is the filesystem in question a standard SunOS filesystem (And
doesn't
   SunOS use the Berkeley filesystem?  I'm not sure about this.), or is
it
   something odd?

3. How did you unmount the disk?  If you did it with umount or anything
   that uses the unmount system call, it's likely that you forced a
sync
   to the disk before the unmount.  If you did it by crashing the
machine
   (seriously) it's possible that some of the deleting didn't make it
to
   the disk.

4. How quickly is "immediately"?

  I can think of a few ways that you might proceed, but I am somewhat
unsure about whether or not most of them will work (and I'm sure others
will chime in and point out which ones won't):

1. If the disk wasn't sync'd, the files may not actually be deleted, or
they
   may be removed from their directory but not actually removed from the
disk,
   so fsck will reconnect them in /lost+found.  You should be able to
run
   "fsck -n" on the disk fairly safely to check this (but don't quote me
on
   that :-).

2. If the inodes for the files in question haven't been zero'd, and you
know
   the inode numbers, you may be able to read the inode and get the
block
   numbers on the disk, then read those block numbers to get the
contents of
   the files.  However, I'm not really convinced this will work, since
I
   believe that inodes and indirectly referenced block lists (for large
   files) are zero'd immediately when a file is removed.

3. If the inodes are not an option, and the filesystem in question has
a
   free list (rather than, or in addition to, a bitmap table of used
and
   unused blocks), then the blocks from the files which were deleted
were
   probably added to either the end or the beginning of the free list.
   You could check the list and read the blocks at each end of it to
see
   if they are blocks from your files.  I'm also not convinced this
will
   work, since I suspect the filesystem you're using uses a bitmap and
not
   an ordered free list.

4. If that fails, you can dd the raw disk and search through the
resulting
   file for blocks of the files that were lost, and piece them together
as
   well as you can.

  Now I think you see why I started with recommendations on how to
prevent this from happening in the future :-).

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710