Almost every office we walk into has backups. Far fewer have ever restored one.
The backup software says "completed successfully" every night, so everyone assumes things are fine. Then a server dies, or ransomware hits, or someone deletes a shared folder, and the first real restore happens under pressure. That is the worst possible time to learn what the backup actually captured.
"Scheduled" is not "tested." Here is why backups fail quietly, what a real recovery objective looks like, and a checklist you can run yourself.
How backups fail without telling you
- The wrong things are in the job. A new shared drive, a new database, or a cloud mailbox was never added. The backup runs perfectly and omits what matters.
- The job succeeds but the data is unusable. Corrupt files, an application database copied while it was open, or a backup of a drive that was already encrypted by ransomware.
- The backup is reachable from the network it protects. If the backup drive is mapped as a normal drive letter, ransomware can encrypt it along with everything else.
- Nobody reads the alerts. Warning emails go to a former employee's inbox, or to a folder nobody opens.
- Retention runs out. You keep 14 days, and you notice the problem on day 20.
- Credentials or encryption keys are lost. The backup is encrypted, and the only copy of the key was on the server that died.
- Cloud software isn't backed up at all. Microsoft 365 and similar services keep your data available, but that isn't the same as a point-in-time backup you control. Check what your plan actually covers.
Two numbers that matter: RPO and RTO
Instead of "we have backups," define two targets in plain language.
RPO (recovery point objective): how much data can you afford to lose? If the server fails at 3 p.m. and your last backup was at 11 p.m. the night before, you've lost a day of work. Is that acceptable? For a clinic, probably not. For an archive share, probably yes.
RTO (recovery time objective): how long can you be down? If the answer is "we need to see patients tomorrow morning," the backup has to be restorable within hours, not days. Restoring terabytes from a slow offsite connection can take much longer than people expect.
Write both numbers down for each important system: email, accounting, practice management software, file shares. Then check whether your current backup can really meet them. Often it can't, and it's better to find that out on a Tuesday afternoon than during an outage.
A restore-testing checklist
Do the first round now, then repeat on a schedule: monthly for a spot-check, and at least yearly for a full recovery exercise.
Monthly spot-check (15–30 minutes)
- Confirm the last backup date and status for every job, and read the actual log, not just the green icon.
- Restore three random files from different locations to a temporary folder. Open them.
- Restore one file from at least a week ago, to confirm older versions exist.
- Check that the offsite or cloud copy is current, not just the local one.
- Confirm alert emails are going to someone who still works for you, and who knows what to do with them.
Quarterly
- Restore a full folder or mailbox, and time it.
- Check the backup scope against what you actually use: new drives, new software, new cloud services.
- Confirm that at least one copy can't be changed or deleted from your regular network, either offline, immutable, or on separate credentials.
Yearly (the real test)
- Restore a complete system, such as your practice management server or file server, into a spare machine or virtual environment. Measure the time and write it down. Compare it with your RTO.
- Confirm the people involved can do it without you: the steps are written, the passwords and keys are stored somewhere safe, and the vendor contact numbers are current.
- Fix whatever failed, and test again.
The 3-2-1 rule, with an update
The classic advice is three copies of your data, on two kinds of storage, with one offsite. It's still a good start. The modern addition is that at least one copy should be immutable or offline, so ransomware can't reach it, and every copy must be tested.
What a failed test is worth
A failed restore test is a good result. It cost you an afternoon instead of an outage. Write down what failed, fix it, and test again. The only bad outcome is not testing at all.