Almost every business backs things up. Very few have ever restored from those backups, which means very few know whether they have backups at all.
This is the least glamorous automation in the series and the one whose absence has ended businesses.
Almost every organisation backs things up. Very few have ever restored from those backups, which means very few actually know whether they have backups at all.
Why success reports mean so little
A backup job reporting success tells you the job ran. It does not tell you it captured the right data, that the data is readable, or that anyone can get it back within a useful timeframe.
The failure modes are boringly consistent: a folder that was moved and is no longer included, a database excluded by a filter nobody remembers writing, silent corruption in an archive nobody has opened, an expired credential meaning the last successful run was months ago, or a backup stored somewhere that is compromised by the same event that takes the original.
You do not have a backup until you have restored from it. Until then you have a job that reports success.
How to build it
1. Write down what must survive, and what need not
Not everything needs backing up, and pretending otherwise makes the whole thing unwieldy. Client deliverables, financial records, contracts, the operational systems the business runs on. Be explicit, because an unlisted system is an unbacked one.
2. Confirm the backup exists at all for each item
Go through the list and identify where each is backed up and by whom. Cloud services having version history is not the same as a backup, and it is the assumption that catches most small businesses out.
3. Automate a monthly restore test
Pick a file at random from the backup, restore it to a scratch location, compare checksum and size against the source, and report. This is a modest script and it converts a claim into evidence every month.
4. Make failure loud and success quiet
A failed restore test should reach a named person immediately. A successful one should be a line in a log. Inverting this is how people learn to ignore the notification.
5. Test the credentials as part of the check
An expired token is one of the most common reasons a backup silently stops. If the test authenticates each run, expiry surfaces as a failure rather than as a gap discovered later.
6. Do one full restore drill a year, by hand, and time it
The automated check proves data is retrievable. The drill tells you how long it takes to actually get a working business back, which is the number nobody knows until the day they need it.
Tools and what they cost
| Option | What it costs | Honest trade-off |
|---|---|---|
| Backup service native verification | Included with most paid backup products. | Usually verifies archive integrity, which is genuinely useful. Rarely proves the right data is included, which is the more common failure. |
| Apps Script or a small script doing sample restores | Free with Google Workspace. | Tests the actual round trip including credentials. You write it, and it is a modest job. |
| Dedicated backup for SaaS data (Backupify, Rewind, Afi) | Per user or per seat monthly. | Covers the gap most businesses miss, since Workspace and Microsoft 365 retention is not a backup. Another subscription for something people assume they already have. |
| Manual quarterly restore by a person | Free. | Genuinely valuable and better than most businesses manage. It depends on somebody remembering, which is the thing being automated away. |
What it is actually worth
This is insurance, so measure it as exposure rather than return.
Two numbers to establish now. How long since anyone restored anything, which for most small businesses is never. And how long a full recovery would take, which almost nobody can answer. Producing those two answers is the entire value of starting.
The context, carefully attributed: Verizon 2025 Data Breach Investigations Report, drawn from 22,052 real incidents, found 88 percent of breaches at small and medium businesses involved ransomware, against 39 percent at large enterprises. Ransomware is precisely the scenario where a verified backup is the difference between an expensive week and an existential event, and where a backup on the same compromised network is no backup at all.
I am not going to quote downtime cost figures. Those come overwhelmingly from backup and continuity vendors and vary by an order of magnitude between sources.
How it breaks
The test restores the same file every month. It proves one file is retrievable. Randomise the selection, and include different systems in rotation.
The backup is on the same network as the original. Ransomware encrypts both. At least one copy should be somewhere the compromised environment cannot reach.
Nobody knows who owns it. Backups are everybody assuming somebody. Name one person, and name a deputy.
Success notifications train people to ignore the channel. Report failures loudly and successes quietly, or the alert that matters arrives in a stream people have muted.
How to tell whether it worked
Days since the last successful verified restore, which should never exceed a month. Systems on the must-survive list with a confirmed backup, target all of them. And measured time to full recovery from your annual drill, which is the only number that answers the question anyone will actually ask.