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 2^nd , 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.
--
Dan Langille - http://langille.org
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
