Reference of files generated during backup. This page explains the purpose of metadata files like xtrabackup_checkpoints created by the tool.
mariadb-backup creates the following files:
backup-my.cnfDuring the backup, any server options relevant to mariadb-backup are written to the backup-my.cnf option file, so that they can be re-read later during the --prepare stage.
ib_logfile0mariadb-backup creates an empty InnoDB redo log file called ib_logfile0 as part of the --prepare stage. This file has 3 roles:
In the source server, ib_logfile0 is the first (and possibly the only) InnoDB redo log file.
In the non-prepared backup, ib_logfile0 contains all of the InnoDB redo log copied during the backup.
During the --prepare stage, ib_logfile0 is initialized as an empty InnoDB redo log file. That way, if the backup is manually restored, any pre-existing InnoDB redo log files get overwritten by the empty one. This helps to prevent certain kinds of known issues.
mariadb_backup_binlog_infoThis file stores the binary log file name and position that corresponds to the backup.
This file also stores the value of the system variable that correspond to the backup, like this:
The values in this file are only guaranteed to be consistent with the backup if the option was not provided when the backup was taken.
mariadb_backup_binlog_pos_innodbThis file is created by mariadb-backup to provide the binary log file name and position when the --no-lock option is used. It can be used instead of the xtrabackup_binlog_info file to obtain transactionally consistent binlog coordinates from the backup of a master server with the --no-lock option to minimize the impact on a running server.
Whenever a transaction is committed inside InnoDB when the binary log is enabled, the corresponding binlog coordinates are written to the InnoDB redo log along with the transaction commit. This allows one to restore the binlog coordinates corresponding to the last commit done by InnoDB along with a backup.
backup_typeIf the backup is a non-prepared full backup or a non-prepared partial backup, then backup_type is set to full-backuped.
If the backup is a non-prepared incremental backup, then backup_type is set to incremental.
If the backup has already been prepared, then backup_type is set to log-applied.
from_lsnIf backup_type is full-backuped, then from_lsn has the value of 0.
If backup_type is incremental, then from_lsn has the value of the log sequence number (LSN) at which the backup started reading from the InnoDB redo log. This is internally used by mariadb-backup when preparing incremental backups.
This value can be manually set during an incremental backup with the --incremental-lsn option. However, it is generally better to let mariadb-backup figure out the from_lsn automatically by specifying a parent backup with the --incremental-basedir option.
to_lsnto_lsn has the value of the log sequence number (LSN) of the last checkpoint in the InnoDB redo log. This is internally used by mariadb-backup when preparing incremental backups.
last_lsnlast_lsn has the value of the last log sequence number (LSN) read from the InnoDB redo log. This is internally used by mariadb-backup when preparing incremental backups.
uuidIf a UUID was provided by the --incremental-history-uuid option, then it are saved here. Otherwise, this is the empty string.
nameIf a name was provided by the --history or the ---incremental-history-name options, then it are saved here. Otherwise, this is the empty string.
tool_nameThe name of the mariadb-backup executable that performed the backup. This is generally mariadb-backup.
tool_commandThe arguments that were provided to mariadb-backup when it performed the backup.
tool_versionThe version of mariadb-backup that performed the backup.
ibbackup_versionThe version of mariadb-backup that performed the backup.
server_versionThe version of MariaDB Server that was backed up.
start_timeThe time that the backup started.
end_timeThe time that the backup ended.
lock_timeThe amount of time that mariadb-backup held its locks.
binlog_posThis field stores the binary log file name and position that corresponds to the backup.
This field also stores the value of the gtid_current_pos system variable that correspond to the backup.
The values in this field are only guaranteed to be consistent with the backup if the --no-lock option was not provided when the backup was taken.
innodb_from_lsnThis is identical to from_lsn in xtrabackup_checkpoints.
If the backup is a full backup, then innodb_from_lsn has the value of 0.
If the backup is an incremental backup, then innodb_from_lsn has the value of the log sequence number (LSN) at which the backup started reading from the InnoDB redo log.
innodb_to_lsnThis is identical to to_lsn in xtrabackup_checkpoints.
innodb_to_lsn has the value of the log sequence number (LSN) of the last checkpoint in the InnoDB redo log.
partialIf the backup is a partial backup, then this value are Y.
Otherwise, this value are N.
incrementalIf the backup is an incremental backup, then this value are Y.
Otherwise, this value are N.
formatThis field's value is the format of the backup.
If the --stream option was set to xbstream, then this value are xbstream.
If the --stream option was not provided, then this value are file.
compressedIf the --compress option was provided, then this value are compressed.
Otherwise, this value are N.
mariadb_backup_slave_infoIf the --slave-info option is provided, this file contains the CHANGE MASTER command that can be used to set up a new server as a slave of the original server's master after the backup has been restored.
mariadb-backup does not check if GTIDs are being used in replication. It takes a shortcut and assumes that if the system variable is non-empty, then it writes the CHANGE MASTER
<table>.deltaIf the backup is an incremental backup, this file contains changed pages for the table.
<table>.delta.metaIf the backup is an incremental backup, this file contains metadata about <table>.delta files. The fields in this file are listed below.
page_sizeThis field contains either the value of innodb_page_size or the value of the KEY_BLOCK_SIZE table option for the table if the ROW_FORMAT table option for the table is set to COMPRESSED.
zip_sizeIf the ROW_FORMAT table option for this table is set to COMPRESSED, this field contains the value of the compressed page size.
space_idThis field contains the value of the table's space_id.
This page is licensed: CC BY-SA / Gnu FDL
xtrabackup_binlog_infoThis file stores the binary log file name and position that corresponds to the backup.
This file also stores the value of the gtid_current_pos system variable that correspond to the backup, like this:
The values in this file are only guaranteed to be consistent with the backup if the --no-lock option was not provided when the backup was taken.
The limitation of using xtrabackup_binlog_pos_innodb with the --no-lock option is that no DDL or modification of non-transactional tables should be done during the backup. If the last event in the binlog is a DDL/non-transactional update, the coordinates in the file xtrabackup_binlog_pos_innodb are too old. But as long as only InnoDB updates are done during the backup, the coordinates are correct.
xtrabackup_binlog_pos_innodbThis file is created by mariadb-backup to provide the binary log file name and position when the --no-lock option is used. It can be used instead of the xtrabackup_binlog_info file to obtain transactionally consistent binlog coordinates from the backup of a master server with the --no-lock option to minimize the impact on a running server.
Whenever a transaction is committed inside InnoDB when the binary log is enabled, the corresponding binlog coordinates are written to the InnoDB redo log along with the transaction commit. This allows one to restore the binlog coordinates corresponding to the last commit done by InnoDB along with a backup.
The limitation of using xtrabackup_binlog_pos_innodb with the --no-lock option is that no DDL or modification of non-transactional tables should be done during the backup. If the last event in the binlog is a DDL/non-transactional update, the coordinates in the file xtrabackup_binlog_pos_innodb are too old. But as long as only InnoDB updates are done during the backup, the coordinates are correct.
xtrabackup_checkpointsThe xtrabackup_checkpoints file contains metadata about the backup.
For example:
See below for a description of the fields.
If the --extra-lsndir option is provided, then an extra copy of this file are saved in that directory.
xtrabackup_infoContains information about the backup. The fields in this file are listed below.
If the --extra-lsndir option is provided, an extra copy of this file is saved in that directory.
MASTER_USE_GTIDslave_posCHANGE MASTERMASTER_LOG_FILEMASTER_LOG_POSxtrabackup_slave_infoIf the --slave-info option is provided, this file contains the CHANGE MASTER command that can be used to set up a new server as a slave of the original server's master after the backup has been restored.
mariadb-backup does not check if GTIDs are being used in replication. It takes a shortcut and assumes that if the gtid_slave_pos system variable is non-empty, then it writes the CHANGE MASTER command with the MASTER_USE_GTID option set to slave_pos. Otherwise, it writes the CHANGE MASTER command with the MASTER_LOG_FILE and MASTER_LOG_POS options using the master's binary log file and position. See for more information.
xtrabackup_galera_infoIf the --galera-info option is provided, this file contains information about a Galera Cluster node's state.
The file contains the values of the and status variables.
The values are written in the following format:
For example:
mariadb-bin.000096 568 0-1-2mariadb-bin.000096 568 0-1-2backup_type = full-backuped
from_lsn = 0
to_lsn = 1635102
last_lsn = 1635102
recover_binlog_info = 0backup_type = full-backuped
from_lsn = 0
to_lsn = 1635102
last_lsn = 1635102
recover_binlog_info = 0wsrep_local_state_uuid:wsrep_last_committedd38587ce-246c-11e5-bcce-6bbd0831cc0f:1352215wsrep_local_state_uuid:wsrep_last_committedd38587ce-246c-11e5-bcce-6bbd0831cc0f:1352215