Business data backup: the short answer
Business data backup means keeping independent copies of important data, separate from the systems you run every day, so you can restore after user error, hardware failure, ransomware or a fire. Disaster recovery (DR) is the plan and procedure for bringing systems back from those copies within the downtime and data loss the business can accept.
For a small or mid-sized business, a sensible minimum has four parts: follow the 3-2-1 rule, keep at least one offline or immutable copy, set RPO/RTO targets per system, and test restores on a schedule. This guide walks through each part with a tier table and a runbook checklist you can use straight away. If you are still choosing where systems should run, see choosing cloud architecture by operational constraints.
The 3-2-1 rule and the 3-2-1-1-0 variant
The Data Backup Options paper from US-CERT (now part of CISA) sets out the 3-2-1 rule: keep 3 copies of any important file (1 primary and 2 backups), keep them on 2 different media types to protect against different hazards, and store 1 copy offsite. CISA's backup guidance for small and medium businesses still calls 3-2-1 a trusted guideline and recommends combining on-site and remote backups.
The 3-2-1 rule predates the ransomware era, so many backup vendors extend it to 3-2-1-1-0: add 1 immutable or air-gapped copy, and 0 errors when restores are verified. This is an industry convention rather than a standard issued by an agency, but its core matches CISA's advice on offline copies and restore testing.
| Element | Meaning | Common approach (illustrative example) |
|---|---|---|
| 3 copies | 1 live copy + 2 backups | Server or app + copy on a NAS + copy in the cloud |
| 2 media types | No single cause can destroy every copy | Local disk plus cloud object storage |
| 1 offsite | Survives fire, flood or theft at the office | Cloud in another region, or a drive rotated to another site |
| +1 immutable/offline | Ransomware cannot delete or encrypt it | Object lock, a disconnected removable drive, a separate backup account |
| 0 errors | The copy is proven to restore | Restore drills with written results |
RPO and RTO: the two numbers that drive the design
In the NIST glossary (from SP 800-34 Rev. 1), the Recovery Point Objective (RPO) is the point in time to which data must be recovered after an outage; in plain terms, how much data, measured in time, you can afford to lose. The Recovery Time Objective (RTO) is the overall time a system's components can stay in the recovery phase before the mission or business process is harmed; in plain terms, the longest outage you can accept.
Illustrative example: if your sales system is backed up nightly at 23:00 and fails at 16:00 the next day, you could lose about 17 hours of data. If that is unacceptable, the RPO must be shorter, which means more frequent backups or continuous replication. Shorter RPO and RTO cost more and add complexity, so not every system needs the top tier. CISA also advises scheduled recovery tests to refine RPOs and RTOs against business needs.
| Tier | Example systems | Suggested RPO | Suggested RTO | Typical approach |
|---|---|---|---|---|
| Tier 1 – critical | Sales, payments, customer database | Minutes to 1 hour | A few hours | Continuous or hourly database backup, copy in another region, pre-built standby environment |
| Tier 2 – important | Accounting, HR, email, shared documents | About 24 hours | 1–2 days | Nightly backup, immutable cloud copy, restore from system images |
| Tier 3 – supporting | Old document archives, test environments | Days to 1 week | Several days | Weekly backup, cold storage |
Setting RPO/RTO in a single working session
- List the systems and data you use (CISA suggests starting with a simple inventory spreadsheet). The same inventory underpins data governance.
- For each system, ask the business owner: how long can it be down before the damage is unacceptable, and how many hours of data could not be re-entered?
- Assign a tier, then check whether the current backup schedule actually meets those numbers.
- Write down who decides to start a recovery and the order in which systems are restored.
Ransomware: why you need an offline or immutable copy
The #StopRansomware Guide, published by CISA with the FBI, NSA and MS-ISAC, recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity in a disaster recovery scenario. The reason it gives is direct: many ransomware variants try to find and then delete or encrypt accessible backups, making restoration impossible unless the ransom is paid.
The same guide suggests keeping "golden images" of critical systems for fast rebuilds, keeping infrastructure-as-code templates backed up offline, enabling versioning on storage, and considering cloud-to-cloud or multi-cloud backups in case every account with one vendor is affected. CISA also cautions that immutable storage should be used carefully, because it does not meet some compliance criteria and misconfiguration can impose significant cost.
- Separate credentials: backup admin accounts are not shared with production admin accounts, and they use multi-factor authentication.
- Turn on object lock or a non-deletable retention policy for a defined period on at least one copy.
- Keep one copy truly disconnected where practical, for example a removable drive rotated on a schedule.
- After an attack, rebuild on a clean network and check backups before reconnecting, as CISA advises, to avoid reinfection.
Does your SaaS back up your data? The shared responsibility model
Many businesses assume data in Google Workspace or Microsoft 365 is safe because it is "in the cloud". The vendors' own documents show why platform availability and backing up your data are different things.
Google Cloud's Google Workspace data protection implementation guide (December 2020) describes a shared responsibility model: the customer is responsible for the security of components it provides or controls, such as the content put into the services and access control for its users. Under information backup, it advises customers to have a backup and recovery policy and to define RTO and RPO for essential operations.
On the Microsoft side, the Shared responsibility in the cloud page on Microsoft Learn states that for all cloud deployment types, you own your data and identities and are responsible for protecting them. Microsoft's Microsoft 365 Backup best-practices paper asks customers to think through an operational recovery plan and recommends either the native Microsoft 365 Backup offering or a recognised third-party application built on the Microsoft 365 Backup Storage platform. Note that the same paper says Microsoft generally does not recommend taking large quantities of data outside Microsoft 365 and urges careful thought about security, compliance and privacy; Microsoft 365 Backup keeps copies inside the Microsoft 365 boundary on append-only storage. Each business therefore has to decide how "independent" its copy needs to be, based on its own risks (for example a compromised admin account) and compliance needs.
| Area | SaaS provider | Your business |
|---|---|---|
| Physical infrastructure, data centres, service availability | Yes | No |
| Content (email, files, spreadsheets) | Stores it and runs the platform | Owns it and is responsible for protecting it |
| Identity, permissions, multi-factor authentication | Provides the tools | Configures and manages them |
| Backup and recovery policy, RPO/RTO | Provides features (depending on plan) | Decides, implements and tests |
Recycle bins, version history and retention are not backups
Recycle bins, version history and legal-hold tools (such as Google Vault) help with small mistakes and retention needs, but they live in the same account and platform as the original data. If an admin account is taken over or bad changes sync everywhere, you still need an independent copy in the spirit of 3-2-1. Exact retention periods vary by plan; check the provider's current documentation rather than relying on numbers passed around.
Restore testing: an untested backup may not restore
Both CISA's SMB guidance and the #StopRansomware Guide stress regular testing. A backup job that reports "success" only shows data was written; it does not prove the data reads back correctly, that applications start, or that the team knows the steps.
A restore drill should pick a backup at random (not only the newest), restore it into an isolated environment, time it against the RTO, have business users check the data, and record what needs fixing. How often to drill depends on the system's tier and how fast the infrastructure changes; what matters is a schedule, an owner and a written record.
When an outside partner runs your systems
If an external provider operates your systems, have the contract state the scope of data backed up, where copies are kept, retention periods, who holds the encryption keys, and the restore-test schedule. For projects EYC delivers, restore tests are carried out on a schedule agreed in the contract.
Disaster recovery runbook checklist for small businesses
A runbook is a step-by-step document the on-call person can follow under pressure. The table below is a minimum frame; keep one printed copy and one copy outside your main systems, because during an incident your internal wiki may be unreachable too.
| Phase | What should be ready | In place? |
|---|---|---|
| Prepare | System inventory with tiers, RPO/RTO and business owners | |
| Prepare | Where each copy lives, how to reach it, who holds encryption keys and break-glass accounts | |
| Prepare | Out-of-band contact list (for when internal email is down) | |
| Detect | Criteria for declaring an incident and who may declare it | |
| Contain | Steps to isolate affected machines; avoid careless shutdowns that destroy forensic evidence | |
| Recover | Restore order by tier; clean environment; verify backups before use | |
| Confirm | Business users check data; reset passwords and revoke old access | |
| After | Lessons-learned record, runbook update, review of legal notification duties (see Vietnam's Personal Data Protection Law 2025) |
A 30-day plan starting from zero
Illustrative example for a business with a few dozen people using accounting software, a sales application and a cloud office suite:
- Week 1: inventory data and systems, assign tiers, agree RPO/RTO with leadership.
- Week 2: turn on automated backups for every system following 3-2-1; add independent backup for SaaS data.
- Week 3: set up at least one immutable or offline copy; separate backup admin accounts and enable multi-factor authentication.
- Week 4: write the runbook, run a restore drill for one tier-1 and one tier-2 system, record results and fix what you find.
Frequently asked questions
What is the 3-2-1 backup rule?
Keep 3 copies of your data (1 primary, 2 backups), on 2 different media types, with 1 copy offsite. The rule is set out in the US-CERT/CISA Data Backup Options paper.
What is the difference between RPO and RTO?
RPO is how much data, measured in time, you can accept losing (the point you restore back to). RTO is how long a system can be down before the damage is unacceptable. The source definitions are in the NIST glossary, based on SP 800-34 Rev. 1.
Do Google Workspace and Microsoft 365 data need a separate backup?
It is advisable. Under the shared responsibility model in Google's and Microsoft's documentation, the provider handles infrastructure and availability, while the customer is responsible for its data, identities and backup and recovery policy.
What is an immutable backup?
A copy that cannot be changed or deleted during a defined retention period, even by an administrator account. It protects against ransomware that hunts for and deletes backups. CISA notes it must be configured carefully because misconfiguration can be costly.
How often should we test restores?
There is no single number for every business. CISA advises scheduled testing; the frequency should follow the system's tier, how fast your infrastructure changes and any contractual requirements. What matters is a schedule, an owner and a written record.
Does a small business need a disaster recovery plan?
Yes, but it need not be complex. A system inventory, RPO/RTO per tier, 3-2-1 backups with one immutable copy, and a runbook that has been rehearsed are a reasonable minimum.