> > 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? I would really like to see a generic ISO that you can download and run in the event of a total loss disaster. > 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? 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. > 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... 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'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 :) 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
