Backup restore test

Backup restore test is the only honest name for proving recovery. Backups you’ve never restored aren’t backups — green ticks on USB sticks, NAS folders, cloud sync, or an MSP dump all look fine until yesterday’s database fails to come back, takes days, or restores the wrong thing.

For a London SMB, the clock that matters is how fast you can take a real order again, not whether last night’s job finished.

Backup is not the same as restore

Jobs that finish overnight are not the same as a working business the next morning. I’ve seen owners point at a full backup report while nobody could say how long a restore would take, which machine it would land on, or who still knew the encryption passphrase. The product you bought was recovery. The product you actually tested was “something got written somewhere.”

Untested backups create false confidence. The failure mode is quiet: ransomware, a bad deploy, a deleted share, or a disk that finally dies, then the restore is the first real rehearsal, with customers waiting and the office frozen on “we thought we had this covered.”

Sync is not a backup

Cloud sync and mirrored folders copy mistakes as fast as they copy files. Delete or corrupt a working set and the “backup” often follows within minutes. A real backup keeps point-in-time copies you can choose from, held somewhere the live system cannot silently rewrite. Unencrypted USB in a drawer and an MSP archive nobody has ever opened are the same class of false friend. If your only offsite copy is the sync client everyone uses day to day, you have a second copy of today’s mess, not a restore path.

RTO and RPO without the jargon fog

RPO is how much work you can afford to lose: the gap between the last good copy and the incident. RTO is how long you can stay down while that copy becomes a working system again. Write both in hours your ops team would actually accept for quotes, job sheets, or the line-of-business app. “As soon as possible” is not a number. If your RTO is four hours and nobody has ever restored in under a day, the paperwork is fiction. Say the numbers out loud once; most teams discover the backup window and the downtime they will tolerate do not match.

One restore drill that proves something

Pick one critical system. Write down the target: for example, “accounts database from last night, on a spare host, logged in and queryable within two hours.” Run a backup restore test on a quiet afternoon with a second person watching. Time the clock from “start restore” to “we can take a real order.” Note what broke: missing credentials, wrong retention, backups on the same dying box, no one who can approve the cut. Fix those gaps. Repeat on a calendar you will keep. Quarterly is enough for many SMBs if the drill is real, not a screenshot of a green job.

That is disaster recovery for a small business without a war-room theatre. You are proving a restore drill, not buying a binder full of untested steps.

Ownership after the engagement

After a survey and any fixed-price remediation, you should still own the backup accounts, the encryption keys, and the runbook that says how to restore. Vendors and MSPs can operate the tooling. They should not be the only people who can open yesterday’s copies. If Eight Mile helps close gaps under infrastructure and cloud, the end state is your logins, your documented RTO/RPO, and a restore you have already watched succeed, not a black box you hope someone else remembers when they are on holiday.

Make restore the product

Stop treating overnight jobs as proof. Treat a timed restore as proof. Then keep doing it until the scary day is boring.

If you want a short restore-readiness survey: what must come back first, how long you can stay down, and whether today’s copies would actually restore, contact Eight Mile and tell us what you believe is backed up and when you last proved it.