The Backup You Have Not Restored

Ask a small business whether it has backups and the answer is almost always yes.

Ask when one was last restored and the answer is almost always a pause.

That pause is the whole subject, because the two questions measure completely different things and only the second one predicts what an incident costs.

Backups fail silently, which is the entire problem

A backup job that writes an empty archive every night reports success every night. It ran, it completed, it produced a file. Every status indicator is green.

The ways this happens are mundane:

A credential expired, and the job now backs up nothing while exiting cleanly.
A new server, database or share was added and never included.
The retention setting means the oldest copy is four days old, and the ransomware sat dormant for two weeks.
The archive is encrypted with a key stored on the machine being backed up.
It backs up the database and not the uploaded files, which is where most of the business’s actual work lives.

Not one of those produces an error. Several produce a nightly success email, which is worse than silence because it is read as evidence.

The restore is the only test

Everything else — the job status, the file size, the dashboard — is a measurement of the backup process. The only measurement of the backup is whether data comes back out of it and works.

A restore answers three things nothing else can:

Does the data come back? The binary question, and the one people expect.

Is it complete? Frequently the answer is “mostly”. The database restores and the uploaded documents do not. The email comes back without the shared mailboxes.

How long does it take? This is the one nobody anticipates and the one that matters most commercially. An outage is priced in hours. Until you have restored once, you do not know whether yours is four hours or three days, which means you cannot plan, quote or insure against it.

★ Insight ───────────────────────────────────── The third answer is the reason to do this even if you are confident in the first two. Most businesses discover their recovery time is several times longer than assumed, and almost always for the same reason: the restore itself is fast, and the work around it is not — provisioning somewhere to restore to, finding credentials, reconnecting integrations, and confirming the data is right. None of that is in the backup vendor’s estimate, and all of it is in your outage. ─────────────────────────────────────────────────

The rule, and the part that has changed

The long-standing guidance is three copies of your data, on two different types of media, with one copy off-site.

What ransomware changed is that “off-site” is no longer sufficient on its own. An attacker with access to your systems for a fortnight before acting has had time to find and encrypt a connected backup — including a cloud drive that syncs, which is not a backup at all but a second live copy of whatever state your files are in, including the encrypted one.

The addition worth making is one copy that cannot be modified from your network: immutable storage, or a copy that is genuinely offline. The test is simple — if an administrator on your network could delete it today, so could an attacker with that administrator’s credentials.

How to run one, in an afternoon

You do not need a disaster recovery exercise. Pick one meaningful thing.

Choose a real target. A database, a shared drive, a mailbox. Something you would actually need.
Restore it somewhere else. A test machine, a separate folder, a spare account. Never over the live copy.
Start a timer, and include everything — locating the backup, finding credentials, waiting for the transfer, and confirming the data.
Open the restored data and use it. A file that exists is not a file that works. Open documents, run a query, check the most recent record is actually recent.
Write down the time and what was missing. That number is your recovery time for that system. It is the single most useful figure in your continuity planning and most businesses do not have it.

Then do it again in six months, because the answer changes as systems are added.

What to check even before that

Three things you can establish today, in minutes:

What is actually in scope? Get the list of what is backed up and compare it against the list of where your business’s data lives. The gap is usually one or two systems added since the backup was configured.

How far back does it go? If your retention is seven days and a compromise went unnoticed for three weeks, every copy you hold is already compromised.

Where are the credentials to restore? If they are in the email system you are restoring, you have a circular dependency that only reveals itself at the worst moment.

What to write down afterwards

The restore produces information that is worthless unless it is recorded somewhere other than in the head of whoever ran it.

Four things, on one page:

The recovery time, per system, with the date it was measured. This is the number that goes into every continuity conversation afterwards and the one that makes insurance discussions concrete.

What was missing. Almost every first restore turns up something out of scope — uploaded files, a secondary database, a mailbox. That list is the scope change for your backup configuration.

Where the credentials came from. If you had to ask someone, or find them in a system that might itself be down, that is a circular dependency to fix now.

Who did it, and who watched. A restore run by one person is a restore only that person can do. The second time, have somebody else drive.

Then put a date in the calendar for six months’ time. The answer changes as systems are added, and the value of the number decays with every change nobody re-tested.

The honest framing

Most businesses that lose data did not lack backups. They had backups that did not contain what was needed, or took longer to restore than the business could survive, or could not be reached because the thing holding the credentials was the thing that was down.

None of those are discovered by checking that the job ran. All of them are discovered by an afternoon and a timer.

Cloud Geeks provides backup, disaster recovery and managed IT for Australian small businesses. Websites come from Cosmos Web Tech, apps from Awesome Apps, and the group is Ganda Tech Services.