There is a sentence I wish every business owner, office manager, and accidental IT person would tape to the wall:
A backup you have never restored is not a backup.
It is a theory backed by green checkmarks, email reports, and a dashboard that says everything is fine. But until somebody proves that the data can be restored, in a useful condition, within a useful amount of time, you do not actually know what you have.
You have hope. And hope is not a backup strategy.
The green checkmark problem
Most backup systems are very good at telling you that a job completed. That is useful, but it is not the same as proving recovery works.
A backup job can complete successfully while still being useless for your real-world need. Maybe it backed up the wrong folder. Maybe the database files were captured in an inconsistent state. Maybe the encryption key is missing. Maybe the retention policy aged out the version you needed. Maybe the backup account no longer has access. Maybe the restore process requires a password nobody knows.
The job was green. The business was still in trouble.
This is where people get burned. They assume “backup successful” means “we can recover.” Those are related, but they are not the same thing.
Restore is the whole point
The point of a backup is recovery.
- Can you restore the deleted file?
- Can you recover the mailbox?
- Can you bring back the accounting database?
- Can you rebuild the server?
- Can you get the business running after ransomware, hardware failure, accidental deletion, theft, fire, or a bad software update?
Those are the questions that matter.
A backup system should be judged by restore performance, not just backup completion. That includes how much data you can lose and how long you can be down. In IT terms, those are usually called RPO and RTO.
RPO – recovery point objective – is how much data loss is acceptable. If your last good backup is from last night, can the business tolerate losing today’s work?
RTO – recovery time objective – is how long it takes to get running again. If your server dies at 9 AM, is it acceptable to be down until tomorrow? Until next week?
Most organizations have never answered those questions honestly. They think “having backups” is enough.
Common ways backups fail
Most backups fail from some simple underlying issues.
Someone sets them up once and never looks again. A drive fills up. A cloud token expires. A NAS share changes. A new folder gets created outside the protected path. A server is replaced and the backup agent is never installed. A database grows too large for the backup window. A password manager entry disappears. A vendor changes licensing. A ransomware infection encrypts both the production files and the always-connected backup share.
None of this is dramatic until the restore fails. Then it is very dramatic. The most painful failures are usually not technical issues. They are small maintenance gaps that had months or years to become disasters.
That is why backup systems need routine review. Not only when something breaks.
The 3-2-1 rule
The classic backup rule is 3-2-1: keep three copies of your data, on two different types of storage, with one copy offsite.
You want the working copy, a local backup for fast restores, and an offsite or cloud copy for site-level disasters. For ransomware protection, you also want some form of immutability or offline separation. If malware or a compromised admin account can delete or encrypt every backup, you do not have enough separation.
Cloud backup can be excellent, but do not confuse sync with backup. A file sync service that instantly mirrors deletions and corruption may help with convenience, but it is not automatically a backup. Version history helps, but only if retention is long enough and restore is practical.
External drives can help, but only if they are rotated, monitored, and disconnected when appropriate. A USB drive permanently attached to the infected computer may become one more encrypted drive.
Testing does not have to be complicated
Pick a file and restore it to a different location. Open it. Confirm it is the right version. Do the same with a folder. Test a mailbox restore if email matters. Test a database restore if the business depends on that database. For servers, periodically test whether you can restore to alternate hardware or a virtual machine.
Document the steps while you do it. The person doing the restore during an emergency may not be the person who set up the backup system. They may be tired, stressed, and under pressure. A clean restore procedure is part of the backup.
Also document where credentials, encryption keys, recovery codes, and vendor support information live. Protect that documentation, but make sure the right people can access it when needed.
Tabletop exercises test the ugly scenarios
It is easy to test when the environment is set up. Real incidents rarely go that easy.
What if the main server is gone? What if the office burns? What if the owner’s laptop is stolen? What if the backup admin account is locked out? What if the latest backup contains encrypted ransomware files? What if the cloud backup bill was not paid? What if the internet is down during the restore?
Think through the unexpected cases. At minimum, know what you would do if the original machine is unavailable and the person who normally handles IT is unreachable.
This is where experienced IT help pays for itself. A good backup review is not just “is there software installed?” It is “what happens on the worst Tuesday of the year?”
For small businesses that need a practical second set of eyes, this is exactly the kind of operational review that 255 IT Consulting can help with: https://255consulting.com.
Put backup testing on the calendar
If testing is not scheduled, it usually does not happen.
For a small office, quarterly restore tests may be a reasonable starting point. More critical systems may need monthly tests or automated verification. Here’s where things go wrong:
Backup coverage should be reviewed after any major change:
- new server
- new application
- new storage location
- new cloud tenant
- new compliance requirement
Test restore scenarios.
Keep records. Note what was restored, who tested it, how long it took, and what problems were found. Those notes become valuable when you need to improve the system or prove due diligence.
Backup testing is not busywork. It is risk management.
The uncomfortable truth
The first restore test sometimes fails. That is not a reason to avoid testing. That is the reason to do it.
Finding the problem during a quiet Tuesday afternoon is a gift. Finding it after a server crash, ransomware event, or accidental mass deletion is a crisis.
Backups are not about feeling prepared. They are about being able to recover. Until you have tested that recovery, you do not know whether your backup system is a safety net or just an expensive green checkmark.
Test it before you need it.