Home / Insights / A Backup Isn’t a Plan Until You’ve Restored From It

A Backup Isn’t a Plan Until You’ve Restored From It

Every IT manager has said “don’t worry, it’s backed up.” I’ve said it in nurseries, in a school, and in business IT. What I’ve learned across those settings is that the backup is the easy part. The thing that actually protects an organisation is knowing, with evidence, that you can get the data back, how long it takes, and what you lose in the process.

What a backup really is

A backup is a copy. Recovery is a business outcome. The gap between the two is where most organisations get caught out. A job can report “successful” every night for a year while quietly backing up the wrong folder, skipping locked files, or writing to storage that the same ransomware would encrypt alongside everything else.

So the question I ask now isn’t “do we have backups?” It’s “when did we last restore something, on purpose, and time it?”

In the nursery and school world

At Little Barn Owls and Atelier 21, the data that mattered most wasn’t big. It was child records, safeguarding logs, medical and allergy information, attendance, staff files and parent contact details. Much of it lived in cloud platforms and Microsoft 365, which gives a comforting sense that “Microsoft has it covered.”

It doesn’t, entirely. Microsoft keeps the service running. Accidental deletion, a compromised account, a leaver’s OneDrive that’s purged too early, or a SharePoint library someone overwrites are still your problem. In an education setting, losing a safeguarding record isn’t just inconvenient. It can be a regulatory and welfare issue, and you may need to show Ofsted or a local authority exactly what happened and when.

What worked for us was simple and repeatable:

• A third-party backup of Microsoft 365 (mail, OneDrive, SharePoint and Teams), separate from the tenant itself.
• Retention set to match our data protection and safeguarding obligations, not just the default.
• A termly restore test: pick a real mailbox, a real SharePoint folder and a deleted file, restore them, and write down how long it took.
• Clear ownership of who can trigger a restore, so it couldn’t become an easy route for misuse.

The restore tests were never glamorous, but they turned “I think we’re fine” into evidence you can restore when it matters.

In business IT

In business the shape of the risk is often different. The crown jewel may be an ERP or other core trading systems: orders, stock, customers, pricing, suppliers and finance, all tied together. Here, the question isn’t only “can we get the data back?” but “can we get the business trading again, and from what point in time?”

That brings two measures front and centre:

• Recovery Point Objective (RPO): how much data can we afford to lose? For systems processing orders all day, losing a day’s transactions means re-keying, missed deliveries and unhappy customers.
• Recovery Time Objective (RTO): how long can we be down? An hour is an annoyance. A day affects revenue and reputation.

Those numbers have to come from the business, not from IT. The job is to ask operations and finance what they can tolerate, then design and test against it, and be honest when the current setup doesn’t meet it.

Restoring an ERP is also more than restoring a database. It’s the application server, integrations, scheduled jobs, user permissions and the order in which they come back. A database you can restore but can’t connect anything to isn’t a recovery.

What both sectors have in common

The tools and the stakes differ, but the principles are the same:

1. Follow the 3-2-1 rule, with an immutable or offline copy. Three copies, two types of media, one off-site, and at least one that ransomware can’t touch.
2. Test restores on a schedule. Termly in a school, quarterly or more often for critical business systems. Record the results.
3. Know your RPO and RTO, and get the business to agree them.
4. Write the runbook before you need it. At 2am during an incident is not the time to work out the restore order.
5. Protect the backup admin accounts with MFA and separate credentials. Attackers go after backups first.
6. Align retention with data protection. Keeping everything forever isn’t safe either; UK GDPR expects you to hold personal data only as long as you need it.

James Millsom-Mills is IT & Systems Manager, with previous ICT leadership in nursery and school settings.