A backup no one has restored is a hypothesis

Almost every company has backups. Very few have restores. And until someone restores, what you have is not a backup: it's a hypothesis with a good reputation.

Day-to-day work reinforces the misunderstanding. The backup agent reports “successful” every night, the dashboard turns green, and nobody asks any further. But that “successful” says the file was written, not that the business can run again with it.

What shows up the first time you actually restore

The first restore test of an environment that was never tested almost always finds something. Not because the team did a poor job, but because some things only become visible when you restore:

• Dependencies nobody wrote down. The database comes back, but the application won't start because certificates, connection strings, scheduled tasks, or a service that lived on another machine are missing.
• The order. Restoring the application before identity, or the data before the storage where it needs to land, turns one recovery into two.
• The real time. Everyone thought it was “a couple of hours,” and it turns out to be six, almost all of them spent waiting for the copy from cold storage.
• What wasn't backed up. A disk added after the policy was configured. A new machine nobody included. A configuration file that lived outside the application folder.
• Who knows how to do it. If the procedure exists only in one person's head, the continuity plan depends on that person answering the phone.

Why it goes in the contract, not in good intentions

A restore test costs people's time and a maintenance window. Like everything that costs something and isn't urgent, it gets postponed. That's why, in our managed services, the quarterly test is a written obligation, with its evidence and its date, and not a verbal commitment: once it's in writing, someone has to run it and someone has to check that it was run.

It's the same logic as everything else we measure. Availability is reported per server, with the cause of each event; security, with the evolution of the Secure Score; backups, with a restore that actually happened. What isn't verified, over time, stops being true without anyone noticing.

What a policy that actually works should include

• Separate backups by workload type: the operating system, the application, and the data are not the same thing, and they don't have the same frequency or the same retention.
• Stated retention in days, weeks, and months, aligned with what the business requires and with what the regulator requires, which don't always match.
• A copy out of reach of everyday credentials. A backup that can be deleted with the same account that manages the server doesn't protect you from the scenario that worries people most.
• A quarterly test with evidence: what was restored, where, how long it took, and what failed.
• A recovery time objective agreed with the business, not inherited from the provider's catalog.

The value isn't the file: it's the number

In the end, the deliverable of a good backup policy isn't a folder full of copies. It's a sentence someone can say in a meeting without crossing their fingers: “If this goes down today, we're back up in so many hours, and we know because we did it in July.”

If you don't have that number, or you have it but no one has verified it this year, let's talk.