Before backing up a particular database server for the first time, gather some information and decide on some directory names, as outlined in the following table.

For most backup operations, the mysqlbackup command connects to the MySQL server through --user and --password options. This user requires certain privileges. You can either create a new user with a minimal set of privileges, or use an administrative account such as the root user.

The minimum privileges for the MySQL user that mysqlbackup connects are:

To set these privileges for a MySQL user (mysqlbackup in this example) connecting from localhost, issue statements like the following from the mysql client program:

GRANT RELOAD ON *.* TO 'mysqlbackup'@'localhost';
GRANT CREATE, INSERT, DROP, UPDATE ON mysql.backup_progress TO 'mysqlbackup'@'localhost';
GRANT CREATE, INSERT, SELECT, DROP, UPDATE ON mysql.backup_history TO 'mysqlbackup'@'localhost';
GRANT REPLICATION CLIENT ON *.* TO 'mysqlbackup'@'localhost';
GRANT SUPER ON *.* TO 'mysqlbackup'@'localhost';

The following additional privileges are required for using transportable tablespaces (TTS) to back up and restore InnoDB tables:

To set these privileges, issue a statement like the following from the mysql client program:

GRANT LOCK TABLES, SELECT, CREATE, ALTER ON *.* TO 'mysqlbackup'@'localhost';

All backup-related operations either create new files or reference existing files underneath a specified directory that holds backup data. Choose this directory in advance, on a file system with sufficient storage. (It could even be remotely mounted from a different server.) You specify the path to this directory with the --backup-dir option for many invocations of the mysqlbackup command.

Once you establish a regular backup schedule with automated jobs, it is preferable to keep each backup within a timestamped subdirectory underneath the main backup directory. To make the mysqlbackup command create these subdirectories automatically, specify the --with-timestamp option each time you run mysqlbackup.

For one-time backup operations, for example when cloning a database to set up a replication slave, you might specify a new directory each time, or specify the --force option of mysqlbackup to overwrite older backup files.

In this example, we specify all required options on the command line for illustration purposes. After testing and standardizing the backup procedure, we could move some options to the MySQL configuration file. The options specify connection information for the database and the location to store the backup data. The final option backup specifies the type of operation, because mysqlbackup can perform several kinds of backup, restore, and pack/unpack operations.

For this example, we specify the final option as backup-and-apply-log. This option performs an extra stage after the initial backup, to bring all InnoDB tables up-to-date with any changes that occurred during the backup operation, so that the backup is immediately ready to be restored. For backups of huge or busy databases, you might split up these stages to minimize load on the database server. That is, run mysqlbackup first with the backup option, transfer the backup to another server, then run mysqlbackup with the apply-log option to perform the final processing.

The output echoes all the parameters used by the backup operation, including several that are retrieved automatically using the database connection. The unique ID for this backup job is recorded in special tables that mysqlbackup creates inside the instance, allowing you to monitor long-running backups and view the results of previous backups. The final output section repeats the location of the backup data and provides the LSN values that you might use when you perform an incremental backup next time over the full backup that is just made.

$ ./mysqlbackup --user=root -p --backup-dir=/home/admin/backups backup-and-apply-log

MySQL Enterprise Backup version 3.11.1 Linux-2.6.18-274.el5-i686 [2014/09/04]
Copyright (c) 2003, 2014, Oracle and/or its affiliates. All Rights Reserved.

 mysqlbackup: INFO: Starting with following command line ...
 ./mysqlbackup --user=root -p --backup-dir=/home/admin/backups
        backup-and-apply-log

 mysqlbackup: INFO:
Enter password:
 mysqlbackup: INFO: MySQL server version is '5.6.17-log'.
 mysqlbackup: INFO: Got some server configuration information from running server.

IMPORTANT: Please check that mysqlbackup run completes successfully.
           At the end of a successful 'backup-and-apply-log' run mysqlbackup
           prints "mysqlbackup completed OK!".

140904 12:34:54 mysqlbackup: INFO: MEB logfile created at /home/admin/backups/meta/MEB_2014-09-04.12-34-54_backup_apply_log.log

--------------------------------------------------------------------
                       Server Repository Options:
--------------------------------------------------------------------
  datadir = /var/lib/mysql/
  innodb_data_home_dir =
  innodb_data_file_path = ibdata1:12M:autoextend
  innodb_log_group_home_dir = /var/lib/mysql/
  innodb_log_files_in_group = 2
  innodb_log_file_size = 50331648
  innodb_page_size = 16384
  innodb_checksum_algorithm = innodb
  innodb_undo_directory = /var/lib/mysql/
  innodb_undo_tablespaces = 0
  innodb_undo_logs = 128

