CLIFFORD ILKAY wrote:

>BRU (Backup and Restore Utility) and CRU (Crash Recovery Utility) from
><http://www.tolisgroup.com> should do the trick. I have used BRU for a
>while and really like it. I have not had a chance to play with CRU even
>though I got it bundled with BRU.


Personally, I like the dirt work of typing commands at the system prompt,
knowing what's going on in detail, so I followed another path.

I already had the SuperRescue CD available from Kernel.org
(http://www.kernel.org/pub/dist/superrescue/v2/) - I resort to it to solve
gremlin problems like Win98 that crashes while repartitioning a disk on
which it was already installed, or regaining control of a notebook a
manager's son ruined with an ill-ended Linux installation.

SuperRescue is a Linux distribution based on RedHat 7.2 - if I remember
well - that runs directly from the CD. So, I can use the SuperRescue CD to
boot the ESSG and do what I want with its disk(s).

To recover from a crash, I customized the SuperRescue CD installing what
needed to backup and restore an ESSG: dump was already installed, so I had
to install the rpm packages flexbackup and buffer (and set the console
default keymap to italian, too), and rebuilded the ISO image with the
provided tools, following the instructions contained in the distribution.

I do my backups with flexbackup, directly and periodically launched by cron,
on a HP 24GB DAT unit, and flexbackup saves all ESSG filesystems. So, if the
hard disk crashes, I can boot the system with my "SuperRescue for ESSG" CD,
repartition the hard disk(s) following the original scheme, mount the newly
created ESSG root filesystem under the "SuperRescue for ESSG" filesystem,
restore all the ESSG contents, and issue a chrooted lilo command to create
the boot sector on the boot disk.

This way I can do a "standalone restore" (to mutuate an OpenVMS terminology)
of a complete system following a standard procedure. I should be able to
mirror a standard installation on a second machine, too, and "standalone
backup" every other operating system that can be started by lilo or whose
custom boot block can be saved and restored on the disk using standard Linux
tools, or at least every other not FS journaled Linux based system.

I still have to test this procedure with the due accuracy: no time yet to do
it on the production server (the test should involve simulating a crashed
disk by substituting the original disk with a scratch one, doing a full
restore following the procedure and rebooting and checking the recovered
system).

I tried the restore operation on my home machine, and it went smooth and
fine, but the hardware differences (dual disk, IDE and SCSI, a 64bit
AHA29160 controller instead of a 32 bit one and a different video card) were
enough to crash lilo, so the system won't boot anymore, hanged on the "LI"
prompt.

I'm reasonably sure that the problem should be LILO itself, because a clean
ESSG 4.0 install on my home machine ends the same way - hanged at the "LI"
prompt, while newer ESSG systems from 4.1 onward (that use a newer LILO
version) install and boot just fine, and the backup and restore tests work
very well - of course, these are just "formal" tests: the restored systems
work as expected, but without the load and the multiplicity of requests that
a production machine goes under I just can't state it works for sure.

If somebody is interested in this kind of recovery procedure (

If someone is interested in [testing] this procedure, I could detail it in a
how-to (at least, a sort of... ) by translating the notes I already made...
let me know.

--

Pierluigi Miranda


--
Please report bugs to [EMAIL PROTECTED]
Please mail [EMAIL PROTECTED] (only) to discuss security issues
Support for registered customers and partners to [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org

Reply via email to