Backup lifecycle¶
Quick-scan facts: privileges, phases, defaults, and behavior. For the internals narrative, see What happens underneath. For commands and flag selection, see How-to: backup lifecycle operations.
Privileges (summary)¶
| Privilege | Typical use |
|---|---|
BACKUP_ADMIN |
Read performance_schema.log_status; use LOCK INSTANCE FOR BACKUP, LOCK TABLES FOR BACKUP, LOCK BINLOG FOR BACKUP when applicable |
RELOAD |
Workflows using FLUSH TABLES WITH READ LOCK or similar |
LOCK TABLES |
Workflows that issue table-level locks |
REPLICATION CLIENT |
--slave-info and related replication metadata |
Connection and privileges needed has the full list.
Three operator-facing phases¶
| Step | Phase | What happens |
|---|---|---|
| 1 | Backup (hot copy) | Copy data files; stream redo for the whole run |
| 2 | Prepare | Replay redo; roll back uncommitted work |
| 3 | Restore | --copy-back or --move-back into datadir |
Three in-backup sub-phases (locking)¶
With backup locks, Percona XtraBackup (PXB) typically runs the stages in the table below. Each numbered row is a phase in order: the Locks column is the global lock posture for that phase, and the Work column is what PXB copies or records while those locks apply—InnoDB pages and redo first (often with no global backup lock), then non-InnoDB files under the backup lock (with DDL restricted), then a short LOCK BINLOG FOR BACKUP to pin binlog or replica coordinates. Exact steps depend on server version and which storage engines are in use.
| # | Locks | Work |
|---|---|---|
| 1 | None global | Copy InnoDB files and redo while data manipulation language (DML) runs |
| 2 | Backup lock | Copy non-InnoDB files (e.g. .frm, .MRG, .MYD, .MYI, .CSM, .CSV, .sdi (serialized dictionary information), .par); data definition language (DDL) restricted, DML usually allowed—details are server-specific |
| 3 | LOCK BINLOG FOR BACKUP (short) |
Pin binlog/replica coordinates; read performance_schema.log_status; drop locks |
Backup locks vs FTWRL (FLUSH TABLES WITH READ LOCK): Percona Server backup locks.
MySQL 8.4: LOCK INSTANCE FOR BACKUP.
--lock-ddl¶
| Value | When the backup lock is taken (typical) |
|---|---|
ON (default) |
Backup start |
REDUCED |
After InnoDB data copy finishes |
ON blocks DDL for the whole window from the beginning; REDUCED delays that until InnoDB is copied (shorter DDL stall, different overlap with DDL during the InnoDB phase). InnoDB DML usually keeps running through the main copy.
--register-redo-log-consumer¶
| Field | Detail |
|---|---|
| Default | Off |
| Does | Registers PXB as a redo consumer so the server won’t purge a redo file until PXB copies that file |
| Cost | Redo can pile up (“redo bloat”); disk use may spike |
| Writes | Server may stall writes briefly while the consumer advances |
Prepare options (subset)¶
| Option | Notes |
|---|---|
--use-memory |
Random-access memory (RAM) for prepare only (default 100MB); larger often helps |
--parallel |
8.4.0-3+: parallel .delta apply for incrementals; not the same as parallel full-backup redo replay |
Full flags: xtrabackup option reference.
Restore (facts)¶
-
Pulls paths from
my.cnf(e.g.datadir,innodb_data_home_dir,innodb_data_file_path,innodb_log_group_home_dir). -
Order: MyISAM-family files first (
.MRG,.MYD,.MYI,.CSM,.CSV,.sdi,.par), then InnoDB tables/indexes, then logs. -
Keeps file attributes.
-
Successful backup prints binlog coordinates to standard error (STDERR)—redirect if you need a file.
When backup locks are skipped (“lockless”)¶
Locks stay off only if every table in every schema—including mysql—is InnoDB. Commonly mysql still holds CSV/MyISAM tables (e.g. general_log), so PXB usually takes backup locks anyway.
| Server | Notes |
|---|---|
| Percona Server for MySQL 8.4 | log_status may carry relay coordinates; --slave-info can skip extra locks |
| Standard MySQL 8.4 | May still need FLUSH TABLES WITH READ LOCK with --slave-info when you need relay position |
Cloud / streaming¶
Same phases; slow networks stretch Final Sync and can lengthen short locks. Streaming backup, xbcloud overview.