A green tick on a backup dashboard means a job ran. It doesn't mean the data is complete, that it can be read, that anyone still has the credentials to restore it, or that the restore would finish before the end of the week. Those are four separate questions, and the only way to answer them is to try.
It's impossible to predict every incident, but it's entirely possible to be prepared for them. Preparation here means one afternoon, once a quarter, doing a restore while nothing is on fire.
Start with two numbers
Before testing anything, agree two figures with the people who run the business, not with IT:
- How much work can we afford to lose? If backups run overnight, the honest answer is up to a day's worth. Some systems need that to be an hour.
- How long can we be without this before it really hurts? An hour, a day, a week - it differs by system, and it's rarely the answer people assume.
Those two numbers turn backup from a technical setting into a business decision. Everything else is checking whether what you have matches them.
The test itself
Pick something real. Not a test file created for the purpose - a mailbox, a finance folder, a database from a system people actually use. Then restore it, ideally to a separate location so nothing live is at risk, and check the contents properly.
- Time it from the moment you decide to restore, not from when the copy starts. The decision, the approvals and the hunt for credentials are part of your real recovery time.
- Open the restored data. Does the file open, does the mailbox have the folders, does the database load?
- Check how far back you can go. Ransomware and quiet corruption are often noticed weeks later.
- Note who did it. If only one person could have, that's a finding in itself.
Write the result down, including how long it took. That number is your actual recovery time, whatever the contract says it is.
The Microsoft 365 gap
This catches a lot of organisations. Microsoft keeps the service running and highly available - that's their job, and they're good at it. Keeping your data recoverable is yours. Deleted items, retention policies and version history help, but they're short-lived and they aren't designed for the scenario where something was deleted, encrypted or overwritten and nobody noticed for two months.
If Exchange, SharePoint, OneDrive and Teams matter to how your organisation works, they need a backup you control, with a retention period you chose. Worth checking what yours is set to. Thirty days is common and often shorter than the time it takes to spot a problem.
The copy an attacker can't reach
Ransomware goes looking for backups, because encrypting them is what turns an incident into a payment. If your backup is on a network share, reachable with the same administrator account that manages everything else, treat it as part of the same estate rather than as protection.
What you're after is at least one copy that can't be altered or deleted from the environment being backed up, whether that's immutable cloud storage, a separate account, or something genuinely offline. You don't need a complicated architecture. You need one copy that survives a bad day.
The bit that isn't technical
A recovery plan that lives on the file server you're trying to recover isn't a plan. Neither is one that depends on a person who might be on holiday. Keep a printed or offline copy that covers the basics: what gets restored first, who decides, who to call, and how people are told what's happening while systems are down.
- Which systems come back first, agreed with the business rather than assumed.
- Who has authority to make the call at 7am on a Saturday.
- Contact details for your provider and key suppliers, held somewhere that doesn't depend on email.
- How you'll communicate with staff and customers if email is unavailable.
A reasonable rhythm
Monthly, check the jobs are still running and nothing new has been left out - new systems are the usual gap. Quarterly, restore something real and record the time. Annually, walk through a bigger scenario on paper with the people who'd be involved. That's enough for most organisations, and it's considerably more than most do.
If you can't remember the last successful restore, that's the place to start. Not a new product, not a bigger plan - one restore, this month, written down.