--------------------------------------------------------------------
                       Backup Config Options:
--------------------------------------------------------------------
  datadir = /home/admin/backups/datadir
  innodb_data_home_dir = /home/admin/backups/datadir
  innodb_data_file_path = ibdata1:12M:autoextend
  innodb_log_group_home_dir = /home/admin/backups/datadir
  innodb_log_files_in_group = 2
  innodb_log_file_size = 50331648
  innodb_page_size = 16384
  innodb_checksum_algorithm = innodb
  innodb_undo_directory = /home/admin/backups/datadir
  innodb_undo_tablespaces = 0
  innodb_undo_logs = 128

 mysqlbackup: INFO: Unique generated backup id for this is 14098484948398421

 mysqlbackup: INFO: Creating 14 buffers each of size 16777216.
140904 12:34:57 mysqlbackup: INFO: Full Backup operation starts with following threads
        1 read-threads    6 process-threads    1 write-threads
140904 12:34:57 mysqlbackup: INFO: System tablespace file format is Antelope.
140904 12:34:57 mysqlbackup: INFO: Starting to copy all innodb files...
140904 12:34:57 mysqlbackup: INFO: Found checkpoint at lsn 1611237.
140904 12:34:57 mysqlbackup: INFO: Starting log scan from lsn 1610752.
140904 12:34:57 mysqlbackup: INFO: Copying log...
140904 12:34:57 mysqlbackup: INFO: Log copied, lsn 1611237.
140904 12:34:57 mysqlbackup: INFO: Copying /var/lib/mysql/ibdata1 (Antelope file format).
140904 12:34:59 mysqlbackup: INFO: Completing the copy of innodb files.
140904 12:34:59 mysqlbackup: INFO: Starting to copy Binlog files...
140904 12:34:59 mysqlbackup: INFO: Preparing to lock tables: Connected to mysqld server.
140904 12:34:59 mysqlbackup: INFO: Starting to lock all the tables...
140904 12:35:00 mysqlbackup: INFO: All tables are locked and flushed to disk
140904 12:35:00 mysqlbackup: INFO: Opening backup source directory '/var/lib/mysql/'
140904 12:35:00 mysqlbackup: INFO: Starting to backup all non-innodb files in
    subdirectories of '/var/lib/mysql/'
140904 12:35:00 mysqlbackup: INFO: Copying the database directory 'performance_schema'
140904 12:35:01 mysqlbackup: INFO: Completing the copy of all non-innodb files.
140904 12:35:01 mysqlbackup: INFO: Completed the copy of binlog files...
140904 12:35:02 mysqlbackup: INFO: A copied database page was modified at 1611237.
          (This is the highest lsn found on page)
          Scanned log up to lsn 1611237.
          Was able to parse the log up to lsn 1611237.
          Maximum page number for a log record 0
140904 12:35:02 mysqlbackup: INFO: All tables unlocked
140904 12:35:02 mysqlbackup: INFO: All MySQL tables were locked for 2.530 seconds.
140904 12:35:03 mysqlbackup: INFO: Reading all global variables from the server.
140904 12:35:03 mysqlbackup: INFO: Completed reading of all global variables from the server.
140904 12:35:03 mysqlbackup: INFO: Creating server config files server-my.cnf and server-all.cnf in /home/admin/backups
140904 12:35:03 mysqlbackup: INFO: Full Backup operation completed successfully.
140904 12:35:03 mysqlbackup: INFO: Backup created in directory '/home/admin/backups'
140904 12:35:03 mysqlbackup: INFO: MySQL binlog position: filename mysqld-bin.000001, position 120

-------------------------------------------------------------
   Parameters Summary        
-------------------------------------------------------------
   Start LSN                  : 1610752
   End LSN                    : 1611237
-------------------------------------------------------------


 mysqlbackup: INFO: Creating 14 buffers each of size 65536.
140904 12:35:03 mysqlbackup: INFO: Apply-log operation starts with following threads
        1 read-threads    1 process-threads
 mysqlbackup: INFO: Using up to 100 MB of memory.
140904 12:35:03 mysqlbackup: INFO: ibbackup_logfile's creation parameters:
          start lsn 1610752, end lsn 1611237,
          start checkpoint 1611237.
 mysqlbackup: INFO: InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
 mysqlbackup: INFO: InnoDB: Setting log file size to 50331648
 mysqlbackup: INFO: InnoDB: Setting log file size to 50331648
