New argument syntax for the --incremental-base option makes it simpler to perform a sequence of incremental backups. When you specify the option combination--incremental --incremental-base=history:last_backup, the mysqlbackup command uses the metadata in the mysql.backup_history table to determine the LSN to use as the lower limit of the incremental backup. You no longer need to keep track of the actual LSN (as in the option --start-lsn=LSN) or even the location of the previous backup (as in the option --incremental-base=dir:directory_path). (Bug #11765316)

The ibbackup and innobackup commands, provided for compatibility with command syntax from earlier releases are deprecated, meaning that they could be removed in a future release. For more information, see Appendix B, Compatibility Information for MySQL Enterprise Backup Releases and InnoDB Hot Backup.

Important Change: When backing up a slave server using the --slave-info option, updates could be lost when restoring the backup and starting replication using the command in the meta/ibbackup_slave_info file. This issue could arise if the replication SQL thread was not in synch with the replication I/O thread.

Prior to this fix, the workaround for backups with the --slave-info option was to stop the I/O thread and wait for the SQL thread to catch up before starting the backup. (Bug #13588571, Bug #15865869)

An error (segmentation fault) could occur when using the Tivoli Storage Manager product for backups, in combination with the SBT interface and associated --sbt* options for mysqlbackup. (Bug #13738674)

A single-file backup produced on a Linux system could not be extracted on a Windows system. The mysqlbackup command with the image-to-backup-dir option would fail with the message:

mysqlbackup.exe: ERROR: Could not extract contents of image file.

(Bug #13478310)

When mysqlbackup was run with the --only-innodb-with-frm option, it incorrectly displayed messages indicating that tables were being locked. The tables were not actually being locked. The fix suppresses the erroneous messages. (Bug #13477573)

If the MySQL server had a low value for the wait_timeout configuration option, large backups (particularly for large MyISAM tables) could fail due to timeout errors. The timeout could also prevent the mysql.backup_progress table from recording the final details of the failed backup. The fix raises the value of wait_timeout to the maximum value within the session opened by the mysqlbackup command. The maximum timeout value is platform-specific: approximately 24 days on Windows systems, and 1 year for other platforms. (Bug #13258784, Bug #13416025, Bug #14468879)

The operation of the --force operation has been fine-tuned and clarified.

Now --force allows overwriting InnoDB data and log files in combination with the apply-log and apply-incremental-backup options, and replacing the image file in combination with the backup-to-image and backup-dir-to-image options. For all other mode options, the --force option is rejected.

It is now possible to perform another apply-log and apply-incremental-backup, even after a successful apply operation. Previously, this was not allowed by mysqlbackup. (Bug #12922426)

The file meta/image_files.xml was incorrectly displayed twice when listing the contents of a single-file backup. (Bug #12563349)

Specifying a very large memory limit, such as --limit-memory=999999, could cause a segmentation fault when running the mysqlbackup command with the apply-log option. (Bug #11779864)

The engines column in the mysql.backup_history table does not correctly reflect the storage engines of the backed-up databases. This has been documented as a current limitation. (Bug #11763818, Bug #56582)

When mysqlbackup is run with the copy-back option, now it displays warnings as existing files are overwritten. (Bug #11760714)