> Hi, Kern - > > I'll go ahead and see what I can do about getting a basic CD rolled. > It's been a while since I have done it, so I will be a bit rusty, for > sure - and for that reason, I cannot give you a timeframe. > > However, I'll put a fair amount of work into it. I completely see what > you're saying about the differences, not necessarily between kernel > versions, but other things such as LVM. Which makes me wonder - would > it be possible/wise to investigate Bacula's ability to back all that > information up, as well? > > I might have misunderstood how Bacula worked a little bit there in > regards to setting up things such as partitions and LVM. I believe the > ideal solution for a good restore would include Bacula's ability to back > up not only files and directories, but also partition info, layouts, > LVM, SCSI interfaces, blah blah blah. See we could spend a good amount > of time making an all-in-one boot CD to allow for the re-initialization > of said devices, or Bacula could learn how to restore this information. > Of course, I'm in no position to dictate how the development process > should work, so I guess what I'm asking here is - is that sort of thing > planned for the near future? Will Bacula eventually be able to back up > all that data in addition to just files and directories? > > None the less, I'll get rolling on this later this evening for sure, and > see if I can make even a little contribution.
The idea I had for this was that the first thing bacula would do at the time of backup is: . Run a script to prepare a directory with some system config info in, including: . Partitions and ID's . RAID volumes and ID's . IP address (or DHCP info to try and get the same IP again) . Hostname . Back up that directory such that it can be identified and restored easily. All of that is do-able right now I believe. Then when you want to restore: . Boot your generic CD . In the case of a client: . configure the fd on the CD and make sure all the working stuff is in ram . restore system config into ram (should only be tiny) . apply system config (either manually or via some tool if one exists) . restore everything else . In the case of a server: . bextract the above info into ram . apply system config . bextract everything else According to Kern, bextract isn't to be trusted with such a large job at the moment, so while it should work for the config directory, it won't work for the entire server. The whole thing could be really smooth if we had a single tool which could: . Suck data straight from tape in the case of the sd . Suck data straight from the sd in the case of the director . Suck data straight from the director (or sd?) in the case of the fd The tool should need minimal configuration and would first be used to grab the system config, and then the data. Backup Exec's IDR functions in a similar way to this. 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
