Backups: the question isn't whether you have one, it's whether anyone has restored it

Ask a developer whether your website is backed up and the answer is nearly always yes. It is the wrong question. A backup you have never restored is a hope, not a backup, and the gaps usually show up on the worst day.

This article is what a backup is, the three ways a site loses data, and the questions that tell you whether yours would actually come back. Every claim about a standard or a product links to its source at the bottom.

• Ask "when did someone last restore it?" not "do you have backups?"
• Keep at least one copy somewhere else. A copy stored with the thing it protects goes down with it.
• Your customer data is the part that cannot be rebuilt. Pages can be redone. Orders, bookings and enquiries cannot.
• A backup is not monitoring, and monitoring is not a backup. One tells you something broke. The other lets you undo it.
• Know how far back you can go. Some mistakes are noticed a week later.

A site is made of two different things. The first is the code and design, which can be rebuilt from a copy. The second is the data that visitors and you create over time: form submissions, orders, bookings, the posts you edit in the dashboard. That data lives in a database, and once it is gone nobody can recreate it, because it only ever existed there.

Backups protect against three different problems, and a setup that handles one may not handle the others:

1. A mistake. Someone deletes the wrong page, overwrites a file or runs a bad update. This is the most common one.
2. A failure. The disk, the host or the database breaks.
3. An attack or a lockout. Ransomware, a hacked login, or an account that gets suspended.

CISA, the US government's cybersecurity agency, gives small businesses a simple rule: three copies of important files, on two different kinds of storage, with one copy off-site, away from your business location. It also says to protect backups with physical security, encryption and offline copies.

The one-copy-elsewhere part is the one that gets skipped. If the backup lives on the same account as the site, then losing the account loses both. A well-known hosting guide says it directly: wiping a volume deletes all of its backups, so backups protect against data mistakes, not against deleting the volume itself. That is a fair description of a typical hosting backup. It covers the first problem and part of the second. It does not cover the third.

The PostgreSQL manual, which is the documentation for one of the most common databases behind websites, describes three fundamentally different approaches: an SQL dump, a file-system-level backup, and continuous archiving. They answer different questions.

A dump is a file containing the database's contents. The manual says it makes consistent exports even if the database is being used concurrently, so a customer submitting a form during the export does not corrupt it. Dumps are easy to store anywhere, which makes them good as the off-site copy. The same page also says that, except in simple cases, a dump is generally not the right choice for taking regular backups of production databases.

Continuous archiving records every change as it happens, so in the manual's words it is possible to restore the database to its state at any time since your base backup was taken. That is what lets you say "put it back to ten minutes before the mistake" instead of "put it back to last night." The manual also warns that it does not restore changes made to configuration files, so the settings need their own copy.

Volume backups are snapshots of the disk the database lives on. A host such as Railway, whose guide I read for this article, offers all three layers and recommends using all three for production. I am citing it as an example of what a host can offer, not as a description of anyone's site.

The point for you: "we have backups" can mean any of these, and they behave differently when you need them. Ask which kind.

Backups are kept for a limited time. In Railway's guide, for example, the daily volume backups are kept for 6 days, the weekly ones for 1 month and the monthly ones for 3 months. Those figures are one host's settings on one date, not a standard, and yours may differ.

This matters because many mistakes are not noticed straight away. A product price edited wrongly, a form that quietly stopped saving, a page deleted by accident: if you find it after the oldest backup has expired, there is nothing to go back to. CISA's advice is to make sure you can roll back data at least seven days. A reasonable question is "what is the oldest version I can get back, and how often is a new one taken?"

CISA says to perform scheduled recovery tests to verify backup integrity, and to test that your team can restore data both fully and partially. A full restore is the whole site back from nothing. A partial restore is one deleted booking or one lost page, which is far more common.

Restoring is where backups tend to fail. The file is corrupt, it is missing the database, the password to open it is on the machine that died, or nobody remembers the steps. None of this shows until someone tries.

Railway's guide has a limit worth knowing about as well: backups can only be restored into the same project and environment. That is not a flaw. It is the sort of detail you only learn by reading the documentation or trying a restore, and it affects where a rehearsal can happen.

On the sites I run for clients, the site is checked every five minutes, the database as well as the page, and I am alerted if it fails. That is useful. It is also not a backup. It tells me something is wrong. It does not let me undo it.

The check also has a stated limit: it reads a status code, so a checkout that breaks politely and still returns a normal page can slip past it. So I would not treat monitoring as a safety net for your data. Backups are the safety net, and monitoring is how you find out you need one.

• Where are the backups kept, and is any copy outside the account the site runs on?
• How often is one taken, and how long are they kept?
• Does it include the database, uploaded photos and the settings, or only the code?
• When did anyone last restore one, and what did they restore?
• If I ask for my data, can I get it in a form I can open?
• Who can restore it, and how long would it take?

The last-but-one question has a simple version you can ask for: a copy of your own data. Whoever builds your site should be able to hand it over. Under my care plans, an export on request is part of the Essential plan, and an off-site copy with a six-monthly review is part of Plus. The plan details and what they cost are on the hire page.

A good answer is not a longer answer. It is a specific one: a date, a place and a person.

Without making this fancier than it is:

1. Keep one copy of your customer data, a form-enquiry list or order export, somewhere that is yours: your own cloud drive, not your developer's.
2. Pick a date every six months, ask for a restore to be tried, and write down that it worked.
3. Write down who can get at each account, so a restore does not wait on a password.

None of this takes long. Skipping all three is how a small mistake becomes a lost month.

If you want a site where those questions have specific answers, I reply within one business day: see /hire.