A local manager had a problem with the file system, panic'ed, L1-A
and rebooted *multi-user* the system. Fsck cleaned up the file
system and on reboot a couple of important directories turned out
to be missing. He doesn't seem to have any lost+found directory at
all, so no hope of discovering missing files there and NO backups !@#!@
He's running 4.1.1 on a sun4.

Any hint on how to recover files/directories/blocks from a
raw disk? It seems a safe guess to say that nobody had time to actually
overwrite any files in the disk before I umounted that partition. Any
and all help will be welcomed,
----- End Included Message -----

Well most people who replied either said that there was no hope
or that we would have to pay $$$ to a consultant. However, there
is a potential way of recovering some if not most files with a lot
of work. The first thing to do is to go down single-user and mount
the partition read-only. Now the trick is to use the raw device
to find strings that occurs in the missing files. Grep -b is good
for this.

Personnaly, I would start by going over the list of used blocks
and zero them out (probably a backup first would be a good thing :-).
Then go over the list of free blocks looking for blocks that belong
to your missing files. Normaly all blocks from a single file tend
to be together. I don't know exactly what it means to be "together":
spatialy or linearly? My guess is that all the missing file's blocks
are together at the beginning (or end?) of the free list narrowing
down the search considerably.

I assume that if one know enough about inodes and the BSD file
system that it would be possible to recover part or all the information
from a directory inode/block.

And for those that still don't know, Norton's utilities are
totaly useless for this case, there undelete tool relies on using
their special remove tool which only moves the file(s) to a
special name or special directory (something like that).

I posted a letter earlier this week asking if anyone knew of a utility
to restore deleted files. I got back 14 replies. Many people suggested
looking into Norton Utilities for the Sun. The author of the first
letter below gives a review of it. He is not impressed. Another letter
suggested a utility called Buttsaver. I have not looked into it
yet, their address is listed in the letter below. Several of the replys
authoritativly stated that nothing could be done. Barry Shein sent a
letter saying he is doing it now. He also mentioned that it is a
major pain and he charges $150/hour. Barry, I think you should
consider upping your rate. ;-)

Thamks for all the replies,
Sid

====================================================================

Sorry, but you are out of luck.

DOS UnDelete programs take advantage of the unoptomized DOS file
system and the single-tasking nature of DOS. When you delete a file
under DOS, the space typically isn't reused until sometime later.
Also, it is easy to completely stop any modifications to the
filesystem, because there is only one program running.

In contrast to this, U*IX thinks that a good place to put a file is in
the free space nearest to where the drive head is physically
positioned (an oversimplification). This makes for a fast filesystem.
However, there are typically another hundred processes running at any
given time that may want to write to files, and thereby write over the
spot where your deleted file data was.

-----

There is a Norton Utilities for U*IX, but it's overpriced misleading
garbage. The review I saw in Byte described several different
programs, which I will mercilessly pick apart:

"Super block editor" - allows unsophisticated users to
completely scramble the important parameters of their
filesystems beyond any wild hope of recovery.

The only parameters that can be changed without completely
regenerating the filesystem from scratch are tweakable by the program
"tunefs" that already exists on your system. Any other parameters
need to be specified at build time, and may be given to the program
"mkfs" that already exists on your system.

"Norton Batch Enhancer" - allows bored users to put
highlighting, cursor positioning, and other bells and whistles
into their scripts in a terminal-independent way.

This program already exists on your system, and it is called "tput".

"Norton UnDelete" - allows files that have been deleted by the
user at the command line after the time that Norton UnDelete
has been installed, to be retrieved.

This isn't a general undelete-from-disk program. What this program
gives you is a replacement for the "rm" command that moves the file to
a hidden directory instead of actually deleting it. The "undelete"
program just mv's the file back out where it's visible. Note that
files deleted from within other programs are still unretrievable.
This sort of functionality can be programmed in a couple ten-line
scripts, or I can mail you the C source and man pages for a few
programs called "delete", "undelete", and "purge" that do exactly what
I've described.

Unless you had that disk turned off line as soon
as the damage was done, it's probably hopeless.
The information will be scattered all over the disk with
absolutely no pointers to it because they'll have been
replaced by pointers to new material as the inodes
were recycled. If the disk was bagged soon enuf,
there are services that can recover the data.
I don't know anyone who's doing it or has had it
done -- I seem to recall that James Joyce's UNIX
Bookstore in San Francisco had some involvement with
this, but I could be confused. Good luck.

==========================================================================
I can't answer the question you asked, but I'd certainly install
MIT's undelete program (it's in an old archive of comp.sources.unix). It
basically, makes rm a 2 step process, so you can recover from these types
of things. I forced some of my users to start using it, because I was
tired of restoring their files ;-)

