MySQL Enterprise Backup 4.1 Release Notes
The InnoDB-related data files that are backed up include the ibdata* files (which represent the system tablespace and possibly the data for some user tables), any .ibd files (which contains data from user tables created with the file-per-table setting enabled), and the data extracted from the ib_logfile* files (the redo log information representing changes that occur while the backup is running), which is stored in a new backup file ibbackup_logfile.
If you use the compressed backup feature, the
.ibd files are renamed in their compressed
form to .ibz files.
The files, as they are originally copied, form a
raw backup that requires
further processing before it is ready to be restored. You then
run the apply step (either as
part of a copy-back-and-apply-log
command or a backup-and-apply-log
command, or as a separate apply-log
command), which updates the backup files based on the changes
recorded in the ibbackup_logfile file,
producing a prepared
backup. At this point, the backup data corresponds to a
single point in time. The files are now ready to be restored, or
for some other uses such as testing, reporting, or deployment as
a replica.
To restore InnoDB tables to their original state, you must also
have the corresponding .frm
files along with the backup data. Otherwise, the table
definitions could be missing or outdated if someone has run
ALTER TABLE or DROP TABLE
statements since the backup. By default,
mysqlbackup automatically copies the
.frm files during a backup operation and
restores the files during a restore operation.
Note
To avoid concurrency issues during backups of busy databases,
you can use the --only-innodb or
--only-innodb-with-frm option to
back up only InnoDB tables and the associated data.