140904 12:35:14 mysqlbackup: INFO: We were able to parse ibbackup_logfile up to
          lsn 1611237.
 mysqlbackup: INFO: Last MySQL binlog file position 0 120, file name mysqld-bin.000001:120
140904 12:35:14 mysqlbackup: INFO: The first data file is '/home/admin/backups/datadir/ibdata1'
          and the new created log files are at '/home/admin/backups/datadir'
140904 12:35:14 mysqlbackup: INFO: Apply-log operation completed successfully.
140904 12:35:14 mysqlbackup: INFO: Full backup prepared for recovery successfully.

mysqlbackup completed OK!

Now the backup subdirectory is created under the backup-dir we specified. The directory name for each new backup is formed from the date and the clock time when the backup run was started, in the local time zone. The backup directory contains the backed-up ibdata files and ibbackup_logfile. Each subdirectory corresponds to a MySQL database, and contains copies of .frm, .MYD, .MYI, and similar files. For an example of the layout of such a backup directory, see Section C.1, “Sample Directory Structure for Full Backup”.

To verify the backup, restore the backup data on a different server and run the MySQL daemon (mysqld) on the new data directory. Then you can execute SHOW statements to verify the database and table structure, and execute queries to verify the number of rows, latest updates, and so on.

This is the same general technique to use when you intend to put the backup data to some other use. For example, you might set up a replication slave by making a backup of the master server, or turn a backup into a new MySQL instance for running report queries.

If you did the backup with the backup-and-apply-log option as in the previous example, the backup data is fully consistent and ready to verify. If you only ran the first stage by using the backup option, run mysqlbackup a second time with the apply-log option before doing this verification. (Typically, you run this second phase on the other server after transferring the backup data there, to minimize the load on the original database server.)

See Chapter 4, Recovering or Restoring a Database for the procedure to restore the database files on a different server.

Running the mysqld daemon on the restored data requires a valid configuration file, which you specify with the --defaults-file option of the mysqld command. You can reuse most of the settings from the original my.cnf file, combined with the backup-my.cnf file in the backup directory, which contains only the small subset of parameters required by mysqlbackup. Create a new configuration file by concatenating those two files into a new one, and use that configuration file on the server where you do the verification. Edit the resulting file to make sure the datadir parameter points to the right location on the verification server. directory. Edit the values for port, socket, and so on if you need to use different connection settings on the verification server.

To restore a MySQL instance from a backup:

$ mysqlbackup --defaults-file=path_to_my.cnf \
  --datadir=path_to_data_directory \
  --backup-dir=path_to_backup_directory copy-back
...many lines of output...
mysqlbackup: Finished copying backup files.

101208 16:48:13 mysqlbackup: mysqlbackup completed OK!

Now the original database directory is restored from the backup, and you can restart the database server.

Most backup strategies start with a complete backup of the MySQL server, from which you can restore all databases and tables. After you do one full backup, you might do incremental backups (which are smaller and faster) for the next several backup jobs. Periodically, you then do another full backup to begin the cycle again.

This section outlines some of the considerations for making this most basic kind of backup. Because a full backup can take longer and produce larger backup files then other kinds of backups, your decisions about speed, capacity, and convenience are especially important for this part of the backup strategy.

For examples showing the commands to make a full backup, see Section 3.2.1, “Backing Up an Entire MySQL Instance”.

Options on Command Line or in Configuration File?

For clarity, the examples in this manual typically show command-line options to demonstrate connection parameters and other information that might be the same for each backup job. For convenience and consistency, you can include these options in the [mysqlbackup] section of the MySQL configuration file that you pass to the mysqlbackup command; mysqlbackup also picks them up from the [mysqld] section if they are present. For example, relying on the port information in the configuration file avoids the need to edit your backup scripts if the database instance switches to a different port.

Output in Single Directory or Timestamped Subdirectories?

For convenience, the --with-timestamp option creates uniquely named subdirectories under the backup directory to hold the output from each backup job. The timestamped subdirectories make it simpler to establish retention periods, for example by removing or archiving backup data past a certain age. This option is NOT set on default.

If you do use a single backup directory (that is, if you omit the --with-timestamp option), either specify a new unique directory name for each backup job, or specify the --force option to overwrite existing backup files.

With the --incremental-base option, as part of each incremental backup command, you specify the directory containing the previous backup. To make the directory names predictable, you might prefer to leave out the --with-timestamp option and instead generate a sequence of directory names as part of your backup script.

