=head1 NAME

bacula-backup-mysql - A hook for Bacula to backup mysql databases using mysqlhotcopy or mysqldump.

=head1 SYNOPSIS

Job { Name = "example.org-mysql" ... # This prepares the backup Client Run Before Job = "/usr/sbin/bacula-backup-mysql" # This deletes the copy of the catalog Client Run After Job = "/usr/sbin/bacula-backup-mysql -cleanup" }

=head1 DESCRIPTION

This is a script to be setup as C<Client Run Before Job> in Bacula.

=head1 CONFIGURATION

Config starts with C<EclustersE> block, which you can define several database instances to be backed up.

Each C should define connection dsn and databases to be backed up.

To define connection dsn, you can also define common options in C<EclientE> section, those options would be shared for each cluster which has not overriden the specific option.

In C<EclusterE> sections, you should list databases to be backed up. You can use C<include_database> options to explicitly list which databases should be backed up, and C<exclude_database> options to explicitly list those that should not.

Additionally C<include_database> supports table regexp, which is passed directly to L<mysqlhotcopy(1)>. This allows you to include or exclude tables from each database backup.

Unless you only specify C<include_database> options, all databases which can be seen with a C query are considered for backup; any C<exclude_database> options will reduce this list.

Since v0.6 it's possible to do SQL dump backups with L<mysqldump(1)>. Use this if you want to backup InnoDB databases. Option name is C<dump_type>, which takes values C (default) and C.

Since v0.7 you can pass arbitary options to C or C using C<mysqlhotcopy_options> or C<mysqldump_options> respectively. Use this to pass options like C<--old_server>.

Ordinarily, using C<include_database> and C options in the same C cause the C<include_database> option to be unnecessary, as the existence of any C<exclude_database> options implicitly includes all available databases obtained from C. However, when using a C<dump_type> of C, the C<include_database> option can be further configured to specify the exact tables to be backed up, giving the user far more control over the process.

Dump type C allows you to pass C<--record_log_pos log-pos-table> option to C. The C table must already exist, see C for the table schema. Please note that this option is not safe to use when backing up more than one database, because current operation backs up each database with separate C call and so the log pos is saved with each call overwriting the previous.

=head1 EXAMPLE CONFIGURATION

clusters to backup

there is nothing special about name "mysql", name just picked as convience

client connection parameters, can be overriden per cluster

global options, can be overriden per cluster

mysql cluster: backup all but mysql database

forums cluster: exclude phorum_forums and phorum_users tables

# include_database can also support table regexp for mysqlhotcopy:
include_database teensForum5./~(phorum_forums|phorum_users)/

selected_dbs cluster: backup all except mysql, and be specific about tables

in the teensForum5 database

# can be specific about tables when using mysqlhotcopy:
include_database teensForum5./~(phorum_forums|phorum_users)/

=head1 BUGS

If you find bugs in L<bacula-backup-mysql(1)>, file the reports into L<Bugtracker|https://github.com/glensc/bacula-backup-mysql/issues> or even better, send L<Pull Request|https://github.com/glensc/bacula-backup-mysql/pulls> with a fix.

There are also bugs in L<mysqlhotcopy(1)>, see from L<Wiki|https://github.com/glensc/bacula-backup-mysql/wiki> if your version nees patching.

In C mode C<record_log_pos> option is useless if cluster contains more than one database.

=head1 AUTHOR

Copyright (C) 2009-2016, Elan RuusamEe [email protected]

=head1 SEE ALSO

http://www.bacula.org/, L<Bacula wiki: Application specific backups: mysql|http://wiki.bacula.org/doku.php?id=application_specific_backups:mysql>

=cut