Mend
Maintenance
The Backup Test Most WordPress Sites Still Skip
A sensible WordPress backup strategy is not “take backups every day.” It is “take backups you can actually restore, quickly, to a clean site.” The real safety check is a restore test, because a backup that cannot be recovered is just a file taking up space.
If your site matters for leads, sales, or support, the safest plan is simple: keep multiple backup copies, store them off-site, and test restores on a schedule before you are under pressure. If you are not sure your current backups would work, fix that now — not after an update, hack, or hosting issue.
What a good WordPress backup strategy should do
A backup strategy is about recovery, not just storage. The goal is to be able to rebuild your site after a bad plugin update, failed migration, hosting problem, accidental deletion, malware cleanup, or a broken database.
A practical strategy has four parts:
- Back up the right things. That means your database, your wp-content files, and anything custom outside the default WordPress folders if your setup uses them.
- Back up often enough. How often depends on how much changes. A brochure site and a busy store do not need the same schedule.
- Store copies somewhere separate. If the backup lives only on the same server as the live site, it can disappear in the same incident.
- Test the restore. This is the part most sites skip, and the part that matters most when things go wrong.
The symptoms of a weak backup setup
Most backup problems do not show up until you need the backup. Common warning signs include:
- You have never actually restored a backup.
- Your backups are stored only in the hosting account.
- You do not know whether the backup includes the database.
- You are not sure whether media uploads, custom code, or configuration files are included.
- Backups fail quietly, and nobody checks the logs.
- You only have one backup copy, or only one provider.
- Your backup schedule is based on convenience, not how often the site changes.
If any of those sound familiar, your site may be “backed up” in name only.
What to back up on a WordPress site
For most sites, a complete backup includes both the database and the files that make the site work.
1. The database
This contains posts, pages, users, settings, WooCommerce orders, form entries, menus, and much more. If you lose the database, you lose the live content and site configuration.
2. The wp-content directory
This is usually where themes, plugins, and uploads live. It is the most important file-level backup for most WordPress installs.
3. Custom files outside the standard folders
Some sites have custom code, special config files, or deployment-related files outside wp-content. If your engineer added anything nonstandard, make sure the backup process includes it.
4. A note on core WordPress files
You usually do not need to preserve core files in a backup if you can reinstall WordPress cleanly, but your restore process should still account for the exact version and configuration you were running.
How often should you back up?
There is no single schedule that fits every site. The right frequency depends on how much you can afford to lose between backups.
| Site type | Typical backup frequency | Why |
|---|---|---|
| Small brochure site | Daily or before changes | Content changes less often, but you still need a recent recovery point |
| Business site with regular edits | Daily, plus before updates | Content and settings can change often enough to matter |
| WooCommerce or membership site | Frequent backups, sometimes more than once per day | Orders, accounts, and transactions can change quickly |
| High-change or editorial site | Frequent scheduled backups and pre-change backups | Publishing activity creates constant recovery risk |
For sites with orders, form submissions, or frequent publishing, a single daily backup may not be enough. You may need a tighter recovery window, especially if you cannot afford to lose recent transactions.
Where to store backups
The safest answer is: somewhere outside the live hosting account, and ideally in more than one place. That way a server failure, account lockout, or storage problem does not take out both the site and the backup at once.
- Off-site storage: Separate from the live server.
- Multiple copies: At least more than one restore point.
- Access you can use in a crisis: Make sure you know who can download or restore the backups if the site is down.
If your host provides backups, that can be useful, but it should not be your only copy unless you have confirmed the retention, restore process, and limitations in writing.
How to test a WordPress restore safely
The restore test is where many backup plans fail. The best test is not “can I download the archive?” It is “can I rebuild a working copy of the site from that archive?”
- Back up the live site first. Yes, before testing the restore. Never start by overwriting a working site unless you are repairing a known failure.
- Use a staging site or separate test environment. Do not test on production if you can avoid it.
- Restore both database and files. A partial restore may look successful but still break menus, forms, images, or plugin settings.
- Check the front end and the admin area. Make sure pages load, media displays, login works, and the dashboard is usable.
- Test the site’s important workflows. Submit a contact form, add a product to cart, complete a checkout flow if possible, and verify any key membership or booking actions.
- Compare against the live site carefully. Confirm the restore includes the right theme, active plugins, recent content, and correct settings.
- Document what happened. Note how long the restore took, what was missing if anything, and whether the backup method needs adjusting.
What to look for during a restore test
A restore can appear “good enough” while still hiding serious problems. Watch for these issues:
- Missing recent posts, orders, users, or form submissions
- Broken images or missing uploads
- Theme customizations that vanished
- Plugin settings that reverted
- Permalink or redirect problems
- Database prefix mismatches or connection errors
- Fatal errors caused by plugin or PHP version differences
If the restore only works after extra manual fixing, that is useful information. It means your recovery process is incomplete and may fail under pressure.
Common backup mistakes to avoid
Most backup failures come from a few predictable mistakes:
- Only backing up files. Without the database, the site is incomplete.
- Only backing up the database. Without files, the site may not render correctly.
- Never testing restores. This is the biggest mistake of all.
- Keeping backups on the same server. One incident can remove both copies.
- Assuming the host’s backups are enough. They may not be frequent, portable, or easy to restore.
- Not protecting access to the backup destination. A backup that can be tampered with is not a safe backup.
A simple backup plan most WordPress sites can use
If you want a practical baseline, use this:
- Take automatic backups on a schedule that matches how often the site changes.
- Keep at least one off-site copy.
- Before major changes, take a fresh backup manually.
- Test one restore on a staging site or separate environment.
- Review the result and fix whatever failed before the next incident.
That is enough for many sites to move from “we hope we can recover” to “we know we can.”
How to prevent restore-day surprises
The best backup strategy is paired with good operational habits. Keep WordPress core, plugins, and themes updated safely, and make sure you know which changes happened before each backup. If your site has custom code, document it. If your host changes PHP versions or server settings, treat that like a change event and make a fresh backup first.
It also helps to keep a short recovery note: where the backups live, who can access them, what gets restored first, and what key pages or functions must be checked after recovery. In an emergency, simple beats clever.
When to call a professional
If your site is already broken, if you are not sure which backup is clean, or if you need to restore a live store without losing orders, it is worth getting help. A restore can get messy fast when the backup is incomplete, the database is inconsistent, or the site depends on custom code and third-party services.
Mend can help you verify the backup, test the restore, and rebuild the site safely on a backup-first workflow. Start with a free diagnosis at /start/diagnosis, or if the situation is urgent, use /start/emergency. If you want ongoing protection after you get this sorted, see /care.
If you need secure site access for a fix or restore check, use /connect rather than sharing passwords.
Related reading
If you want to make your recovery process safer end to end, these guides help:
- Safe WordPress Updates Without Breaking Your Site
- How to Migrate WordPress Without Downtime or Broken Links
- WordPress Site Broke After an Update? Here's What Happened and How to Fix It
A backup only protects you if the restore works. Test it on a schedule, keep copies off-site, and make sure your recovery steps are written down before you need them.
Frequently asked questions
What is the most important part of a WordPress backup strategy?
Testing the restore is the most important part. A backup is only useful if you can bring the site back from it quickly and correctly.
Should I back up files, the database, or both?
Both. The database holds content and settings, while the files hold themes, plugins, and uploads. Leaving out either one can make the restore incomplete.
Is my host’s backup enough?
Sometimes, but not always. Host backups can be useful, but you should confirm how often they run, how long they are kept, and how easy they are to restore.
How often should I test a restore?
At least periodically, and after any major change to your backup system, host, or site structure. If the site changes often, test more frequently.