[Bacula-users] generic 'bare metal' restore CD
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... 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] generic 'bare metal' restore CD
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 - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] [Bacula-devel] generic 'bare metal' restore CD
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. [..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 ... If anyone has some better ideas, I would appreciate it to hear them ... It would be really handy if the FD saved the above tar file as a normal part of the backup run (would only be a few KB, so negligible amount of extra work/data to transfer). I'm not so convinced that maintaining partitioning data is all that useful any more -- when's the last time you replaced a disk with an identical size disk? -- but it can't hurt. I've had very good luck with restoring Unix/Linux clients using a Knoppix CD as the recovery CD. It has a bacula-fd package (albeit 1.36 vintage), and they go to great lengths to detect and handle hardware, LVM and RAID detection and all the other hard stuff. Boot the Knoppix CD, tell it where to find the Bacula SD and Dir in your config, and the client id it's supposed to be using, do a full restore to the replacement disk, and then do whatever you need to do for that distro to make the replacement disk bootable. If you use grub, then there are text and GUI tools on the Knoppix CD to handle that for you once you have your grub config file accessible again. I haven't tried recovering a Windows system yet, but I suspect it shouldn't be too different, at least because I use grub to boot my (few) Windows boxen as well. It's too bad my OS/2 TSM standalone restore CD no longer works on modern versions of Windows -- there were some good ideas there. Key tricky bit is reconstructing the client ID and pwd string if you use strong passwords and don't record them somewhere. A server-side client data access ACL (eg, client X is allowed to access client Y's data) might be a useful thing to think about for the future. - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] [Bacula-devel] generic 'bare metal' restore CD
On Tuesday 26 December 2006 15:57, David Boyes wrote: 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. [..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 ... If anyone has some better ideas, I would appreciate it to hear them ... It would be really handy if the FD saved the above tar file as a normal part of the backup run (would only be a few KB, so negligible amount of extra work/data to transfer). I'm not so convinced that maintaining partitioning data is all that useful any more -- when's the last time you replaced a disk with an identical size disk? -- but it can't hurt. Yes, I think that is a good idea. First, though, we must create such a tar file, which doesn't currently exist as such. If you load and run the rescue make, it will exist as a directory. Over the next few days, I am going to delete all the old stuff that tried to build a bootable CDROM and just stick to providing the tar file. After that, I think the user can handle backing it up (by for example sticking it in his Bacula scripts directory), and the user can handle getting it onto a CD or onto the Knoppix CD. There is a *big* advantage in maintaining the partitioning data. First it can be used to reformat an existing disk if the disk is not bad. Second, even if you have a different sized disk, it serves as a good template. I have many different configurations of partitioning depending on the use (server, file server, development, laptop), and by having that data handy when something goes wrong at least I can easily see what I had before the crash. As you say, the total amount of data is rather small -- the whole thing including the Bacula FD binary on my current system is 1,208 KB -- hardly a problem on any medium. I've had very good luck with restoring Unix/Linux clients using a Knoppix CD as the recovery CD. It has a bacula-fd package (albeit 1.36 vintage), and they go to great lengths to detect and handle hardware, LVM and RAID detection and all the other hard stuff. Boot the Knoppix CD, tell it where to find the Bacula SD and Dir in your config, and the client id it's supposed to be using, do a full restore to the replacement disk, and then do whatever you need to do for that distro to make the replacement disk bootable. If you use grub, then there are text and GUI tools on the Knoppix CD to handle that for you once you have your grub config file accessible again. Yes Knoppix is a good solution. I haven't tried recovering a Windows system yet, but I suspect it shouldn't be too different, at least because I use grub to boot my (few) Windows boxen as well. It's too bad my OS/2 TSM standalone restore CD no longer works on modern versions of Windows -- there were some good ideas there. A number of people have hand good experiences with BartPE. Key tricky bit is reconstructing the client ID and pwd string if you use strong passwords and don't record them somewhere. A server-side client data access ACL (eg, client X is allowed to access client Y's data) might be a useful thing to think about for the future. - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] [Bacula-devel] generic 'bare metal' restore CD
Yes, I think that is a good idea. First, though, we must create such a tar file, which doesn't currently exist as such. If you load and run the rescue make, it will exist as a directory. One other thing that might be an issue is encryption information. I'm not sure if the current scripts grab the key files, etc -- you'd need to get those too. I have many different configurations of partitioning depending on the use (server, file server, development, laptop), and by having that data handy when something goes wrong at least I can easily see what I had before the crash. OK. All my systems of a particular type have the same partition structure, so it wouldn't be useful for me unless everything went up in a smoking heap all at once, but I can see that others would find it useful. It can't hurt to save it -- and one never knows when it'll be useful. There's never too much information in a disaster restore situation. - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Cloned jobs
On Thu, 14 Dec 2006, Kshatriya wrote: The best solution would be to clone the files which are stored on disk to tape... Is really nobody using Cloned Pools and Jobs? :-( My current try is, to make a Default pool and a Clone pool. The Clone pool has the type Cloned. After that I created 2 jobs, a job Client1 which writes to the default pool and a job CloneClient1 which writes to the ClonePool and has an extra statement: Run = 'Client1 level=%l since=\'%s\'' Unfortunatly this seems to do nothing. When I start CloneClient1, a backup goes to the ClonePool, but Client1 job does not run - the jobs just seem to run independently from each other. Am I understanding something wrong in this concept, or am I doing something wrong? If I need to start jobs independently from each other, then what is the difference to just start 2 regular jobs who write things concurrently to 2 regular backup pools? Thanks! :-) - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] generic 'bare metal' restore CD
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
Re: [Bacula-users] generic 'bare metal' restore CD
On Tuesday 26 December 2006 20:23, Dan Trainor wrote: 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 Hello, 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. Well, from a
Re: [Bacula-users] generic 'bare metal' restore CD
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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net
Re: [Bacula-users] generic 'bare metal' restore CD
On Tue, Dec 26, 2006 at 09:02:12PM +1100, 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 Ignoring the case of restoring the machine hosting the dir/sd, this is pretty straightforward. I've done a number of bare metal client restores using a stock fedora rescue cd roughly like so: - perform a bacula restore of /usr/sbin/bacula-fd and /etc/bacula/ to an fd on a working seperate machine - boot the rescue cd on the new hardware - when prompted, bring the network up, but do not mount any filesystems - scp enough files to run the partioning and file system creation scripts and to run the bacula-fd (config files, certs, etc) - use the scripts to partition, mkfs, and mount everything - launch bacula-fd and do a full restore with a where parameter of wherever the new root is installed - reinstall the bootloader (grub in my case) and you're good to go -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that WPI Network Engineer | is simple, elegant, and wrong. - HL Mencken GPG fingerprint = 6174 1257 129E 0D21 D8D4 E8A3 8E39 29E3 E2E8 8CEC - 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.phpp=sourceforgeCID=DEVDEV ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
[Bacula-users] include statement in config files?
Do any of the configuration files allow an include statement? What about
an include statement to include all files in a directory? Eg
Director {
Name = my-dir
...
}
include /etc/bacula/bacula-dir.d/
My bacula-dir.conf only has a few clients in it and is already huge.
Breaking up the config would also allow simpler manipulation by a GUI.
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.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] include statement in config files?
for an individual file include you can place an @ in front of the
filename.
I dont think that there is a full directory include at this time.
Here is an example of my bacula-dir.conf:
Director {
Name = kninfra01_mycastle-dir
DIRport = 9501
QueryFile = /usr/local/bacula_mycastle/etc/query.sql
WorkingDirectory = /usr/local/bacula_mycastle/var/bacula/working
PidDirectory = /var/run
Maximum Concurrent Jobs = 1
Password = removed...
Messages = Daemon
}
#
# INCLUDES:
#
@server_configs/kninfra01_mycastle.conf
@server_configs/BackupCatalog.conf
@server_configs/RestoreFiles.conf
@server_configs/mycastledb01.conf
@server_configs/mycastleapp01.conf
@server_configs/mycastletest01.conf
@server_configs/mycastledb02.conf
#
# SCHEDULES:
#
@schedule_configs/WeeklyCycle.conf
@schedule_configs/WeeklyCycleAfterBackup.conf
@schedule_configs/mycastle_schedule.conf
#
# STORAGE DEFINITIONS
#
@storage_definitions/vtape_mycastle.conf
#
# POOLS:
#
@pool_definitions/vtape_mycastle_pool.conf
#
# CATALOGS:
#
@catalog_definitions/MCCatalog.conf
#
# MESSAGING:
#
@message_definitions/Standard_messages.conf
@message_definitions/Daemon_messages.conf
#
# CONSOLES:
#
@console_definitions/default_console.conf
-Jeff Humes
James Harper wrote:
Do any of the configuration files allow an include statement? What about
an include statement to include all files in a directory? Eg
Director {
Name = my-dir
...
}
include /etc/bacula/bacula-dir.d/
My bacula-dir.conf only has a few clients in it and is already huge.
Breaking up the config would also allow simpler manipulation by a GUI.
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.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
-
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.phpp=sourceforgeCID=DEVDEV___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] include statement in config files?
Yes, but not a dir as far as I know. This is in the manual, and as I recall is
rather obviously explained.
Use an @/path/to/include.conf
-Original Message-
From: James Harper [EMAIL PROTECTED]
Subj: [Bacula-users] include statement in config files?
Date: Wed Dec 27, 2006 12:11 am
Size: 883 bytes
To: bacula-users@lists.sourceforge.net
Do any of the configuration files allow an include statement? What about
an include statement to include all files in a directory? Eg
Director {
Name = my-dir
...
}
include /etc/bacula/bacula-dir.d/
My bacula-dir.conf only has a few clients in it and is already huge.
Breaking up the config would also allow simpler manipulation by a GUI.
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.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
-
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.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] include statement in config files?
[EMAIL PROTECTED] wrote:
for an individual file include you can place an @ in front of the
filename.
I dont think that there is a full directory include at this time.
Here is an example of my bacula-dir.conf:
Director {
Name = kninfra01_mycastle-dir
DIRport = 9501
QueryFile = /usr/local/bacula_mycastle/etc/query.sql
WorkingDirectory = /usr/local/bacula_mycastle/var/bacula/working
PidDirectory = /var/run
Maximum Concurrent Jobs = 1
Password = removed...
Messages = Daemon
}
#
# INCLUDES:
#
@server_configs/kninfra01_mycastle.conf
@server_configs/BackupCatalog.conf
@server_configs/RestoreFiles.conf
@server_configs/mycastledb01.conf
@server_configs/mycastleapp01.conf
@server_configs/mycastletest01.conf
@server_configs/mycastledb02.conf
#
# SCHEDULES:
#
@schedule_configs/WeeklyCycle.conf
@schedule_configs/WeeklyCycleAfterBackup.conf
@schedule_configs/mycastle_schedule.conf
#
# STORAGE DEFINITIONS
#
@storage_definitions/vtape_mycastle.conf
#
# POOLS:
#
@pool_definitions/vtape_mycastle_pool.conf
#
# CATALOGS:
#
@catalog_definitions/MCCatalog.conf
#
# MESSAGING:
#
@message_definitions/Standard_messages.conf
@message_definitions/Daemon_messages.conf
#
# CONSOLES:
#
@console_definitions/default_console.conf
-Jeff Humes
James Harper wrote:
Do any of the configuration files allow an include statement? What about
an include statement to include all files in a directory? Eg
Director {
Name = my-dir
...
}
include /etc/bacula/bacula-dir.d/
My bacula-dir.conf only has a few clients in it and is already huge.
Breaking up the config would also allow simpler manipulation by a GUI.
Thanks
James
Hi -
This is how I've been doing it, too. It's been working quite well,
however, a way to include a directory would be convenient.
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.phpp=sourceforgeCID=DEVDEV
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
