Metadata for ARCHIVE tables. Contrast with .ARZ file. Files with this extension are always included in backups produced by the mysqlbackup command of the MySQL Enterprise Backup product.

See Also .ARZ file.

Data for ARCHIVE tables. Contrast with .ARM file. Files with this extension are always included in backups produced by the mysqlbackup command of the MySQL Enterprise Backup product.

See Also .ARM file.

The code name for the original InnoDB file format. It supports the redundant and compact row formats, but not the newer dynamic and compressed row formats available in the Barracuda file format.

See Also Barracuda, compression, file format.

The operation that transforms a raw backup into a prepared backup by incorporating changes that occurred while the backup was running, using data from the log.

See Also log, prepared backup, raw backup.

A licensed products that performs hot backups of MySQL database servers. It offers the most efficiency and flexibility when backing up InnoDB tables; it can also back up MyISAM and other kinds of tables. It is included as part of the MySQL Enterprise Edition subscription.

See Also Barracuda, hot backup, InnoDB.

When mysqlbackup performs a compressed backup for a server that has binary logging enabled, it transforms each binary log file and relay log file (for a replica server in a replication setting) to a binary-or-relay-log-file-name.bz file. The .bz files are uncompressed at the time of restore.

See Also binary log, .bz file, compression, compression level, .ibz file, relay log.

The process of copying some or all table data and metadata from a MySQL instance, for safekeeping. Can also refer to the set of copied files. This is a crucial task for DBAs. The reverse of this process is the restore operation.

With MySQL, physical backups are performed by the MySQL Enterprise Backup product, and logical backups are performed by the mysqldump command. These techniques have different characteristics in terms of size and representation of the backup data, and speed (especially speed of the restore operation).

Backups are further classified as hot, warm, or cold depending on how much they interfere with normal database server operation. (Hot backups have the least interference, cold backups the most.)

See Also cold backup, hot backup, logical backup, mysqldump, physical backup, warm backup.

The directory under which the backup data and metadata are stored, permanently or temporarily. It is used in most kinds of backup and restore operations, including single-file backups and restores. See the description of the --backup-dir option on how the backup directory is used for different purposes and for different operations.

Contrast with server repository.

See Also repository, server repository.

A small configuration file generated by MySQL Enterprise Backup, containing a minimal set of configuration parameters. This file records the settings that apply to this backup data. Subsequent operations, such as the apply process, read options from this file to determine how the backup data is structured. This file always has the extension .cnf, rather than .cnf on Unix-like systems and .ini on Windows systems.

See Also apply, configuration file.

The code name for an InnoDB file format that supports compression for table data. It supports the compressed row format that enables InnoDB table compression, and the dynamic row format that improves the storage layout for BLOB and large text columns.

See Also Antelope, file format, MySQL Enterprise Backup, row format, system tablespace.

A file containing a record of all statements that attempt to change table data. These statements can be replayed to bring replica servers up to date in a replication scenario, or to bring a database up to date after restoring table data from a backup. The binary logging feature can be turned on and off, although Oracle recommends always enabling it if you use replication or perform backups.

You can examine the contents of the binary log, or replay those statements during replication or recovery, by using the mysqlbinlog command. For full information about the binary log, see The Binary Log. For MySQL configuration options related to the binary log, see Binary Logging Options and Variables.

For the MySQL Enterprise Backup product, the file name of the binary log and the current position within the file are important details. To record this information for the source server when taking a backup in a replication context, you can specify the --slave-info option.

The binary log, if enabled on the server, is backed up by default.

See Also binlog, relay log, replication.

An informal name for the binary log file. For example, you might see this abbreviation used in e-mail messages or forum discussions.

See Also binary log.

A backup taken while the database is shut down.

MySQL Enterprise Backup 8.0 and later does not support cold backups.

See Also backup, connection, hot backup, warm backup.

A technique that produces smaller backup files, with size reduction influenced by the compression level setting. Suitable for keeping multiple sets of non-critical backup files. (For recent backups of critical data, you might leave the data uncompressed, to allow fast restore speed in case of emergency.)

MySQL Enterprise Backup can apply compression to the contents of InnoDB tables during the backup process, turning the .ibd files into .ibz files.

Compression adds CPU overhead to the backup process, and requires additional time and disk space during the restore process.

