Kern Sibbald wrote: > 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 >
Good afternoon, Kern - I've not yet read up on the bare metal recovery process, except for a quick fly-by just to get the basic setup in my head. I'm still very new to Bacula, and I think that a bare-metal restore of anything is quite out of the question at this point. However, I have ample experience in rolling my own CentOS/RHEL-based boot CDs for a job that I used to work at, and I think that a single generic CD, which is to be booted on a bare metal machine, would work just fine. It's my understanding that a spin-off could be created to support a very large amount of generic hardware, and for the recovery process, the kernel version would not matter in the slightest. The kernel and associated modules would only be used in 'live' mode, so they would not even be touching the disk. I'd like to think of it as a live distribution (Barecula? har har har) which simply contains support for the hardware - via modules, etc etc -, has a file daemon on it, network support, and knows where to look for partition information to restore. Assuming bare-metal recovery implies that the machine should have absolutely nothing on it to begin with, I don't see why we would need to be concerned about what kernel we use in such a beast - however, it of course would be as current as it can be to support hardware which might be a little awkward, such as RAID and Network and such. As far as specifics go re: partitioning, if we do replace say a failing disk with a bigger/smaller one, like you said earlier, a template could be used. A script could facilitate this template, which would allow one to either let the restore process "expand" on the template and fill up remaining space, or the user can define the space. As I understand, Bacula wouldn't give a damn about what an actual partition is, unless you're doing a backup or snapshot of the drive or partition itself - not just the mount point. The name by which Bacula calls these escapes me right now, but I hope that you understand where I'm going with this. Anyway, I'd be happy to tread this thread and get some ideas, perhaps being able to deliver something that might achieve this goal. WHat are your additional thoughts on the subject? Thanks! -dant ------------------------------------------------------------------------- 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
