A backup you have never restored is not a backup

A file that has never been opened is a hope. It becomes a backup the first time someone restores it into an empty environment, checks the numbers against the live system, and writes down who did it and when. Until then you own a scheduled job and a dashboard that says "success". The condition that flips this: data you can rebuild from another source within the time you can afford to lose — a price list typed from a supplier's PDF, photos that exist on a phone too — needs no ceremony. Everything else does.

What has to be in the set?

Most failed restores are complete copies of the wrong things.

• The database, with its users, permissions and schema version. A dump restored into a differently-shaped database is a second outage.
• Uploaded files. Scanned invoices, product photos, signed delivery notes. Nobody notices they were never included until a customer asks for a document.
• Configuration. Environment values, mail settings, routing rules, scheduled jobs, integrations. A restored database on a misconfigured server is not a recovery.
• Keys and secrets. Encrypted columns are unreadable without the key. Data and key stored in the same place is one backup, not two.
• The code, at the version that was running. Not the current branch — the commit deployed on the day the data was written.

NIST's contingency planning guide (SP 800-34) treats this as one plan, not a file-copying task: what must be recovered, in what order, by whom, and how you will know.

What does 3-2-1 mean without the slogan?

Three copies, on two kinds of storage, one of them elsewhere. The idea: do not let one failure take every copy.

• Three copies means the working copy plus two. Two copies is a mirror; a mistake reaches both.
• Two kinds of storage means not three snapshots on the same disk array, under one account, with one key.
• One off-site means outside the building and outside the account: another provider, or a drive that leaves the office on a schedule.

The value is the question the rule forces: what single event destroys all of these at once? If the answer is "the server is deleted" or "the account is closed", you need a copy that event cannot reach.

Copy	Where it lives	What it survives
Working data	The live server	Nothing on its own
Local copy	Another disk, same building	A disk failure
Off-site copy	Another provider or a drive off premises	Fire, theft, a deleted account

How much data can you lose, and how long can you be down?

Two business questions, and their answers decide the cost of the arrangement. Ask in days and hours, not acronyms.

How much can you lose? If the system died now, how far back may the data go before the loss becomes something you cannot explain to a customer? A workshop writing three invoices a day can lose a day. A pharmacy dispensing against stock cannot lose the afternoon.

How long can you be down? A day offline in a shop with a paper fallback is an inconvenience; a day in a warehouse with trucks waiting is a different number. That decides between a warm standby and a restore from a drive — the second is much cheaper. Write both answers down, or the schedule stays a guess.

How do you run a restore drill?

Restore into a place that is not production, using only what the backup contains.

1. Pick the copy at random. Not the newest, not the one made for the test.
2. Restore into an empty environment with no access to the live database. Many "successful" restores depend on something that was never in the backup.
3. Start the application from it. A database that loads but will not boot the app is not a recovery.
4. Check the numbers that matter. Count customers, sum a month of invoices, open a document from the file store, log in as a real user.
5. Time the whole thing, from the decision to restore to a user who can work. That is your real recovery time, not the estimate in the plan.
6. Write the date, the name, the copy used and what failed. Fix the gap before the next drill, not after the next incident.

Repeat after every significant change, and on a fixed date in someone's diary. Name one person who receives the failure alert and one who covers for them. A short entry per drill — date, person, what was restored, what broke — is evidence for an auditor or a buyer, and makes the next drill faster.

Where must the backup not live?

• On the same server as the data. The commonest arrangement, and the one that leaves with the server.
• In the same account as production. One compromised credential deletes both. Destructive attacks look for backups first.
• Only with the provider hosting the site. Ask what happens to your copies if the account is suspended over a billing dispute.
• On a drive that is always plugged in. Ransomware encrypts mounted drives.
• In a format only one person can read. An undocumented archive is a hostage, not a backup.

A decision procedure

1. List what must come back, in the order the business needs it: customers, orders, invoices, documents, logins.
2. Answer the two questions in hours, where the owner can see them.
3. Check what the job contains. Restore one file and one table from last week's copy before trusting the schedule.
4. Add the missing pieces: files, configuration, keys, the deployed code.
5. Move one copy out of the building and out of the account.
6. Book the first drill with a name and a date on it, and book the second before the first is done.

Where this goes wrong

• Success is measured by the job, not the restore. A nightly job that writes an empty archive reports success too. Only a completed restore counts.
• The backup is tested once, at go-live. Schemas change, file storage moves, keys rotate: a drill that passed two years ago tests a system that no longer exists.
• Only the person who built it can restore. If the written steps cannot be followed by someone else, the knowledge leaves with the developer.
• Nobody has decided who may order a restore. It costs the hours since the last copy. Decide in advance, or the call is made at the worst moment by whoever is in the office.

What this does not cover

This is about recovering data, not staying online during an incident: a backup does not replace redundancy, monitoring or a paper fallback. And it says little about protecting the copies: sensitive data needs encryption, and the keys need their own arrangement.

We build backup routines that someone has actually restored from, with the drill written down and a date against it.