> - no nfs server, which is needed for exporting filesystems to
> allow the dump to occur over a network, and
This part, I don't get, there are several ways around this. Have tomsrtbt
be the nfs client, or use rsh, or nc, or some combination- there are lots
of ways to have 'dump' occur over a network, including under the control
of another machine, without rpc.nfsd and rpc.mountd. You are welcome to
customize this into your copy, but I just don't get it. Please, somebody
convince me that making tomsrtbt an nfs server is a good idea in any way,
I need to have a situation described to me where the other ways aren't
just as good.
> # CONFIG_SCSI_MEGARAID is not set
>
> so there no support for raid5, not even a module for it.
Well, it is easy to add your own kernel. I may put the raid support in,
in fact, this is on the list of things that might be justtified. But, I
don't get why you don't just put your own kernel on- it is almost the
easiest change to make to tomsrtbt, you just unpack.s then copy over a new
zImage then buildit.s. Anyone doing raid backups in a network environment
should have no trouble just slapping a 2.2.x kernel with raid support onto
the diskette...
> I've looked at several recovery utilities, none of them seem to be
> able to do the job. I need to be able to totally recover a dead image
> from a network backup.
>
> Anybody here have any suggestions?
Customization. Why do you care if there is an "out of the box" solution
that exactly meets your needs? The strategy of tomsrtbt is to make it
_EASY_ to customize, and I'm always interested in hearing about problems
that people have when they customize. Sure, it will be convenient if you
have the megaraid support built in, but the customization is NOT a big
deal.
-Tom
