Hi managers!
Original question:
>
> I'm posting this for a friend without e-mail connectivity.
>
> Apparently today somebody quite new to system administration accidentially
> ran SunInstall (miniroot installation) on a disk somebody else had been
> configuring for a customer of theirs, and, because that system was to go
> out on monday, nobody had cared about doing a backup.
>
> Now, the partition table is still intact. SunInstall "just" installed
> a new file system in the first 6 megs of sd3b, which is approx. 200 meg
> and contains (or contained) /usr2 (the applications). The other partitions
> are all unmodified.
>
> So, instead of repeating the configuration of that /usr2, which would
> take a whole day he tells me, is there a possibility to salvage files
> beyond the first 6 megs? The first thing he did on sd3b was to install
> Sybase, which uses 45 megs for its files. After that, he did the really
> time-consuming configurations and tests. Do SunOS 4.1.3 file systems fill
> from "low" to "high"? Can he salvage his work?
>
> I think a "fsck -b block-#" would be a solution, but naturally nobody
> bothered to write down the superblock backup block numbers that newfs
> reported. Is there a way to find them?
>
> If others are interested, I'll summarize to the list.
>
Hmm... Seems I was relly lazy about RTFM this time... Sorry about that.
Here are the findings:
1. To find the superblock backup block numbers for, say, partition sd3b do
newfs -Nv /dev/rsd3b (as man will tell you)
This will give you the same information that you got at installation time
of the file system in that partition. Thanks guys!
2. My friend decided to re-create manually, as he is quite new to UNIX and
thought it would take to long to identify things in lost+found by hand
after the fsck. So I took the time to simulate the thing:
On a spare partition I have (lucky me, I know) of approx. 200 MB size I
created a new FS and copied lots of things there (approx. 100 MB, Sybase as
the first thing). Then I wrecked it by creating a new one with size 6 MB on
the same partition and copied some files there. Then I found the backup
superblocks of the original (large) FS and did a fsck -b (with the highest
backup superblock number). The whole operation took about 30 min.
What I did:
newfs -v /dev/rsd1f
mount /dev/sd1f /mnt
(cd /usr2; tar cf - sybase) | (cd /mnt; tar xf -)
(cd /home; tar cf - sten) | (cd /mnt; tar xf -)
find /mnt -ls | awk '{ sum += $7 } END { print NR, sum/1024 }'
umount /mnt
newfs -v -s 11970 /dev/rsd1f
mount /dev/sd1f /mnt
cp /vmunix /etc/termcap /usr/lib/libc.a /usr/dict/words /mnt
umount /mnt
newfs -Nv /dev/rsd1f
fsck -y -b 408608 /dev/rsd1f
mount /dev/sd1f /mnt
find /mnt -ls | awk '{ sum += $7 } END { print NR, sum/1024 }'
umount /mnt
What I found: before after loss
files 4144 4057 2.1 %
kbytes 103266 102964 0.3 %
The directory structure was now partially destroyed, i.e. some file names
had wanished and fsck had put them in lost+found with the i-node number as
file name, but, basically, if the stuff is *very* important, it seems to be
possible to salvage a lot, given enough time to decipher lost+found.
I assume, that the Berkeley FFS (which Sun uses) allocates blocks very
sparse, i.e. they are using all cylinder groups in a FS right from the
start, putting files "here" and "there" (seems inefficient, though).
That way, a small FS created at the beginning of a large one does not
kill everything. Please correct me, if you know this to be wrong.
Naturally, the whole idea would not work in the "real world", because
the most important file(s) would certainly not have survived ;-)
Other things:
Some people did not believe that there was actually a FS in partition
b of the disk in question and suggested "go ahead, mount things, then
do a backup".
No cigar (this time ;-)
The sd3 disk in question is the second disk (so no swap in partition b)
and was not configured using SunInstall: sd3a is /home, sd3b is /usr2.
This is a bad partition layout, you might say, and I would agree, but:
there are also 2 Sybase raw database partitions on that drive and some
people - including myself - have found out the hard way: NEVER PUT A RAW
DATABASE PARTITION AT THE BEGINNING OF A DISK (doing so destroys the disk
label). Following that, a FS has to go first, so they placed both FSs on
that disk at the beginning (partition b is probably still a bad choice).
[ I just verified with our DB people: still not fixed in Sybase 4.9.1 ]
-- Sten
Thanks to:
weingart@inf.ethz.CH (Tobias Weingartner)
Ray Brownrigg <Ray.Brownrigg@isor.vuw.ac.nz>
John Hasley<hasley@andy.bgsu.edu>
lem@shaddam.usb.ve (LDC - Luis E. Mun~oz)
larry@ducktales.med.ge.com (Larry Landwehr)
etnsed!xhaque@uunet.UU.NET (Amanul Haque)
eparr@gsscwest.com (Eric Parr)
jayl@lattice.com (Jay Lessert)
Kelvin Hui <kelvinh@sa-htn.valmet.com>
louis@andataco.com (Louis M. Brune)
Richard Threadgill <richardt@apple.com>
Here are the responses:
***** From: weingart@inf.ethz.CH ***********************************************
#I think a "fsck -b block-#" would be a solution, but naturally nobody
#bothered to write down the superblock backup block numbers that newfs
#reported. Is there a way to find them?
Yeah, how about
newfs -N <partition>
I think that should show them to you.
--Toby.
***** From: Ray Brownrigg <Ray.Brownrigg@isor.vuw.ac.nz> ***********************
Just a small contribution.
> I think a "fsck -b block-#" would be a solution, but naturally nobody
> bothered to write down the superblock backup block numbers that newfs
> reported. Is there a way to find them?
Running
newfs -Nv /dev/rsd3b
will tell you what the superblock backup numbers were.
Good luck!
***** From: John Hasley<hasley@andy.bgsu.edu> **********************************
I can't say for certain what part of the partition would be written to
by Sun Install, or how much you can get back, but to find out backup
superblocks (starting with 32), run the command:
newfs -N -v /dev/rsd3b
the -N option says, "Don't do it, just tell me what you would do
if I ran this command." (It's in the newfs(8) man page.)
***** From: lem@shaddam.usb.ve (LDC - Luis E. Mun~oz) **************************
Ok. Sun-OS does *not* use the disk either head to tail or the reverse.
It divides the disk in `cylinder groups', and there's a copy of the
superblock at each cylinder group. The locations and sizes of these
cylinder groups are determined with mkfs, and typically span about 32
cyls each.
Hope this helps...
***** From: larry@ducktales.med.ge.com (Larry Landwehr) ************************
Try "newfs -N". Always summarize.
***** From: etnsed!xhaque@uunet.UU.NET (Amanul Haque) **************************
Your whole disk should be intact!. The b partition is normally the swap
partition and I am assuming that you are using the b partition for
swapping.
>Can he salvage his work?
Yes! Now the miniroot has been installed, you can manuall mount your other
partitions (a,d,e,f,g) etc using the mount command (you might want
to do this read only) and ran a backup. I have done this in the past.
My disks normally have 3 partition: the a partition being the root partition,
the g partition being the /usr partition and the h partition being the
home partition. What have done is the following:
cd /tmp
mkdir -p crash/root crash/usr crash/home.
mount -t 4.2 -o ro /dev/sd3a /tmp/crash/root
mount -t 4.2 -o ro /dev/sd3g /tmp/crash/usr
mount -t 4.2 -o ro /dev/sd3h /tmp/crash/home
Once mounted, you can run the backup.
All of this will not apply if your partition b is not the swap space.
You could look into /var/adm/messages to find out which partition is
being used for swap space.
> I think a "fsck -b block-#" would be a solution, but naturally nobody
> bothered to write down the superblock backup block numbers that newfs
> reported. Is there a way to find them?
Superblock 32 is always the next one (per man pages on fsck). there is an
option that will tell you where the superblocks are. Try "newfs -N"; this
will print out the file system parameters without actually creating the file
system (per man pages)
***** From: eparr@gsscwest.com (Eric Parr) *************************************
newfs -N /dev/rsd3b will give the superblock backup block numbers. Note the
CAPITAL -N, it must be in CAPS.
***** From: jayl@lattice.com (Jay Lessert) *************************************
If we're only talking about spending a day to rebuild from scratch,
it is *extremely* unlikely that he can do any recovery that will
actually end up saving time.
>time-consuming configurations and tests. Do SunOS 4.1.3 file systems fill
>from "low" to "high"?
Not really. It will probably tend in this direction, but in general,
inode and data blocks will be scattered all over the place.
>Can he salvage his work?
Mmmmm, probably not. Before he tries, he should probably use dd(1)
to do a literal copy of the disk area in question to tape (see, I told
you this wansn't going to save time... :-)
>I think a "fsck -b block-#" would be a solution, but naturally nobody
>bothered to write down the superblock backup block numbers that newfs
>reported. Is there a way to find them?
The fsck -b is certainly worth a try, he might get lucky. Do a "newfs
-N -v" to get newfs to report what backup superblock locations were
used. If the disk label has not changed, newfs will always do exactly
the same thing.
However, even if your friend is lucky and the recovery mostly works,
he still has to go through the data file by file to find out what
may be missing. It almost certainly takes less time to rebuild
from scratch.
***** From: Kelvin Hui <kelvinh@sa-htn.valmet.com> *****************************
Try run
newfs -vN sd3b
which will tell you the parameters and super block # for sd3b without
actually creating the file system.
***** From: louis@andataco.com *************************************************
I'm not a lot of help here, but you can run
"newfs -N /dev/rsdwhatever"
to get the backup superblock numbers, assuming that the partition of
interest (or of terror, as the case may be is still the same size.
But you may well be asking quite a bit of fsck to take it from there.
***** From: Richard Threadgill <richardt@apple.com> ****************************
newfs -N /dev/<raw device> will print out all of the alternate block numbers.
----------------------------------------------------------------------------
Sten Gunterberg Why did King Kong climb the Empire State
ERGON Informatik AG building? - He didn't fit in the elevator.
gunterberg@ergon.ch
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:54 CDT