1.3.1 Types of Files Contained in a Backup

The following table shows the different types of files that are included in a single-file backup image or a directory backup. In the case of a single-file backup, unpack the file into a backup directory structure using the extract or the image-to-backup-dir command to view the files.

Table 1.1 Types of Files in a Backup

File Name, Pattern, or Extension	Relation to Original Data Files	Notes
ibdata*	The InnoDB system tablespace, containing multiple InnoDB tables and associated indexes.	Because the original files might change while the backup is in progress, the apply-log step applies the same changes to the corresponding backup files.
*.ibd	An InnoDB tablespace, which can be (a) a file-per-table tablespace, containing a single InnoDB table and associated indexes, or (b) a file-per-table external tablespace located outside of the server's data directory, containing a single InnoDB table and associated indexes, or (c) a general tablespace, containing one or more tables and their indexes.	Because the original files might change while the backup is in progress, the apply-log step applies the same changes to the corresponding backup files.
*.ibz	Compressed form of InnoDB data files from the MySQL data directory.	Produced instead of .ibd files in a compressed backup. The ibdata* files representing the InnoDB system tablespace also receive this extension in a compressed backup. The .ibz files are uncompressed during the apply-log, copy-back, or copy-back-and-apply-log step.
*.sdi	Hold Serialized Dictionary Information (SDI) for MyISAM tables, which is the tables' metadata.	The database is put into a read-only state while these files are copied. These files are copied unmodified.
*.MYD	MyISAM table data.	The database is put into a read-only state while these files are copied. These files are copied unmodified.
*.MYI	MyISAM index data.	The database is put into a read-only state while these files are copied. These files are copied unmodified.
*.CSM	Metadata for CSV tables.	These files are copied unmodified. The backup_history and backup_progress tables created by mysqlbackup use the CSV format, so the backup always includes some files with this extension.
*.CSV	Data for CSV tables.	These files are copied unmodified. The backup_history and backup_progress tables created by mysqlbackup use the CSV format, so the backup always includes some files with this extension.
*.MRG	MERGE storage engine references to other tables.	The database is put into a read-only state while these files are copied. These files are copied unmodified.
*.ARM	ARCHIVE storage engine table metadata.	The database is put into a read-only state while these files are copied. These files are copied unmodified.
*.ARZ	ARCHIVE storage engine table data.	The database is put into a read-only state while these files are copied. These files are copied unmodified.
backup-my.cnf	Records the configuration parameters that specify the layout of the MySQL data files.	Used in restore operations to reproduce the same layout as when the backup was taken.
ibbackup_ibd_files	Records names of the .ibd files and their space IDs during an incremental backup.	This file is created during an incremental backup. During a restore, the information in the file is used to delete the tables from the full backup that has been removed between the time of the full backup and the time of the incremental backup.
ibbackup_logfile	A condensed version of the ib_logfile* files from the MySQL data directory.	The InnoDB log files (ib_logfile*) are fixed-size files that are continuously updated during the database's operation. For backup purposes, only the changes that are committed while the backup is in progress are needed. These changes are recorded in ibbackup_logfile, and used to re-create the ib_logfile* files during the apply-log phase.
ibbackup_redo_log_only	Created instead of the ibbackup_logfile for incremental backups taken with the --incremental-with-redo-log-only option.
ib_logfile*	Created in the backup directory by mysqlbackup during the apply-log phase after the initial backup.	These files are not copied from the original data directory, but rather re-created in the backup directory during the apply-log phase after the initial backup, using the changes recorded in the ibbackup_logfile file.
Timestamped directory, such as 2011-05-26_13-42-02	Created by the --with-timestamp option. All the backup files go inside this subdirectory.	Use the --with-timestamp option to easily keep more than one set of backup data under the same main backup directory.
datadir directory	A subdirectory that stores the data files and database subdirectories from the original MySQL instance.	Created under the backup directory by mysqlbackup.
binary log files	Binary log files from the server, which are included in a backup by default (except when the backup is created with the --use-tts option). They allow a snapshot of the server to be taken, so a server can be cloned to its exact state. Using a full backup as a basis, the binary log files that are included with an incremental backup can be used for a point-in-time recovery (PITR), which restores a database to its state at a certain point in time after the last full backup. See Section 5.3, “Point-in-Time Recovery” for details.	Saved under the datadir directory inside the backup. A copy of the index file on the MySQL server that lists all the used binary log files, with the locations of the binary log files properly updated to point to the files' locations in the backup, is included into the backup as well also under the datadir directory. Use the --skip-binlog option to exclude the binary log from the backup. By default, the binary log files and the index file are restored to the same locations they were found on the backed-up server. Use the --log-bin option to specify a different target location for the binary log. Use the --skip-binlog option to skip the restoring of the binary log. The binary log files are compressed and saved with the .bz extension when being included in a compressed backup. Notes For MySQL Enterprise Backup 8.0.18 and ealrier: If any binary log files are missing on the server you are backing up, you should use the --skip-binlog option to avoid mysqlbackup throwing an error for the missing files. No binary log files are copied into the incremental backup if the --use-tts option or the --start-lsn option is used. To include binary log files for the period covered by the incremental backup, do not use the --use-tts option and, instead of --start-lsn, use the --incremental-base option, which provides the necessary information for mysqlbackup to ensure that no gap exists between binary log data included in the previous backup and the current incremental backup. No binary log files are restored onto a server with a partial restore.
relay log files	Relay log files from a replica server, which are included in a backup of a replica server by default (except when the backup is created with the --use-tts option). Their inclusion saves the time and resources required for fetching the relay logs from the source when the replica is being restored.	Saved under the datadir directory under the backup directory. A copy of the index file on the replica server that lists all the used relay log files, with the locations of the relay log files properly updated to point to the files' locations in the backup directory, is included into the backup as well, under the datadir directory. Use the --skip-relaylog option to exclude the relay log from the backup. By default, the relay log files and the index file are restored to the same locations they were found on the backed-up replica server. Use the --relay-log option to specify a different target location for the relay log. Use the --skip-relaylog option to skip the restoring of the relay log. No relay log files are restored onto a server with a partial restore. The relay log files are compressed and saved with the .bz extension when being included in a compressed backup.
*.bz	Compressed binary log or relay log files.	The binary log and relay log files are compressed and saved with the .bz extension when being included in a compressed backup. They are decompressed during a restore.
undo log files	Undo log files from the server. See Undo Tablespaces for details. For release 8.0.16 and later: Both active and inactive undo tablespaces are included in the backup. Also, when the --incremental-with-redo-log-only option is used for creating incremental backups, mysqlbackup creates from the redo log an undo log for the period covered by the incremental backup, and includes it in the backup.	Saved by default under the datadir directory inside the backup. Use the --backup_innodb_undo_directory option to specify another location for the undo log in the backup. For release 8.0.15 and earlier: The undo tablespaces are restored to the location pointed to by the --innodb_undo_directory option. For release 8.0.16 and later: During a restore, the default undo tablespaces, as well as any non-default undo tablespaces resided in the backed-up server's data directory, are restored to the location pointed to by the mysqlbackup option --innodb_undo_directory. Non-default, external undo tablespaces are restored to the locations they were found on the backed-up server; change their restore locations by editing the tablespace_tracker file. No undo log files are restored onto a server with a partial restore.
*.uz	Compressed undo log files.	The undo log files are compressed and saved with the .uz extension when being included in a compressed backup. They are decompressed during a restore.
encrypted keyring data file	For a server using the keyring_encrypted_file plugin, the file specified by the keyring_encrypted_file_data option on the server is copied over into the backup with its original name under the meta folder. For a server using the a keyring plugin other than keyring_encrypted_file, the file is named keyring_kef, saved under the meta folder.	An encrypted file containing the master key for InnoDB table encryption . See Chapter 6, Working with Encrypted InnoDB Tablespaces for detail.
replica status log files	Usually named master.info and relay-log.info, they are included by default in a backup of a replica database in a replication setup. See Replication Metadata Repositories, for details.	Saved under the datadir directory under the backup directory. The copying of these files are skipped during a backup or a restore when the --skip-relay-log option is used.
Backup image file	A single-file backup produced by the backup-to-image option, with a name specified by the --backup-image option.	You can move the image file without losing or damaging the contents inside it, then unpack it with mysqlbackup using the extract command and specifying the same image name with the --backup-image option. Although some extra files such as backup-my.cnf and the meta subdirectory are present in the backup directory, these files are also included in the image file and do not need to be moved along with it.
Any other files in subdirectories under the datadir directory (that is, under backup-dir/datadir/subdir)	Copied from the database subdirectories under the MySQL data directory.	By default, any unrecognized files in subdirectories under the MySQL data directory are copied to the backup. To omit such files, specify the --only-known-file-types option. Notes Some limitations apply to this behavior. See the discussion here in Appendix B, Limitations of MySQL Enterprise Backup. Any subdirectories under a subdirectory under datadir (for example, backup-dir/datadir/subdir/sub-subdir) are ignored in the back up process.
meta directory	A subdirectory that stores files with metadata about the backup.	Created under the backup directory by mysqlbackup. All files listed below go inside the meta subdirectory.
backup_variables.txt	Holds important information about the backup. For use by mysqlbackup only.	mysqlbackup consults and possibly updates this file during operations after the initial backup, such as the apply-log phase or the restore phase.
image_files.xml	Contains the list of all the files (except itself) that are present in the single-file backup produced by the backup-to-image or backup-dir-to-image options. For details about this file, see Section 17.4, “Using the MySQL Enterprise Backup Manifest”.	This file is not modified at any stage once generated.
backup_create.xml	Lists the command line arguments and environment in which the backup was created. For details about this file, see Section 17.4, “Using the MySQL Enterprise Backup Manifest”.	This file is not modified once it is created. You can prevent this file from being generated by specifying the --disable-manifest option.
backup_content.xml	Essential metadata for the files and database definitions of the backup data. It also contains details of all the plugins defined on the backed-up server, by which users should make sure the same plugins are defined in the same manner on the target server for restoration. For details about this file, see Section 17.4, “Using the MySQL Enterprise Backup Manifest”.	This file is not modified once created. You can prevent this file from being generated by specifying the --disable-manifest option.
comments.txt	Produced by the --comments or --comments-file option.	The comments are specified by you to document the purpose or special considerations for this backup job.
backup_gtid_executed.sql	Signifies the backup came from a server with GTIDs enabled.	GTIDs are a replication feature in MySQL 5.6 and higher. See Replication with Global Transaction Identifiers for details. When you back up a server with GTIDs enabled using mysqlbackup, the file named backup_gtid_executed.sql is created in the meta folder under the backup directory. Edit and execute this file after restoring the backup data on a replica server; see Section 8.1, “Setting Up a New replica” for details. Note For TTS backups for replica servers, use the --replica-info option to have backup_gtid_executed.sql generated.
server-my.cnf	Contains values of the backed-up server's global variables that are set to non-default values. Use this file or server-all.cnf to start the target server for restoration.	During a copy-back or copy-back-and-apply-log operation, the server repository options values (e.g., --datadir, --innodb_data_home_dir, etc.) in the file are modified if the command makes changes to them through the command options. However, during an apply-incremental-backup operation, the values already saved in the file take precedence and they are not modified by the option values supplied through the command. Warning When using the file to restart the target server, change parameters like --tmpdir, --general-log, etc., and any global variable that uses an absolute file path to avoid the accidental usage of the wrong file locations by the target server.
server-all.cnf	Contains values of all the global variables of the backed-up server. Use this file or server-my.cnf to start the target server for restoration.	During a copy-back or copy-back-and-apply-log operation, the server repository options values (e.g., --datadir, --innodb_data_home_dir, etc.) in the file are modified if the command makes changes to them through the command options. However, during an apply-incremental-backup operation, the values already saved in the file take precedence and they are not modified by the option values supplied through the command. Warning When using the file to restart the target server, change parameters like --tmpdir, --general-log, etc., and any global variable that uses an absolute file path to avoid the accidental usage of the wrong file locations by the target server.
backup-auto.cnf	Copy of the file auto.cnf from the backed-up server.	The file is restored into the data directory of the restored server. To use the UUID stored inside for your restored server, rename the file back to auto.cnf before you start the server.
backup-mysqld-auto.cnf	Copy of the file mysqld-.cnf from the backed-up server.	The file is restored into the data directory of the restored server. To use the persisted system variables stored inside for your restored server, rename the file back to mysqld-auto.cnf before you start the server.
ib_buffer_pool	The file produced on the server when innodb_buffer_pool_dump_at_shutdown (enabled by default on MySQL 5.7.7 and after) or innodb_buffer_pool_dump_now is enabled. It holds the list of tablespace IDs and page IDs of the server's buffer pool. The actual file name might be different, as it can be configured by the server's system variable innodb_buffer_pool_filename"	With the default setting on MySQL server 5.7.7 and after (innodb_buffer_pool_load_at_startup=ON), the target server, during start up, is going to restore the buffer pool state of the backed up server using this file. See Saving and Restoring the Buffer Pool State for details.
tablespace_tracker	The file tracks external tablespaces, recording their file paths on the backed-up server and their tablespace IDs.	If any external tablespace exists on a backed up server, the tracker file is going to be found in the datadir folder inside the backup. Change server_file_path in the file for any tablespace if you want to change the restore location for that tablespace (an absolute path must be used). To access the tracker file in a single-file backup, use the extract command. Warnings If the tracker file is deleted from the backup, the restore of the backup might fail silently, resulting in corruptions of the restored data. For release 8.0.16 and later: You cannot change the restore location for the default undo tablespaces of the database by editing their server_file_path entries. Their restore location is controlled by the setting of the mysqlbackup option --innodb_undo_directory. After a restore is finished, if the restored server contains any external tablespace, a tracker file is going to be found in the data directory of the restored server.