> 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.
That's why I cringe when I hear people talk about "backup
strategies." I know they don't really mean it, but the
problem has more to do with RECOVERY PLANNING.
> 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.
Doesn't BRU offer some sort of "crash bag" facility for
building a bootable floppy to do a basic sytem restore?
I realize that any such facility might not have the
flexibility of a Tom's Root/Boot and might not be able to
gracefully handle cases where you've had to replace some of
your hardware (particularly controllers and network
interface cards). But It seems shameful if they expect that
you have to do a full OS IPL (initial program load --
e.g. installation) to recover from a catastrophic failure.
[...]
> 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.
glibc2 (Linux libc/6) is just too bloated for this stuff.
I've heard that the Debian crew is working with some sort
of "busybox" trimmed glibc2 build. This sounds too clunky
for use (building) by mere mortals.
I realize that glibc made great strides with their modular
NSS, thread safety, and other aspects of their support for
the needs of modern Unix/Linux/GNU workstations in their 2.x
relalease, however I wonder if it really needed to have such
a huge footprint.
> 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).
I don't accept this as an inevitability. I think it's
entirely up to Tom when or if he will ever adopt glibc.
David Parsons still maintains a distribution (Mastodon)
based on libc 4.
> Anyway, just a thought... so go on mate - shoot it down in flames :-)))
> Cheers
> Tony
--
Jim Dennis [EMAIL PROTECTED]
Linuxcare: Linux Corporate Support Team: http://www.linuxcare.com