See Also backup, compression level, .ibd file, .ibz file, InnoDB, restore.

A setting that determines how much compression to apply to a compressed backup. This setting ranges from 0 (none), 1 (default level when compression is enabled) to 9 (maximum). The amount of compression for a given compression level depends on the nature of your data values. Higher compression levels do impose additional CPU overhead, so ideally you use the lowest value that produces a good balance of compression with low CPU overhead.

See Also compression.

The file that holds the startup options of the MySQL server and related products and components. Often referred to by its default file name, my.cnf on Linux, Unix, and macOS systems, and my.ini on Windows systems. The MySQL Enterprise Backup stores its default configuration settings in this file, under a [mysqlbackup] section. For convenience, MySQL Enterprise Backup can also read settings from the [client] section, for configuration options that are common between MySQL Enterprise Backup and other programs that connect to the MySQL server.

See Also my.cnf, my.ini.

The mechanism used by certain backup operations to communicate with a running MySQL server. For example, the mysqlbackup command can log into the server being backed up to insert and update data in the progress table and the history table. A hot backup typically uses a database connection for convenience, but can proceed anyway if the connection is not available. A warm backup always uses a database connection, because it must put the server into a read-only state. A cold backup is taken while the MySQL server is shut down.

Cold backups are not supported by MySQL Enterprise Backup 8.0 or later. Therefore a connection to the server is always needed for MySQL Enterprise Backup 8.0 and later to back it up.

See Also cold backup, history table, hot backup, progress table, server, warm backup.

The cleanup activities for InnoDB tables that occur when MySQL is started again after a crash. Changes that were committed before the crash, but not yet written to the tablespace files, are reconstructed from the doublewrite buffer. When the database is shut down normally, this type of activity is performed during shutdown by the purge operation.

A set of tables, controlled by the InnoDB storage engine, that keeps track of InnoDB-related objects such as tables, indexes, and table columns. These tables are part of the InnoDB system tablespace.

Because the MySQL Enterprise Backup product always backs up the system tablespace, all backups include the contents of the data dictionary.

See Also hot backup, MySQL Enterprise Backup, system tablespace.

A set of tables and related objects owned by a MySQL user. Equivalent to “schema” in Oracle Database terminology. MySQL Enterprise Backup can perform a partial backup that includes some databases and not others. The full set of databases controlled by a MySQL server is known as an instance.

See Also instance, partial backup.

A backup that captures only the data changed since the last full backup. It has the potential to be smaller and faster than a full backup, but is usually bigger and takes longer to create than an incremental backup. See Section 4.3.3, “Making a Differential or Incremental Backup” for usage details. Related mysqlbackup options are --incremental, --incremental-with-redo-log-only, --incremental-backup-dir, --incremental-base, and --start-lsn.

See Also full backup, incremental backup.

A period when the database is unresponsive. The database might be entirely shut down, or in a read-only state when applications are attempting to insert, update, or delete data. The goal for your backup strategy is to minimize downtime, using techniques such as hot backup for InnoDB tables and minimizing the duration of the suspend stage where you run customized backup logic while the MySQL server is locked.

See Also cold backup, hot backup, InnoDB, locking, replica, replication, suspend.

In a partial backup, to select a set of tables, databases, or a combination of both to be omitted from the backup. Contrast with include.

See Also partial backup.

The operation that retrieves some content from an image file produced by a single-file backup. It can apply to a single file (unpacked to an arbitrary location) or to the entire backup (reproducing the original directory structure of the backup data). These two kinds of extraction are performed by the mysqlbackup options extract and image-to-backup-dir, respectively.

See Also image, single-file backup.

A file containing the metadata, such as the table definition, of a MySQL table. .frm files were removed in MySQL 8.0 and later but are still used in earlier MySQL releases. In MySQL 8.0 and later, data that was previously stored in .frm files is stored in data dictionary tables.

The format used by InnoDB for its data files named ibdata1, ibdata2, and so on. Each file format supports one or more row formats.

See Also Antelope, Barracuda, ibdata file, row format.

A backup that includes all the tables in each MySQL database, and all the databases in a MySQL instance. Contrast with partial backup and incremental backup. Full backups take the longest, but also require the least amount of followup work and administration complexity. Thus, even when you primarily do partial or incremental backups, you might periodically do a full backup.

