In short: a website backup strategy is only real once you have restored from it. Keep three copies on two kinds of media with one off-site and one immutable, automate the schedule, and put a restore test in the calendar. Most sites that lose data had backups; they had never tried using them.
A website backup strategy fails quietly. The job reports success, the file lands somewhere, and nobody discovers the database was excluded or the archive was truncated until the day it matters. That is why the useful measure is not whether backups exist but when one was last restored.
How we approached this
This describes practice rather than products. RankBoast has not tested backup services and names none as a recommendation — see our review methodology.
The rule worth following
Three copies of your data, on two different kinds of storage, with one copy off-site. To that, add one modern requirement: at least one copy that cannot be deleted or encrypted by whoever compromises your site.
That last point is the change ransomware forced. A backup your web server can write to is a backup an attacker who owns your web server can destroy. Immutable or append-only storage, or credentials that only permit writing and not deleting, is what makes an off-site copy meaningful.
What a complete backup contains
| Component | Why it matters |
|---|---|
| Database | Posts, users, settings, orders. A file backup without it restores an empty site. |
| Uploads and media | Usually the largest part, and irreplaceable. |
| Themes and plugins | Including any customisations that exist nowhere else. |
| Configuration | Server config, redirects, cron jobs, environment variables. |
| Certificates and DNS records | Exported separately. Reconstructing DNS from memory during an outage is grim. |
A website backup strategy that captures files but not the database is the most common incomplete configuration, and it looks fine in the job log.
Website backup strategy: frequency follows tolerance for loss
Ask one question: how much work can you afford to redo? That answer sets the interval. A brochure site updated monthly is fine with weekly backups. A shop taking orders needs at least daily, arguably continuous.
Retention matters as much as frequency. Corruption and compromise are often discovered late, so a single rolling copy is dangerous — it may already have overwritten the last good version. Keep daily copies for a couple of weeks, weekly for a couple of months, and monthly for a year.
The restore test is the whole point
Put it in the calendar quarterly and follow it properly.
- Restore to a separate environment, never over the live site.
- Check the database restored, not just the files. Log in. Look at recent content.
- Time it. How long did the whole process take? That figure is your real recovery time, and it is usually longer than assumed.
- Write down the steps as you go. During an actual incident you will not be thinking clearly.
- Note what was missing and fix the backup configuration, then repeat.
A backup you have never restored is a hypothesis. This is the single highest-value hour in any website backup strategy.
Where copies should live
Not solely on the same server as the site — that fails when the server does. Not solely with the same provider, so a compromised account is not a total loss. Object storage is the usual off-site destination, and here the pricing structure matters: retrieving a large backup incurs egress charges on most providers, while Cloudflare publishes R2 storage at $0.015 per GB-month with no egress charges. For data you hope never to download but must be able to, that difference is worth checking before you need it.
Common mistakes
Never restoring. The defining mistake. Everything else is secondary.
Backing up files without the database. Common, and silent.
Keeping the only copy on the same server. A single failure takes both.
One rolling copy. Overwrites the last good version before you notice the problem.
Backups deletable with site credentials. Ransomware’s first target.
No documented procedure. Recovery under pressure without notes takes far longer.
By situation
- Small brochure site: weekly automated backup off-site, quarterly restore test. Adequate and cheap.
- Blog or content site: daily, two weeks retention, quarterly restore test.
- Shop or transactional site: at least daily plus database transaction logs, monthly restore test, documented procedure.
- Agency managing many sites: centralised backups with per-site restore testing on a rota.
- Anyone who has never restored: that is this week’s task, before anything else on this list.
Verdict
Automate three copies, keep one off-site and one immutable, retain enough history to survive late discovery, and test a restore quarterly. The measure of a website backup strategy is not how many copies exist but how quickly you can prove you can bring the site back — and the only way to know that number is to have done it.
What we would need to test to say more
Recommending backup services would require restore-time measurement at realistic data volumes, verification of immutability claims, and failure testing during simulated incidents. We have not done that and name no service as best.
Sources and methodology
Pricing and platform behavior come from providers’ published documentation, linked below and retrieved August 2026, and change frequently. RankBoast is independent, took no payment or sponsorship from any provider named, and holds no affiliate relationship with them. Research and drafting were AI-assisted. Errors are handled under our corrections policy.
Source links
Join the discussion
Add useful context, ask a focused question or share relevant experience. Comments are moderated to protect readers from spam and promotional links.
Leave a thoughtful comment