Almost every host takes backups. Considerably fewer can restore your specific site to a specific point in time, quickly, with the database, uploads, and email intact. The difference only becomes visible on the day you need it, which is the worst possible moment to find out, so the question to ask is not whether backups exist but when one was last successfully restored.
The gap between a backup and a recovery
A backup is a copy of something. A recovery is a working site, at a known point in time, back in front of customers. Between the two sit a series of assumptions that are rarely tested: that the copy is complete, that it is recent enough, that it includes the database as well as the files, that it can be restored without also restoring the problem, and that somebody knows how.
Every one of those assumptions holds until the day it does not. The pattern is depressingly consistent: a site is compromised or a change goes wrong, the business asks for a restore, and the answer is that backups go back seven days and the problem started three weeks ago, or that the files are there but the database is not, or that the restore will overwrite everything including the work done since.
The three questions that actually matter
How far back can you go?
A single overnight copy means you can only return to yesterday. That is fine for a server failure and useless for a compromise that began a fortnight ago, which is the more common scenario. Meaningful protection means multiple restore points across weeks, not one rolling copy.
How much would you lose?
The distance between backups is the work you accept losing. Daily backups mean up to a day of form submissions, orders, and content changes gone. For most service businesses that is tolerable. For anything taking bookings or payments it is not, and the frequency should be set deliberately rather than inherited from a default.
How long does a restore take?
The number nobody asks for. A restore that technically works but takes two days is functionally a two-day outage. Ask for the realistic figure, including how long before someone starts, since queue time is usually longer than the restore itself.
What backups routinely miss
- The database. Files and database are often backed up on different schedules or by different systems. Restoring one without the other produces a site that loads and has lost its content, its settings, or both.
- Email. Frequently outside the hosting backup entirely. Restoring a site to last Tuesday does not restore a mailbox somebody emptied, and for many businesses the mail is the more valuable asset.
- Configuration. DNS records, redirects, certificates, cron jobs, and mail routing. A file-level restore can bring a site back and leave it unreachable or unable to send.
- Recent uploads. Anything added between the last backup and the failure, which is exactly the material nobody has another copy of.
Why the copy needs to sit somewhere else
A backup stored on the same server as the site protects against a narrow set of problems: a bad edit, a failed update, a deleted file. It protects against none of the serious ones.
Server failure, data centre incident, account suspension, and compromise can take the site and the backups together. Ransomware in particular targets connected backups deliberately, because a recoverable victim does not pay.
Proper redundancy means copies in more than one place, with at least one of them independent of the server itself. That is the entire argument, and it is why layered backup arrangements exist rather than single nightly copies. It also costs very little relative to what it protects, which is the part businesses are usually surprised by.
The test almost nobody runs
An untested backup is a belief. The only way to convert it into a safeguard is to restore one and see what happens.
A restore test should answer four things: whether the restored site actually works, whether the database came with it, whether email and configuration survived, and how long the whole thing took from request to working site. Anything that fails one of those is better discovered on a quiet Tuesday than during a real incident.
This is a reasonable thing to ask a provider to demonstrate, and the answer tells you a great deal. A host that can describe when they last restored a client site, and how long it took, is operating differently from one that can only confirm backups are enabled.
The scenarios worth planning for
| Scenario | What it demands of your backups |
|---|---|
| Bad edit or failed update | Yesterday's copy is sufficient. Almost any arrangement handles this. |
| Compromise discovered late | Restore points going back weeks, since the clean version may be well behind you |
| Server or data centre failure | A copy held independently of that server, and a documented route to standing the site up elsewhere |
| Departing developer or dispute | A copy you hold yourself, plus ownership of the domain and hosting in your name |
| Accidental deletion of email | Mail backed up separately, because site backups frequently exclude it |
The last row of that table is worth noting alongside how email hosting is arranged, since the two are commonly assumed to be covered by the same safety net and often are not.
What to ask, and what to do
Ask your provider four questions: how many restore points exist and how far back, where the copies are held, how long a full restore takes in practice, and when they last performed one. Vague answers to the last two are the meaningful ones.
Then keep one independent copy of your own, refreshed occasionally, of the site files and the database. It is not a substitute for a proper arrangement and it is a useful insurance policy against the one scenario nothing else covers, which is losing access to the hosting account itself.
Frequently asked questions
How often should a website be backed up?
Daily is the sensible baseline for most service businesses, since the interval defines how much work you accept losing. Sites taking bookings or payments should back up more frequently, and the frequency should be a deliberate decision rather than an inherited default.
Are my host's backups enough?
It depends on how far back they reach, whether they include the database and email, where the copies are stored, and how quickly a restore actually happens. A single nightly copy on the same server covers only the mildest failures.
What is the difference between a backup and a restore?
A backup is a copy. A restore is a working site back in front of customers at a known point in time. The gap between them is where the assumptions live, and they are only tested on the day it matters.
Should backups be stored somewhere other than the server?
Yes. Copies on the same server are lost alongside it in a hardware failure, data centre incident, account suspension, or compromise. At least one copy should be independent of the server it protects.
Does a website backup include email?
Frequently not. Site and mail are often backed up by different systems on different schedules, and restoring a site does not necessarily restore a mailbox. Worth confirming rather than assuming, since mail is often the more valuable of the two.
How do I know my backups actually work?
Restore one and see. A test should confirm the site works, the database came with it, email and configuration survived, and how long the whole process took. Until that has been done, the backups are a belief rather than a safeguard.
West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.
When was your last backup actually restored?
We run layered backups with multiple restore points held independently of the server, and we can tell you exactly how long a restore takes because we have done it.
Start a Conversation