On Fri Oct 29 1999 at 09:10, Mark B Withers wrote:
> Wow!
>
> Thanks a lot! This really helps me to plan for the unforseen.
[ ... ]
Just something that comes from hard experience...
It's easy to make backups, really easy.
But not so easy to restore a totally crashed system.
This is what you ultimately need to be able to do... recover to its
former glory a system from a total disaster like a disk crash starting
from absolute scratch with your backups. So the backup strategy needs
to be designed so that recovery is made possible (yes - *possible*),
simple, and foolproof.
To have a successful backup strategy means that you have a proven and
verified methodology for complete recovery. This includes not having
any sort of operating system running from the hard drive at all.
Of course, tomsrtbt is an invaluable tool for recovery purposes. Mind
you - not a complete solution for some situations, but indespensible
none-the-less.
As an aside... we were doing some backups using "bru". This is a very
nice professional backup program that has been shipped with redhat
linux over the past few releases. However, it needs to run on a
glibc-based system - something tomsbtrt doesn't provide.
I once had an idea to put together another floppy disk to compliment
tomsrtbt that had a basic glibc-based filesystem on it, but without a
boot kernel - tomsrtbt would actually provide that.
The idea was to boot with tomsrtbt, load this second floppy into a ram
disk (or run it off the floppy), then chroot'ing to it for the express
purpose of runnning bru in a small glibc runtime library enviroment to
have some way to do a recovery with it. I never did follow this up,
but with the work I was doing with similar sorts of things (eg, using
YARD to create a bootable ide zip drive), I did manage to prove to
myself that the concept is sound and it could be made to work without
too much effort. The runtime libraries are (almost) independent of
the linux kernel.
Tom, how do you react to such a strategy for handling glibc-based
recovery tools? It means a two-disk methodology, but it should work.
Besides, it might have another spin-off... creating and then
fine-tuning such a beast and could provide a useful practical
mechanism for helping to migrate tomsrtbt to glibc in the longer term
(which is an inevitability).
Anyway, just a thought... so go on mate - shoot it down in flames :-)))
Cheers
Tony
