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 DROP TABLE statements since the backup. Copying the .FRM files is automated by the mysqlbackup command. If you rely on the lower-level ibbackup command for the backup, you must copy the .FRM files yourself.

The mysqlbackup command can also back up the .MYD files, .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.