Nobody gets promoted for a good backup and disaster recovery setup. Nobody throws a party when the restore script runs clean. That is exactly why it gets skipped, deferred, and eventually discovered to be broken on the one day it actually matters, usually a Monday morning after a ransomware note shows up on the accounting PC.
I have sat across from business owners in the worst thirty minutes of their year, staring at a "backup" folder that turned out to be empty, or a cloud sync that stopped silently four months ago. The pattern is always the same: they had something that looked like a backup. They had never tried to restore from it. A backup you have never restored is a hope, not a backup, and hope is not a disaster recovery plan.
What actually needs backing up
Most businesses back up the wrong things, or back up everything indiscriminately and call it a strategy. Start with what would actually stop the business if it vanished tomorrow.
- Transactional databases, orders, invoices, inventory, customer records. This is the crown jewel category.
- Configuration and credentials, server configs, API keys, DNS settings, payment gateway setup. Losing these costs days of rebuild even if data survives.
- Document stores, contracts, signed agreements, compliance paperwork.
- Application code, if you run custom software, the repository itself needs a copy outside your primary git host's single point of failure.
Marketing assets, old draft documents, and personal files on shared drives are lower priority. Don't let backup jobs choke on gigabytes of noise while the database backup silently times out.
The 3-2-1 rule, applied practically
The classic rule: three copies of data, on two different types of media, with one copy off-site. For a small or midsize business running on cloud infrastructure, this translates to something concrete rather than abstract.
- Production copy, the live database or file store.
- Automated daily snapshot, stored in the same cloud region but a separate service or bucket, encrypted.
- Off-site or off-provider copy, a different cloud provider or region entirely, updated at minimum weekly.
The reason for provider diversity is not paranoia, it is that cloud provider outages happen, and ransomware that compromises your admin credentials can reach anything your credentials can reach, including your "backup" if it lives in the same account with the same access.
Automate the schedule, then forget it exists
Manual backups fail because they depend on someone remembering. The fix is boring: a scheduled job, running without a human in the loop, with an alert that fires when it does NOT run successfully, not just a log entry nobody reads.
A reasonable cadence for most SMEs:
| Data type | Frequency | Retention |
|---|---|---|
| Transactional database | Every 6 hours | 30 days rolling |
| Full system snapshot | Daily | 14 days rolling |
| Off-site copy | Daily | 90 days rolling |
| Configuration/credentials vault | On change | Indefinite, versioned |
Retention matters as much as frequency. Ransomware often sits dormant for days or weeks before triggering, encrypting your daily backups right along with production if your retention window is too short to reach back before the infection.
The restore drill: the only test that counts
This is the step almost everyone skips, and it is the entire point of backup and disaster recovery planning. A backup that has never been restored is unverified. You do not know if the backup file is corrupted, if the restore script references a server that no longer exists, or if the process takes six hours when the business can only tolerate one.
Run a quarterly restore drill:
- Pick a backup at random, not the most recent one, an older one from the retention window.
- Restore it to an isolated environment, not production.
- Verify the data is complete and the application actually runs against it.
- Time the whole process, start to finish.
- Write down what broke, because something usually does.
I have run this drill for a multifinance company client and found, on the first attempt, that the restore script had a hardcoded path to a server that had been decommissioned eight months earlier. Nobody knew until we tried. That is the value of the drill: it converts an assumption into a fact, before the fact matters.
Ransomware as the modern trigger scenario
Fire, flood, and hardware failure used to be the textbook disaster recovery scenarios. Today the most common trigger is ransomware, and it changes the requirements in one important way: your backup has to be immutable or air-gapped from the credentials that got compromised. If an attacker with admin access can delete or encrypt your backups too, you do not have a backup, you have a second target.
Practical steps:
- Use backup storage with object-lock or write-once retention so even an admin account cannot delete backups within the retention window.
- Keep at least one credential set for the backup system separate from general admin access.
- Assume the attacker had access for weeks before you noticed; retain enough history to restore from before the compromise, not just before the ransom note.
The one-page disaster plan
When systems go down, nobody wants to read a 40-page document. Write one page: who declares an incident, who has access to the backup restore process, what the communication plan is for customers and staff, and what the acceptable downtime is per system. Print it. Keep a copy somewhere that does not depend on the systems that just went down.
If you're building or fixing this kind of resilience alongside a broader digital transformation push, disaster recovery should be a line item from day one, not a patch applied after the first scare.
Practical takeaway
Backup and disaster recovery is not a technology purchase, it is a discipline of automation plus verification. Set the 3-2-1 structure, automate the schedule so it does not depend on memory, and put a restore drill on the calendar every quarter, treated with the same seriousness as a fire drill. The businesses that survive a bad day are not the ones with the fanciest backup tool, they are the ones who already know, because they tested it, that the restore works. If you want a second pair of eyes on your current setup before it gets tested by an actual incident, that is a conversation worth having sooner rather than later at partner.