See Also backup, incremental backup, partial backup, table.

The table mysql.backup_history that holds details of completed backup operations. While a backup job is running, the details (especially the changing status value) are recorded in the progress table.

See Also backup, progress table.

A backup taken while the MySQL instance and is running and applications are reading and writing to it. Contrast with warm backup and cold backup.

A hot backup involves more than simply copying data files: it must include any data that was inserted or updated while the backup was in process; it must exclude any data that was deleted while the backup was in process; and it must ignore any changes started by transactions but not committed.

The Oracle product that performs hot backups, of InnoDB tables especially but also tables from MyISAM and other storage engines, is MySQL Enterprise Backup.

The hot backup process consists of two stages. The initial copying of the InnoDB data files produces a raw backup. The apply step incorporates any changes to the databases that happened while the backup was running. Applying the changes produces a prepared backup; these files are ready to be restored whenever necessary.

A full backup consists of a hot backup phase that copies the InnoDB data, followed by a warm backup phase that copies any non-InnoDB data such as MyISAM tables and the associated .sdi files.

See Also apply, cold backup, .frm file, full backup, InnoDB, instance, prepared backup, raw backup, warm backup.

Each InnoDB tablespace created using the file-per-table setting has a filename with a .ibd extension. This extension does not apply to the system tablespace, which is made up of files named ibdata1, ibdata2, and so on.

See Also .ibz file, system tablespace, tablespace.

When the MySQL Enterprise Backup product performs a compressed backup, it transforms each tablespace file that is created using the file-per-table setting from a .ibd extension to a .ibz extension.

The compression applied during backup is distinct from the compressed row format that keeps table data compressed during normal operation. An InnoDB tablespace that is already in compressed row format is not compressed a second time, but is, nevertheless, still saved as an .ibz file in the compressed backup.

See Also .bz file, compression, compression level, .ibd file, .ibz file, MySQL Enterprise Backup, tablespace.

A set of files with names such as ibdata1, ibdata2, and so on, that make up the InnoDB system tablespace. These files contain metadata about InnoDB tables, and can contain some or all of the table and index data also (depending on whether the file-per-table option is in effect when each table is created). For backward compatibility these files always use the Antelope file format.

See Also Antelope, system tablespace.

The file produced as part of a single-file backup operation. It can be a real file that you store locally, or standard output (specified as -) when the backup data is streamed directly to another command or remote server. This term is referenced in several mysqlbackup options such as backup-dir-to-image and image-to-backup-dir.

See Also single-file backup, streaming.

In a partial backup, to select a set of tables, databases, or a combination of both to be backed up. Contrast with exclude.

See Also partial backup.

A backup that captures only data changed since the previous backup. It has the potential to be smaller and faster than a full backup. The incremental backup data must be merged with the contents of the previous backup before it can be restored. See Section 4.3.3, “Making a Differential or Incremental Backup” for usage details. Related mysqlbackup options are --incremental, --incremental-with-redo-log-only, --incremental-backup-dir, --incremental-base, and --start-lsn.

See Also full backup.

The type of MySQL table that works best with MySQL Enterprise Backup. These tables can be backed up using the hot backup technique that avoids interruptions in database processing. For this reason, and because of the higher reliability and concurrency possible with InnoDB tables, most deployments should use InnoDB for the bulk of their data and their most important data. In MySQL 5.5 and higher, the CREATE TABLE statement creates InnoDB tables by default.

See Also hot backup, table.

The full contents of a MySQL server, possibly including multiple databases. A backup operation can back up an entire instance, or a partial backup can include selected databases and tables.

See Also database, partial backup.

See Also suspend, warm backup.

Several types of log files are used within the MySQL Enterprise Backup product. The most common is the InnoDB redo log that is consulted during incremental backups.

See Also incremental backup, redo log.

A backup that reproduces table structure and data, without copying the actual data files. For example, the mysqldump command produces a logical backup, because its output contains statements such as CREATE TABLE and INSERT that can re-create the data. Contrast with physical backup.

See Also backup, physical backup.

Acronym for log sequence number. This arbitrary, ever-increasing value represents a point in time corresponding to operations recorded in the redo log. (This point in time is regardless of transaction boundaries; it can fall in the middle of one or more transactions.) It is used internally by InnoDB during crash recovery and for managing the buffer pool.