Always Full Backup, or Full Backup plus Incremental Backups?

If your InnoDB data volume is small, or if your database is so busy that a high percentage of data changes between backups, you might run a full backup each time. Typically, you can save time and storage space by running periodic full backups, and in between running several incremental backups, as described in Section 3.3.2, “Making an Incremental Backup”.

Use Compression or Not?

Creating a compressed backup can save you considerable storage space and reduce I/O significantly. And with the LZ4 compression method (introduced since release 3.10), the overhead for processing compression is quite low. In cases where database backups are moving from a faster disk system where the active database files sit to a possibly slower storage, compression will often significantly lower the overall backup time. It can result in reduced restoration time as well. In general, we recommend LZ4 compression over no compression for most users, as LZ4-based backups often finish in a shorter time period. However, test out MySQL Enterprise Backup within your environment to determine what is the most efficient approach.

An incremental backup only backs up data that changed since the previous backup. This technique provides additional flexibility in designing a backup strategy and reduces required storage for backups.

Incremental backups are typically smaller and take less time than a full backup, making them a good choice for frequent backup jobs. Taking frequent incremental backups ensures you can always restore the database to the same state as a few hours or days in the past, without as much load or storage overhead on the database server as taking frequent full backups.

Incremental backup is enabled through an option to the mysqlbackup command. For straightforward incremental backups, specify the --incremental option. An alternative method uses the --incremental-with-redo-log-only option, requiring additional planning on your part.

You also indicate the point in time of the previous full or incremental backup. For convenience, you can use the --incremental-base option to automatically derive the necessary log sequence number (LSN) from the metadata stored in a previous backup directory. Or, you can specify an explicit LSN value using the --start-lsn option, using the ending LSN from a previous full or incremental backup.

To prepare the backup data to be restored, you combine each incremental backup with an original full backup. Typically, you perform a new full backup after a designated period of time, after which you can discard the older incremental backup data.

When running the “apply log” step for an incremental backup, you specify the option sequence --incremental apply-log, and the paths to 2 MySQL configuration files, first the .cnf file pointing to the full backup that you are updating, then the .cnf file pointing to the incremental backup data files. If you have taken several incremental backups since the last full backup, you might run several such “apply log” steps, one after the other, to bring the full backup entirely up to date.

Space Considerations for Incremental Backups

The incremental backup feature is primarily intended for InnoDB tables, or non-InnoDB tables that are read-only or rarely updated. For non-InnoDB files, the entire file is included in an incremental backup if that file changed since the previous backup.

You cannot perform incremental backups with the --compress option.

Incremental backups detect changes at the level of pages in the InnoDB data files, as opposed to table rows; each page that has changed is backed up. Thus, the space and time savings are not exactly proportional to the percentage of changed InnoDB rows or columns.

Examples of Incremental Backups

This example uses the mysqlbackup command to make an incremental backup of a MySQL server, including all databases and tables. We show two alternatives, one using the --incremental-base option and the other using the --start-lsn option.

With the --incremental-base option, you do not have to keep track of LSN values between one backup and the next. Instead, you specify the directory of the previous backup (either full or incremental), and mysqlbackup figures out the starting point for this backup based on the metadata of the earlier one. Because you need a known set of directory names, you might use hardcoded names or generate a sequence of names in your own backup script, rather than using the --with-timestamp option.

$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
  --incremental-base=dir:/incr-backup/wednesday \
  --incremental-backup-dir=/incr-backup/thursday \
  backup
...many lines of output...
mysqlbackup: Backup created in directory '/incr-backup/thursday'
mysqlbackup: start_lsn: 2654255717
mysqlbackup: incremental_base_lsn: 2666733462
mysqlbackup: end_lsn: 2666736714

101208 17:14:58 mysqlbackup: mysqlbackup completed OK!

With the --start-lsn option, you do have to record the LSN of the previous backup, but then the location of the previous backup is less significant, so you can use --with-timestamp to create named subdirectories automatically.

$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
  --start-lsn=2654255716 \
  --with-timestamp \
  --incremental-backup-dir=/incr-backup \
  backup
...many lines of output...
mysqlbackup: Backup created in directory '/incr-backup/2010-12-08_17-14-48'
mysqlbackup: start_lsn: 2654255717
mysqlbackup: incremental_base_lsn: 2666733462
mysqlbackup: end_lsn: 2666736714

