Every business owner tells me they have backups. Almost none of them have tested a restore. Disaster recovery for small business isn't about buying expensive enterprise tooling, it's about closing the gap between "we have backups" and "we've proven we can actually get the business running again after something breaks." That gap is where most real disasters happen, and it costs nothing to close except an afternoon.
I've seen a multifinance company discover, during an actual server failure, that their nightly backup script had been silently failing for three months. Nobody checked because nobody had ever needed to restore from it. The backup existed. It was worthless. That's the single most common failure mode in disaster recovery for small business, and it's entirely preventable.
The untested backup is a false comfort
A backup that has never been restored is a hypothesis, not a safety net. Backup jobs fail silently all the time: a credential expires, a disk fills up, a schema change breaks the export script, a cloud storage bucket quietly changes permissions. None of these show up unless someone actually tries to use the backup.
The fix isn't more backups. It's a quarterly restore drill: once every three months, pick a recent backup and actually restore it, ideally to a separate environment, and verify the data is complete and usable. This takes half a day for most small businesses and it is the single highest-leverage disaster recovery activity you can do, more valuable than any additional backup frequency or storage redundancy.
What "offsite" actually needs to mean
Backups stored on the same physical premises as your primary system protect you against hardware failure. They do not protect you against fire, flood, theft, or ransomware that encrypts everything it can reach on the network, including attached backup drives. This is the realistic threat model for a small business: not a hypothetical meteor strike, but a burst pipe in the server room combined with a phishing email that got a staff laptop encrypted the same month.
Practical minimum for offsite disaster recovery:
- Automated, not manual. If backing up depends on someone remembering to plug in a drive, it will eventually not happen. Use automated scheduled backups to cloud storage.
- Geographically separate. Cloud storage in a different physical region or at minimum a different building than your primary servers.
- Access-isolated. The backup storage credentials should not be the same credentials that have write access to your production system. If ransomware compromises your main network, it should not be able to reach and encrypt your backups too.
- Versioned, not overwritten. Keep at least 30 days of point-in-time snapshots, not just "the latest backup," so a slow-moving corruption or ransomware infection doesn't get backed up over your only clean copy.
The one-page plan beats the 40-page policy
Most disaster recovery documentation nobody has ever read sits in a folder as a 40-page policy document written for a compliance audit. When something actually breaks at 11pm, nobody opens it. What actually gets used in a real incident is a single page taped conceptually to the front of everyone's mind: who does what, in what order.
A workable one-pager answers:
- Who declares an incident, and who do they call first?
- Where are the backup credentials stored, and who has access to them right now, not who used to?
- What is the order of systems to restore (usually: core transaction system first, reporting and analytics last)?
- What is the acceptable downtime before you escalate to your hosting provider or a specialist?
- Who communicates with customers or partners during the outage, and with what message?
Print it. Put it somewhere physical, not only in the system that might be down.
Match your recovery time to what the business can actually absorb
Not every system needs the same recovery speed. A retail chain's point-of-sale system going down for two hours during business hours is a revenue emergency. The same chain's internal HR portal going down for two hours is an inconvenience. Disaster recovery for small business means being honest about this hierarchy and spending your limited budget and attention on the systems where downtime actually costs money, rather than treating every system as equally critical. This is the same prioritization discipline that shows up in Technical Debt Explained for Business Owners, where not every legacy system deserves the same urgency either.
Ransomware changes the math
Ransomware specifically targets backups, because attackers know backups are the thing that would let you refuse to pay. If your backup strategy assumes only hardware failure, you're planning for last decade's disaster. The access-isolation point above (backup credentials separate from production credentials) is the single most important defense here. If an attacker who compromises your main system can also delete or encrypt your backups, you don't actually have a backup strategy, you have a delayed single point of failure.
The takeaway
Disaster recovery for small business comes down to three unglamorous habits: automate offsite backups with real access isolation, actually restore from backup once a quarter to prove it works, and write the one-page plan that a stressed employee can follow at midnight. None of this requires an enterprise budget. It requires treating "we have backups" as a claim that needs testing, not a fact you can assume.