How to Build a Backup and Disaster Recovery Plan for a Small Business

Most small businesses have some form of backup. Far fewer have a disaster recovery plan that says what gets restored first, how long it takes, who decides and whether it has ever actually worked. This guide walks through building both. It is a core component of our managed IT services.

What is the difference between backup and disaster recovery?

Backup is a copy of data; disaster recovery (DR) is the documented ability to restore operations after a disruption. A backup of your accounting database is useful, but DR also covers where you would run that database if the server or office were unavailable, how staff would reach it and in what order systems come back.

Common disruptions to plan for include:

• Ransomware or a compromised admin account
• Accidental or malicious deletion of files, mailboxes or SharePoint sites
• Hardware failure of a server, NAS or firewall
• Loss of the office through fire, flood, extended power outage or earthquake, which is a real consideration in the Puget Sound region
• Outage of a SaaS provider or internet carrier

Step 1: Inventory critical systems and data

Start by listing everything the business depends on, not just servers. A typical small-business inventory includes:

• Microsoft 365 or Google Workspace (email, OneDrive, SharePoint, Teams)
• Line-of-business applications such as accounting, practice management, CRM or donor management
• File shares or NAS devices still on-site
• Cloud virtual machines and databases in Azure, AWS or Google Cloud
• Network configuration for firewalls, switches and Wi-Fi controllers
• Identity systems, including Entra ID and any on-premises Active Directory
• Phone system configuration and website or DNS records

For each item, record the owner, where the data lives and whether it is currently backed up.

Step 2: Assess business impact

For each system, ask two questions: how long can we operate without it, and how much recent data could we afford to re-enter or lose? Answer with the people who use the system, not just IT. A payroll system may tolerate a day of downtime most of the month but almost none on payday.

Step 3: Set RTO and RPO by tier

Group systems into tiers rather than setting unique targets for each one. The table below shows a typical starting point; your values should come from the impact assessment.

Shorter RTO and RPO targets cost more, so this conversation is a business decision about acceptable risk.

Step 4: Design the backup architecture

Follow the 3-2-1 rule: keep three copies of data, on two different types of storage, with one copy offsite. Many organizations now extend this to 3-2-1-1-0: one copy immutable or offline, and zero errors in verified restores.

Key design decisions:

• Immutability or isolation. At least one copy should be immutable or stored in a system that your everyday admin accounts cannot delete. Ransomware operators routinely target backups first.
• Separate credentials. Backup consoles should use separate accounts with MFA, not the same global admin used for Microsoft 365.
• SaaS backup. Back up Microsoft 365 or Google Workspace with a dedicated tool. Retention policies help with compliance, but they are not a substitute for an independent, restorable copy.
• Endpoints. Redirect Documents and Desktop to OneDrive with Known Folder Move so user files on laptops are captured, then back up OneDrive itself.
• Servers and cloud workloads. Use image-level backups for remaining servers. For cloud VMs, native services such as Azure Backup or AWS Backup provide policy-based protection, and cross-region copies add resilience.
• Configuration. Export firewall and switch configurations after every change and store them with your documentation.

If you still run a server room, consider whether disaster recovery to the cloud, or moving the workload entirely, is simpler than maintaining a second site. Connectivity for cloud-based recovery is covered in hybrid cloud networking.

Step 5: Write the recovery runbook

The runbook is the document people will use under stress, so keep it short and specific. Include:

1. Declaration criteria. Who can declare a disaster and trigger the plan.
2. Contact list. IT provider, internet carrier, key vendors, cyber insurer, legal counsel and leadership, with phone numbers stored outside the systems that might be down.
3. Recovery order. Identity first, then communications, then Tier 1 applications, then everything else.
4. Step-by-step procedures for each Tier 1 system, including where backups live and how to restore them.
5. Communication templates for staff, clients, donors and, where required, regulators.
6. Ransomware-specific steps. Isolate affected devices, preserve evidence, contact your insurer before engaging outside responders if your policy requires it, and restore only from known-clean backups.

Store a copy of the runbook offline or in a separate account so it is reachable if your main tenant is compromised.

Step 6: Test and maintain the plan

An untested backup is an assumption. Build a recurring schedule:

Update the plan whenever you add a system, change providers or move offices.

How do nonprofits approach disaster recovery?

Nonprofits should prioritize donor, client and program data, and consider grant or contract obligations that require data retention or continuity of services. Many nonprofits already run on donated Microsoft 365, which simplifies DR because email and files are cloud-hosted, but they still need independent backup and a plan for restoring access if accounts are compromised.

Next steps

Begin with the inventory and impact assessment; the rest of the plan follows from them. Pair this work with the IT security checklist and, if you are moving data to the cloud, the data migration guide. Desai InfoTech can help you design, implement and test a BDR plan; contact us to get started.