„We have backups” versus „we can restore”

The question “do you have backups” almost always gets a yes. The question “when did anyone last restore anything from them” almost always gets silence.

That is not carelessness. Backups are configured once, then run quietly in the background for years and give no reason to revisit them. The trouble is that the only moment anyone remembers them is also the only moment with no time left to discover they do not work.

Four questions that separate one from the other

1. How long does a restore take?

Not “is it possible” — how many hours. This is a number you need before the failure, because everything else depends on it: whether the company can work in the meantime, whether people go home, what you tell customers.

Restoring a file server from a backup over the internet can take a day or more. If the backup sits in the cloud and the link is 100 Mbit/s, two terabytes take many hours to pull down no matter how good the software is.

Nobody works this out until they have to.

2. How much data will we lose?

A backup at two in the morning means a failure at five in the afternoon costs fifteen hours of the whole company’s work. Sometimes that is acceptable. Sometimes it is not, and nobody has established which.

Ask this one of the departments, not the technicians: how much work could you reconstruct from memory and from paper. The answer tends to differ sharply between finance and sales.

3. Will the backup survive the same event as the data?

A backup on the same server does not protect against that server failing. A backup on a permanently mounted network drive does not protect against encrypting malware, because that sees the drive too. A backup in the same server room does not protect against fire or flooding.

The check, in one sentence: is there a copy that cannot be reached from a compromised machine. If not, what you have protects against deleting a file by mistake — not against the thing you are actually worried about.

4. Has anyone verified it?

Not a full environment restore test — that is a project of its own and rarely has a place in a small company. Something far more modest, doable in fifteen minutes:

• restore one file from last week and check that it opens,
• restore one mailbox into a temporary folder,
• restore one database onto a test machine.

This does not prove everything will work. It proves that the backup contains data rather than empty files with the right names — and that is the most common silent failure.

The silent backup failure

The worst case is not the absence of backups. It is a backup that exists, runs every night, and has been writing an empty folder for eight months because somebody changed a network share path.

Symptoms nobody notices:

• the backup size stopped growing, or dropped suddenly,
• the job has been finishing “with warnings” for months,
• failure notifications go to the mailbox of somebody who left,
• the backup covers the server from before the migration, not the one running today.

Hence the simplest thing worth enabling: an alert for a backup that did not run, or whose size deviates from previous ones. Nobody needs a success alert — after a week it stops being read.

What I do not promise, and what is not worth promising

I do not run cyclical full-environment restore tests, and I know of no small company where that would make economic sense. It is a practice from organisations with a dedicated team and a dedicated budget.

The realistic scope, one that makes sense and stays within reasonable cost:

• backups designed around the value of the data, not the cheapest option in the panel,
• at least one copy outside the machine and outside the network holding the data,
• a known restore time — worked out once, written down,
• an alert for a backup that did not run,
• a sample restore alongside every larger change in the environment.

That is enough to make a failure cost one day rather than the company.

One sentence to close

A backup is not a product. It is a procedure whose result somebody once checked. Without that last element it is an expense rather than a safeguard — and you find out which at the worst possible moment.