Ask a firm whether it has backups and the answer is almost always yes. Ask when the restore was last performed and the answer changes shape. It becomes a description of the software, or of the schedule, or of the provider. What it rarely becomes is a date.
That gap is the whole problem. Backup software reports success for a great many configurations that cannot actually bring a business back. The job ran. The files copied. Whether the copy is complete, whether it is readable, whether anybody still holds the credentials needed to open it, and whether the thing it would restore onto still exists, are all separate questions, and none of them is answered by a green tick.
What a green tick does not tell you
A backup that has never been restored is untested in at least four ways.
Completeness. The job backs up what it was pointed at. Systems accumulate: a database moves, a share is added, somebody stands up a new server. Unless the scope is reviewed, the backup slowly becomes a copy of the estate as it was when the job was written.
Integrity. Storage fails quietly. A file can be present, correctly sized and unreadable, and nothing in the backup report will say so, because the report describes the write and not the read.
Access. Restores are needed on the worst day, which is frequently the day the person who configured the backup is unreachable, or the day their account was the one compromised. If the credentials live only with them, the backup is theirs and not the firm’s.
Destination. Restoring needs somewhere to restore to. If the plan assumes hardware that no longer exists, or a licence that has lapsed, the recovery time is not the length of the copy. It is the length of the procurement.
The test
Take one system. Restore it, to a place that is not production, from the backup you actually hold. Time it. Write down what you found.
The first time a firm does this, something is usually wrong. That is not a failure of the exercise, it is the point of it. Finding out on a Tuesday afternoon that a restore takes eleven hours is inconvenient. Finding out during an incident, while the business is stopped, is a different order of problem.
What we do about it
On our engagements the restore is part of the work, not a recommendation left at the end of a report. Backups get configured, and then one is restored while we are still there, with the elapsed time and the findings written down. On a retainer that test is repeated on a schedule rather than assumed to still hold.
It is not the most impressive thing we do. It is regularly the most valuable.