Re: [Bacula-users] [Bacula-devel] generic 'bare metal' restore CD

[James H. <jam...@be...>]

> > Is there any reason that it can't be on the tape and restored first
up
> > as part of the DR process?
>=20
> That would be having the cart before the horse.  The snapshot of the
hard
> disk configuration is to be able to reconfigure a broken hard disk or
> configure a replacement disk. Until you have a configured disk there
is
> no way to do a restore.  This information must be on a floppy or a
CDROM
> or you must manually reconstruct it.

I was assuming that bextract could be used to do it. Being slow wouldn't
matter if it was the first thing backed up on the tape. Being error
prone might be a bit of a downer though. Do you think it would be
capable of reliably restoring a few kb of config info? Murphy's law
applied to disaster recovery states that the disaster will occur shortly
after you have made some major change to the system but shortly before
you have updated your disaster recovery media. Having it on tape would
resolve this.

I've just re-read the docs and noticed that bextract can't restore ACL
info. This breaks my idea of using it to restore enough to get a running
system, as do your comments about it being error prone.

Do you think there would be value in having a bextract tool that could
reliably do a full restore? It would certainly make disaster recovery a
lot easier!

> A full disaster recovery plan from bare metal is *very* complex.  I'm
only
> trying to address the problem of getting a single client machine back
up.
> The same principles may apply to the larger problem, but I cannot even
get
> a
> client machine back up, so for the moment until I find a good
solution, I
> need to keep the problem simple.

I just did the single client version today using dfsbuild (+ some
patching I had to do), without any of the automated partitioning stuff
of course... It was only mildly painful.

<snip>
=20
> bextract is a last resort solution one wants to use only if one has
not
> been
> careful to do a proper disaster planning.  It is *very* slow and prone
to
> error.  It is much better to read the Restore chapter and learn how to
> recover with restore without bextract.

I had greatly overestimated the power of bextract. As I mentioned above,
is there any reason why this couldn't be improved? If bextract could
restore the system to a bootable point, then all the problems of
bootstrapping and getting a runnable director and sd go away... The
server problem is pretty much reduced to the size of the client problem,
with the exception of tape device drivers (which is minor if they are
standard kernel drivers). I haven't really looked at the code, but if
bextract isn't using the fd and sd codebases directly and you are
keeping them in sync manually then I can see that this would be a lot of
extra effort.

> > No matter what distro-centric tools you used to make your
> > partition+md+lvm setup, they can all be reconstructed in a generic
way,
> > unless there's something somewhere that I don't know...
>=20
> Well, for the moment, I am stopped by my ignorance of the boot process
> because
> I am unable to make a boot CDROM containing Bacula files that boot.
So I
> am
> dead in the water.

I don't know what distro you prefer, but dfsbuild should work for Debian
(it doesn't under etch though, needs some patching, see my recent bug
reports against it). I can supply some patches if Debian is your distro
of choice and you are using etch.

Otherwise, maybe customise knoppix?

> > I'd also love to be able to use the generic Linux CD ROM to restore
a
> > Windows system from 'bare metal'... this would open up a huge market
to
> > Bacula (not sure if you'd want a large swarm of Windows Newbies
suddenly
> > appearing on the mailing list though... :). The new ntfs driver
(ntfs-3g
> > or something) needs to mature a bit, and Bacula would need a bit of
work
> > to allow restoring the ACL's and other information to it, but I
don't
> > see anything impossible about doing this, except for the final step
of
> > making the windows system bootable again...
>=20
> I'm not convinced that a "generic" Linux CDROM will solve the problems
of
> restore on Windows unless you restore an image.  To properly restore a
> Windows machine, you need to run the Bacula Windows client, and it
runs
> only under Windows and not under Linux.

True. I was referring to a point in the future where the ntfs-3g driver
had matured a bit. At that point you should be able to build an ntfs
filesystem under Linux and restore the files. The only problem then is
making it bootable. As it is now, it might still work but will be
missing all sorts of acl info. I'm going to try it out shortly though.

> > Finally, has anyone ever thought of creating a Bacula distribution?
> > (Baculix? Bacubian? Bachat? Bacpix? :). It could be installed on a
box
> > with a lot of disk and a tape drive and run D2D2T style backups a-la
> > Tivoli and the like. A user interface could be provided to allow
users
> > to restore files to their workstations too, instead of bugging the
> > admin. It also means that even in a windows environment, the
director
> > and sd are still on a linux box where they belong :)
>=20
> I think that already exists.  Just load any modern distribution
(Fedora,
> RedHat, SuSE, ...), load Bacula, build it, configure it, and you have
a
> Director and a Storage daemon that can handle a whole network.  With
> version
> 1.39.x you can now also do the same thing on a Windows Server.

Of course, but you need to know a bit about Linux to do it. I was
dreaming about something like openfiler which is more or less boot and
go. Not a priority in any way of course given the other things going on.

Thanks

James