The Structure of WordPress Backups
A WordPress backup is not a single file in the way a simple archive or database dump is. Most complete WordPress backups consist of at least two distinct components: a file archive containing the WordPress installation directory (including themes, plugins, and uploads), and a SQL database dump containing the WordPress database tables. In many plugin-generated backups, these components are bundled together into a single outer archive.
Understanding this layered structure is important when assessing corruption. Damage to the outer container does not necessarily mean the inner components are affected. In many cases, we can extract the database dump and the file archive from a partially damaged outer container, even when the outer archive itself fails all standard integrity checks.
Conversely, a backup where the outer archive opens cleanly but the inner SQL dump is truncated will restore the files but fail on the database component — leaving a WordPress installation that starts but has no content, configuration, or user data.
Supported Backup Sources
We work with backups generated by most common WordPress backup plugins and hosting platforms, including:
- UpdraftPlus: Produces separate database and files archives, sometimes split across multiple volumes for large sites. CRC errors in one volume do not always prevent recovery of data from other volumes.
- BackupBuddy: Uses a custom archive format for the file component. We have documented experience with BackupBuddy archive structures and the common failure patterns.
- Duplicator: Packages the site into a ZIP file alongside an installer script and a SQL dump. Corruption in the ZIP layer often leaves the SQL component intact and accessible through raw extraction.
- All-in-One WP Migration: Uses the .wpress format, a proprietary binary container. Recovery from corrupted .wpress files depends on where in the file the damage is located.
- cPanel Full Backup: Produces a TAR.GZ archive of the entire hosting account, including all databases and home directory files. These are large files and are vulnerable to truncation on slower hosting environments.
- Plesk Backup Manager: Produces a proprietary backup format. Recovery depends on the version of Plesk and the nature of the corruption.
- Manual exports: Combinations of mysqldump output and tar-compressed file trees. These are often the easiest to work with, as they follow standard format specifications without plugin-specific wrappers.
Common Failure Scenarios
The most frequently encountered issues with WordPress backup files include:
- Incomplete backups created under server time limits: Many shared hosting environments impose execution time limits (often 60–300 seconds) that can cause large backup operations to terminate before completion. The resulting file is valid up to the interruption point only.
- Split UpdraftPlus archives with missing volumes: UpdraftPlus splits large backups into multiple files. If one file is deleted, moved, or was never successfully uploaded to remote storage, the set is incomplete.
- Duplicator ZIP corruption from large sites: Duplicator uses PHP's ZipArchive library for packaging, which has known limitations with files exceeding certain sizes. Very large sites can produce malformed ZIP files, particularly on PHP 32-bit environments.
- cPanel backup failures mid-archive: cPanel's backup process can be interrupted by out-of-memory conditions, disk quota limits, or server restarts. The resulting archive is valid up to the point of interruption.
- Cloud storage download truncation: Backups retrieved from S3, Dropbox, or Google Drive via slow or unreliable connections sometimes arrive incomplete. This produces a valid-looking file that fails all integrity checks.
Recovery Approach
We treat WordPress backup recovery as two parallel tasks: recovering the file archive and recovering the database. Each is assessed independently because the damage profile is often different, and the priorities for a given site may differ — a content-heavy site might prioritise the uploads directory, while a subscription-based site might prioritise the database above all else.
For the file component, we attempt to extract the WordPress core files, the wp-content directory (including plugins, themes, and uploads), and the wp-config.php file from whatever portion of the archive is readable. Where the wp-config.php is recoverable, the database credentials it contains may allow us to validate the database against the expected structure.
For the database component, we follow the SQL repair methodology described in our Database Backup Repair service — identifying which tables are fully recoverable, which are partial, and which are absent. The most critical WordPress tables (wp_users, wp_options, wp_posts, and wp_postmeta) are prioritised in the assessment.
After Recovery
Once recovery is complete, we provide the recovered files and database in a clean, importable format. We include a written summary of what was recovered, what was not, and what the recovered material contains. We can also advise on the restoration process and on improving the backup setup to reduce the risk of this situation recurring.