[clue-tech] Pristine root for restore

[mike havlicek]

--- Collins Richey <crichey at gmail.com> wrote:

> On 7/22/06, mike havlicek <mhavlicek1 at yahoo.com>
> wrote:
> > Hello All,
> >
> > I am having a bit of trouble creating a pristine
> root
> > target for a level 0 restore from tape for my root
> > partition. Ultimately I think the problem is
> perturbed
> > from the fact that I have my root on a logical
> volume.
> >
> > The system is RHEL4-AS based. I am booting the
> system
> > from an install CD going into rescue mode to
> perform
> > the restore. It seems to be working for partitions
> > other than root (root may work as well but I can't
> > seem to umount it allowing me to mkfs it
> pristine...)
> > Creating a new fs on a mounted area makes me
> > nervous...
> > I guess since I am not running from it ... it will
> be
> > half way ok ... thus the good feelings from raw
> > devices on other systems :)
> >
> > Any suggestions on doing a level 0 restore on root
> ???
> > This works SO nicely with Solaris :)
> >
> 
> When booting from CD in rescue mode, have you tried
> skipping the scan
> for RedHat systems? This will get you to a shell
> prompt without
> mounting anything.

The scan seems to be required to get the logical
volume
devices set up in accord with the previous/existing
system. Learning to set up lvm from rescue would be a
value in this type of situation :)

> 
> OTOH, I've never had any probelm umounting the
> /mnt/sysimage
> directories. If any of them are mounted on a root
> mountpoint, you have
> to unmount all of them before you can unmount the
> root partition.
> 
> HTH,
> 

This is all true. Actually it turns out the root of
the problem I was dealing with had to do with the
options available for umount in rescue mode. What I
needed was the -l option for "lazy" which seems not to
be available in the rescue umount. Hack solution was
to copy the /usr/bin/umount from the rescue mounts to
/tmp eg and run that version. That allowed me to
umount everyting, mkfs.ext3 etc and restore from
tape...

One catch was the /boot area. The machine I am working
on is a Compaq proliant 6400R "old server" with nifty
tools that go onto a partition on yer RAID:) This by
default changed my partition layout so restoring /boot
off tape kinda munged things ... especially given I
was doing the whole process due to a primary disk
failure -> switched my RAID 5 on 4 disks to 3...

Ended up cheating by doing a min install then
restoring tape dumps on top of that ... ( I don't
recommend this for various reasons .. but most of all
as follows)

By installing restores ontop of a base CD install you
potentially put your rpm database out of sync with
"actually" installed software. In the case described
above the risks were minimal. I believe the only
discrepancies were confined to the kernel. That might
sound bad ... but actually it was managable. It was
querky querying the rpm database and seeing mismatches
in /boot eg... but a few rpm -e commands to clear
things out and then installing a working kernel from
rpm seems to have sync'd stuff.

In this case I had a couple of "weird" things going
on... the most significant being that the physical
disk layout was changed... new array controller added
...etc.

I think the right way to restore a system from level 0
dumps would have involved restoring /boot as well...
but I got a little anxious....

-Mike

(BTW mkfs requires umount ... silly)
 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com