The primary InnoDB-related data files that are backed up include the ibdata* files that represent the system tablespace and possibly the data for some user tables; any .ibd files, containing data from user tables created with the file-per-table setting enabled; 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 to be ready to be restored. You then run the
apply step, 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 to their original
location, or for some other use, such as testing or deployment
as a replication slave.
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
statements since the backup. Copying the
files is automated by the
command. If you rely on the lower-level
for the backup, you must copy the
mysqlbackup command can also back up the
.MYI files, and associated
.FRM files for MyISAM tables. The same
applies to files with other extensions, as shown in
this list. MyISAM
tables and these other types of files cannot be backed up in the
same non-blocking way as InnoDB tables can; changes to these
tables are prevented while they are being backed up, possibly
making the database unresponsive for a time.