I got the message that the lost data on that partition was created with errors
in the code. So everything has to be recalculated and almost nothing is lost.
Thanks to all persons trying to help:
Scott Ruffner <jpr9c_at_cs.virginia.edu>
"Lars Bro" <lbr_at_nettest.dk>
alan_at_nabeth.cxo.dec.com
Lars and Scott suggested to use alternate superblocks:
"Run "newfs -N" with the same parameters you used in creating the original
file system, then you can get a list of the alternate superblocks.
At that point, you can run an fsck of the partition using an alternate
superblock:
fsck -b 'alternate superblock'
If you've already newfs'd the partition, these alternate blocks may no
longer be good."
To find out the parameters one can use the command disklabel.
Didn't help in our case, all superblocks had the same opinion about the files:
There are none! :-[
Alan gave me several hints:
"If the inode was cleared as part of the fsck, all you have
left is a jigsaw puzzle of the blocks of the data. [...]
There's a program on gatekeeper.dec.com in /pub/sysadm
called recover (recovery.tar.Z) that may help."
My reply:
"The Inodes are cleared, as far as I can tell. So we are left with a jigsaw
puzzle. The program 'recover' gives me lots of blocks of 1kB."
Then Alan gave me detailed info about how a new file is written to a UFS
partition:
"The minimum file system allocation size is 1 KB (a fragment), which is why
recover uses that. I think it gets the size from the superblock, so it may
handle other fragment sizes reasonably.
On a clean disk space tends to be allocated as follows.
1. A new directory is created in the cylinder with an
above average amount of free space.
2. A new file is create in the same cylinder group as
its parent directory
3. The file system will tend to allocate contiguously
when the space is available. However, it will tend
to put breaks in whenever an indirect block is
allocated; 96 KB and up to 16 MB thereafter.
4. Once a certain number of blocks (usually 16 MB worth)
have been allocated in a particular cylinder group
it will switch to a new one. Of course if the group
isn't big enough it will have switched before then.
You may have a jigsaw puzzle, but it may be a reasonably
well ordered one. How hard it is to put back together
depends on the data."
Our data was gzipped, so I couldnt find out, what belonged together.
Thanks again to Lars, Scott and Alan!
Original Posting:
>During a system crash we lost our root partition (so I installed 4.0D from
>scratch) and a data partition on another harddisk. All are UFS partitions.
>With the new system we did a "fsck -v -o" on the data partition which gave us
>only 1 file, the uppermost directory. Then we did a mklost+found and the fsck
>again - same result. The data is still there, as one can see with dd.
>Question: How can we get the data back? Is there a tool available? One could do
>it perhaps with fsdb, but I think one can only use it interactively. How long
>would it take us for 500MB? :-(
>Any hint is welcome.
+-------------------------------------------------------------------------+
Andreas Vetter
Universitaet Wuerzburg
Institut fuer Theoretische Physik
Theoretische Physik I
Am Hubland
D-97074 Wuerzburg
+-------------------------------------------------------------------------+
Received on Mon Oct 04 1999 - 12:41:14 NZDT