Backup and Disaster Recovery Planning for SMBs
A pragmatic BCDR plan an SMB can actually execute - RTO/RPO, 3-2-1-1-0, tested restores, and a one-page runbook that survives an incident.
Disaster recovery plans fail in two predictable ways: they are never written, or they are written and never tested. Either way, the first time you need them, you find out the hard way. The good news: most SMBs do not need a 50-page binder. They need a small set of decisions made deliberately, a backup architecture that survives ransomware, and a one-page runbook the team can actually execute under pressure.
This is the working framework we use when building BCDR plans for SMBs in Ottawa and the GTA. It is built around four questions and one rule.
The four questions every SMB BCDR plan must answer
- What data and systems are critical? (Not everything - the top five to ten.)
- How fast must they come back? (Recovery Time Objective, in hours.)
- How much data can we afford to lose? (Recovery Point Objective, in hours.)
- Who runs the restore? (Named individuals, with backups for the backups.)
Defining RTO and RPO for real
RTO and RPO are business decisions, not technical ones. Sit down with the people who run finance, operations and sales. Ask: if the order-entry system is down for four hours, what happens? Eight hours? A day? Three days? The answer reveals the real RTO. Then ask: if we restored from a backup taken at 7 a.m. and lost everything since, what does that cost? That reveals the real RPO.
Most SMBs land somewhere in the four-to-eight-hour RTO and one-to-four-hour RPO range for critical systems. Less-critical systems can tolerate 24-to-48 hours. Writing these numbers down ends the eternal argument about whether the current backup is "good enough."
The 3-2-1-1-0 backup rule
The old 3-2-1 rule (three copies, two media, one offsite) is no longer enough in the ransomware era. The modern version adds two requirements:
- 3 copies of your data.
- 2 different media types.
- 1 offsite copy.
- 1 immutable copy that cannot be deleted or encrypted, even with admin credentials.
- 0 errors after testing - a backup that has not been verified is a hope, not a backup.
What to back up - and what is often missed
Beyond the obvious file servers and databases, do not forget: Microsoft 365 (mail, SharePoint, OneDrive, Teams), the configuration of network devices, line-of-business application configuration, identity (Entra ID / Active Directory), and the documentation that tells you how to restore everything. SMBs frequently back up the data and forget the configuration; recovery then takes ten times longer because the environment has to be rebuilt from memory.
Test restores: monthly spot, quarterly full
Backups are not real until they have been restored. Build a recurring schedule: monthly spot-restore of a random file, mailbox or VM; quarterly full DR drill of one critical system to an isolated environment. Document the results. The first time a real incident hits, that documentation is the difference between a calm recovery and a panic.
If your provider cannot show you a restore log from the last 90 days, you do not have a tested backup. You have an assumption.
The one-page runbook
Long DR plans do not survive contact with a real incident. Build a one-page runbook that fits on a printed sheet and includes:
- Who declares the incident, and how (phone numbers, not email).
- Who calls the cyber insurance carrier first (this matters legally).
- Which systems get isolated immediately.
- Restore order: identity, then email, then file shares, then line-of-business apps.
- Communication template for staff and customers.
- Printed copies in physical locations, because you may not have access to email.
Ransomware-specific considerations
Ransomware crews actively hunt for and destroy backups before triggering encryption. An immutable copy - one that cannot be deleted or overwritten even with backup admin credentials - is now table-stakes. Cloud object-lock storage (Wasabi, Backblaze B2, AWS S3 Object Lock, Azure Blob immutability) is the standard SMB approach. Without it, paying the ransom is sometimes the only option, and that is not a decision you want to make at 3 a.m. for the first time.
Microsoft 365 backup, specifically
Microsoft 365 is your SMB's most critical data store and the one most likely to be assumed safe. Microsoft replicates the service; they do not protect you from deletion, ransomware encryption, retention mistakes or malicious insiders. A third-party M365 backup (Veeam, Datto, AvePoint, Keepit) protecting mail, SharePoint, OneDrive and Teams is essential. Test restores apply here too.
Bottom line
A good SMB BCDR plan is short, written, immutable, tested and rehearsed. Most of the cost is the discipline of testing - the technology is mature and affordable. If you cannot answer the four questions at the top of this article today, that is where to start.