101208 17:14:58 mysqlbackup: mysqlbackup completed OK!

Wherever you use the --incremental option, you can use the --incremental-with-redo-log-only option instead. Because --incremental-with-redo-log-only is more dependent on the precise LSN than the --incremental option is, use the --incremental-base option rather than the --start-lsn option with this kind of incremental backup.

For this alternative kind of incremental backup to work, the volume of changed information must be low enough, and the redo log files must be large enough, that all the changes since the previous incremental backup must be present in the redo log and not overwritten. See the --incremental-with-redo-log-only option description to learn how to verify those requirements.

$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
  --incremental-base=dir:/incr-backup/wednesday \
  --incremental-backup-dir=/incr-backup/thursday \
  backup
...many lines of output...
mysqlbackup: Backup created in directory '/incr-backup/thursday'
mysqlbackup: start_lsn: 2654255717
mysqlbackup: incremental_base_lsn: 2666733462
mysqlbackup: end_lsn: 2666736714

101208 17:14:58 mysqlbackup: mysqlbackup completed OK!

See Section C.3, “Sample Directory Structure for Incremental Backup” for a listing of files from a typical incremental backup.

Once again, we apply to the full backup any changes that occurred while the backup was running:

$ mysqlbackup --backup-dir=/full-backup/2010-12-08_17-14-11 apply-log
..many lines of output...
101208 17:15:10  mysqlbackup: Full backup prepared for recovery successfully!

101208 17:15:10 mysqlbackup: mysqlbackup completed OK!

Then, we apply the changes from the incremental backup:

$ mysqlbackup --incremental-backup-dir=/incr-backup/2010-12-08_17-14-48 
  --backup-dir=/full-backup/2010-12-08_17-14-11 apply-incremental-backup
...many lines of output...
101208 17:15:12 mysqlbackup: mysqlbackup completed OK!

Now, the data files in the full backup directory are fully up-to-date, as of the time of the last incremental backup.

This example shows an incremental backup. The last full backup we ran reported that the highest LSN was 2638548215:

mysqlbackup: Was able to parse the log up to lsn 2638548215

We specify that number again in the command here; the incremental backup includes all changes that came after the specified LSN.

$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
  --start-lsn=2638548215 \
  --incremental-backup-dir=/incr-backup/2010-12-08_17-14-48 \
  --backup-dir=/full-backup/2010-12-08_17-14-11 \
	backup
...many lines of output...
mysqlbackup: Scanned log up to lsn 2654252454.
mysqlbackup: Was able to parse the log up to lsn 2654252454.
mysqlbackup: Maximum page number for a log record 0
mysqlbackup: Backup contains changes from lsn 2638548216 to lsn 2654252454
101208 17:12:24  mysqlbackup: Incremental backup completed!

Next steps:

To save disk space, you can compress InnoDB backup data files by using the --compress option of mysqlbackup. Compression lets you keep more sets of backup data on hand and save on transmission time when sending the backup data to another server. The downside includes the extra CPU overhead during the backup itself and the extra time needed for the restoration process for uncompressing the data.

The backup compression feature works only for InnoDB tables. After the InnoDB tablespace files are compressed during backup, they receive the .ibz extension rather than the usual .ibd extension. To avoid wasting CPU cycles without saving additional disk space, --compress does not attempt to compress already-compressed tables that use the Barracuda file format; such tablespace files keep the usual .ibd extension.

You can only use the --compress option for full backups, but not for incremental backups.

You can also select the compression algorithm to use by the --compress-method option and, when using the ZLIB or LZMA compression algorithm, the level of compression by the --compress-level option. See Section 5.1.7, “Compression Options” for details.

This is a sample command for making a compressed backup:

mysqlbackup --defaults-file=/etc/my.cnf --compress --compress-level=5 backup

This is a sample command for making a compressed single-file backup:

mysqlbackup --defaults-file=/etc/my.cnf --compress --compress-level=5 \
  --backup-image=backup.img backup-to-image

Next steps:

By default, all the files in the data directory are included in the backup, so that the backup includes data from all MySQL storage engines, any third-party storage engines, and even any non-database files in that directory. This section explains options you can use to selectively back up or exclude data.

There are various ways to create different kinds of partial backup with MySQL Enterprise Backup:

For syntax details on all the options involved, see Section 5.1.9, “Partial Backup and Restore Options”.

The following are some command samples for partial backups.

Including all tables with names starting with “emp” into the backup:

