On Tuesday 02 January 2007 12:23, Alan Brown wrote: > On Wed, 27 Dec 2006, Kern Sibbald wrote: > > >> Is there any reason that it can't be on the tape and restored first up > >> as part of the DR process? > > > > 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. > > ...Or restored from tape to a floppy or memdisk or USB disk, etc..... > > > A full disaster recovery plan from bare metal is *very* complex. > > I'm getting quite worried that for every single machine in our network > which might be backed up by Bacula (there are over 200) I will have to > create a customised CDrom.
I've now documented how you can run the Bacula rescue, save a single directory, then use it for restoring your systems using any non-Bacula rescue or LiveCD disk. > > Kern, PLEASE consider using a Knoppix or Trinity or similar live system as > the basis of the bare metal restore system. Most of these people will > actively work with you to facilitate this. I think this is a good idea. However, it is not something I am personally going to do (I just don't have the time). The major problem with this is that they are not used to following a distribution and updating with it. >From what I understand, Knoppix still has a Bacula 1.36.x FD. As I say, this is a nice and a valid approach, but the Bacula community needs to organize it. > > >> > >>> 2. A copy of your current Bacula file daemon that can be run on > >>> a rescue system (i.e. probably statically linked). > >> > >> For a 'client', you want the FD. For a 'server', do you have to have the > >> director? Is there anything that bextract can't do that dir+fd+sd can? > > > > I think you need to read the Bacula disaster recovery chapter. You are > > talking about a "complete" disaster recovery system, which is orders of > > magnitude more complicated to do from bare metal than what I am trying to > > accomplish as a first step in that process. > > Nonetheless, the system needs to be 100% bootstrappable. I'm not sure what you mean here, but IMO, recovering a system depends on what happened. In some cases, it is simply firing up the existing FD and restoring some files, in other cases it is firing up a static FD and restoring some or all files, and in the worst cases, it is replacing hard disks, repartitioning, formating, then restoring. If damage is sever enough, one may even want to start by booting up the OS installation disks and having a minimal running system, then running a Bacula FD (non-necessarily static) to restore the files as they were. As is mentioned in this email somewhere, a complete disaster recovery plan is very complicated. > > Consider the case of the Bacula server (Director and SD) itself falling > over. I use RAID1 on the system and database disks for this very reason, > but as you youself know, RAID is not safe against "rm -r" style errors (or > physical system destruction - fire, earthquake, theft....) > > > My rescue CDROM will restore a client machine where the Director and SD > > are up and running on one or more other machines. > > I've managed to do a restore without the rescue CDrom by simply loading up > an appropriately configured bacula-fd-static on a Trinity Rescue Disk. > > After redoing the partitions, restore took approximately 25 minutes. Great! > > The basic fact is that the standard Linux system rescue CDs(+) are > designed to be able to read as many different filesystems as possible, > handle LVM/Raid, etc and interact with as much hardware as possible - and > they're regularly updated. All that's needed is to convince the authors to > include appropriate bacula file daemons and as long as partitioning > information is available(*) they would cover 99% of all cases (including > restoral of most generally used non-Linux operating system filesystems and > partition tables(**)) What I would like to see, and where I would be happy to participate, is to convince the OS vendors (i.e. RedHat/Fedora, SuSE, Debian, Ubantu, FreeBSD, Solaris, HP, ...) that they should have an easy way for the user to make a rescue disk that captures the state of the current harddisk(s) and provides easy scripts, or better yet a GUI, for repartitioning those disks much like they do in the installation. This rescue disk should not be a bare bones rescue with few binaries as is currently the case, but something that includes every conceivable command line program one would want in analysing and fixing a problem. Furthermore, the user should be able to include a large number of machine configurations on a single rescue CD as well as to be able to add one directory to be loaded in memory at boot time and one directory to be saved on the CD. With that, everyone should be happy. The above should be a *standard* part of the OS release. > > (+) most are x86 only, but Ubuntu live (at least) has a PPC version. There > is a definite need for SPARC and Alpha rescue/live systems too. > > (*) Given your standard case of restoring a bacula client, this should be > trivially obtainable from the Bacula server. > > (**) I'm sure BSD people will pop up and say they can do the same thing > and I'd be surprised if they couldn't produce a rescue system. > > AB > ------------------------------------------------------------------------- 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
