The mysqlbackup client is an easy-to-use tool for all backup and restore operations. During backup operations, mysqlbackup backs up:
All InnoDB tables and indexes, including:
The InnoDB system tablespace, which, by default contains all the InnoDB tables.
Any separate data files produced with the InnoDB file-per-table setting. Each one contains one table and its associated indexes. Each data file can use either the original Antelope or the new Barracuda file format.
All MyISAM tables and indexes.
Tables managed by other storage engines.
Other files underneath the MySQL data directory, such as the
.frmfiles that record the structure of each table.
Any other files in the database subdirectories under the server's data directory.
In addition to creating backups, mysqlbackup can pack and unpack backup data, apply to the backup data any changes to InnoDB tables that occurred during the backup operation, and restore data, index, and log files back to their original locations, or to other places.
Here are some sample commands to start a backup operation with mysqlbackup are:
# Information about data files can be retrieved through the database connection. # Specify connection options on the command line. mysqlbackup --user=dba --password --port=3306 \ --with-timestamp --backup-dir=/export/backups \ backup # Or we can include the above options in the configuration file # under the [mysqlbackup] section, and just specify the configuration file # and the 'backup' operation. mysqlbackup --defaults-file=/usr/local/mysql/my.cnf backup # Or we can specify the configuration file as above, but # override some of those options on the command line. mysqlbackup --defaults-file=/usr/local/mysql/my.cnf \ --compress --user=backupadmin --password --port=18080 \ backup
--user and the
you specify are used to connect to the MySQL server. This MySQL
user must have certain privileges in the MySQL server, as
described in Section 4.1.2, “Grant MySQL Privileges to Backup Administrator”.
--with-timestamp option places the
backup in a subdirectory created under the directory you specified
above. The name of the backup subdirectory is formed from the date
and the clock time of the backup run.
For the meanings of other command-line options, see Chapter 14, mysqlbackup Command-Line Options. For information about configuration files, see Chapter 15, Configuration Files and Parameters.
Make sure that the user or the cron job running mysqlbackup has the rights to copy files from the MySQL database directories to the backup directory.
Make sure that your connection timeouts are long enough so that the mysqlbackup command can keep the connection to the server open for the duration of the backup run. mysqlbackup pings the server after copying each database to keep the connection alive.
Although mysqlbackup backs up InnoDB tables without interrupting database use, the final stage that copies non-InnoDB files (such as MyISAM tables and
.frmfiles) temporarily puts the database into a read-only state, using the statement
FLUSH TABLES WITH READ LOCK. For best backup performance and minimal impact on database processing:
Do not run long
SELECTqueries or other SQL statements at the time of the backup run.
Keep your MyISAM tables relatively small and primarily for read-only or read-mostly work.
Then the locked phase at the end of a mysqlbackup run is short (maybe a few seconds), and does not disturb the normal processing of mysqld much. If the preceding conditions are not met in your database application, use the
--only-innodboption to back up only InnoDB tables, or use the
--no-lockingoption to back up non-InnoDB files. Note that MyISAM,
.frm, and other files copied under the
--no-lockingsetting cannot be guaranteed to be consistent, if they are updated during this final phase of the backup.
For a large database, a backup run might take a long time. Always check that the mysqlbackup command has been completed successfully by verifying that mysqlbackup has returned the exit code 0, or by observing that mysqlbackup has printed the text “mysqlbackup completed OK!”.
mysqlbackup is not the same as the former “MySQL Backup” open source project from the MySQL 6.0 source tree. The MySQL Enterprise Backup product supersedes the MySQL Backup initiative.
Schedule backups during periods when no DDL operations involving tables are running. See Appendix B, Limitations of MySQL Enterprise Backup for restrictions on creating backups in parallel with the DDL operations.