$ mysqlbackup \
 --host=localhost --user=mysqluser --protocol=TCP --port=3306 \
 --backup-dir=$MEB_BACKUPS_DIR/backupdir \ --include-tables='\.emp' \
 backup

Taking a backup of all tables except tables from the “mysql” and “performance_schema” databases:

$ mysqlbackup \
 --host=localhost --user=mysqluser --protocol=TCP --port=3306 \
 --backup-dir=$MEB_BACKUPS_DIR/backupdir \
 --exclude-tables='^(mysql|performance_schema)\.' \
 backup

Taking a backup of all tables in the “sales” database, but excludes the table with the name “hardware”

$ mysqlbackup \
 --host=localhost --user=mysqluser --protocol=TCP --port=3306 \
 --backup-dir=$MEB_BACKUPS_DIR/backupdir \
 --include-tables='^sales\.' --exclude-tables='^sales\.hardware$' \
 backup

Backing up all InnoDB tables, but not .frm files:

$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --only-innodb backup

You can also make compressed, single-image, and other kinds of selective backups by adding the appropriate options.

Next Steps:

Making a Partial Backup with the Legacy Options

MySQL Enterprise Backup can make different kinds of partial backup using the legacy partial-backup options:

For syntax details on all these options, see Legacy Partial Backup Options.

With its --include option, mysqlbackup can make a backup that includes some InnoDB tables but not others:

This operation requires the tables being left out to be stored in separate table_name.ibd files. To put an InnoDB table outside the system tablespace, create it while the innodb_file_per_table MySQL configuration option is enabled. Each .ibd file holds the data and indexes of one table only.

Those InnoDB tables created with innodb_file_per_table turned off are stored as usual in the InnoDB system tablespace, and cannot be left out of the backup.

For each table with a per-table data file a string of the form db_name.table_name is checked against the regular expression specified with the --include option. If the regular expression matches the complete string db_name.table_name, the table is included in the backup. The regular expression syntax used is the extended form specified in the POSIX 1003.2 standard. On Unix-like systems, quote the regular expression appropriately to prevent interpretation of shell meta-characters. This feature has been implemented with Henry Spencer's regular expression library.

The backup directory produced contains a backup log file and copies of InnoDB data files.

IMPORTANT: Although the mysqlbackup command supports taking partial backups, be careful when restoring a database from a partial backup. mysqlbackup copies also the .frm files of those tables that are not included in the backup, except when you do partial backups using, for example, the --databases option. If you use mysqlbackup with the --include option, before restoring the database, delete from the backup data the .frm files for any tables that are not included in the backup.

IMPORTANT: Because the InnoDB system tablespace holds metadata about InnoDB tables from all databases in an instance, restoring a partial backup on a server that includes other databases could cause the system to lose track of those InnoDB tables in other databases. Always restore partial backups on a fresh MySQL server instance without any other InnoDB tables that you want to preserve.

The --only-innodb and --only-innodb-with-frm options back up InnoDB tables only, skipping those of other storage engines. You might also use them together with the --include option to make selective backup of InnoDB tables while excluding all other files created by other storage engines.

$ ls /sqldata/mts/test
alex1.frm  alex2.ibd  blobt3.frm    ibstest0.ibd  ibtest11a.frm  ibtest11d.frm
alex1.ibd  alex3.frm  blobt3.ibd    ibtest09.frm  ibtest11b.frm
alex2.frm  alex3.ibd  ibstest0.frm  ibtest09.ibd  ibtest11c.frm

# Back up some InnoDB tables but not any .frm files.
$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --include='test\.ib.*' --only-innodb backup
...many lines of output...
mysqlbackup: Scanned log up to lsn 2666737471.
mysqlbackup: Was able to parse the log up to lsn 2666737471.
mysqlbackup: Maximum page number for a log record 0
101208 17:17:45  mysqlbackup: Full backup completed!

# Back up some InnoDB tables and the .frm files for the backed-up tables only.
$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --include='test\.ib.*' \
  --only-innodb-with-frm=related backup
...many lines of output...
mysqlbackup: Scanned log up to lsn 2666737471.
mysqlbackup: Was able to parse the log up to lsn 2666737471.
mysqlbackup: Maximum page number for a log record 0
101208 17:17:45  mysqlbackup: Full backup completed!

# With the --only-innodb option:
$ ls /sqldata-backup/test
ibstest0.ibd   ibtest09.ibd

# With the --only-innodb-with-frm=related option:
$ ls /sqldata-backup/test
ibstest0.frm   ibtest09.frm
ibstest0.ibd   ibtest09.ibd