If you haven't done anything else on the filesystem you might be able to
use "Buttsaver" by "Lone Star Computer." The most recent reference I
have to it is "The Programmer's Shop/Unix Catalog," a distributor at
800-544-8732 or 617-740-2510; Lone Star seems to be in Maryland
at 800-525-UNIX (Mt Airy, MD).

Right this moment I am working on the same exact problem for a client
and slowly developing utilities. The big problem is the definition of
"recover". You generally cannot recover exactly what was there,
particularly the directory structure as that's exactly what is mostly
gone even if the data is 99% intact. However, you can do better than
nothing on guessing the structure by the disk locations of where you
found files, say grouping files together, the Sun (and BSD in general)
file system is pretty good on locality of creation on the disk.

Needless to say this is not my idea of a walk in the park, I charge
real money to tackle these problems and will expect something even if
it's deemed a hopeless case (since it even takes a few hours work to
be able to give that diagnosis, but cost has to be based on my time,
not results, primarily, I have no idea if I'm being handed an,
effectively, zero'd disk.) But it won't cost much if it looks
hopeless, I can usually determine that in a couple of hours work at
$150/hour.

I'm also happy to pull back as much as I can and then let the client
sort the mess out (they're usually better able to anyhow as they know
what was in the files and how the directories might have been arranged
etc.) The less I do, the less I charge. I'm happy to get back to my
newsgroup posting...

I'll also say at the outset that files which can be typified (e.g.
ASCII text, files created by certain software packages) are much
easier to recover than, say, random binaries, as at some point one
usually has all these blocks, some of which obviously go together with
each other, some, who knows, etc. Kind of a jigsaw puzzle dropped on
the floor.

But there's no real magic, ie. something which can just run over the
disk image and put it all back together, there are some hints around
for the detective work, and I've been developing some tools to speed
up that process a lot.

Usually without hope. DON'T mount the disk, and use dd to search
trough it (as I said, without hope..).
A good lesson perhaps: who is letting people use computers
without automatic backup systems? It is very unfortunate that
every site has to learn this the hard way...

The last time I needed to do this, I dd'ed the entire raw filesystem
onto another disk - as soon as possible after the incident, so that
new files don't get allocated and potentially overwrite the remains
of the deleted files. Then, split the result up into 8K blocks, and grep
for strings that occur in the missing files. At the time, a given file
occurred as a series of 8K blocks, in general taking up alternate blocks
in the filesystem, so once I found a "hit" I'd search for blocks nearby
to see if they were part of the file, too.
The final portion of a file is a set of 1K blocks.
The new extent-based filesystem may well allocate things differently;
I haven't had to do this in awhile.

There should be a directory called "lost+found" on the disk partition. With
any luck, the missing directories/files should be out there. The names will
probably look something like #12345 where '12345' is the inode number.

]] A few others also mentionned lost+found, in this case it is one
]] of the first thing I checked, but the lost+found directory was missing,
]] I suspect that the manager removed it one day of cleaning up!

1) dd the raw disk and run STRINGS on it collecting the output to a BIG file.
2) split the BIG file into small enough files that you can cope with
(say 1 meg each)
3) use grep to find the parts that have what you need.
4) cut and paste
----- End Included Message -----

I found this on the net quite a while ago. I kept it for future reference.
Fortunately I've never needed the information. Perhaps if you require more
details, you could e-mail to the author: Ed Sanborn. Hope it helps.

Sandra Scott INTERNET: scott@vela.astro.utoronto.ca
Dept. of Astronomy
University of Toronto
Toronto, Canada M5S 1A7
>
>Forwarded message:
>>Date: Mon, 15 Apr 1991 12:18:30 -0400
>>From: Ed Sanborn <esanborn@cadence.com>
>>Subject: SUMMARY: Recovery after rm *'ing.
>>
>> 1. After discovering that you've rm'd some number of files take the
>>machine the disk is on off the network.
>>
>> 2. Take steps to insure that files aren't being created as this runs the
>>risk of overwriting your data. The data is still out there on the disk.
>>As long as the files aren't too big and/or too fragmented you'll be able to
>>recover most of your data if conditions under #3 are met.
>>
>> 3. You will need to come up with unique strings within your files that will
>>be able to be searched for and hopefully won't be found in a zillion other
>>files on the disk. Something like the procedure name or module name, etc.
>>
>> 4. The idea is to use "dd" and the raw partition "rsd0g", for example, to
>>scan the disk and search for occurences of the string. A buffer is kept of
>>a set buffer size and blocks of data are saved in files before and after the
>>occurence. One very rough idea is below. You will need to customize it to
>>suit your needs. This one will work well for medium size files 30k to 60k or
>>so. If the file isn't fragmented you should recover alot. The files created
>>by the captured data should be created on another partition obviously.
>>
>>Please let me know if you are interested in a copy of the program used.
>>
>>Take care,
>>
>> Ed
----- End Included Message -----