Physical Backups: CLONE, XtraBackup and Snapshots

A physical backup copies the files that MySQL uses (tablespaces, redo logs, system files), not the SQL that creates the data. Backups and restores are much faster than a dump, which matters for databases of tens or hundreds of gigabytes. The price is portability: a physical backup is for the same major version (and usually the same operating system and architecture).

Never copy the data directory of a running server

Copying /var/lib/mysql with cp or rsync while MySQL is running gives a corrupted, inconsistent copy: pages change while they are being copied. The server must be stopped cleanly, or you must use a tool that handles the live server. The options:

The CLONE plugin, for real

CLONE makes a consistent copy of all InnoDB data while the server keeps running. It needs a plugin, installed once (this is the Windows library name, on Linux it is mysql_clone.so):

1
2
3

INSTALL PLUGIN clone SONAME 'mysql_clone.dll';

SELECT PLUGIN_NAME, PLUGIN_STATUS FROM information_schema.PLUGINS WHERE PLUGIN_NAME = 'clone';

1
2
3
4
5

+-------------+---------------+
| PLUGIN_NAME | PLUGIN_STATUS |
+-------------+---------------+
| clone       | ACTIVE        |
+-------------+---------------+

Then clone to a new directory (it must not exist yet, and the MySQL server’s operating system user must be able to create it):

1
2
3

CLONE LOCAL DATA DIRECTORY = '/backups/clone-2026-10-05';

SELECT STATE, ERROR_NO, ERROR_MESSAGE FROM performance_schema.clone_status;

1
2
3
4
5

+-----------+----------+---------------+
| STATE     | ERROR_NO | ERROR_MESSAGE |
+-----------+----------+---------------+
| Completed |        0 |               |
+-----------+----------+---------------+

On a real MySQL 8.4 test server the clone directory afterwards contained a complete data directory:

1

#clone   #innodb_redo   ib_buffer_pool   ibdata1   learn   mysql   mysql.ibd   shop   sys   undo_001   undo_002

To prove it is a real, working backup, a second MySQL server was started on the cloned directory (on another port), and it contained the data:

1

mysqld --datadir=/backups/clone-2026-10-05 --port=3399

1

SELECT @@port AS port, (SELECT COUNT(*) FROM shop.orders) AS orders, (SELECT COUNT(*) FROM shop.customers) AS customers;

1
2
3
4
5

+------+--------+-----------+
| port | orders | customers |
+------+--------+-----------+
| 3399 |      6 | 5 |
+------+--------+-----------+

(Values from the real test; the table layout is shortened.) A few important points:

• CLONE copies InnoDB data. Other engines’ files are copied only partly (MyISAM tables are not consistent), and configuration files and the binary logs are not included.
• A remote clone (CLONE INSTANCE FROM 'user'@'host':3306 IDENTIFIED BY '...') copies from one server to another over the network. It is a fast way to build a new replica.
• It needs the account to have the BACKUP_ADMIN privilege (on the donor), and CLONE_ADMIN on a recipient.
• Cloning blocks some DDL (ALTER TABLE, DROP TABLE) on the donor while it runs.
• After restoring a clone, the server runs crash recovery on start, like after a power cut. That is normal for hot backups.

XtraBackup

Percona XtraBackup is the common free tool for hot physical backups:

1
2
3
4
5
6
7
8
9

# take a full backup
xtrabackup --backup --user=backup --password --target-dir=/backups/full-2026-10-05

# prepare it (apply the redo log so the files are consistent)
xtrabackup --prepare --target-dir=/backups/full-2026-10-05

# restore: with MySQL stopped and an empty data directory
xtrabackup --copy-back --target-dir=/backups/full-2026-10-05
chown -R mysql:mysql /var/lib/mysql

The three phases are always backup, prepare, restore. An unprepared backup is not consistent. XtraBackup also offers incremental backups (only pages changed since the last one), compression and encryption. Use the XtraBackup version that matches your MySQL version.

Snapshots

Cloud disks and storage systems can take an instant snapshot. For MySQL:

• Keep data and redo logs on the same volume, so that one snapshot is consistent.
• InnoDB recovers from the snapshot as from a crash, which works because InnoDB is crash-safe.
• With sync_binlog = 1 and innodb_flush_log_at_trx_commit = 1 (the safe defaults), no committed transaction is lost.
• For a more controlled snapshot, run FLUSH TABLES WITH READ LOCK, snapshot, then UNLOCK TABLES. That blocks writes for a moment.
• Test a restore from a snapshot like any other backup.

Choosing

Physical backups and the binary log together give you point-in-time recovery: restore the files, then replay the log from the position stored in the backup (Point-in-Time Recovery).