I've been in IT for over two decades, and I've seen the same scenario play out more times than I can count. A business owner calls in a panic — their server crashed, their backups haven't worked in months, and they're facing days or weeks of downtime. 'I thought we were covered,' they say. They had backup software. They had external drives. What they didn't have was a disaster recovery plan.
A backup is not a recovery plan. Backing up data is step one. Knowing how long recovery takes, who does what, and how to keep the business running during the outage — that's disaster recovery planning. And it's something every business, regardless of size, needs to have documented and tested.
The Two Numbers That Define Your Recovery Strategy
Every disaster recovery plan starts with two deceptively simple questions:
- RTO (Recovery Time Objective): How long can your business survive without each system? For email, the answer might be 1 hour. For a legacy file server used once a month, it might be 48 hours. For your ERP system, it might be 4 hours. Be honest — and get input from department heads, not just IT.
- RPO (Recovery Point Objective): How much data can you afford to lose? An RPO of 1 hour means you need backups every hour. An RPO of 24 hours means daily backups are sufficient. Your accounting system might tolerate losing a day of data; your e-commerce transaction database absolutely cannot.
These numbers drive every technical and budgetary decision in your recovery plan. Lower RTO and RPO numbers mean higher costs — but that cost must be weighed against what downtime actually costs your business.
The 3-2-1 Backup Rule (Still the Gold Standard)
The 3-2-1 backup strategy has been best practice for decades, and it remains solid:
- 1Three copies of your data: One production copy and two backups. This ensures that a single failure (or even two simultaneous failures) won't result in data loss
- 2Two different media types: Don't put both backups on the same type of storage. One on a NAS and one in the cloud. One on local disk and one on tape. If a ransomware variant targets NAS devices specifically, your cloud backup saves you
- 3One copy off-site: Physically separate from your primary location. Cloud storage counts, as long as it's a separate service with different credentials. A backup drive in the server room doesn't survive the fire that destroys the server
The modern addition to this rule: at least one copy should be immutable — meaning it cannot be modified or deleted, even by administrators. This protects against ransomware that specifically targets and encrypts backup files.
The Recovery Plan Document
Your disaster recovery plan needs to be a written document — not something that lives in one person's head. If that person is on vacation (or hit by the same disaster), your business is paralyzed. The document should include:
- Emergency contacts: Names and phone numbers for your IT provider, key vendors, internet service provider, insurance agent, and key employees — with at least two contact methods for each
- System priority list: Rank every system by criticality. When everything is down, what gets restored first? This decision should not be made in the heat of the moment
- Recovery procedures: Step-by-step instructions for restoring each system. Include credentials, software versions, configuration notes, and any known prerequisites or dependencies
- Communication plan: Who notifies employees? Clients? Vendors? What do they say? Draft template messages in advance so you're not writing crisis communications during the crisis
- Alternate work procedures: If your office is inaccessible, where does the team work? How do they access critical systems? If a key system will be down for days, what's the manual workaround?
Testing: The Step Everyone Skips
A recovery plan that hasn't been tested is not a plan — it's a wish. Testing doesn't need to be elaborate:
- Tabletop exercise (quarterly): Gather key people, walk through a disaster scenario, and discuss what each person would do. Takes 60-90 minutes. Reveals gaps in your plan that nobody noticed
- Partial restore test (quarterly): Restore a single critical system — email, a key database, a file share — to verify the backup data is intact and the restore procedure works. Takes a few hours
- Full failover test (annually): Simulate a complete outage and execute the full recovery plan. Yes, it's disruptive. It's also the only way to know if your RTO numbers are realistic
I cannot overstate how often we find failed or incomplete backups during these tests. Backup software silently failing — not reporting errors, just not capturing data properly — is disturbingly common. If you haven't tested a restore, you don't have backups. You have hope.
Cloud Considerations
If your systems are in the cloud (Microsoft 365, hosted servers, SaaS applications), don't assume the vendor handles everything. Microsoft 365, for example, provides redundancy against infrastructure failure but does not provide point-in-time backups that protect against accidental deletion, malicious insiders, or ransomware. You still need a third-party backup solution for M365 data — Exchange Online, SharePoint, Teams, and OneDrive.
How Litefoot Approaches Disaster Recovery
Every Litefoot managed IT client gets a documented disaster recovery plan as part of onboarding. We define RTO and RPO for every system, implement automated backups with verification, configure immutable cloud backups, and test restores quarterly. When something goes wrong — and eventually, something always does — our clients know exactly what happens next, and their businesses keep running. If you don't have a disaster recovery plan you'd bet your business on, let's fix that.