Backup lifecycle

A Percona XtraBackup (PXB) workflow runs three sequential phases: backup, prepare, and restore. This how-to guide describes each phase and the operational flags that shape locking, redo retention, and recovery output.

Apply the following principles across every lifecycle phase:

• Grant only the privileges that the workflow requires.

• Run backup, prepare, and restore in sequence.

• Capture binary log coordinates for recovery and replication.

• Choose operational flags, such as --lock-ddl and --register-redo-log-consumer, to match the workload and lock tolerance.

Grant the minimum privileges

PXB needs database privileges that match the locking operations and metadata reads in the workflow.

Complete the following privilege steps:

1. Grant BACKUP_ADMIN so PXB can read performance_schema.log_status.

2. Confirm BACKUP_ADMIN allows PXB to take LOCK INSTANCE FOR BACKUP, LOCK TABLES FOR BACKUP, and LOCK BINLOG FOR BACKUP.

3. Add RELOAD, LOCK TABLES, or REPLICATION CLIENT for workflows that need extra capabilities. Examples include FLUSH TABLES WITH READ LOCK and the --slave-info option.

For privilege lists and worked examples, see Connection and privileges needed.

Run a backup and capture binary log coordinates

Capture binary log coordinates during the backup phase to support recovery and replica bootstrap.

Complete the following backup steps:

1. Run xtrabackup against the target directory with the standard options.

2. Redirect STDERR to a log file because PXB writes the binary log coordinates to STDERR. For example, xtrabackup ... 2> backupout.log.

3. Confirm the command returns exit code 0.

For the artifact list a backup produces, see Index of files created by Percona XtraBackup.

Choose a --lock-ddl mode

PXB uses backup locks to copy non-InnoDB files without blocking InnoDB DML, when the server supports backup locks.

The following table compares the two --lock-ddl modes:

Option	Effect
--lock-ddl=ON (default)	Takes the backup lock at start. DDL stays blocked for the full run, unless the workflow changes.
--lock-ddl=REDUCED	Takes the lock after InnoDB is copied. DDL blocks for a shorter window. This mode accepts DDL contention during the InnoDB phase in exchange for a shorter DDL block.

Warning

Both modes block schema changes (DDL) for part of the backup window. Schedule DDL outside the backup, or accept the contention.

For a compact comparison, see Reference: backup lifecycle.

When to enable --register-redo-log-consumer

Enable --register-redo-log-consumer when heavy write throughput risks purging redo before PXB finishes reading the redo stream. The flag prevents failures caused by missing redo.

Review the following checks before enabling the flag:

• Plan for redo bloat and possible disk exhaustion, because the server retains redo longer.

• Monitor free space and I/O throughout the run.

• Abort the backup with Ctrl+C or SIGTERM to the xtrabackup process if disk space reaches a critical threshold. The consumer then releases, the server purges redo, and the operator can free space and retry.

The default value is OFF. Enable the flag only when spare disk space is available.

Prepare the backup with --prepare

The prepare phase applies redo and rolls back uncommitted transactions to produce a consistent snapshot.

Complete the following prepare steps:

1. Run xtrabackup --prepare with --target-dir set to the backup directory.

2. For large or incremental backups, tune prepare performance with the following options:

   • Raise --use-memory to between 1 GB and 2 GB when RAM allows, because the default value is small.

   • Pass --parallel to apply .delta files in parallel on incremental backups, starting in 8.4.0-3. The flag does not parallelize first-pass redo on a full backup.

The following command shows a tuned prepare run:

xtrabackup --prepare --use-memory=2G --parallel=4 --target-dir=/data/backups/

Warning

Leave RAM headroom for the OS and mysqld when prepare runs on the same host as production. Insufficient headroom triggers OOM kills.

For flag references, see --use-memory and --parallel.

Restore with --copy-back or --move-back

The restore phase places prepared backup files into the destination datadir for mysqld startup.

Complete the following restore steps:

1. Stop mysqld if the process owns the destination datadir.

2. Run xtrabackup --copy-back or xtrabackup --move-back with --target-dir set to the prepared backup. PXB reads destination paths from the configuration, including datadir, InnoDB paths, log paths, and related settings.

3. Set ownership and permissions before starting mysqld. For example, run chown -R mysql:mysql /var/lib/mysql. Backup files belong to the user that ran xtrabackup, while the server expects the mysql user.

4. Start mysqld.

Warning

--move-back destroys the original backup directory because the command moves files instead of copying them. Use --move-back only when disk space is constrained, and confirm a separate backup copy is available.

For full restore flows covering full, incremental, and compressed backups, see Restore full, incremental, and compressed backups.

Stream backups or upload to object storage

Streaming backups and cloud uploads follow the same lifecycle as a local backup. Slow networks extend the PXB final-sync phase and hold the short backup locks, including the binary log lock, for longer.

Plan streaming and upload runs with the following guidance:

• Run streaming backups inside a maintenance window.

• Size network bandwidth and destination throughput to keep the final-sync phase short.

• Confirm the destination object store accepts the backup payload size.

For workflow details, see the following references:

• Take a streaming backup

• xbcloud binary overview