Skip to content
logo
Percona XtraBackup
How Percona XtraBackup works
Initializing search
    percona/pxb-docs
    percona/pxb-docs
    • Home
      • Release notes index
      • Percona XtraBackup 8.0.35-30 (2023-12-04)
      • Percona XtraBackup 8.0.34-29 (2023-08-21)
      • Percona XtraBackup 8.0.33-28 (2023-07-19)
      • Percona XtraBackup 8.0.33-27 (2023-05-25)
      • Percona XtraBackup 8.0.32-26 (2023-04-04)
      • Percona XtraBackup 8.0.32-25 (2023-02-27)
      • Percona XtraBackup 8.0.31-24 (2023-02-07)
        • Percona XtraBackup 8.0.30-23 (2022-11-14)
        • Percona XtraBackup 8.0.29-22 (2022-07-19)
        • Percona XtraBackup 8.0.28-21 (2022-05-25)
        • Percona XtraBackup 8.0.28-20
        • Percona XtraBackup 8.0.27-19
        • Percona XtraBackup 8.0.26-18.0
        • Percona XtraBackup 8.0.25-17.0
        • Percona XtraBackup 8.0.23-16.0
        • Percona XtraBackup 8.0.22-15.0
        • Percona XtraBackup 8.0.14
        • Percona XtraBackup 8.0.13
        • Percona XtraBackup 8.0.12
        • Percona XtraBackup 8.0.11
        • Percona XtraBackup 8.0.10
        • Percona XtraBackup 8.0.9
        • Percona XtraBackup 8.0.8
        • Percona XtraBackup 8.0.7
        • Percona XtraBackup 8.0.6
        • Percona XtraBackup 8.0.5
        • Percona XtraBackup 8.0.4
        • Percona XtraBackup 8.0-3-rc1
      • About Percona XtraBackup
      • How Percona XtraBackup works
        • Restoring a backup
      • Understand version numbers
        • LRU dump backup
        • Throttling backups
        • Store backup history on the server
        • Dictionary cache
        • Point-in-time recovery
        • Restore individual tables
      • Encrypted InnoDB tablespace backups
      • FLUSH TABLES WITH READ LOCK option
      • Improved log statements
      • lock-ddl-per-table option improvements
      • Smart memory estimation
      • Work with binary logs
      • Overview
        • The xtrabackup binary overview
        • xtrabackup implementation details
        • Configure xtrabackup
        • Analyze table statistics
      • The xbcrypt binary overview
        • The xbstream binary overview
        • Take a streaming backup
        • Accelerate the backup process
        • Encrypt backups
        • The xbcloud binary overview
          • Use the xbcloud binary with Amazon S3
          • Use the xbcloud binary with an IAM instance profile
          • Use the xbcloud binary with Swift
          • Use the xbcloud binary with Google Cloud Storage
          • Use the xbcloud binary with Microsoft Azure Cloud Storage
          • Use the xbcloud binary with MinIO
        • Update curl utility
        • FIFO data sink
        • Exponential backoff
      • Quickstart Guide for Percona XtraBackup
      • Install Percona XtraBackup 8.0 overview
        • Server version and backup version comparison
        • Connection and privileges needed
        • Permissions needed
        • Use APT repositories
        • Files in DEB package
        • Downloaded DEB packages
        • Apt pinning
        • Work with AppArmor
        • Uninstall
        • Use RPM repositories
        • Files in RPM package
        • Downloaded RPM packages
        • Work with SELinux
        • Uninstall
        • Install with binary tarballs
        • Binary tarballs available
        • Compile and install Percona XtraBackup 8.0 from source
        • Run Percona XtraBackup 8.0 in a Docker container
        • Create a full backup
        • Prepare a full backup
        • Create an incremental backup
        • Prepare an incremental backup
        • Take an incremental backup using page tracking
        • Create a compressed backup
        • Decompress and prepare a compressed backup
        • Create a partial backup
        • Prepare a partial backup
        • Create an individual partitions backup
        • Prepare an individual partitions backup
        • Restore full, incremental, compressed backups
        • Restore a partial backup
        • Restore an individual partitions backup
        • How to set up a replica for replication in 6 simple steps with Percona XtraBackup
        • How to create a new (or repair a broken) GTID-based replica
        • Make backups in replication environments
        • Verify backups with replication and pt-checksum
      • Error Message: Found tables with row versions due to INSTANT ADD/DROP columns
      • xtrabackup exit codes
      • Topic index
      • The xtrabackup option reference
      • Index of files created by Percona XtraBackup
      • Frequently asked questions
      • Glossary
      • Percona Toolkit version checking
      • Trademark policy
      • Copyright and licensing information

    • Restoring a backup

    How Percona XtraBackup works¶

    Percona XtraBackup is based on InnoDB’s crash-recovery functionality. It copies your InnoDB data files, which results in data that is internally inconsistent; but then it performs crash recovery on the files to make them a consistent, usable database again.

    This works because InnoDB maintains a redo log, also called the transaction log. This contains a record of every change to InnoDB data. When InnoDB starts, it inspects the data files and the transaction log, and performs two steps. It applies committed transaction log entries to the data files, and it performs an undo operation on any transactions that modified data but did not commit.

    Percona XtraBackup 8.0.30-23 adds the --register-redo-log-consumer parameter. This parameter is disabled by default. When enabled, the parameter lets Percona XtraBackup register as a redo log consumer at the start of the backup. The server does not remove a redo log that Percona XtraBackup (the consumer) has not yet copied. The consumer reads the redo log and manually advances the log sequence number (LSN). The server blocks the writes during the process. Based on the redo log consumption, the server determines when it can purge the log.

    Percona XtraBackup works by remembering the LSN when it starts, and then copying away the data files. It takes some time to do this, so if the files are changing, then they reflect the state of the database at different points in time. At the same time, Percona XtraBackup runs a background process that watches the transaction log files, and copies changes from it. Percona XtraBackup needs to do this continually because the transaction logs are written in a round-robin fashion, and can be reused after a while. Percona XtraBackup needs the transaction log records for every change to the data files since it began execution.

    Percona XtraBackup uses Backup locks

    where available as a lightweight alternative to FLUSH TABLES WITH READ LOCK. This feature is available in Percona Server for MySQL 5.6+. MySQL 8.0 allows acquiring an instance level backup lock via the LOCK INSTANCE FOR BACKUP statement.

    Locking is only done for MyISAM and other non-InnoDB tables after Percona XtraBackup finishes backing up all InnoDB/XtraDB data and logs. Percona XtraBackup uses this automatically to copy non-InnoDB data to avoid blocking DML queries that modify InnoDB tables.

    Important

    The BACKUP_ADMIN privilege is required to query the performance_schema_log_status for either LOCK INSTANCE FOR BACKUP or LOCK TABLES FOR BACKUP.

    xtrabackup tries to avoid backup locks and FLUSH TABLES WITH READ LOCK when the instance contains only InnoDB tables. In this case, xtrabackup obtains binary log coordinates from performance_schema.log_status. FLUSH TABLES WITH READ LOCK is still required in MySQL 8.0 when xtrabackup is started with the --slave-info. The log_status table in Percona Server for MySQL 8.0 is extended to include the relay log coordinates, so no locks are needed even with the --slave-info option.

    See also

    MySQL Documentation: LOCK INSTANCE FOR BACKUP

    When backup locks are supported by the server, xtrabackup first copies InnoDB data, runs the LOCK TABLES FOR BACKUP and then copies the MyISAM tables. Once this is done, the backup of the files will begin. It will backup .frm, .MRG, .MYD, .MYI, .CSM, .CSV, .sdi and .par files.

    After that xtrabackup will use LOCK BINLOG FOR BACKUP to block all operations that might change either binary log position or Exec_Master_Log_Pos or Exec_Gtid_Set (i.e. source binary log coordinates corresponding to the current SQL thread state on a replication replica) as reported by SHOW MASTER/SLAVE STATUS. xtrabackup will then finish copying the REDO log files and fetch the binary log coordinates. After this is completed xtrabackup will unlock the binary log and tables.

    Finally, the binary log position will be printed to STDERR and xtrabackup will exit returning 0 if all went OK.

    Note that the STDERR of xtrabackup is not written in any file. You will have to redirect it to a file, e.g., xtrabackup OPTIONS 2> backupout.log.

    It will also create the following files in the directory of the backup.

    During the prepare phase, Percona XtraBackup performs crash recovery against the copied data files, using the copied transaction log file. After this is done, the database is ready to restore and use.

    The backed-up MyISAM and InnoDB tables will be eventually consistent with each other, because after the prepare (recovery) process, InnoDB’s data is rolled forward to the point at which the backup completed, not rolled back to the point at which it started. This point in time matches where the FLUSH TABLES WITH READ LOCK was taken, so the MyISAM data and the prepared InnoDB data are in sync.

    The xtrabackup offers many features not mentioned in the preceding explanation. The functionality of each tool is explained in more detail further in this manual. In brief, though, the tools enable you to do operations such as streaming and incremental backups with various combinations of copying the data files, copying the log files, and applying the logs to the data.

    Restoring a backup¶

    To restore a backup with xtrabackup you can use the --copy-back or --move-back options.

    xtrabackup will read from the my.cnf the variables datadir, innodb_data_home_dir, innodb_data_file_path, innodb_log_group_home_dir and check that the directories exist.

    It will copy the MyISAM tables, indexes, etc. (.MRG, .MYD, .MYI, .CSM, .CSV, .sdi, and par files) first, InnoDB tables and indexes next and the log files at last. It will preserve file’s attributes when copying them, you may have to change the files’ ownership to mysql before starting the database server, as they will be owned by the user who created the backup.

    Alternatively, the --move-back option may be used to restore a backup. This option is similar to --copy-back with the only difference that instead of copying files it moves them to their target locations. As this option removes backup files, it must be used with caution. It is useful in cases when there is not enough free disk space to hold both data files and their backup copies.

    Contact us

    For free technical help, visit the Percona Community Forum.

    To report bugs or submit feature requests, open a JIRA ticket.

    For paid support and managed or consulting services , contact Percona Sales.


    Last update: 2023-10-26
    Percona LLC and/or its affiliates, © 2023
    Made with Material for MkDocs

    Cookie consent

    We use cookies to recognize your repeated visits and preferences, as well as to measure the effectiveness of our documentation and whether users find what they're searching for. With your consent, you're helping us to make our documentation better. Read more about Percona Cookie Policy.