What a real backup plan answers
A backup plan is not “a plugin runs nightly.” It answers the recovery questions before the emergency, not during it.
- How often backups run — and is that frequent enough for how fast your data changes?
- Where backups are stored (off-site, ideally encrypted).
- How long backups are retained, so you can reach a known-clean point.
- Who can actually perform a restore, and how fast.
- How you handle orders or signups that happened after the backup you are restoring.
Why restore testing is the whole point
This is where most backup plans secretly fail. A backup can run successfully every night and still be unrestorable — corrupt files, a database that will not import, wrong permissions, or a process nobody has ever actually run. Restore testing proves the files, database, permissions, and workflow genuinely work. It is also the difference between a five-minute recovery and a panicked afternoon discovering your safety net has a hole. Backups matter most during a hacked-site recovery — exactly when you cannot afford to find out they do not work.
Backup frequency by site type
Match frequency to how fast you would lose data you cannot recreate. A brochure site that changes monthly is fine on daily backups. A busy WooCommerce store taking orders all day, or a membership site where users sign up and renew constantly, needs more frequent database protection — a once-a-day backup can still lose hours of real orders and customer activity.
Backup frequency and retention by site type
How much you can afford to lose dictates how often you back up.
| Site type | Suggested frequency | Why |
|---|---|---|
| Brochure / content site | Daily | Content changes slowly; a day of loss is tolerable. |
| Lead-gen / forms site | Daily, plus form-delivery backup | Leads are captured by email too; site loss is low. |
| WooCommerce store | Frequent / real-time DB | Orders change all day; a day of loss = lost orders. |
| Membership / booking | Frequent | Signups, renewals, and bookings change constantly. |
Building your restore plan
Three decisions turn “we have backups” into “we can recover.”
Set frequency by how fast your data changes
A store needs far more frequent backups than a brochure site. Ask how many hours of orders or signups you could afford to lose, and back up at least that often.
Store off-site and test the restore
Keep backups off the production server, and actually run a restore on staging on a schedule. An untested off-site backup is still a gamble.
Decide the post-backup data plan
Before an incident, decide how you will reconcile orders or signups that arrived after the backup you restore — exporting recent records first is often the answer.
Backup mistakes that cost sites
- Trusting backups that have never been restore-tested.
- Storing backups on the same server, where a crash or hack takes both.
- Backing up daily for a store where orders change hourly.
- No retention depth, so the only backups are already infected after a hack.
- No plan for the orders or signups that arrived after the restore point.
How we treat backups
In our experience, almost everyone has “backups” and almost nobody has tested a restore — until the day they need one and discover it does not work. So we treat the restore, not the backup, as the deliverable: off-site and encrypted, frequent enough for how the site’s data changes, retained deep enough to reach a clean point, and proven by an actual test restore on staging. A backup you have never restored is a hope; a tested restore is a plan, and it is the backbone of any maintenance routine.
- Test restores on a schedule, not just when disaster strikes.
- Keep backups off-site and encrypted.
- Match frequency to how fast the site’s data changes.
- Retain enough history to reach a pre-incident clean point.
Frequently asked questions.
Are daily backups enough for WordPress?
For simple content or brochure sites, usually yes. For WooCommerce stores, memberships, and booking sites, daily backups can lose hours of orders, signups, and customer activity — so those sites need more frequent, often real-time database backups.
Should backups be stored on the same server as the site?
No. Off-site backups are far safer, because a server failure, account compromise, or malware infection can wipe out or infect local backups along with the live site. Keep at least one copy off the production server.
Why isn’t having a backup enough?
Because backups fail silently — corrupt files, un-importable databases, wrong permissions, or a restore process nobody has actually run. Only a tested restore proves you can recover. Treat the restore as the real deliverable, not the backup file.
How do I handle orders that came in after my backup?
Decide this before an incident: typically you export the most recent orders, signups, or form entries before restoring, then reconcile them afterward. A restore plan that ignores post-backup activity can lose exactly the customers you most want to keep.
Research sources.
This guide was checked against current platform and search documentation before publication.