Backups are not a strategy until you have restored one

Almost every organisation we assess has backups. A much smaller number have ever restored from them. Those are entirely different positions, and only one of them is protection.

The failure is always discovered at the worst time

A backup that has been silently failing for four months looks exactly like a backup that is working, right up until the morning you need it. So does one that is running perfectly but excluding the database. So does one that is complete but encrypted with a key that was on the machine that died.

None of these are exotic. They are the ordinary ways backups fail, and every one of them is invisible until a restore is attempted.

Three things that make the difference

A restore you have actually performed. Not a verified backup job: a real restore, to a real environment, with somebody checking that the data is right and complete. Until that has happened once, the backup is a hypothesis.

A copy somewhere else. A backup on the same server is a copy of a file. A backup in the same building is protection against hardware failure and nothing else. The copy that saves you in a fire, a theft or a ransomware event is the one somewhere your running systems cannot reach.

A runbook your team can follow. Written for the person who will be doing it, which may not be the person who set it up. If restoring requires knowledge that lives in one person's head, you have a single point of failure with a pulse.

What to ask for

Ask when the last successful test restore was, and what was restored. If the answer is a date and a description, you are in good shape. If it is "the backups run nightly", you have just learned something important.

We test restores as part of every managed service, and we will tell you the date of the last one without being asked.