Backup Testing: The Drill That Saves Hospitals
A backup you have never restored is a hypothesis. What to test, how often, and why "the job completed successfully" is the least informative line in the whole report.
GuardsArm Team
Security Experts
"Backup completed successfully" means the backup software finished writing something. It does not mean the data is complete, that the database is consistent, that the encryption key still exists, or that anyone knows the sequence to bring the system back. Every one of those has failed in a real hospital incident, discovered on the day it mattered.
Four levels of testing, and what each proves
Most organisations do the first and believe they have done the fourth.
| Level | What it is | What it proves | Cadence |
|---|---|---|---|
| 1. Job monitoring | Reading the success/failure report | The software ran | Daily |
| 2. File restore | Pull back individual files | Media is readable, catalogue is intact | Weekly |
| 3. System restore | Rebuild a full system in isolation | The image boots and the application starts | Quarterly |
| 4. Scenario drill | Restore a clinical service end to end, under time pressure, with the people who would really do it | You can actually recover | Annually, minimum |
Level 4 is the only one that tests the thing you care about. It is also the only one that finds the human failures: the runbook nobody updated, the credential held by someone who left, the dependency nobody documented.
What to test that people skip
Restore order. Clinical systems have dependencies: identity, then database, then application, then interfaces. Restoring in the wrong order produces a system that starts and then fails in confusing ways. The order should be written down and exercised.
Database consistency. A file-level backup of a running database often restores to something that will not start or is subtly corrupt. Verify with the database's own consistency tooling, not by checking the file exists.
Encryption key availability. If the key management system is itself down, or the key is stored only inside the environment you are recovering, the backup is unreadable. Test recovery of the key path.
The interface engine. A restored EHR that cannot exchange HL7 messages with the lab is not a restored clinical service. Interfaces are frequently out of scope for the drill and are precisely what determines whether care can resume.
Whether anyone can do it without the usual person. Run the drill with the primary engineer deliberately unavailable.
Measuring recovery honestly
The number that matters is not stated RTO but demonstrated recovery time.
Report the demonstrated figure to leadership, not the policy figure. If the two differ substantially, that gap is either a funding request or a change to the stated objective — but it should not remain undisclosed.
A cadence that survives contact with a hospital
The weekly random restore is the highest value-per-minute activity in the list. It is thirty minutes, it can be delegated, and it catches silent media and catalogue corruption months before an annual drill would.
Where this connects
Backup testing only matters if the backups still exist when you need them, which is a separate problem — ransomware operators specifically hunt backup infrastructure, and segmenting it is the highest-value first step covered in microsegmentation for hospitals.
And a successful technical restore is not a resumed clinical service; that is covered in business continuity for EHR downtime.
GuardsArm runs restore drills and recovery assessments for healthcare organisations, including the interface and dependency testing usually left out. Book a scoping call.
Written by GuardsArm Team
Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.
Take the next step on “Backup Testing: The Drill That Saves Hospitals”
Talk to the GuardsArm team about how these services apply to your environment.
