Physical backup files need a preparation phase
A physical backup captures database files while transactional work can be active. Percona XtraBackup's preparation phase applies recovery information so a supported backup set can be used for restoration. Copying the backup directory successfully does not establish that this preparation has completed.
Preparation writes to the target backup files. This is an operational mutation, not a read-only integrity check. Preserve the original backup and perform rehearsals on a controlled working copy so an unsuccessful experiment does not consume the only retained recovery artifact.
Setup: pin the source and tooling contract
This guide concerns the documented Percona XtraBackup 8.4 full-backup preparation workflow. Record the database version, XtraBackup version, backup type, completion evidence, encryption or compression requirements and file ownership. Confirm compatibility against the current vendor guidance before using a backup from another database release.
Choose an isolated working directory with sufficient storage and access controls. Preserve the backup metadata and logs with the original set. If the backup workflow includes incremental sets, compression or encryption, follow their documented sequence rather than treating an arbitrary directory as a standalone full backup.
Prepare and inspect a working copy
- Verify that the selected backup operation completed and that all expected files reached the recovery location. Use transfer-integrity evidence to detect copying problems before applying recovery.
- Create the controlled working copy and verify its ownership, capacity and contents. Keep its identity distinct from both the retained original and any live database directory.
- Run the supported preparation operation against that working directory using the compatible XtraBackup release. The illustrative command shape is
xtrabackup --prepare --target-dir=/approved/working-copy; review and substitute the actual directory before execution. - Inspect final tool status and preparation logs. Preserve errors and metadata rather than retrying different versions or options until one process exits without an obvious message.
Illustrative incident: a copy check is mistaken for restore readiness
In this illustrative scenario, a backup transfer job reports matching file checksums. During a recovery exercise, the team discovers that the copied files were never prepared using the compatible toolchain. Storage delivery had been tested, but the physical recovery workflow had not.
The operator preserves the original set, prepares a working copy and completes an isolated restoration and application check. The exercise adds preparation evidence to acceptance. This example explains layered verification and does not claim an actual failed production restore.
Diagnostic table
| Observation | Evidence | Boundary |
|---|---|---|
| Files transferred but recovery fails | Backup completion and prepare logs | Physical recovery readiness |
| Tool rejects the set | Source and tool versions | Compatibility |
| Working disk fills during preparation | Capacity and temporary usage | Recovery workspace |
| Database starts but data is unusable | Database and application checks | Restore acceptance |
Verify an isolated restoration
Use the documented restore procedure on a separate compatible target with the necessary privileges. Do not overwrite a running database as part of a casual test. Check database startup, representative records and the application's important read and write behavior on the restored system.
Record the time spent transferring, preparing and validating separately, because all can affect recovery expectations. Verify access to encryption keys and configuration where the backup depends on them. A prepared directory is another necessary checkpoint, not a replacement for testing the service that will consume the data.
SOP and monitoring
Retain source-version metadata, original backup identity, transfer evidence, preparation logs and restore acceptance results. Monitor backup completion and rehearsal freshness independently. The SOP should name the approved working-copy location and compatible tools, preserve the original recovery artifact, and identify who can approve the final restore into a service environment.
See Clouvenix backup disaster recovery for implementation and operational handover.
Technical reference
Official reference 1. Documentation checked 20 October 2026; confirm behavior for your deployed edition and version.