Backup and disaster recovery is one of those IT categories where every vendor claims comprehensive protection and many SMBs discover the gaps only after a failure. Ransomware that encrypts both primary systems and connected backup destinations. A "tested" recovery that takes four days instead of the promised four hours. Backup jobs that complete with errors no one monitors. This guide cuts through the marketing to explain what a credible SMB backup and DR posture actually requires, what vendors sell, and how to evaluate whether what you're buying matches what you need.
RTO and RPO: The Two Numbers That Define Your DR Plan
Every disaster recovery conversation should begin with two numbers. If your DR vendor has not asked you for these numbers, they are not selling you a plan — they are selling you a product.
Recovery Time Objective (RTO): How long can your business operate with a critical system unavailable before the impact becomes unacceptable? For a manufacturing plant's production scheduling system, the answer might be four hours. For a law firm's document management system, it might be 24 hours. For a retail POS system on a Saturday, it might be 30 minutes. The RTO is a business decision, not a technology decision — and it drives your entire DR architecture.
Recovery Point Objective (RPO): How much data can you afford to lose? If your backup runs at midnight and your server fails at 11pm, you've lost 23 hours of data. Is that acceptable? For accounting data in a month-end close, probably not. For a marketing file server with assets also in cloud storage, perhaps. The RPO determines how frequently your backups must run.
These two numbers together drive your backup frequency, storage architecture, and the type of recovery technology you need. An RTO of four hours and an RPO of one hour requires very different technology than an RTO of 24 hours and an RPO of 24 hours.
The Three Types of Backup Technology
Traditional backup: A scheduled job copies data to a backup destination — usually an on-premises NAS device, tape, or cloud storage. Recovery requires restoring files to a system, which can take hours to days depending on data volume. Traditional backup meets long RTO requirements cheaply. It is inadequate for anything under an 8-hour RTO.
Image-based backup with instant recovery: Instead of backing up individual files, an image-based backup captures the entire state of a system — operating system, applications, and data — as a snapshot. Modern platforms (Veeam, Datto, Acronis, and others) can boot these images directly in a virtual machine, enabling "instant recovery" where a failed physical server can be replaced with a VM running the snapshot in under an hour. This is the minimum appropriate technology for RTOs under 8 hours.
Continuous data protection (CDP): Instead of scheduled backup jobs, CDP captures every write operation to disk in near-real time, enabling recovery to a point minutes before a failure. CDP products can achieve RPOs under 15 minutes. This technology is appropriate for databases and applications where data loss of more than an hour is unacceptable. It is also the most expensive tier.
The Air Gap: Why Your Backup Destination Matters
One of the most common backup failures in ransomware incidents is the backup being encrypted along with the primary data. If your backup destination is a network share on the same domain as your production systems, ransomware that has domain admin credentials can encrypt it in the same attack.
An air-gapped backup is one that is not accessible from the same network as the compromised system. Options range from offline tape (completely air-gapped, but slow recovery) to immutable cloud storage (backups written to cloud storage with immutability policies that prevent deletion or modification for a defined period, even by admin credentials) to a physically separate appliance with access controls preventing bidirectional write from the production network.
For any SMB facing ransomware risk — which is essentially all SMBs — at least one copy of your backup should be in immutable cloud storage or an otherwise air-gapped medium. The 3-2-1 rule (three copies, two media types, one offsite) is the minimum baseline, and the "offsite" copy should be immutable or physically offline.
What MSPs Usually Sell vs What You Need
Standard MSP backup offerings often include backup to a local appliance (sometimes plus cloud replication), monthly or quarterly recovery testing, and email alerts for backup job status. This is a reasonable baseline for companies with RTOs over 24 hours and RPOs over 24 hours.
Where the gaps typically appear: backup jobs that complete with warnings go unmonitored because no one is reading the alert emails. Recovery testing is scheduled but not actually performed or is performed only at file level, not full-system. The cloud replication is to the MSP's infrastructure, which creates dependency on the MSP's own availability and business continuity during a crisis.
When evaluating your MSP's backup offering, ask: When was the last full-system recovery test performed, and what was the actual measured recovery time? Who monitors backup job alerts 24/7? If your MSP is also impacted by a regional disaster, where is your data and who manages the recovery?
SaaS Data Is Not Automatically Backed Up
A common assumption that costs companies data: Microsoft 365 and Google Workspace are backed up by Microsoft and Google. This is a misunderstanding of those platforms' data retention architecture.
Microsoft 365 retains deleted items in the Recycle Bin for 30 days by default (configurable). It does not provide point-in-time recovery for Exchange Online to an arbitrary past date. If a malicious insider deletes a significant volume of email and the deletion isn't caught within the retention window, the data is gone. Similar limitations apply to SharePoint and OneDrive.
Third-party SaaS backup products — Veeam Backup for Microsoft 365, Backupify, Druva, and others — provide true backup with point-in-time recovery for 365 and Google Workspace data. For companies where Microsoft 365 or Google Workspace holds business-critical data (which is essentially all of them), a third-party backup for SaaS data is a separate requirement from your server/endpoint backup strategy.
Frequently Asked Questions
What is the difference between backup and disaster recovery?
Backup is the creation of copies of data. Disaster recovery is the process of restoring systems to operational status after a failure event, using backup data and a tested recovery procedure. A backup without a tested recovery procedure is not a DR plan. Many companies have backups; far fewer have validated DR plans with documented RTOs and actual recovery test results.
How often should you test your disaster recovery plan?
At minimum, a full-system recovery test annually, with individual-system recovery tests quarterly. If your business has significant compliance requirements (HIPAA, SOC 2), documented evidence of DR testing is often required for audits. After any major infrastructure change — server migration, cloud adoption, new backup software — test recovery immediately.
What is immutable backup storage?
Immutable storage is backup data written with a lock policy that prevents modification or deletion for a defined period, even by administrative credentials. Cloud providers (AWS S3 Object Lock, Azure Immutable Blob Storage, and others) and purpose-built backup appliances support immutability. It is the primary technical control against ransomware encrypting or deleting backup data.
What backup solution is appropriate for a 50-person company?
A reasonable baseline for a 50-person company: image-based backup for all servers (physical and virtual) with instant-recovery capability; Microsoft 365 or Google Workspace backup via a third-party product; at least one backup copy in immutable cloud storage; monthly recovery testing documented in writing; and RTO/RPO defined for critical systems. This can be delivered through a managed backup service from an MSP or directly through cloud-native backup products.
← What a vCISO Really Costs | When to Outsource IT vs Hire Internal IT →