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
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.