On Wednesday 27 December 2006 02:10, James Harper wrote: > > > > 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. > > 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. > I would really like to see a generic ISO that > you can download and run in the event of a total loss disaster. I think you need to define your concept of what a generic ISO is and what disaster you are trying to recover, since what you are saying doesn't make sense in light of how I have defined it above. If your definition of a generic ISO is different from mine (i.e. it serves a different purpose) then maybe this would make sense. 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. > > > 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. My rescue CDROM will restore a client machine where the Director and SD are up and running on one or more other machines. The Bacula disaster recovery (or probably Rescue) chapter briefly talks about this more complicated problem. > At least to get the system to the point of booting and having Bacula > running again. I was testing the other day and it appeared that I could > bextract from a tape (well... disk based backup actually) without any > daemons running and only a very tiny mocked up sd config file. 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. > > > 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. > > As long as the kernel was about the same vintage, a knoppix style boot > with base kernel and hardware detection should be fine. > > > 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). > > Cool. > > <snip> > > > 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 ... > > I'm not sure that the problem is as large or as necessary as you make > out... > > There are two scenario's to consider: > > 1. Restoring to exactly the same system (eg HP or Dell system where > something broke in a major way and it was repaired under warranty with > exactly the same components) > 2. Restoring to an upgraded system (eg whitebox server replaced with > something similar but not identical - bigger disks) > > In #1, you want to make sure that your new disks get restored with exact > uuids etc. In #2 you might want the same if you have the same partition > layout except bigger, or you might not. Actually you probably want the > same flexibility in either case... how many times have you said "damn... > I wish I'd made this partition bigger when I built this system!" :) > > The main hurdle I see for non-genericness is the large combination of > boot loaders (grub, lilo, and then all the non-x86 types). > > 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... 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'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... 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. Again, you are talking about a problem that is much larger than I am currently trying to address. I can only work one step at a time toward a full disaster recovery solution, but find myself blocked with silly technical details. Note these silly technical details aren't really so complicated, it is just that I don't particularly like working on the kernel and boot problems, so the problem becomes hard for me. > > I've done the BartPE thing before and restored a Windows XP system from > 'bare metal', and it worked more smoothly than I could have hoped for, > but it felt like a hack and I'm not confident that it would work well in > the case where the windows box was also the server. > > 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 :) 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. > > How I wish I had time to do this stuff... > > Thanks > > James > ------------------------------------------------------------------------- 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