In the MySQL Enterprise Backup product, you can specify an LSN to represent the point in time from which to take an incremental backup. The relevant LSN is displayed by the output of the mysqlbackup command. Once you have the LSN corresponding to the time of a full backup, you can specify that value to take a subsequent incremental backup, whose output contains another LSN for the next incremental backup.

See Also crash recovery, hot backup, incremental backup, redo log.

A file containing references to other tables, used by the MERGE storage engine. Files with this extension are always included in backups produced by the mysqlbackup command of the MySQL Enterprise Backup product.

A file that MySQL uses to store data for a MyISAM table.

See Also .MYI file.

A file that MySQL uses to store indexes for a MyISAM table.

See Also .MYD file.

The record of the environment (for example, command-line arguments) and data files involved in a backup, stored in the files meta/backup_create.xml and meta/backup_content.xml, respectively. This data can be used by management tools during diagnosis and troubleshooting procedures.

A class of software programs for managing backup media, such as libraries of tape backups. One example is Oracle Secure Backup. Abbreviated MMS.

See Also Oracle Secure Backup.

The typical name for the MySQL configuration file on Linux, Unix, and macOS systems.

See Also configuration file, my.ini.

The typical name for the MySQL configuration file on Windows systems.

See Also configuration file, my.cnf.

A MySQL storage engine, formerly the default for new tables. In MySQL 5.5 and higher, InnoDB becomes the default storage engine. MySQL Enterprise Backup can back up both types of tables, and tables from other storage engines also. The backup process for InnoDB tables (hot backup) is less disruptive to database operations than for MyISAM tables (warm backup).

See Also hot backup, InnoDB, warm backup.

The primary command of the MySQL Enterprise Backup product. Different options perform backup and restore operations.

See Also backup, restore.

A MySQL command that performs logical backups, producing a set of SQL commands to recreate tables and data. Suitable for smaller backups or less critical data, because the restore operation takes longer than with a physical backup produced by MySQL Enterprise Backup.

See Also logical backup, physical backup, restore.

A backup that is NOT created using transportable tablespace (TTS), that is, not with the --use-tts option.

See Also transportable tablespace, TTS backup.

A file containing database server configuration information. Files with this extension are always included in backups produced by the backup operations of the MySQL Enterprise Backup product.

A type of operation performed while the database server is stopped. With the MySQL Enterprise Backup product, the main offline operation is the restore step. You cannot perform a cold backup with MySQL Enterprise Backup 8.0 or later. Contrast with online.

See Also cold backup, online, restore.

A type of operation performed while the database server is running. A hot backup is the ideal example, because the database server continues to run and no read or write operations are blocked. For that reason, sometimes “hot backup” and “online backup” are used as synonyms. A cold backup is the opposite of an online operation; by definition, the database server is shut down while the backup happens (MySQL Enterprise Backup 8.0 and later does not support cold backups). A warm backup is also a kind of online operation, because the database server continues to run, although some write operations could be blocked while a warm backup is in progress. Contrast with offline.

See Also cold backup, hot backup, offline, warm backup.

Optimistic backup is a feature for improving performance for backing up and restoring huge databases in which only a small number of tables are modified frequently. An optimistic backup consists of two phases: (1) the optimistic phase in which tables that are unlikely to be modified during the backup process (identified by the user with the optimistic-time option or, by exclusion, with the optimistic-busy-tables option) are backed up without any locks on the MySQL instance; (2) a normal phase, in which tables that are not backed up in the first phase are being backed up in a manner similar to how they are processed in an ordinary backup: the InnoDB files are copied first, and then other relevant files and copied or processed with various locks applied to the database server. The redo logs, undo logs, and the system tablespace are also backed up in this phase. See Section 4.3.6, “Making an Optimistic Backup” for details.

In an optimistic incremental backup mysqlbackup scans InnoDB data files that have been modified since the last backup for changed pages and then saves them into the incremental backup. It is performed by specifying --incremental=optimistic. See Full-scan versus Optimistic Incremental Backup for details.

An Oracle product for managing backup media, and so classified as media management software (MMS). Abbreviated OSB. For MySQL Enterprise Backup, OSB is typically used to manage tape backups.

See Also backup, media management software, OSB.

Abbreviation for Oracle Secure Backup, a media management software product (MMS).

