Starting with version 7.104, All-in-One WP Migration calculates a CRC32 checksum every time you export your site and verifies it every time you import. If your backup was corrupted during download, transfer, or storage, the plugin catches it before any changes touch your database or files.
This post explains how it works, why it matters, and why the .wpress archive format makes this possible in ways that ZIP-based backup plugins simply cannot match.
What Is CRC32 and Why Does It Matter?
CRC32 (Cyclic Redundancy Check, 32-bit) is a checksum algorithm used everywhere from Ethernet frames to PNG files. It produces a short fingerprint of your data. If even a single byte changes, the checksum changes.
When you move a WordPress backup between servers, a lot can go wrong. FTP transfers can silently drop bytes. Browser downloads can get interrupted and resumed incorrectly. Cloud storage syncs can fail mid-file. And the worst part? A corrupted backup file often looks perfectly normal from the outside. You only discover the damage after importing it, when pages are broken, images are missing, or your database is mangled.
CRC32 verification eliminates that risk. The plugin now knows whether the file you are importing is exactly the file that was exported.
How It Works
The integrity verification operates at two levels:
Per-file checksums. Every file inside the .wpress archive (your themes, plugins, uploads, database dump) gets its own CRC32 checksum stored in the file header. This means the plugin can pinpoint exactly which file is damaged, not just that “something is wrong.”
Archive-wide checksum. A CRC32 checksum of the entire archive is calculated and stored in the .wpress EOF (end-of-file) block. This catches corruption that might affect the archive structure itself, not just individual files.
During import, the plugin recalculates the archive-wide checksum and compares it to the stored value. If they do not match, the import stops immediately with a clear error message explaining what happened and what to do next. No partial imports. No half-restored databases. No guesswork.
The .wpress Advantage: Large Files Without Compromise
Here is where things get interesting, and where the .wpress format proves its worth over ZIP.
Most WordPress backup plugins use the ZIP archive format. ZIP is ubiquitous and well-understood, but it has a fundamental limitation: you must write an entire file into the archive in a single operation. The ZIP local file header requires the CRC32 checksum and file size to be finalized when the entry is written (or patched immediately after via a data descriptor). This means the entire file must be processed in one go.
On most WordPress hosting environments, PHP execution is limited to 15 to 30 seconds per request. For small files, that is plenty. But what happens when your uploads folder contains a 500MB video, a 2GB database dump, or a large WooCommerce product catalog with thousands of high-resolution images?
ZIP-based plugins have three options, and none of them are good:
Skip large files. Many backup plugins simply exclude files above a certain size threshold. Your backup looks complete, but that 500MB video or critical database table is missing. You only find out when you restore and the file is gone.
Fail with a timeout error. If the plugin tries to add a large file and PHP times out, the backup fails entirely. Users are left troubleshooting server configurations they may not have access to change.
Require server-level changes. Some plugins ask you to increase
max_execution_timein php.ini or .htaccess. This requires hosting access that many users do not have, and some managed hosts do not allow it at all.
The .wpress format solves this by design. It does not use ZIP. Instead, it uses a custom streaming archive format that writes raw file data in 512KB chunks across multiple PHP requests. Here is how it works:
- The file header (containing filename, size, path, and CRC32 field) is written once at the start.
- File data is written in 512KB chunks. After each chunk, the plugin checks whether PHP is approaching its timeout limit.
- If time is running out, the plugin saves its exact position (byte offset, bytes written, and partial CRC32) and gracefully exits.
- On the next request, it picks up exactly where it left off, resuming from the saved byte offset.
- When the file is complete, the partial CRC32 values from each chunk are mathematically combined using GF(2) polynomial arithmetic (the same approach used by zlib) to produce the final checksum.
This means a 2GB file on a host with a 30-second PHP timeout gets processed across dozens of small requests, each writing a few megabytes. No files are skipped. No timeouts. No server configuration changes needed.
And the CRC32 checksum is calculated across all of those chunks, producing the same result as if the entire file had been processed in one pass. The mathematical combining of partial CRC values is exact, not an approximation.
What Happens When Verification Fails
If the archive-wide checksum does not match during import, you see a clear error:
This backup file is damaged and can’t be imported. Try downloading or transferring the file again.
Reason: File integrity check failed (CRC mismatch).
The import stops before any changes are made to your site. Your existing WordPress installation remains untouched. You can then re-download or re-transfer the backup and try again.
Backward Compatibility
If you import a .wpress file that was created with an older version of the plugin (before 7.104), the import works normally. Older archives simply do not have a CRC32 checksum stored, so the verification step is skipped. No action is required on your part.
Going forward, every new export includes the checksum automatically. There is no setting to enable or configure. It just works.
Update Today
CRC32 checksum verification is available now in All-in-One WP Migration version 7.104. Update through your WordPress dashboard to start generating verified backups immediately.
If you are moving a site between hosts, restoring from a backup, or just want peace of mind that your .wpress files are intact, this update has you covered.