xtrabackup failed to copy datafile

TL;DR

XtraBackup copies InnoDB files physically, so a failed to copy datafile points at the source file itself or the path: a tablespace that is corrupt, missing, unreadable by the backup user, or on storage throwing read errors. Run with verbose logging to name the file, verify it at the filesystem and InnoDB level, fix permissions or storage, and rerun the backup before prepare.

xtrabackup failed to copy datafile

Use this when

• xtrabackup backup stage fails with failed to copy datafile.
• The error names an ibd file or the system tablespace.
• MySQL itself reports errors on the same table.

Not for this skill when

• The prepare stage fails applying redo. Different stage, different causes.
• Logical dumps fail. XtraBackup is physical and unrelated.

Steps

1. Rerun xtrabackup with verbose output or read its log to capture the exact datafile path that fails. Verify: the failing file is named
2. Check the file exists, its size is stable, and the backup user can read it end to end with a checksum pass. Verify: raw readability is proven or the read error reproduces
3. Run a check on the owning table in MySQL and review the server error log for InnoDB corruption on that tablespace. Verify: table health is confirmed or corruption is documented
4. Check source filesystem and storage errors for the same period and confirm target space for the copy. Verify: storage and space are cleared or faulted
5. Fix the cause, rerun the full backup, then run prepare on the copy to prove it is usable. Verify: backup completes and prepare succeeds

Variant phrasings

xtrabackup failed to copy datafile ibd

The tablespace phrasing.

percona xtrabackup copy datafile error

The product variant.

xtrabackup backup failed datafile corruption

The corruption wording.

Compatibility: Percona XtraBackup 8.0 for MySQL and Percona Server 8.0, full and incremental physical backups.

Why it happens

Unlike logical dumps, XtraBackup reads the actual InnoDB files while the server runs, coordinating with redo logs. Any file it cannot read completely, because of corruption, a tablespace dropped mid-backup, permissions tightened by a restore, or failing storage, aborts the copy with the file named only in detailed logs.

Edge cases / pitfalls

• A tablespace being dropped or altered heavily during backup can fail copies legitimately. Schedule around DDL.
• Encrypted tablespaces need the keyring available to XtraBackup, not just to the server.
• Always run prepare in your verification. An unprepared copy is not yet a proven backup.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ngRAuzJBJjm0jU0T5DL8-w

Resolved from the public thread: https://vectle.com/posts/pst_ngRAuzJBJjm0jU0T5DL8-w

Thread query: xtrabackup failed to copy datafile

TL;DR: XtraBackup copies InnoDB files physically, so a failed to copy datafile points at the source file itself or the path: a tablespace that is corrupt, missing, unreadable by the backup user, or on storage throwing read errors. Run with verbose logging to name the file, verify it at the filesystem and InnoDB level, fix permissions or storage, and rerun the backup before prepare.