See Also Oracle Secure Backup.

A file containing partition definitions. Files with this extension are always included in backups produced by the mysqlbackup command of the MySQL Enterprise Backup product.

The default processing mode in MySQL Enterprise Backup 3.8 and higher, employing multiple threads for different classes of internal operations (read, process, and write). See Section 1.2, “Overview of Backup Types” for an overview, Section 20.10, “Performance / Scalability / Capacity Options” for the relevant mysqlbackup options, and Chapter 13, Performance Considerations for MySQL Enterprise Backup for performance guidelines and tips.

A backup that contains some of the tables in a MySQL database, or some of the databases in a MySQL instance. Contrast with full backup. Related mysqlbackup options are --include-tables, --exclude-tables, --use-tts, --only-known-file-types, and --only-innodb.

See Also backup, database, full backup, partial restore, table.

A restore operation that applies to one or more tables or databases, but not the entire contents of a MySQL server. The data being restored could come from either a partial backup or a full backup. Related mysqlbackup options are --include-tables, --exclude-tables, and --rename.

See Also database, full backup, partial backup, restore, table.

A backup that copies the actual data files. For example, the MySQL Enterprise Backup command produces a physical backup, because its output contains data files that can be used directly by the mysqld server. Contrast with logical backup.

See Also backup, logical backup.

The time corresponding to the end of a backup operation. A prepared backup includes all the changes that occurred while the backup operation was running. Restoring the backup brings the data back to the state at the moment when the backup operation completed.

See Also backup, prepared backup, restore.

The set of backup data that is entirely consistent and ready to be restored. It is produced by performing the apply operation on the raw backup.

See Also apply, raw backup.

The table mysql.backup_progress that holds details of running backup operations. When a backup job finishes, the details are recorded in the history table.

See Also backup, history table.

The initial set of backup data, not yet ready to be restored because it does not incorporate changes that occurred while the backup was running. The apply operation transforms the backup files into a prepared backup that is ready to be restored.

See Also apply, prepared backup.

A set of files, typically named ib_logfile0 and ib_logfile1, that record statements that attempt to change data in InnoDB tables. These statements are replayed automatically to correct data written by incomplete transactions, on startup following a crash. The passage of data through the redo logs is represented by the ever-increasing LSN value. The 4GB limit on maximum size for the redo log is raised in MySQL 5.6.

See Also LSN.

Some MySQL Enterprise Backup features use POSIX-style regular expressions, for example to specify tables, databases, or both to include or exclude from a partial backup. Regular expressions require escaping for dots in filenames, because the dot is the single-character wildcard; no escaping is needed for forward slashes in path names. When specifying regular expressions on the command line, surround them with quotation marks as appropriate for the shell environment, to prevent expansion of characters such as asterisks by the shell wildcard mechanism.

See Also exclude, include, partial backup.

A record on a replica server for the events read from the binary log of the source server and written by the replication I/O thread. The relay log, like the binary log, consists of a set of numbered files containing events that describe database changes, and an index file that contains the names of all used relay log files. For more information on relay log, see The Relay Log. The relay log on a server is backed up by default.

See Also binary log, replication.

In a replication configuration, a database server that receives updates from a source server. Typically used to service user queries, to minimize the query load on the source server. With MySQL Enterprise Backup, you might take a backup on one server, and restore on a different system to create a new replica server with the data already in place. You might also back up data from a replica server rather than the source, to minimize any slowdown of the overall system.

See Also replication, source.

A common configuration for MySQL deployments, with data and DML operations from a source server synchronized with a set of replica servers. With MySQL Enterprise Backup, you might take a backup on one server, and restore on a different system to create a new replica server with the data already in place. You might also back up data from a replica server rather than the source, to minimize any slowdown of the overall system.

See Also replica, source.

We distinguish between the server repository and the backup repository.

See Also backup repository, server repository.

The converse of the backup operation. The data files from a prepared backup are put back into place to repair a data issue or bring the system back to an earlier state.

See Also backup, prepared backup.

The disk storage format for a row from an InnoDB table. As InnoDB gains new capabilities such as compression, new row formats are introduced to support the resulting improvements in storage efficiency and performance.

Each table has its own row format, specified through the ROW_FORMAT option. To see the row format for each InnoDB table, issue the command SHOW TABLE STATUS. Because all the tables in the system tablespace share the same row format, to take advantage of other row formats typically requires setting the innodb_file_per_table option, so that each table is stored in a separate tablespace.

