There is a particular kind of confidence that comes from a green dashboard. Backups ran. No errors. Everything is covered.
The uncomfortable part is that a successful backup job and a successful recovery are two different claims, and only one of them has been verified.
What a successful backup job actually confirms
It confirms that a process ran, read some data, and wrote it somewhere without reporting an error.
It does not confirm that everything important was included. Scopes are defined once and rarely revisited — a new server, a new share, a database that moved, an application installed last year that writes to a path nobody added.
It does not confirm the data is usable. Backups can complete while capturing a database mid-write, producing a file that restores but will not open.
It does not confirm anyone knows how to restore. The person who set it up may have moved on. The documentation may describe an earlier version of the system.
And it does not confirm that recovery would finish in a timeframe your business could survive.
The two numbers that define what you need
Before deciding on any backup technology, two questions determine everything else. They are business questions rather than technical ones.
How much data can you afford to lose? If your last usable backup was from midnight and a failure happens at 4pm, you have lost a day of work. Is that recoverable for your business — can it be reconstructed from email, paper, or people’s memory? For a firm doing high-volume transactional work, an hour might be the limit. For others, a day is genuinely fine. This is your recovery point objective.
How long can you afford to be down? Not how long until the data is back, but how long until people can actually work. For a business with immovable external deadlines, that tolerance can be very short. This is your recovery time objective.
Answer these honestly and the technical requirements follow. Skip them, and you end up with whatever the product defaults were — which may be adequate, but nobody has checked.
A question worth asking your provider“If our main server failed this morning, what time would we be working again, and how much of today’s work would be gone?” A specific answer means someone has thought it through. A vague one means you have backups but not a recovery plan.
What recovery testing involves
Testing exists on a spectrum, and each level answers a different question.
File-level restore. Recovering individual files and folders. Quick, low-risk, and worth doing regularly. Confirms the basics work.
Application restore. Restoring a database or business application and confirming it opens, the data is intact, and it functions. This is where problems tend to surface — particularly with databases backed up while running.
Full system recovery. Rebuilding an entire server from backup in an isolated environment. The most revealing test, because it exposes the dependencies nobody documented: the license key, the certificate, the service account password, the specific configuration that existed only on the failed machine.
Timed recovery exercise. Running a full recovery while measuring how long it takes end to end. This produces the number that matters — and it is frequently longer than people assume.
What testing tends to uncover
In our experience the failures found during testing are rarely the backup software itself. They are the surrounding assumptions.
Something important was never in scope — a share added two years ago, a virtual machine created for a project, a workstation holding files that only exist there.
Restore is far slower than expected, because it depends on downloading a large volume over a connection sized for normal use. Backup was fast because it was incremental. Restore is not.
A dependency is missing. The server restores, but the application needs a license server, a certificate or a credential that lived somewhere else.
Retention is shorter than the problem. Corruption that began five weeks ago is present in every copy retained for four.
And the restore requires knowledge one person had. They are on holiday, or no longer with the business.
Each of these is straightforward to fix when discovered during a test. None are straightforward to fix at 6am during a real outage.
The Microsoft 365 assumption
This one deserves its own mention because it is so widespread.
Many businesses believe that because their email and files are in Microsoft 365, they are backed up. Microsoft maintains the platform’s availability and provides limited retention. That is not the same as a backup you control.
Items deleted by a user, removed by a departing employee, or affected by malware can pass out of reach once retention windows expire. A separate Microsoft 365 backup gives you a recovery point that you own and can restore from on your terms.
A reasonable testing rhythm
Testing does not need to be constant. It needs to be scheduled and recorded.
Monthly: a file-level restore, verifying the basic mechanism and that recent data is present.
Quarterly: an application-level restore for at least one critical system, rotating through them.
Annually: a full recovery exercise for your most important system, timed, with the procedure written down as you go.
After any significant change: a new server, a migration, a new application. Change is what most often silently breaks backup scope.
Record the result each time — what was tested, how long it took, what went wrong, what was fixed. That record is what turns backups from an assumption into something you can actually rely on.
The point of all this
The purpose of a backup is not to have a backup. It is to be able to continue operating after something goes wrong.
Untested backups provide the feeling of protection without confirming the substance of it — and the feeling is arguably worse than knowing you have a gap, because it stops you addressing it.
If you cannot remember the last time a restore was tested from end to end, that is the thing to schedule this month.
This article is general guidance and is not legal, regulatory or compliance advice. Technology and threats change — if you are making a decision based on it, check that it still reflects your current environment.