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 AT lists.sourceforge DOT 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
