Hi, 18.11.2008 13:54, Kevin Thorpe wrote: > Hi all, > I have a single server which is now backed up with bacula. The > fd, sd and director are all on this single server. > I've read the bare metal restore notes but they only really document > restoring a client (fd). What happens if I lose > the director and catalogue? I cant find any documentation on building > such a rescue CD. I suppose worst case I can > install a copy of CentOS and the director in VMware on my pc. I really > need the sd on the rescue CD though, or I'll > have to buy a second tape drive. If I did it that way, I suppose I would > have to transfer the catalog over after each > backup wouldn't I (or can I get it back from the tape? There's no > documentation on that).
You can get that back, and it's also documented. Not in a chapter dedicated to Bacula DR recovery, though. > > I would be gratefiul if anyone can point me in the general direction of > an answer. Unfortunately we're a bit short on > equipment here so I haven't many options. Well, to get a Bacula server system up and running from backups, you need the following: - The OS (obvious) - Bacula programs - The database engine for the catalog - The catalog contents itself As most of the above can easily be installed, the only problem (usually) is the catalog contents. You'll probably need to restore that from Bacula's volumes without having Bacula itself running. That said, now is the time for you to read the manual sections describing bls and bextract and what bootstrap files are good for :-) This is the documentation you need - how it all fits together is, I believe, quite straightforward. More detailed suggestions: One usable approach is to ensure you can quickly restore the latest catalog dump after installing the OS and Bacula. Once you have that available, you can simply feed the catalog dump to the database, then start up Bacula on the newly-installed system and voilà - Bacula is ready for work again. What I would suggest is to store the catalog backups and the related bootstrap files on a separate set of volumes (preferably something like an external hard disk, or a known set of tapes). Then, in case of desaster, you grab those volumes, look at the bootstrap files, make the needed volume(s) accessible, and run bextract. You end up with the latest catalog dump. If your backup server contains lots of data that don't belong to Bacula and the OS, I would suggest to split your backups into several jobs: - one job to save the OS and Bacula. Typically, you would back up /, /usr/, /var, /lib, /boot and so on. You should not include data that is not related to the OS or Bacula. You would need to run a full backup of this job after OS or Bacula upgrades, so exclude /var/log, /var/mail etc. If currectly set up, an incremental backup of this job wouldn't find anything to store. - one job to save Bacula's catalog. I like to add Bacula binaries, configuration and bootstrap files to this one so this job is all that is needed to get Bacula up and running on a freshly installed (identical) OS. - one or more jobs handling all other data - /home, /var/mail, /var/spool, ..., /opt/, /usr/local and whatever you have. In a DR scenario, you could then use some linux live CD with the Bacula tools to re-create filesystems, restore the OS and Bacula to it, restore Baculas catalog, and re-create the boot loader. After the system is rebooted, you then use the "normal" Bacula way to restore the remaining data. But, in my opinion and especially if you need fast recovery after a catastrophic event, distributing Baculas components on separate servers, which are not used for anything else, is advisable: A dedicated Bacula server is not much to back up - only the minimal OS and Bacula itself. The catalog on a different server ensures that, even if the Backup server itself fails, you only need to set up an OS and Bacula, copy Baculas configuration from somewhere else (for example, the catalog database server), and start Bacula - the catalog is still available. If the catalog server fails, you have a machine with the storage hardware configured, the necessary bootstrap files, and the necessary tools to restore the catalog dump to load it to another database server. You'd need at least two machines dying before you have to go through the Bacula-from-bare-metal routine. Arno > thanks > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück www.its-lehmann.de ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
