A download called backup is a good start. Knowing what is inside it—and how it becomes a working website again—is the useful part.
Save the files and the database
A WordPress site normally needs both. The files contain uploads, themes, plugins and configuration. The database contains posts, pages, settings and other site data. A WordPress XML content export is useful, but it is not a full replacement for a file-and-database backup.
Label the set
- Domain and date of the backup.
- The site’s document root or installation directory.
- The database name associated with that site.
- File archive name and database export name.
- Where the restore instructions are saved.
Keep a copy away from the hosting account. Configuration and database exports may contain sensitive information, so store the backup privately.
Check the archive
Confirm that the archive opens, contains the expected WordPress folders and includes the uploads you care about. Check that the database export is readable or decompresses successfully. File hashes help detect a changed or damaged copy, but they do not prove the site will restore.
Prove the route back
Restore to a separate test location when possible. Restore the files, import the matching database and connect the restored configuration to it. Account for a different test URL, then check the homepage, key pages, media and admin access. Avoid letting a test copy send live notifications or overwrite the production site.
Record the result
Write down what was actually tested. “Archive checked” and “full restore tested” are different claims. After significant site changes, make a fresh backup so the recovery point includes the new work.