$ ls /sqldata/mts/test
alex1.frm  alex2.ibd  blobt3.frm    ibstest0.ibd  ibtest11a.frm  ibtest11d.frm
alex1.ibd  alex3.frm  blobt3.ibd    ibtest09.frm  ibtest11b.frm
alex2.frm  alex3.ibd  ibstest0.frm  ibtest09.ibd  ibtest11c.frm

$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --compress \
  --include='.*\.(alex|blob).*' --only-innodb backup
...many lines of output...
mysqlbackup: Scanned log up to lsn 2666737471.
mysqlbackup: Was able to parse the log up to lsn 2666737471.
mysqlbackup: Maximum page number for a log record 0

mysqlbackup: Compressed 147 MB of data files to 15 MB (compression 89%).

101208 17:18:04  mysqlbackup: Full backup completed!

$ ls /sqldata-backup/test
alex1.ibz   alex2.ibz   alex3.ibz   blobt3.ibz

The --databases and --databases-list-file options of the mysqlbackup command let you back up non-InnoDB tables only from selected databases, rather than across the entire MySQL instance. (To filter InnoDB tables, use the --include option instead.) With --databases, you specify a space-separated list of database names, with the entire list enclosed in double quotation marks. With --databases-list-file, you specify the path of a file containing the list of database names, one per line.

Some or all of the database names can be qualified with table names, to only back up selected non-InnoDB tables from those databases.

If you specify this option, make sure you include the same set of databases for every backup (especially incremental backups), so that you do not restore out-of-date versions of any databases.

To avoid a large number of backup files to track and keep safe, and to simplify moving backup data around, the mysqlbackup command can create a backup in a single-file format, pack an existing backup into a single file, unpack the single file back to the original backup directory structure, list the contents of a single-file backup, verify the contents of a single-file backup against embedded checksums, or extract a single file or directory tree. For the syntax of the relevant mysqlbackup options, see Section 5.1.10, “Single-File Backup Options”.

Because the single-file backup can be streamed or piped to another process, such as a tape backup or a command such as scp, you can use this technique to put the backup on another storage device or server without significant storage overhead on the original database server. (During preparation of the single-file backup, some small work files are prepared temporarily inside the specified backup directory.)

To create a single-file backup, use the mysqlbackup subcommand backup-to-image.

mysqlbackup --backup-image=/backups/sales.mbi --backup-dir=/backup-tmp backup-to-image

mysqlbackup --backup-image=sales.mbi --backup-dir=/backups backup-to-image

mysqlbackup --backup-dir=/backups --backup-image=- backup-to-image > /backup/mybackup.mbi

mysqlbackup --backup-image=/backup/my.mbi --backup-dir=/var/mysql/backup backup-dir-to-image

mysqlbackup --backup-dir=/var/backup --backup-image=/backup/my.mbi image-to-backup-dir

mysqlbackup --backup-image=/backup/my.mbi list-image

mysqlbackup --backup-image=/var/my.mbi extract

mysqlbackup --backup-image=/var/my.mbi --backup-dir=/var/backup extract

mysqlbackup --backup-image=/var/my.mbi \
  --src-entry=meta/comments.txt extract

mysqlbackup --backup-image=/var/my.mbi \
  --src-entry=meta/comments.txt \
  --dst-entry=/tmp/mycomments.txt extract

mysqlbackup --backup-image=/var/my.mbi --src-entry=meta/comments.txt --dst-entry=- extract

mysqlbackup --backup-image=/backup/my.mbi --src-entry=meta extract

mysqlbackup --backup-image=/backup/my.mbi --src-entry=meta \
  --dst-entry=/tmp/my-meta extract

mysqlbackup --backup-image=/backup/my.mbi --src-entry=/ --dst-entry=/myroot extract
mysqlbackup --backup-image=/backup/my.mbi --src-entry=. extract

mysqlbackup --backup-image=- --backup-dir=/tmp backup-to-image | \
ssh user@host command arg1 arg2...

mysqlbackup  --backup-dir=backup --backup-image=-  --compress backup-to-image | \
ssh <user name>@<remote host name> 'mysqlbackup --backup-dir=backup_tmp --datadir=/data \
--innodb_log_group_home_dir=. \
--innodb_log_files_in_group=<innodb_log_files_in_group_of_backedup_server> \
 --innodb_log_file_size=<innodb_log_file_size_of_backedup_server> \ 
