Who is responsible for website backups, and where they live

“Backups included” is a phrase on almost every hosting plan’s marketing page. It answers a narrower question than most people assume it does. It says a copy is being made. It does not say who is actually watching that it keeps being made, whether it has ever been tested, or where the copy is physically stored relative to the site it is meant to protect.

The three places an offsite backup can actually come from

The host, as an included feature of the hosting plan itself. This is generally the most convenient option, and the one most people rely on by default without ever confirming what it actually covers. A plugin or app, installed specifically for backups, run independently of whatever the host is doing. It’s worth having precisely because it does not depend on the host’s own process succeeding. A separate service, entirely independent of both, storing copies somewhere unrelated to either the hosting account or the site’s own software. Relying on only one of these means a single point of failure is protecting against every other single point of failure on the site.

Why “where it lives” matters as much as whether it exists

A backup stored on the same server as the site it protects defends against a software mistake or a bad update. It does not defend against the server itself failing, being compromised, or the hosting account being suspended or cancelled. In any of those scenarios, the backup goes down with the very thing it was meant to save. A genuinely resilient backup lives somewhere physically and administratively separate from the site’s primary hosting. That is the entire logic behind the widely used rule of keeping at least one copy off the original system, not merely a second copy sitting beside it.

Who is actually watching that it happened

A backup schedule that runs silently in the background, with nobody checking that each run actually succeeded, can fail for weeks or months before anyone notices. It is commonly discovered only at the exact moment a restore is needed and does not work. This is not a hypothetical. A backup process failing silently while its dashboard continues to display a green tick is one of the more common, and most damaging, gaps in an otherwise reasonable-looking maintenance setup.

Whether it has ever actually been restored

A copy existing is not the same claim as a copy being usable. A backup that has never been test-restored is an assumption, not a safeguard. The only way to know whether a specific backup process genuinely works is to have actually restored from it at least once, deliberately, rather than only in the moment it is desperately needed.

What to actually confirm about your website backups and hosting backup strategy

Who is responsible for backups on the current hosting plan, specifically — the host, a plugin, or nobody. How frequently they run, and whether that frequency matches how often the site’s content actually changes. Where the copies are stored, and whether that location is genuinely independent of the primary hosting account. And whether a restore has ever actually been tested, by anyone, at any point.

How many incremental, daily historical backup versions are worth keeping

A single, most-recent backup protects against total loss, but not against a mistake that goes unnoticed for a while. Keeping several recent versions, not just the latest, means a problem discovered a week after it occurred can still be recovered from a point before it happened, rather than only from after.

A note for anyone about to migrate hosts

Take an independently verified backup immediately before any hosting migration, regardless of what routine backups already exist. It gives a fresh, known-good fallback point specific to that exact moment — cheap insurance against a migration itself introducing the very problem a backup exists to protect against.

Retention periods for disaster recovery and business continuity, briefly

Beyond simply existing, backups need a defined retention period — how many days or weeks of history are kept before older copies are discarded. This matters because a problem discovered later than the retention window covers may have no clean version left to restore from at all. Confirm this window matches how quickly problems are realistically likely to be noticed. Don’t just assume it is generous by default.

Who to ask, in one sentence

“Where do our backups live, how often do they run, and when did someone last actually restore one.” That is a single question worth putting to whoever manages the site today, regardless of how confident the answer sounds without having asked.

Encryption of stored backup files and databases, briefly

A backup containing customer data is itself a copy of sensitive information. Where it is stored should be encrypted and access-controlled to the same standard as the live site. An unencrypted backup sitting in an easily accessible location is a second, often overlooked, place the same data could be exposed from.

The one automated backup habit that matters more than any specific tool

Whichever backup method is used, the discipline of periodically confirming it still works is worth more than the specific tool or provider chosen. A mediocre backup system tested regularly beats an excellent one nobody has verified in years.

Where to go from here

The fuller detail of what makes a backup genuinely reliable, rather than merely present, is set out in website backups that actually work. And confirming this is being actively managed, rather than assumed, is part of what a competent ongoing arrangement should cover — see what website maintenance costs.