Why Two Identical Backups Had Different Sizes: A Real-World XtraBackup Investigation

Overview

Percona XtraBackup is a widely adopted utility for performing hot physical backups of MySQL databases. It allows database administrators to capture consistent, point-in-time snapshots of data without interrupting active database transactions, making it a critical component of any production infrastructure.

Beyond basic file copying, the tool supports various compression algorithms to reduce disk usage and speed up backup transfers. However, depending on the specific version of XtraBackup you use, different compression methods are available, each offering varying levels of storage efficiency and processing overhead.

When managing multiple replica or backup environments, it is logical to expect that identical source databases will yield identical backup sizes. Yet, variations in tool versions can quietly introduce different default behaviors. This post walks through a real-world troubleshooting case where two backup servers running on identical datasets produced significantly different file sizes, and how identifying a minor tool version mismatch led us to the solution.

The Problem

While conducting routine validations of physical backups between Backup Server 1 and Backup Server 2, our database administration team noticed a substantial discrepancy in file sizes.

Although both backup targets were processing the exact same MySQL dataset, the backup generated on Backup Server 1 was noticeably smaller than the one on Backup Server 2. This size difference raised immediate questions:

• Was one of the backups corrupted or incomplete?
• Was a portion of the data directory skipped during execution?
• Were there hidden configuration differences in the backup scripts?
• Was compression completely bypassed on one of the hosts?

Because ensuring backup integrity is paramount, we had to verify the underlying cause before concluding whether both backups were safe to use for recovery. To learn more about selecting the right backup methods for your architecture, you can refer to our guide on combining physical and logical backup methods.

Initial Investigation

Our first step was to review the respective backup environments and logs. Both servers completed their full physical backups successfully, reporting zero errors. Compression flags were explicitly enabled on both hosts, and their configuration parameters appeared identical.

However, checking the package details revealed a minor version difference:

• Backup Server 1: Running Percona XtraBackup version 8.0.35-30
• Backup Server 2: Running Percona XtraBackup version 8.0.33-28

At first glance, this appeared to be a minor version difference. Since both versions belonged to the 8.0 release series, it was tempting to assume that backup behavior would be identical.

However, backup sizes suggested otherwise. We have previously observed similar challenges with XtraBackup version compatibility issues.

Digging Deeper

Rather than looking only at the version numbers, we analyzed the compression methods actively employed by each process. This parameter proved to be the key differentiator.

Backup Server 1 utilized Zstandard (ZSTD) compression, while Backup Server 2 relied on QuickLZ (.qp) compression.

In Percona XtraBackup version 8.0.34-29, Percona deprecated the older QuickLZ/qpress algorithms and made ZSTD the default compression method for the --compress option. This explains why the two systems behaved differently:

• Backup Server 2 (running 8.0.33-28) defaulted to the legacy QuickLZ (.qp) format.
• Backup Server 1 (running 8.0.35-30) automatically utilized ZSTD (.zst).

While both algorithms yield compressed archives, their efficiency profiles differ significantly. You can find more detail on how these commands operate in the official Percona XtraBackup compression guide.

The table below summarizes the key differences:

In our environment, the older Backup server 2 backup was still using the default QuickLZ compression, whereas Backup server 1 was already using ZSTD. Since both algorithms compress the same data differently, the resulting backup sizes varied significantly despite backing up identical datasets.

The Breakthrough

After confirming that Backup Server 1 benefited from ZSTD, we chose to align the software version on Backup Server 2 to establish standard backup behaviors.

We upgraded Backup Server 2 from version 8.0.33-28 to 8.0.35-30 to match Backup Server 1. Once the upgrade was complete, we initiated a new test backup to verify the result.

The Result

The updated backup executed without errors. Once completed, we analyzed the storage output:

• Before the Upgrade (Backup Server 2): QuickLZ (.qp) yielded a backup size of approximately 9.6 TB.
• After the Upgrade (Backup Server 2): ZSTD (.zst) successfully reduced the backup size to 6.3 TB.

The new file size closely matched the 6.3 TB output of Backup Server 1, proving that the previous variance was purely a function of the compression algorithm rather than data loss or execution errors.

Backup Summary

The successful backup confirmed that the upgraded environment was now producing backups comparable to those of Backup server 1.

The investigation confirmed that the backup size difference was not caused by missing data, backup failures, or storage issues. Instead, it was entirely due to the difference in XtraBackup versions and the compression algorithms they used. Once both environments were aligned to the same version and compression method, the backup sizes became consistent.

For additional context on how XtraBackup performs compared to logical dump options, see our evaluation of the MySQL Clone Plugin vs. XtraBackup.

Why Alignment Matters

This exercise demonstrates that compression settings heavily dictate resource usage in production environments. Implementing modern algorithms like ZSTD offers several advantages:

• Storage Savings: Reduces cold storage and archival disk footprints.
• Network Efficiency: Minimizes bandwidth consumption when moving backups to remote disaster recovery environments or cloud storage.
• Faster Replication Transfers: Smaller files speed up host provisioning and replication setup.
• Consistency: Consistent environment versions prevent false alarms and simplify file verification.

When infrastructures run mixed software versions, subtle shifts in defaults can occur silently, making direct size comparisons confusing. Aligning these utilities across your environments ensures predictable behavior.

Key Takeaways

This investigation highlighted several important lessons:

• Always Align Utility Versions: Standardize minor versions of database utilities (such as Percona XtraBackup) across all secondary and backup servers.
• Verify Defaults: Do not assume identical commands behave identically across different minor software releases; always review release notes.
• Confirm the Compression Algorithm: If backup file sizes diverge, check the extension (.qp vs. .zst) and compression method before suspecting database inconsistency.
• Consider upgrading to ZSTD: If you are running older versions of XtraBackup, planning an upgrade can save substantial storage space. Learn how we facilitate these setup processes in our guide on managing MySQL hot backups.

Final Thoughts

A large discrepancy in backup sizes often triggers concerns about missing data or partial backups. However, in this case, both files were functionally valid and healthy. The differences were entirely structural, driven by the shift from legacy QuickLZ to Zstandard compression.

Before investigating complex database discrepancies, check the version of the tools being executed. A simple package alignment can save hours of troubleshooting and confirm the absolute health of your disaster recovery pipeline.

Maximize Your Storage & Database Performance

‍Is your team struggling with ballooning backup sizes, long transfer windows, or database upgrade challenges?

Our MySQL specialists can analyze your backup architecture, optimize compression settings, and ensure a highly reliable recovery path.