Backup is a copy of your data. Disaster recovery is the tested plan and equipment that get people working again after a loss. Business continuity is how the company keeps operating meanwhile. On backup vs disaster recovery, a small business needs both, sized by how much data it can afford to lose and how long it can be down.
What is the difference between backup, disaster recovery and business continuity?
A backup is a second copy of data, stored somewhere else, from which the original can be rebuilt. It answers one question: can we get the file, the mailbox or the database back?
Disaster recovery is everything else needed to turn that copy into a working business: somewhere to restore to, the order in which systems come back, who does what, and proof that it has been done before. A backup you have never restored is a hope, not a plan.
Business continuity is wider still. It is how the company keeps serving customers while IT is being recovered: who answers the phone, how invoices go out, which manual process stands in for the system for a day. Most of it is not technology at all.
The distinction matters because vendors sell "backup" and owners hear "we are covered." The gap between those two is where businesses get hurt.
What are RPO and RTO, with a worked example for a 15-person office?
RPO, the recovery point objective, is how much work you are willing to lose, measured in time since the last good copy. RTO, the recovery time objective, is how long you can be down before the loss stops being an inconvenience and becomes a business problem. These two numbers are the specification for everything else; without them, every backup product looks fine.
Take a 15-person professional office: an accounting system on a small server, documents in Microsoft 365, and a shared drive of client files.
- Nightly backup of the server to a local drive. If the server fails at 3 p.m., everything entered since last night is gone: an RPO of up to a working day. If the fix means ordering a replacement server and reinstalling, the RTO is measured in days. Fifteen people re-keying a day of entries and then idling for a week is the real cost, and most owners have never put a figure on it.
- Hourly image backup to an appliance that can run the server as a virtual machine, plus a cloud copy. An RPO of an hour. An RTO of an hour or two to boot the image on the appliance, longer if the office itself is gone and you are standing it up in the cloud.
- Microsoft 365 data. Deleted email and documents are recoverable from the service for a limited window, but a backup with its own copy gives you a defined RPO and a restore path that does not depend on what the service happens to retain.
Different systems deserve different numbers. The accounting system might need an RPO of an hour and an RTO of half a day; the archive of old marketing photos could tolerate a week on both. Setting the numbers per system is what stops you paying for the fastest recovery on data that does not need it.
What is 3-2-1 and why does an immutable or offline copy matter?
The 3-2-1 rule is a plain minimum: three copies of your data, on two different kinds of storage, with one copy somewhere else. The working copy on the server, a backup on the appliance and a second backup in the cloud satisfies it. The modern addition is a fourth condition: one copy must be immutable or offline, meaning nobody with your admin credentials can delete or encrypt it before its retention period ends.
That condition exists because of how ransomware now works. Attackers spend time inside the network before encrypting anything, and they look for the backups first. If the backup server is on the domain, the backup share is mapped on a workstation, or the cloud backup account uses the same admin login as everything else, those copies are encrypted or deleted along with the originals. CISA's #StopRansomware Guide says to maintain offline, encrypted backups of critical data precisely because many ransomware variants attempt to find and then delete or encrypt accessible backups, and it notes that some cloud vendors offer immutable storage for the purpose. Endpoint detection from tools such as SentinelOne or Huntress buys time at the front of an attack; the immutable copy is what you fall back on when the time runs out. How the two fit together is covered under ransomware detection and recovery.
Why are Microsoft 365 and Google Workspace not backed up for you?
Because the provider's job is to keep the service running, not to keep your copy of the data. They do not protect you from the things that actually delete data: a user emptying a folder, an administrator removing a departed employee's license and the mailbox with it, a ransomware strain that encrypts files on a laptop and lets the sync client push them to the cloud, or an attacker in a compromised account quietly purging mail. The built-in retention features help, but they have limited windows, they are configured by the same admin an attacker may have taken over, and restoring a whole mailbox or site as it looked last Tuesday is not what they are built for. A separate Microsoft 365 backup keeps an independent copy with its own credentials and its own retention. The same applies to Google Workspace and to any other SaaS application the business depends on.
What does a "tested restore" mean and how often should you do one?
A tested restore means you actually recovered something, timed it, checked that it was usable, and wrote that down. Three levels:
- File and mailbox restores, a few items picked at random, roughly monthly. Cheap, and they catch the silent failures: the job that reports success but has been backing up an empty folder for six months.
- A full server or system restore to isolated hardware or an isolated cloud environment, at least annually and after any significant change. This is the only way to learn the real RTO.
- A disaster recovery exercise, where the people who would do the recovery walk through it against a scenario (the building is inaccessible; the domain is encrypted) and find the gaps in the documentation. NIST's Contingency Planning Guide, SP 800-34 Rev. 1, builds plan testing, training and exercises into the contingency planning process, and the lesson transfers to a small business unchanged: a plan that has not been exercised will fail in a way you have not anticipated.
CISA's ransomware guide makes the same demand, to regularly test the availability and integrity of backups in a disaster recovery scenario. If your provider cannot show you a restore log, you do not yet know whether you have backups.
What gets you back from each kind of failure?
| Failure | What gets you back | How long, realistically |
|---|---|---|
| A deleted or overwritten file | Version history in OneDrive or SharePoint, or a file-level restore from backup | Minutes, if versioning and backup are both on |
| A dead laptop | A spare device, cloud-synced files and a profile that re-creates itself on sign-in | Hours, as long as nothing lived only on the laptop |
| A server hardware failure | An image backup booted on the backup appliance or in the cloud | Hours with an appliance; days if you are waiting for replacement hardware |
| Ransomware across the network | An immutable or offline copy, clean rebuilt systems, and a tested order of restoration | Days, because every system must be rebuilt clean before data is restored |
| Office fire or flood | An offsite copy, cloud-hosted recovery, and a continuity plan for working from elsewhere | Days for IT; the continuity plan decides whether customers notice |
| A compromised Microsoft 365 or Google account | Session revocation and a password reset, then a SaaS backup to restore purged mail and files | Hours to secure; restoring the data depends on having a backup |
What should you ask a backup and disaster recovery provider?
- What RPO and RTO do you commit to, per system, in writing?
- Where are the copies, and is at least one immutable or offline, with credentials separate from our admin accounts?
- Who holds the encryption keys, and what happens if we leave?
- How often do you test restores, and can we see the last six months of logs?
- Does it cover Microsoft 365 or Google Workspace, and which parts: mail, OneDrive, SharePoint, Teams?
- If the office is gone, where does the server run, and who on your team has done that before?
- Is a restore included or billed per incident?
- Will you run a disaster recovery exercise with us once a year?
A provider who answers these quickly and in writing is one to keep; these are the commitments behind backup and disaster recovery as a managed service. Recovery is the last line, though. CISA's Secure Our World steps, recognizing phishing, strong passwords, MFA and software updates, are the front line that keeps you from needing the plan at all.
Frequently asked questions
Is OneDrive or Dropbox sync a backup?
No. Sync replicates whatever happens to the file, including deletion and encryption, to every copy. Version history softens that but has limits. A backup is a separate copy with its own retention that sync cannot touch.
Do we need disaster recovery if everything is already in the cloud?
You still need a plan, but it changes shape. The server-rebuild question goes away; the questions that remain are how you restore SaaS data after deletion or account compromise, how staff work if the internet or the identity provider is down, and who is authorized to do what.
How long should we keep backups?
Long enough to cover the slow failures, like a corruption or a deletion nobody notices for months, and long enough to satisfy whatever regulators and contracts apply to your industry. Set retention per system from those two answers rather than accepting a default.
What is an immutable backup?
A copy that cannot be altered or deleted by anyone, including your own administrators, until a set retention period has passed. It is the control that keeps a ransomware operator with admin credentials from erasing your way back.
Is a NAS in the office enough?
It is one copy on one site, which fails the 3-2-1 rule on its own. Pair it with an offsite copy and make sure the NAS backup credentials are not the same ones an attacker would get by compromising a workstation.