Performance: During both backup and restore jobs, certain operations are performed in parallel: reading data, writing data, compressing or decompressing it (if applicable), and validating it (verifying the page checksum during backup). The parallel execution takes advantage of multi-threading. The performance increase is particularly evident when backing up to or restoring from a RAID storage device, and when using compressed backups. See Section 4.1.11, “Performance / Scalability / Capacity Options” for the options to fine-tune the parallel execution parameters. See Chapter 7, Performance Considerations for MySQL Enterprise Backup for general performance advice, including tips for parallel processing for backup and restore.

A backup using the combination of options --incremental-with-redo-log-only and --incremental-base=history:last_backup could crash the mysqlbackup command. The issue was intermittent, depending on the timing of updates to the database and the beginning of the incremental backup. The workaround was to re-run the incremental backup operation after a delay of a few seconds. (Bug #14241403)

The output of the mysqlbackup command was enhanced to include additional timestamp and summaries of data volume and throughput. (Bug #14054071)

An error could occur when running the apply-log phase on a single-file backup image on a Linux system, if the backup was originally performed on a Windows system.i The cause was a mismatch between the OS-specific file separator characters, resulting in the image file being unpacked into a set of files in a single directory, rather than into a directory tree. The error messages looked like:

InnoDB: Operating system error number 2 in a file operation. 
InnoDB: The error means the system cannot find the path specified.

(Bug #13477633)

The metadata file backup_content.xml could list files with names matching the pattern ibdata*, for example ibdata1 and ibdata2, that did not exist in the backup. The information in the metadata file is for informational purposes only, so the extra filenames did not cause any issues with the backup or restore procedures. (Bug #12554059)

For a single-file backup created using the backup-to-image or backup-dir-to-image option, the metadata file backup_content.xml could show file sizes for ibdata* files that did not match the sizes of the actual files in the backup. The mismatch occurred because huge files are divided into pieces when stored in the single-file backup image. The information in the metadata file is for informational purposes only, so the mismatching file sizes did not cause any issues with the backup or restore procedures. (Bug #12549658)

Backups using the --include option included all tables, rather than only those included in the regular expression argument. (Bug #11772424)