Backups and Disaster Recovery: What Good Hosting Should Provide

"Daily backups included" appears on almost every hosting plan sold today. It is also one of the least informative claims in the industry, because it answers only one of the five questions that matter: how often, how far back, where, who can restore, and how long it takes. Two plans can both advertise daily backups while one rolls a single file back to last Tuesday in ninety seconds, and the other needs a support ticket, a 48-hour queue, and the loss of everything since midnight.

Start with two numbers: RPO and RTO

RPO — Recovery Point Objective — is how much data you can afford to lose, measured in time. If backups run at 02:00 and the server dies at 23:00, your RPO is 21 hours of orders and content.

RTO — Recovery Time Objective — is how long you can afford to be down before the impact becomes unacceptable. Not how long a restore takes in the best case, but the whole sequence: noticing, opening a ticket, waiting, restoring, verifying.

Write down both numbers first. They turn a vague preference for "good backups" into a purchasing requirement.

Most shared hosting sits in the first two rows. If your needs are in the bottom two, the honest answer is a different tier rather than a better backup add-on — see shared hosting vs VPS vs cloud vs managed WordPress.

Frequency is not retention

Two separate settings, and providers advertise the flattering one. Frequency is how often a backup runs; it caps your data loss. Retention is how far back you can go; it caps the kind of disaster you can survive.

Daily backups with 24-hour retention protect you from a bad deploy. They do nothing about anything you failed to notice for two days — a defaced page, a corrupted table, a plugin quietly rewriting your canonical tags, or ransomware that sat dormant before triggering.

A reasonable floor for a commercial site: daily backups, 14–30 days of retention, plus one monthly copy kept longer. Ask specifically. "Daily backups" plus "3 restore points" is a very different product from "daily backups, 30-day retention".

What actually has to be backed up

"The files and the database" is a partial list.

• Files — the document root, plus cron scripts, .env files and media on separate mounts.
• Database — as its own artefact, restorable independently. Most incidents are database-only or files-only; restoring both when you needed one is how a recovery causes a second outage.
• Email — very often not covered by the hosting backup, even on the same account. IMAP mailboxes on staff laptops are not a backup either; a deletion syncs.
• DNS zone — every record, including SPF, DKIM, DMARC, CAA and verification TXT records. Small file, saves hours.
• Configuration and secrets — PHP limits, redirects, cron entries, API keys, gateway credentials, encryption keys.

A useful test: could you rebuild the site on a different provider using only what you hold today? If the answer depends on your current host being reachable, you have a copy, not a backup.

Restore access: self-service or support ticket?

This is the most under-weighted line in hosting comparisons, and it dominates your RTO. Ask three questions:

1. Can I trigger a restore myself, from the control panel, without a ticket?
2. Can I restore a single file or a single database, or is it all-or-nothing?
3. Can I download the backup, or only restore it in place?

The third is the one providers dislike. A backup you cannot download is one you cannot verify, cannot migrate with, and cannot use if your account is suspended over a billing dispute. Watch, too, for restores billed separately or free "once per month" — that pricing is built around the fact that you will only need it on the worst day of your year.

Off-site has to mean "off this provider"

The long-standing baseline is the 3-2-1 rule: three copies of your data, on two different types of storage, with one copy off-site. The part that gets skipped is the last one. A backup stored on the same server as the live site protects you from your own mistakes and nothing else. A backup in the same provider's backup cluster is better, and still shares a failure domain — the provider.

Not a theoretical concern. In August 2023 the Danish hosting company CloudNordic was hit by ransomware during a data centre migration; attackers reached the internal network and encrypted server disks together with the primary and secondary backup systems. The company declined to pay, could not recover, and said the majority of its customers lost all data held with it (SecurityWeek).

The lesson is not that providers are careless, but that "the provider has backups" and "you have a backup" are two different sentences. For anything commercial, keep one copy somewhere your host has no credentials for. Weekly is enough for most small sites.

Snapshots are not backups

VPS and cloud snapshots are excellent operational tools — take one before a PHP upgrade, roll back in a minute if it goes badly. They are not a backup strategy: they usually live on the same infrastructure as the running instance, they are often deleted with the instance (including on account suspension), and they restore the whole machine rather than one file or table. Use snapshots for change management, backups for disaster recovery.

Test the restore

An untested backup is a hypothesis. The failure modes are mundane: the dump was truncated, the job stopped succeeding four months ago, nobody knows the decryption passphrase, or the restore works but the site will not start because a config file outside the document root was never included. Once a quarter:

1. Restore the most recent backup to staging or a local container.
2. Load the home page, one deep page and one that reads from the database.
3. Log in to the admin, and check the newest content is present — that tells you the backup is as fresh as advertised.
4. Note how long it took. That number is your real RTO, not the one on the marketing page.

Twenty minutes, four times a year. Cheapest insurance in this article.

Provider questionnaire

Get these answers in writing from support, not from the features page.

• How often do backups run, and how many restore points are kept, for how many days?
• Are files and database backed up separately and restorable independently?
• Are email mailboxes included?
• Where are backups stored — same server, same data centre, or elsewhere?
• Can I restore myself from the control panel, without a ticket?
• Can I restore a single file or a single table?
• Can I download a full backup on demand?
• Are restores included in the price, or billed per incident?
• Are backups encrypted at rest, and who holds the key?
• What is the documented restore time for a site of my size?
• What happens to backups if my account is suspended or I cancel?
• Is there a retention lock or immutability option against ransomware?

A provider that answers all twelve without hedging is selling a real backup product. If several answers turn out to be "contact support", price that into your RTO.

The web hosting comparison and WordPress hosting comparison let you filter plans on backup features; the VPS comparison is the place to look if snapshots plus your own routine is the right shape. If mailboxes are the critical asset, check email hosting separately — mail backup policies rarely match web hosting policies.

FAQ

Isn't my host responsible for backups?

Your host is responsible for the infrastructure. Almost every hosting contract puts responsibility for your data on you and describes provider backups as a convenience rather than a guarantee. Read the terms — look for a disclaimer that backups come with no warranty of recoverability.

Do I need my own backups if the host already takes them?

For a hobby site, no. For anything that produces revenue, yes — one independent copy somewhere your host has no access to. That is the copy that covers provider-level failure, account suspension and ransomware reaching the backup system.

Are WordPress backup plugins good enough?

A reasonable second copy, especially ones pushing to external storage you control. Weaker as a primary: they run inside the thing that may be compromised, and a plugin cannot back itself up if the site will not load.

What to do next

Pick your two numbers — how much data you can lose, how long you can be down — and check them against what your plan provides rather than what it advertises. Then do the thing nobody does: restore last night's backup somewhere harmless and time it.

If the result is uncomfortable, backups are a good reason to move. The small business hosting checklist covers what else to weigh, and uptime and SLA explained is worth reading alongside it — an SLA credit compensates you for downtime, but nothing in it obliges a provider to still have your data.