----- Begin Included Message -----
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).
Here's a list of some of the answers I got:
----- Begin Included Message -----
From: kevin@fourx.Aus.Sun.COM@kalli.UUCP (Kevin Sheehan {Consulting Poster Child})
Yes, either contact Sun Consulting and see if they did anything with
the disk tools I left behind, or write a quick program to do thru
the free list and look for directory entries...
l & h,
kev
----- End Included Message -----
----- Begin Included Message -----
From: keves@meaddata.com (Brian Keves - Consultant)
This is from an earlier sun-managers query.
Brian
-- Brian Keves | Opinions/Ideas presented | Mead Data Central P.O. Box 149 | here are not necessarily | Engineering Productivity Miamisburg, OH 45343-0149 | those of Mead or Mead | keves@meaddata.com (513) 865-1121 x5767 | Data Central | ...!uunet!meaddata!keves -- From: Sid Stuart <sid@Think.COM>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.
Brian Bartholomew UUCP: ...gatech!uflorida!reef.cis.ufl.edu!bb University of Florida Internet: bb@math.ufl.edu
========================================================================
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 ;-)
Good luck, Michael lamour@mitre.org
============================================================================= ============================================================================
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).
webber@world.std.com (Robert D Webber)
============================================================================
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.
Feel free to call me if I can be of assistance, 617-739-0202.
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
----- End Included Message -----
----- Begin Included Message -----
From: geertj@ica.philips.nl (Geert Jan de Groot)
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...
Good luck, Geert Jan
----- End Included Message -----
----- Begin Included Message -----
From: mp@allegra.att.com (Mark Plotnick)
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.
----- End Included Message ----- ----- Begin Included Message -----
From: kwthomas@nsslsun.nssl.uoknor.edu (Kevin W. Thomas)
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.
Kevin W. Thomas National Severe Storms Laboratory Norman, Oklahoma ----- End Included Message -----
]] 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!
----- Begin Included Message -----
From: Russell Brand <brand@lll-winken.llnl.gov@wuthel.UUCP>
presuming the files that you seek are ascii....
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 -----
----- Begin Included Message -----
From: Sandra Scott <scott@vela.astro.utoronto.ca>
Alain,
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 -----
Thanks also to
From: aldrich@sunrise.stanford.edu (Jeff Aldrich) From: gerry@jtsv16.jts.com (G. Roderick Singleton ) From: eeimkey@eeiua.ericsson.se (Martin Kelly) Ray Brownrigg ray@isor.vuw.ac.nz From: birger@vest.sdata.no ( Birger Wathne) From: macphed@dvinci.usask.ca (Ian MacPhedran) From: ajs6143@eerpf001.boeing.com ( Andy J. Stefancik (206) 234-3049 ) From: vsh@uunet.UU.NET@etnibsd.UUCP (Steve Harris) From: Ian Daniel <Daniel@europarc.xerox.com> From: zjat02@trc.amoco.com (Jon A. Tankersley) From: Brendan Kehoe <brendan@cs.widener.edu>
Alain Brossard, Ecole Polytechnique Federale de Lausanne, SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse, +41 21 693-2211 brossard@sic.epfl.ch
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:21 CDT