--innodb_data_file_path=<innodb_data_file_path_of_backedup_server> \ 
--uncompress --backup-image=- copy-back-and-apply-log'

mysqlbackup --backup-image=- --backup-dir=/path/to/my/backup backup-dir-to-image | \
ssh <user name>@<remote host name> \ 
'mysqlbackup --backup-dir=backup_tmp --datadir=/data --backup-image=- copy-back-and-apply-log'

mysqlbackup\
--cloud-service=s3 --cloud-aws-region=<aws region> \
--cloud-access-key-id=<aws access key id> --cloud-secret-access-key=< aws secret access key> \
--cloud-bucket=<s3 bucket name> --cloud-object-key=<aws object key> \
--backup-dir=/home/user/dba/s3backuptmpdir \
--backup-image=- \
backup-to-image

mysqlbackup\
--cloud-service=s3 --cloud-aws-region=<aws region> \
--cloud-access-key-id=<aws access key id> --cloud-secret-access-key=< aws secret access key> \
--cloud-bucket=<s3 bucket name> --cloud-object-key=<aws object key> \
--backup-dir=/home/user/dba/s3backuptmpdir \
--backup-image=- \
image-to-backup-dir

Optimistic backup is a feature introduced in MySQL Enterprise Backup 3.11 for improving performance for backing up and restoring huge databases in which only a small number of tables are modified frequently.

During a hot backup of a huge database (say, in the order of terabytes), huge redo log files could be generated on the server when the backup is in progress. As the redo log files grow faster than they can be processed by mysqlbackup, the backup operation can actually fail when mysqlbackup cannot catch up with the redo log cycles and LSNs get overwritten by the server before they are read by mysqlbackup. Moreover, the apply-log step for preparing a backup for restoration can take a very long time as mysqlbackup has huge ibbackup_logfile files (created from the big redo log files) to apply to the backup. The problems are intensified when the I/O resources available for reading and writing the redo logs are scarce during the backup and restoration processes.

Optimistic backup relieves the problems by dividing the backup process into two internal phases, which are transparent to the users:

An optimistic backup occurs whenever the optimistic-time or optimistic-busy-tables option is used. For how to use the options, see detailed descriptions for them in Section 5.1.11, “Performance / Scalability / Capacity Options”. If, as expected, the inactive tables identified by the options are not changed a lot during the backup, the overall backup time (time for the backup operation plus time for the apply-log operation) can be reduced significantly comparing with an ordinary backup because the apply-log operation will be much faster. However, if it turns out that the inactive tables identified are modified a lot during the backup process, benefits of performing an optimistic back up will become limited and, in the worst case, an optimistic backup might actually take longer to perform and, for a single-file backup, the size of the backup will be larger when comparing with an ordinary backup. Therefore, users should be careful in identifying which tables are “inactive” and which are “busy” when trying to perform an optimistic backup.

The following examples illustrate how to make an optimistic backup.

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-time=110516120000 backup

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-time=now backup

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-busy-tables='mydatabase\.mytables-.*'  backup

When you use both the optimistic-time and optimistic-busy-tables options and they come into conflict on determining which tables are to be busy tables, optimistic-busy-tables takes precedence over optimistic-time. For example:

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-busy-tables='mydatabase\.mytables-.*'  \
--optimistic-time=100516 backup

The --exec-when-locked option of the mysqlbackup command lets you specify a command and arguments to run near the end of the backup, while the database is still locked. This command can copy or create additional files in the backup directory. For example, you can use this option to back up MEMORY tables with the mysqldump command, storing the output in the backup directory. To delay any redirection or variable substitution until the command is executed, enclose the entire parameter value within single quotes.

Maintaining a regular backup schedule is an important measure for preventing data loss for you MySQL server. This section discusses some simple means for setting up a schedule for running MySQL Enterprise Backup.

For Linux and other Unix-like platforms: you can set up a cron job on your system for scheduled backups. There are two types of cron jobs. To set up a user cron job, which is owned and run by a particular user, do the following:

To set up a system cron job, which is owned and run by root, create a file under the /etc/cron.d folder and put into it a similar crontab entry as the one above, adding the user (root in the following example) before the mysqlbackup command:

@daily root /path-to-mysqlbackup/mysqlbackup -uroot --backup-dir=/path-to-backup-folder/cronbackups --with-timestamp backup  &>/dev/null 

Check your platform's documentation for further details on the different ways to set up cron jobs for various types of schedules.

For Windows platforms: Use the Task Scheduler for the purpose. Check the documentation for your Windows platform for instructions.