[comp.unix.wizards] UNdeleting files

peram@cs.tamu.edu (Suresh B Peram) (07/27/90)

Hi,


   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.

   Any help will be greatly appreciated.

Suresh

jik@athena.mit.edu (Jonathan I. Kamens) (07/27/90)

In article <6905@helios.TAMU.EDU>, peram@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@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710

peram@cs.tamu.edu (Suresh B Peram) (07/30/90)

Hi,

   I have lost files on one of the disks and would
   like to follow the i-nodes to recover them, since
   they are very large (some > 1M) and valuable.

   The files were lost when a shell-script having
   "rm -r" was accidentally executed.  The disk was
   immediatly (within 5 mts) unmounted and the contents
   have since been unchanged.

   I have the i-node numbers of these files from a
   2-month old backup.

   Operating system : Sun OS 4.0.3 (BSD 4.2)
   Machine          : Sun 3

   I would like the steps involved in recovering
   these files.  Your help is greatly appreciated.

Suresh

decot@hpisod2.HP.COM (Dave Decot) (08/01/90)

>    I have lost files on one of the disks and would
>    like to follow the i-nodes to recover them, since
>    they are very large (some > 1M) and valuable.
> 
>    The files were lost when a shell-script having
>    "rm -r" was accidentally executed.  The disk was
>    immediatly (within 5 mts) unmounted and the contents
>    have since been unchanged.
> 
>    I have the i-node numbers of these files from a
>    2-month old backup.
> 
>    Operating system : Sun OS 4.0.3 (BSD 4.2)
>    Machine          : Sun 3

Read the man page for fsdb(8) (or fsdb(1M)) carefully, and then practice
removing and then restoring some other unneeded large file.

This should enable you to restore the file, if it wasn't obliterated
during the "5 mts".

Dave Decot

als@roxanne.mlb.semi.harris.com (Alan Sparks) (08/02/90)

In article <14020106@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes:

>Read the man page for fsdb(8) (or fsdb(1M)) carefully, and then practice
>removing and then restoring some other unneeded large file.
>

What's fsdb?  Filesystem debug? I run SunOS 4.0.3, and I've never seen it.  
Command not found, no man page, etc.  What machine, HP?

-Alan