|
Re: [Bacula-users] disaster recovery of the actual bacula server
2012-11-29 19:38:34
|
Le 29/11/2012 21:58, Dan Langille a
écrit :
On Nov 29, 2012, at 10:30 AM, Jonathan Horne wrote:
I am getting
ready to deploy my first bacula server to our
production environment. I would like to practice 2
scenarios of recovery. First, I will recover the
configuration files and mysql database (from dump
files), and hopefully continue on. The second, I will
recover only the configuration files. Both scenarios,
will tear down the server and rebuild new OS and
reattach the LUN where the volume pools are stored.
The first
seems pretty straight forward, especially is the
mysqldump is current after the most recent backups
that ran. The 2nd, poses the question of
how to import existing volume pool data into a new
bacula director installation?
Any advice
or acedotes from when this has been previously
performed would be appreciated.
Every day:
- copy your Catalog dump (i.e. a text file) to another
location
- copy your *.conf files to the same location
At that location, use log rotate to keep N copies of those
files sitting around.
I do the above to three different locations: one on-site, two
off-site.
Hello,
I used Netbackup for years. When I used it, the catalog was not a
real database, and had to be backed up with Netbackup tools. To
secure the current version, we had a 3-part mirror on 2 remote SAN +
local disks. As Bacula stores most data pieces in text files or in a
mainstream database, you can do everything you can imagine on
databases:
1 - For mysql databases, just forget mysqldump. As soon as your
database will grow, restore from a dump will become longer and
longer. I use mylvmbackup on databases which are modified all the
times (huge environments). For quieter databases, I use mydumper. Of
course, you have to keep several versions of this backup (as you
already do for every thing else, isn't it ? ;-) )
2 - Enable binary logging and export binary logs to another server
often. Hourly is a good start. If you can, you can even imagine to
store binary logs on a remote filesystem. This way, you always have
the latest version of binary logs on another server.
3 - You can imagine to use a MySQL slave to ensure you have at least
2 versions of the same catalog at the same time. In case of crash,
you won't loose your catalog.
3 does not replace 1 and 2 as a slave is "just" a snapshot. If the
database is corrupted, it will be on both servers and you will have
to recover it from backups.
HTH.
Jerome Blion.
|
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net _______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
|
|
