On Tuesday 26 December 2006 11:02, James Harper wrote:
> Assuming that the user would be responsible for the initial partitioning
> etc, is there any reason that a generic 'bare metal' restore CD could
> not be made? It looks like the catalogs and bootstrap files can be
> recreated with the bscan etc tools, so unless I'm missing something, it
> should be possible to create a CD with the client daemon (for restoring
> where the director is on another machine and is still up) and the
> storage daemon (for bextract where the director is not available).
> 
> Or maybe this already exists? I looked but couldn't find anything... I'm
> currently tinkering with dfsbuild to see what it can put together.
> 
> Also, if a pre-backup operation could create a system config file with
> all the partitioning and other bootstrap info, then even that could be
> restored off of a tape at the start to automate the process.
> 
> The reason I'm so interested in this is that the existing documented
> disaster recovery procedure seems to include a lot of pre-disaster work
> and ongoing maintenance (update your DR CD when updating kernels etc)...
> If there was a (more or less) generic ISO that could be downloaded and
> run, then the whole process might be a lot simpler, and therefore
> attractive...

Well, interestingly enough, I am just today working on the Bacula rescue 
CDROM, and I have just about given up the idea of making a generic rescue 
CDROM for a number of reasons that I'll describe below.  First, here is what 
I consider the Bacula CDROM to be:

1. A snapshot of your hard disk configuration.
2. A copy of your current Bacula file daemon that can be run on
   a rescue system (i.e. probably statically linked).
3. A bunch of scripts that can be used to do various recovery tasks
(bring up the network, repartition your hard disks as they were, reformat your 
hard disks, ...).  Obviously you would use only those scripts that are really
necessary.
4. All sorts of binaries to make recovery easy.
5. All this put together with your current kernel on a CDROM that can be 
booted.

Now items 1-4 already exist and are more or less straight foward and more or 
less Linux distro independent.  (If I am not mistaken, these already address 
what you were asking for above).

Unfortunately, item 5 is rather important, but I've now concluded that it is 
far from being distro independent, and way more complicated than anything I 
want to work on.  The problem is that without item 5 (your kernel), you 
cannot be sure that your environment will be setup correctly when booting the 
rescue disk.  This is because there are *major* issues with raid, lvm, ... 
that must be addressed to get a sysstem back up and running without even 
considering the problem of reloading the files.  

Three or four years ago, creating a boot CDROM used to be more or less 
straight forward, but today it is not -- for example, the SuSE 10.2 mkinitrd 
script, which sets up a generic boot environment based on your system is 
3,377 lines of shell script.  Needless to say, each distro has a different 
mkinitrd script.

The first iteration of the Bacula rescue disk implement its own code to make 
the rescue boot (item 5). As we started seeing 2.6 kernels, this 
implementation failed more and more often. The second iteration (not yet 
released) uses mkcdrec to actually do the booting.  This seemed to work 
pretty well until I moved to SuSE 10.2, and now it no longer boots.  So, the 
bottom line is that I give up on trying to implement item 5 -- it is just to 
complicated, too distro dependent, and a constantly moving target.

I have not yet found a satisfactory solution.  Every distro has a rescue disk. 
However, most of them boot up without mounting the disks and leave you 
sitting at a raw command prompt.  If you are like me, you are not even 
capable of mounting a CDROM because I cannot (refuse) to remember all the 
silly options and the syntax needed to mount a CDROM (it is trivial if you 
have the right fstab).  So, we are (I am) sort of dead in the water.

The path I am exploring for the moment is simply packaging the output from 
items 1-4 onto tar file that the user can save to a floppy or a CDROM.  I am 
also considering the possibility of remastering rescue disks and adding the 
Bacula data, but that is probably also a black hole of distro dependent 
code ...

If anyone has some better ideas, I would appreciate it to hear them ...

Best regards,

Kern


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to