Immediately after the backup job completes, the backup files might not be in a consistent state, because data could be inserted, updated, or deleted while the backup is running. These initial backup files are known as the raw backup.
You must update the backup files so that they reflect the state of the database corresponding to a specific InnoDB log sequence number. (The same kind of operation as crash recovery.) When this step is complete, these final files are known as the prepared backup.
During the backup, mysqlbackup copies the
accumulated InnoDB log to a file called
ibbackup_logfile. This log file is used to
“roll forward” the backed-up data files, so that
every page in the data files corresponds to the same log sequence
number of the InnoDB log. This phase also creates new
ib_logfiles that correspond to the data files.
The mysqlbackup option for turning a raw backup
into a prepared backup is apply-log. You can
run this step on the same database server where you did the
backup, or transfer the raw backup files to a different system
first, to limit the CPU and storage overhead on the database
server. For simple backups (without compression or incremental
backup), you can combine the initial backup and the apply-log step
using the option backup-and-apply-log.
Example 5.1. Applying the Log to a Backup
This example runs mysqlbackup to roll forward the data files so that the data is ready to be restored:
mysqlbackup --backup-dir=/export/backups/2011-06-21__8-36-58 apply-log
That command creates InnoDB log files
(ib_logfile*) within the backup directory
and applies log records to the InnoDB data files
(ibdata* and *.ibd).
Example 5.2. Applying the Log to a Compressed Backup
If the backup is compressed, as in
Section 3.3.3, “Making a Compressed Backup”, specify the
--uncompress option to
mysqlbackup when applying the log to the
backup:
mysqlbackup --backup-dir=/export/backups/compressed --uncompress apply-log
Since mysqlbackup does not modify any of the original files in the backup (compressed data files and ibbackup log file), nothing is lost if the apply-log operation fails for some reason (for example, insufficient disk space). After fixing the problem, you can safely try the apply-log operation again.
Example 5.3. Applying an Incremental Backup to a Full Backup
After you take an incremental backup, as in Section 3.3.2, “Making an Incremental Backup”, the changes reflected in those backup files must be applied to a full backup to bring the full backup up-to-date, in the same way that you apply changes from the binary log.
To bring the data files from the full backup up to date, first run the apply log step so that the data files include any changes that occurred while the full backup was running. Then apply the changes from the incremental backup to the data files produced by the full backup:
mysqlbackup --backup-dir=/export/backups/full apply-log mysqlbackup --backup-dir=/export/backups/full \ --incremental-backup-dir=/export/backups/incremental \ apply-incremental-backup
Now the data files in the full-backup
directory are fully up-to-date, as of the time of the
incremental backup.