# Percona XtraBackup for Hot MySQL Backups Without a Database Lock

> Percona XtraBackup is a C++ backup utility for selected MySQL and Percona Server environments. It fits database operators seeking online InnoDB, XtraDB, MyISAM, and MyRocks backups, subject to strict release compatibility checks.

**percona/percona-xtrabackup** — Open source hot backup tool for InnoDB and XtraDB databases

- Repository: https://github.com/percona/percona-xtrabackup
- Website: https://www.percona.com/software/mysql-database/percona-xtrabackup
- Stars: 1,559 · Forks: 364
- Language: C++
- License: NOASSERTION
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/percona-percona-xtrabackup

## Percona XtraBackup's Online Backup Scope

Percona XtraBackup addresses a specific operational problem: backing up a running MySQL-based database without locking the database for the duration of the backup. It is aimed at database administrators, site reliability engineers, and teams responsible for continuously available servers where a maintenance outage for a full file copy is undesirable. The README calls it an open source hot backup utility and explicitly addresses both highly loaded 24x7 systems and servers with lower transaction volumes.

The supported scope differs by release line. According to the README, Percona XtraBackup 8.0 can back up InnoDB, XtraDB, MyISAM, and MyRocks tables on MySQL 8.0 servers. Its listed targets include Percona Server for MySQL with XtraDB, Percona Server for MySQL 8.0, and Percona XtraDB Cluster 8.0. Percona XtraBackup 2.4 has a narrower target list: the README limits it to InnoDB, XtraDB, and MyISAM tables on MySQL 5.7 servers and Percona Server for MySQL with XtraDB.

That distinction makes version selection part of the backup architecture rather than a minor packaging choice. The repository contains client, library, storage, plugin, test, packaging, and documentation directories. Based on this layout, XtraBackup is a substantial native backup codebase with its own build configuration and packaged components. The README does not describe the physical backup format, copy algorithm, replication handling, compression behavior, or recovery procedure, so those details cannot be inferred safely from the repository structure alone.

## Compatibility Boundaries Across XtraBackup 8.0 and 2.4

Compatibility is the first adoption constraint. The repository contains files named `XB_VERSION` and `MYSQL_VERSION`, while the README separates XtraBackup 8.0 from the older 2.4 line. The 2.4 documentation does not claim MyRocks support, and the 8.0 line is not presented as supporting MySQL 5.7. An operator moving between server generations therefore needs to match the backup utility release to the database environment rather than assuming that all XtraBackup versions accept the same tables and server products.

The README also distinguishes upstream MySQL from several Percona distributions and cluster products. `Percona Server for MySQL with XtraDB`, `Percona Server for MySQL 8.0`, and `Percona XtraDB Cluster 8.0` appear as separate targets for the 8.0 utility. This list provides a concrete initial compatibility check, but it does not document authentication, binary log, replication, privilege, storage engine plugin, or operating system requirements. Those prerequisites must come from the official documentation for the selected XtraBackup release.

GitHub lists no releases for this repository. The release page therefore cannot serve as a version inventory. Engineers should read `XB_VERSION`, `MYSQL_VERSION`, `INSTALL`, and the linked documentation for the branch they intend to deploy. Files such as `packaging/`, `CMakeLists.txt`, `cmake/`, and `configure.cmake` show that build and packaging resources exist, but the README provides no reproducible build command or package inventory. It would therefore be unsafe to invent executable names, package names, or installation flags.

## Installing XtraBackup Through the Percona Repository

The README lists two installation paths: use the Percona repository or build from source. It directs readers to the official installation page at `https://docs.percona.com/percona-xtrabackup/8.0/installation.html`. The README does not include operating system package names, repository configuration commands, service names, executable names, or a first-backup command. Those details must come from that installation page and the documentation matching the chosen XtraBackup line.

For a first operational use, begin by recording the server product, MySQL major version, XtraBackup release, and storage engines in use. For version 8.0, compare those values with the README's MySQL 8.0 and listed Percona targets. For version 2.4, verify the narrower MySQL 5.7 or Percona Server with XtraDB target list and confirm that MyRocks is not required.

Then open the official installation page for that release and install the package it specifies. The expected result should be an XtraBackup executable available to the backup operator, but the README does not name that executable, so this review does not supply a command that might differ from the documented package.

Source installation is also supported. `INSTALL`, `BUILD.XtraBackup.txt`, `CMakeLists.txt`, and `config.h.cmake` indicate that the source tree includes native build documentation and configuration. However, the README does not list compiler prerequisites, libraries, build parameters, or a complete source-build invocation. A source deployment must follow the official build documentation rather than infer a procedure from the presence of CMake files.

## Where XtraBackup Is the Wrong Backup Choice

XtraBackup is a credible candidate when the requirement is an online physical backup of one of the explicitly listed MySQL combinations and avoiding a database-wide lock during the backup is important. The clearest documented case is MySQL 8.0 or one of the listed Percona 8.0 environments using InnoDB, XtraDB, MyISAM, or MyRocks. The release line and engine list can be checked before an engineer commits to integration work.

It is the wrong starting point for an unlisted server combination. The README makes no claim about MariaDB, arbitrary MySQL forks, additional storage engines, or server versions outside its compatibility lists. The project name contains MySQL, but that does not make every MySQL-compatible server a supported target. Compatibility documentation for the exact product must govern the decision.

