When a WordPress backup is split across archives, the restore tool usually requires every part plus any manifest or index file created with the backup. Check the backup job's file list, naming sequence, and restore instructions before uploading or extracting anything. A split archive is one backup divided into smaller files, often to meet storage or upload limits. The individual files are not separate backups; the restore process may need the complete set to rebuild the site correctly.
Table of Contents
- Identify the Complete Backup Set
- Find What the Restore Tool Requires
- Check Names, Order, and Completeness
- Upload and Restore the Set Safely
- Understand What a Complete Set Can Still Miss
Identify the Complete Backup Set
Start with the backup folder or download package. Look for files that share the same backup name, timestamp, or job identifier, then compare their numbered suffixes. A typical set might look like this: The exact extensions vary by plugin and hosting system.
Some tools use numbered archive parts, while others provide separate files for the database, uploads, themes, plugins, and configuration. Do not treat a single numbered part as a usable backup unless the restore tool specifically says it can. Missing one part can prevent extraction or produce an incomplete restoration.
- `site-backup.zip.001`
- `site-backup.zip.002`
- `site-backup.zip.003`
- `site-backup-manifest.json`
Find What the Restore Tool Requires
Open the restore tool's backup-selection screen or its documentation and check whether it expects an archive, a folder, or an uploaded backup set. The required file set is defined by that tool, not by the filename alone.
Look for instructions covering: A manifest describes the backup contents and structure. An index can tell the restore process how the archive was divided. If the tool asks for either file, include it with the archive parts.
- Required archive parts and their numbering
- A manifest, index, checksum, or metadata file
- Separate database and files backups
- Whether files must remain in one directory
- Whether the tool combines parts automatically
Check Names, Order, and Completeness
Keep every part's original filename. Renaming `part-02` as `part-2`, changing extensions, or removing timestamps can stop software from matching the files. Check that numbering begins and ends as expected.
If the sequence contains `.001`, `.002`, and `.004`, the missing `.003` may explain why the restore fails. Also compare file sizes: a very small final part may be normal, but an unexpectedly tiny middle part deserves investigation. If the backup provider supplies checksums, use them to compare downloaded files with the originals. A checksum mismatch indicates corruption or an incomplete download, even when the filename and file size appear correct.
Upload and Restore the Set Safely
Place all archive parts and required metadata files in the location the restore tool uses. Some tools require one upload at a time; others scan a server directory or cloud-storage folder.
Follow this order: A restore can overwrite existing files or database tables. Test the backup on a staging site when possible, or create a fresh backup before restoring over a live installation.
- Create a temporary restore location when the tool supports one.
- Upload the complete set without changing names.
- Let the tool scan or validate the files.
- Review the detected database and WordPress files.
- Restore only after the tool reports a complete, valid set.
Understand What a Complete Set Can Still Miss
A complete archive set does not guarantee a complete site recovery. The backup may exclude large media folders, server-level configuration, email accounts, external services, or files stored outside the WordPress installation. Check whether the backup includes both the database and the WordPress files.
The database contains posts, pages, settings, and many plugin records; the files contain themes, plugins, uploads, and core code. Restoring only one side can leave a site broken or incomplete. If the restore tool reports a valid archive but the site still fails, inspect PHP-version compatibility, file permissions, domain settings, rewrite rules, and environment-specific configuration. Those issues concern the restored hosting environment rather than the archive sequence itself.
You Might Also Like
- WordPress Maintenance: Google Calendar Embeds During an Account Outage: How to Check Public and Private Access Separately
- WordPress Maintenance: Google Drive Backup Exports: How to Test a Restore From a Downloaded Archive
- WordPress Maintenance: Recovery Admin Accounts: How to Test Access Without Disabling the Main Login
