Backups are the least interesting topic in running a website, and the one that separates “we had a bad afternoon” from “we lost four years of work.”
Most site owners know they should have them. Fewer have them. Fewer still have ever tested whether the backups they have actually restore. That last group is the one that matters, because an untested backup isn’t a backup — it’s a hope.
Why people skip it
Worth naming honestly, because the reasons are reasonable and that’s exactly why they win.
Nothing has gone wrong yet. The strongest argument against doing anything, right up until it isn’t. Backups are insurance, and insurance always feels wasteful before the incident.
“My host handles it.” Many hosts do run backups. What varies enormously is how often, how far back they go, whether you can access them yourself, and how fast a restore happens. Quite a few hosts keep backups primarily for their own disaster recovery, not for restoring your accidental deletion from three weeks ago — and some charge for a restore.
It’s boring. No new feature, no visible improvement, nothing to show anyone. It competes for attention with things that feel productive and loses.
It sounds technical. It isn’t, particularly. But “database backup” sounds like something requiring a developer, so it gets deferred indefinitely.
Nobody owns it. On small teams, backups belong to whoever set the site up, who may have left. On solo businesses, they belong to the owner, who is busy.
What you’re actually protecting against
The mental model most people have is hacking. That’s on the list, but it’s not the most common cause of loss.
Human error. Someone deletes the wrong page, overwrites the wrong file, or updates something and breaks the layout. Comfortably the most frequent reason anyone reaches for a backup.
A bad update. A plugin, theme, or core update that conflicts with something and takes the site down. Extremely common on WordPress specifically, where dozens of independently-maintained components update on their own schedules.
Hosting failure. Servers die. Accounts get suspended over billing errors. Hosts go out of business.
Malware. Where restoring from a clean pre-infection backup is usually faster and safer than trying to surgically remove injected code. If you’re already worried about infection, start with is my website safe?.
Losing access. A developer disappears, an account gets locked, a domain lapses. Having your own copy of the site means you can rebuild elsewhere.
Notice how many of those have nothing to do with security. Backups aren’t a security measure — they’re an operational one that also happens to help with security.
What a real backup includes
A common and costly mistake: backing up only half the site.
Files — themes, plugins, uploaded images and documents, custom code.
The database — this is the part people miss. On WordPress and most CMSs, your actual content lives in the database, not in files. Pages, posts, settings, users, comments, product data, orders. A file backup without a database backup gives you an empty shell of a site.
If you take one thing from this article: check that your backup includes the database. A surprising number of “backups” don’t, and nobody discovers it until the restore.
The rules that actually matter
Store backups somewhere other than your server
The single most important rule, and the most commonly broken.
A backup stored on the same server as the site protects you from exactly one scenario — deleting something yourself. It doesn’t help if the server fails, the account is suspended, or the whole thing is compromised. In those cases your backups go down with the site.
Off-site means somewhere genuinely separate: cloud storage, a different provider, or downloaded locally. Cloud backup services exist precisely for this and are inexpensive.
Match frequency to how often the site changes
- Static brochure site, rarely updated: monthly is fine, plus a manual backup before any change
- Regular blog or content updates: weekly
- Active site with frequent changes: daily
- Ecommerce with live orders: daily minimum, ideally real-time or hourly
The question that sets the frequency: how much work can you afford to redo? If losing a week of changes would be painful, don’t back up weekly.
For ecommerce this is sharper — losing a day of orders isn’t lost work, it’s lost customer data you may have no other record of.
Keep more than one version
If you only keep the most recent backup and a problem went unnoticed for a week, your only backup contains the problem. Malware in particular often sits quietly for a while.
A reasonable pattern: several daily backups, a few weekly, a couple of monthly. Enough history to reach back past a problem you didn’t spot immediately.
Automate it
Manual backups get done reliably for about three weeks. Anything requiring you to remember will eventually not happen. Automate, then verify occasionally that the automation is still running — automated backups fail silently more often than people expect, usually because storage filled up or a credential expired.
Test a restore
The rule nobody follows, and the one that determines whether any of the above mattered.
Restore a backup to a staging site or a local environment and confirm the site actually comes back. Do it once when you set the system up, and again occasionally.
Untested backups fail in predictable ways: the database wasn’t included, the file is corrupt, the restore process needs credentials nobody has, or it turns out the automation stopped running four months ago. Every one of these is discovered at the worst possible moment unless you check deliberately.
How to actually do it
On WordPress
The most common setup, and the best-served by tooling.
Plugin-based backups are the standard route. Several established plugins handle scheduled backups of both files and database, with direct upload to cloud storage. Look for: automatic scheduling, off-site destinations (Google Drive, Dropbox, S3, or similar), both files and database included, and a one-click restore.
Free tiers usually cover a basic site adequately. Paid tiers add more frequent scheduling, better retention, and — importantly — easier restores. If WordPress is your stack, see WordPress development for the broader maintainability picture.
Watch for: free plugins that back up to your own server by default. That’s the rule above being broken by the default setting. Configure an off-site destination explicitly.
Host-provided backups
Most hosts offer something. Before relying on it, find out:
- How often do they run?
- How far back does retention go?
- Can you trigger a restore yourself, or must you file a support ticket?
- How long does a restore take?
- Does it cost anything?
- Does it include the database?
Host backups are worth having. Treating them as your only backup means depending on a company whose interests in this scenario aren’t identical to yours.
Managed backup services
Dedicated services handle scheduling, off-site storage, and restores independently of your host. Costs more than a plugin, does more, and — the real benefit — keeps your backups entirely separate from the infrastructure they’re protecting.
Worth it if the site matters commercially or if nobody on your side will reliably check that plugin backups are still running. That’s the core of our security & backups work.
Manual backups
Always take one before anything risky: a major update, a redesign, a migration, or handing access to a new developer.
Downloading the files and exporting the database takes minutes and has saved a great many people from a bad afternoon.
Non-WordPress platforms
Website builders (Wix, Squarespace) handle infrastructure backups themselves, with varying ability for you to roll back your own changes. Check what version history you actually get — it’s usually more limited than people assume, and you generally can’t export a full site copy the way you can from a self-hosted setup. Related: when a website builder isn’t enough.
Custom sites need this deliberately set up, usually server-level plus database dumps on a schedule. If a developer built your site, ask directly what backup arrangement exists. “I assumed it was handled” is a common and expensive assumption.
A workable minimum
If you do nothing else:
- Automated backups running on a schedule matched to how often your site changes
- Stored off-site, not on the same server
- Including files and database, verified
- Multiple versions retained, not just the latest
- One tested restore, so you know it works
- A manual backup before anything risky
That’s genuinely it. An afternoon to set up, then largely invisible — which is both why it works and why it gets skipped.
If you’re reading this because something already broke
Order of operations:
- Don’t panic-fix. Rushed changes can destroy the state you’d need to diagnose or recover from.
- Check every backup source — plugin, host, cloud storage, old local downloads, and any staging copy.
- Ask your host. Even hosts without customer-facing backups sometimes have internal snapshots.
- Check for partial recovery — Google’s cache, the Wayback Machine, or your own drafts can sometimes recover content even when the site is gone.
- If it’s malware, restore from before the infection, not from the most recent backup.
- Then set up proper backups, before doing anything else.
The short version
- The database is the part people forget — a file-only backup restores an empty site
- Store backups off-site; a backup on the same server doesn’t survive the scenarios that matter most
- Set frequency by how much work you could afford to redo; daily minimum for ecommerce
- Keep multiple versions — problems often go unnoticed long enough to be inside your only backup
- Automate it, then check occasionally that the automation is still running
- Test a restore at least once, or you don’t know whether you have backups at all
- Take a manual backup before any update, migration, or handing over access
Want backups handled properly — off-site, scheduled, and restorable — rather than hoped for? That’s what our Security & Backups service covers, alongside ongoing maintenance & support.
Plenox Studio
Engineering notes from Plenox Studio on platforms, performance, and choosing builds that match the business.