The utility also should not be treated as a substitute for every data protection control. The README does not establish that XtraBackup replaces replication, logical backups, monitoring, retention management, or disaster recovery planning. Its stated role is narrower: providing a hot backup without locking the database during that operation. Requirements involving point-in-time recovery, replication coordination, backup retention, or restoration validation need separate documentation and may require additional tools.

There is also no basis in the README for promises about backup duration, storage overhead, compressed backups, encryption, throughput, or recovery time. Those characteristics vary with the server and deployment, and no benchmark figures are supplied. Any operational decision based on them requires results from the intended environment rather than assumptions derived from the repository.

## XtraBackup Compared with a Vendor Backup Facility

A real alternative is the database platform's own supported physical backup facility when that facility is documented for the exact server release. The practical difference is ownership and compatibility scope. XtraBackup is an independently distributed open source utility built primarily in C++, with Percona documentation and explicit version-specific target lists. A vendor facility ties the backup process, supported environments, and support path to the database vendor's release matrix.

That comparison does not automatically favor either option. A vendor facility may be the clearer choice when its documentation covers the selected server more completely. XtraBackup may fit a team that already uses the listed MySQL or Percona targets and wants to build an online physical backup process around the documented 8.0 or 2.4 line. The deciding evidence should be the compatibility matrix and restore procedure, not assumptions that an open source tool has broader coverage or that a vendor tool requires a different workflow.

The README does not name MySQL's own backup command, compare file formats, or document whether one tool can read the other's backup artifacts. It also does not define encryption, incremental backup, merge, prepare, apply-log, or point-in-time recovery workflows. Those are concrete gaps for an engineering evaluation. Until they are confirmed in the official documentation, neither format interoperability nor feature parity should be assumed.

## GPLv2 Statement and the Repository License Classification

The README states that the project uses version 2 of the GNU General Public License, GPLv2, and says the documentation uses a separate linked license. GitHub nevertheless classifies the repository license as Other and explains that it cannot classify the custom `LICENSE` file. These descriptions are not interchangeable without inspecting the actual license text.

This discrepancy affects adoption review because engineers need to know which terms apply to source, binaries, modifications, redistribution, and documentation. This article does not provide legal advice or interpret custom terms. The concrete project-specific check is to open `LICENSE`, compare it with the README's GPLv2 statement, and inspect the linked copyright and licensing documentation for the selected version and distribution.

Commercial support contracts are mentioned in the README, but a support contract is separate from the repository license and should not be inferred from source availability. GitHub lists no releases, so there is no GitHub release entry from which to inspect packaged license metadata. Package maintainers should check the files delivered by the installation method they intend to use rather than relying solely on the repository classification.

## Maintenance Signals and Source-Build Cost

The repository is not archived, and its last push was on 2026-10-15. That is a recent development signal, but it does not guarantee that every server and table combination in the README remains equally supported. GitHub lists no releases, so upgrade discovery must come from the source tree or Percona's documentation rather than the repository's release page.

The native C++ layout indicates a substantial maintenance surface. The repository includes libraries, utilities, plugins, clients, tests, and packaging directories. `mysql-test/`, `unittest/`, `.clang-format`, `.clang-tidy`, and `CONTRIBUTING.md` show development areas for tests, formatting, static analysis, and contribution rules. The README does not describe release cadence, support lifecycles, migration procedures, or the work required to move a deployment across major server versions, so a numerical maintenance estimate would have no basis.

Upgrade planning begins with version alignment. Compare `XB_VERSION`, `MYSQL_VERSION`, the server product, and the storage engines listed in the matching documentation. Then consult `INSTALL` and the official upgrade documentation for the installed line. The README does not document rollback, compatibility with backup files created by an older release, or whether a backup utility can be upgraded in place while retained backup images remain usable. Those boundaries must be checked before changing the installation.

## Conclusion

Database operators running one of the server combinations explicitly covered by the XtraBackup documentation should evaluate it for online backup requirements, while developers needing unsupported server versions or storage engines should select another tool. Before adoption, verify `XB_VERSION` and `MYSQL_VERSION`, confirm that the planned server and tables appear in the matching documentation, and read `LICENSE` because the README describes GPLv2 while GitHub classifies the license as Other.

## FAQ

### Which databases and storage engines does Percona XtraBackup support?

The README states that Percona XtraBackup 8.0 supports InnoDB, XtraDB, MyISAM, and MyRocks tables on MySQL 8.0 servers and the listed Percona 8.0 targets. Version 2.4 supports InnoDB, XtraDB, and MyISAM on MySQL 5.7 servers and Percona Server for MySQL with XtraDB.

### Does Percona XtraBackup lock the database during a backup?

The README describes XtraBackup as a hot backup utility for MySQL-based servers that does not lock the database during the backup. It does not claim that backup operations have no impact on the server or performance.

### How do I install and use Percona XtraBackup?

The README lists installation through the Percona repository or by building from source. It does not include commands or the executable name, so installation and the first-backup procedure should be taken from the linked Percona XtraBackup 8.0 documentation.

## Sources

- [Issues](https://github.com/percona/percona-xtrabackup/issues)
- [percona/percona-xtrabackup on GitHub](https://github.com/percona/percona-xtrabackup)
- [Project website](https://www.percona.com/software/mysql-database/percona-xtrabackup)
- [README](https://github.com/percona/percona-xtrabackup/blob/trunk/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/percona-percona-xtrabackup