A file containing the metadata (referred to as Serialized Dictionary Information (SDI)) of a MyISAM table.

Acronym for system backup to tape.

See Also system backup to tape.

Another name for partial backup

See Also partial backup, selective restore.

Another name for partial restore

See Also partial restore, selective backup.

A MySQL instance controlled by a mysqld daemon. A physical machine can host multiple MySQL servers, each requiring its own backup operations and schedule. Some backup operations communicate with the server through a connection.

See Also connection, instance.

Contrast with backup repository.

See Also backup repository, repository.

A backup technique that packs all the backup data into one file (the backup image), for ease of storage and transfer. The streaming backup technique requires using a single-file backup.

See Also image, streaming.

In a replication configuration, a database server that sends updates to a set of replica servers. It typically dedicates most of its resources to write operations, leaving user queries to the replicas. With MySQL Enterprise Backup, typically you perform backups on the replica servers rather than the source, to minimize any slowdown of the overall system.

See Also replica, replication.

A backup technique that transfers the data immediately to another server, rather than saving a local copy. Uses mechanisms such as Unix pipes. Requires a single-file backup, with the destination file specified as - (standard output).

See Also single-file backup.

An optional stage within the backup where the MySQL Enterprise Backup processing stops, to allow for user-specific operations to be run. The mysqlbackup command has options that let you specify commands to be run while the backup is suspended.

See Also .frm file, InnoDB.

An API for media management software. Abbreviated SBT. Several mysqlbackup options (with sbt in their names) pass information to media management software products such as Oracle Secure Backup.

See Also Oracle Secure Backup, SBT.

By default, this single data file stores all the table data for a database server, as well as all the metadata for InnoDB-related objects (the data dictionary).

Turning on the innodb_file_per_table option causes each newly created table to be stored in its own tablespace, reducing the size of, and dependencies on, the system tablespace.

Keeping all table data in the system tablespace has implications for the MySQL Enterprise Backup product (backing up one large file rather than several smaller files), and prevents you from using certain InnoDB features that require the newer Barracuda file format. on the

See Also Barracuda, data dictionary, file format, ibdata file, tablespace.

A file containing trigger parameters. Files with this extension are always included in backups produced by the mysqlbackup command of the MySQL Enterprise Backup product.

Although a table is a distinct, addressable object in the context of SQL, for backup purposes we are often concerned with whether the table is part of the system tablespace, or was created under the file-per-table setting and so resides in its own tablespace.

See Also backup, system tablespace, tablespace.

Table-Level Recovery (TLR) is a selective restore of tables or schemas from a backup; see Section 5.1.4, “Table-Level Recovery (TLR)” for details.

See Also partial restore.

For InnoDB tables, the file that holds the data and indexes for a table. Can be either the system tablespace containing multiple tables, or a table created with the file-per-table setting that resides in its own tablespace file.

See Also InnoDB, system tablespace.

Short form for Table-Level Recovery.

See Also partial restore, Table-Level Recovery (TLR).

A feature that allows a tablespace to be moved from one instance to another. Traditionally, this has not been possible for InnoDB tablespaces because all table data was part of the system tablespace. In MySQL 5.6 and higher, the FLUSH TABLES ... FOR EXPORT syntax prepares an InnoDB table for copying to another server; running ALTER TABLE ... DISCARD TABLESPACE and ALTER TABLE ... IMPORT TABLESPACE on the other server brings the copied data file into the other instance. A separate .cfg file, copied along with the .ibd file, is used to update the table metadata (for example the space ID) as the tablespace is imported. See Importing InnoDB Tables for usage information.

Use the --use-tts option to create a backup with transportable tablespace. See also Section 5.1.5, “Restoring Backups Created with the --use-tts Option”.

See Also partial backup.

Short form for transportable tablespace.

See Also partial backup, transportable tablespace.

A backup that is created using transportable tablespace (TTS), that is, with the --use-tts option.

See Also non-TTS backup, partial backup, transportable tablespace.

A backup taken while the database server is running, but that restricts some database operations during the backup process. For example, tables might become read-only. For busy applications and websites, you might prefer a hot backup.

See Also backup, cold backup, hot backup.