Almost everyone has backups. Almost nobody has restores.
The difference matters, and you find out which one you have at the worst possible moment — mid-incident, with a site down, discovering that the nightly backup has been silently failing since March, or that it captured the files but not the database, or that it's sitting on the same server that just died.
A backup you've never restored is a hypothesis. Here's how to have the other thing.
The short version
Four rules:
- Both files and database, every time — one without the other is useless
- Off-server storage — same server means no backup when the server fails
- A rolling series, not one copy — compromises go undetected for weeks
- Test a restore once, so you know it works and how long it takes
Frequency follows change rate: daily for a store or active blog, weekly for a brochure site, and immediately before any update or migration.
What a complete backup contains
The database holds your posts, pages, comments, users, settings, and every plugin's configuration. Without it you have a working WordPress install with no content.
The files — specifically /wp-content/ — hold your themes, plugins, and uploads. Without them you have your content with no images and no design.
wp-config.php holds your database credentials and security keys.
You need all three. A backup of one without the others gets you a partial recovery, which during an incident is a different flavour of the same problem.
What you don't need to back up: WordPress core files. They're identical for everyone and freely downloadable, so most backup tools skip them sensibly.
Where backups must not live
The single most common failure: storing backups on the same server as the site.
If the server fails, if the account is suspended, if the host has an incident, if the site is compromised at file level — your backups are in the same fire.
Where they should go:
Cloud storage — Google Drive, Dropbox, Amazon S3, Backblaze B2. Most backup plugins push to these directly.
Your host's off-server backup service, if they genuinely store it off the machine. Worth asking rather than assuming.
A local copy of at least one recent full backup, downloaded to your own machine. Cheap insurance against your cloud account having a bad day too.
The standard framing is three copies, on two different media, with one off-site. For a small site that's realistically: the live site, an automated cloud backup, and an occasional local download.
How many, and how far back
Keeping only the most recent backup is the second most common mistake, and it's specifically dangerous for security incidents.
Because compromises go undetected. If malware was injected three weeks ago and you keep three days of backups, every backup you have is infected. You'll restore, feel relieved, and still be compromised.
A reasonable retention pattern:
- Daily backups kept for two weeks
- Weekly backups kept for two months
- Monthly backups kept for six months to a year
That gives you something to reach for when you discover a problem that started before you noticed it.
Also keep a manual backup before any major change — a migration, a redesign, a WooCommerce update, a PHP version change. Label it clearly so you can find it.
How often
Match frequency to how much you'd hate losing.
A store taking orders: daily at minimum, and real-time or hourly database backups if order volume justifies it. Losing a day of orders is a genuine business problem.
An active blog: daily.
A brochure site that changes monthly: weekly is fine.
Everyone, always: immediately before updates, migrations, and any significant change.
One nuance: files and database don't need the same schedule. Your uploads folder rarely changes; your database changes constantly. Several plugins let you back these up on different cycles, which reduces storage cost meaningfully.
Is your host's backup enough?
Often it's a good foundation and rarely sufficient on its own.
Questions worth asking your host:
Is it genuinely off-server, or a snapshot on the same infrastructure?
How far back does retention go? Some hosts keep only a few days, which is the exact gap that fails you during a slow-burning compromise.
Can you restore individual files or tables, or is it all-or-nothing? Selective restore is enormously useful when you need one post back, not a whole rollback.
Can you download it? If your backups only exist inside your host's system, you can't leave — and you can't recover if your account is suspended.
How long does a restore take? Worth knowing before it's urgent.
The practical position: use your host's backup as a convenient first option, and keep your own independent copy going to storage you control. Two systems that fail differently beat one that fails completely.
The restore drill
The step that separates a backup from a hypothesis. Do it once, then annually.
1. Spin up a staging site — most hosts offer one free, or use a local environment.
2. Restore your most recent backup to it. Not the live site. Staging.
3. Check properly. Does the site load? Are recent posts there? Do images display? Do plugin settings survive? Does a form submit?
4. Time it. Knowing a restore takes twenty minutes versus four hours changes how you handle an incident.
5. Note what broke, if anything. Some plugins store data in ways that don't survive a naive restore — better to discover that now.
Most people who run this find something: a backup missing the uploads folder, a database export that was truncated, a scheduled job that stopped running months ago. Finding it on a Tuesday afternoon is infinitely better than finding it during an outage.
Choosing a plugin
What to look for: automated scheduling, off-server destinations, incremental backups (backing up only what changed, which matters on large sites), a restore function that works from within the plugin, and email notification on failure.
That last one is underrated. A backup plugin failing silently for four months is a common and entirely preventable disaster. Turn on failure notifications and act on them.
The main options — UpdraftPlus, BlogVault, Jetpack VaultPress, Duplicator, Solid Backups — all handle the fundamentals. Pricing changes regularly, so check current rates directly rather than trusting figures in an article.
What matters more than which plugin: that it's scheduled, that it stores off-server, that it notifies you on failure, and that you've restored from it once.
Frequently asked questions
How often should I back up?
Match frequency to how much data you'd hate to lose. A store taking orders needs daily backups at minimum, and possibly hourly database backups if volume justifies it. An active blog wants daily. A brochure site changing monthly is fine with weekly. Everyone should take a manual backup immediately before updates, migrations, and significant changes — that's the one that saves you most often.
Is my host's backup enough?
It's a good foundation, rarely sufficient alone. Ask whether it's genuinely stored off-server or is a snapshot on the same infrastructure, how far back retention goes, whether you can restore individual files rather than everything, and whether you can download it. If backups only exist inside your host's system, you can't recover from an account suspension and you can't leave. Keep an independent copy going to storage you control.
Where should backups be stored?
Anywhere other than the server running your site. If that server fails, is suspended, or is compromised, on-server backups are in the same fire. Push them to cloud storage you control — Google Drive, Dropbox, S3, Backblaze — and keep at least one recent full backup downloaded locally. The conventional guidance is three copies on two types of media with one off-site; for a small site that's the live site, automated cloud backups, and occasional local downloads.
What to do next
Check whether your backups are actually running, and where they're going.
For a surprising number of sites the honest answers are "I'm not sure" and "the same server" — and both are worth twenty minutes today rather than discovering them during an incident.
Then put a note in your calendar for one restore drill this quarter. Once you've done it, you'll know whether you have backups or hypotheses.
Free: The WordPress maintenance checklist.
Related guides
- WordPress security without a sysadmin — where backups fit
- My WordPress site is hacked — when retention depth matters most
- Blank page after an update — the everyday restore case
- When WordPress breaks — backing up before troubleshooting
Join the Newsletter
Get practical marketing tactics delivered straight to your inbox.
Written by
Muhammad Basim
Related Articles
Transactional Email Services Compared for WordPress
Every one of these services will deliver your password resets. That's not the differentiator. What differs is setup difficulty, what the free tier covers, how good the logs are when something goes wrong, and — the one people never consider until it bites them — whether the service also handles marketing mail, and whether you […]
Contact Form Notifications Not Arriving: Every Cause
Here's the version of this problem that costs the most: it's been happening for months and you don't know. The form says "thank you." The visitor believes they've reached you. You believe nobody's been in touch. There's no error, no bounce, no alert — just an absence, and absences are invisible. Most of the time […]
WooCommerce Order Emails Going to Spam: The Fix
"I never got a confirmation. Did my order go through?" Every store owner gets this message. And when it arrives often enough, you stop treating it as customer confusion and start realising your receipts genuinely aren't landing. This costs more than most email problems, because a missing order confirmation doesn't just annoy someone — it […]