Data Backup Strategy: The 3-2-1 Rule and How to Apply It

A good data backup strategy keeps at least three copies of your important data, on two different types of storage, with one copy kept offsite. That is the 3-2-1 rule. To survive ransomware, you also need at least one copy that attackers cannot change or delete, and you need proof, from real restore tests, that your backups actually work.

Key takeaways

• The 3-2-1 rule means 3 copies of data, on 2 different media or devices, with 1 copy offsite.
• The 3-2-1-1-0 variant adds 1 offline or immutable copy and 0 errors in verified restore tests.
• Most organizations combine periodic full backups with daily incremental or differential backups to balance speed, storage and restore time.
• Ransomware targets reachable backups, so keep at least one copy offline or locked and protect backup accounts with multi-factor authentication.
• Cloud and SaaS providers keep their platforms running, but restoring your deleted or encrypted data is usually your job.

What is the 3-2-1 backup rule?

The 3-2-1 rule is a simple pattern for keeping data recoverable: keep 3 copies, on 2 different types of storage, with 1 copy offsite. The UK National Cyber Security Centre (NCSC) describes it as "at least 3 copies, on 2 devices, and 1 offsite" and calls it the most common approach to keeping copies logically separated.

What each number protects against:

• 3 copies: your live production data plus two backups. If one backup is corrupt, you still have another.
• 2 types of storage: for example, a disk-based backup appliance and cloud object storage, or disk and tape. A single hardware fault or firmware bug is less likely to hit both.
• 1 offsite copy: a copy in another building, region or cloud account, so a fire, flood or site-wide outage does not take every copy at once.

The rule is a starting point, not a full strategy. The NCSC notes that 3-2-1 on its own "does not require any backup location to be offline." That gap matters a great deal once ransomware enters the picture.

What do the 3-2-1-1-0 and other variants add?

The 3-2-1-1-0 variant keeps the original rule and adds two safeguards: one copy that is offline, air-gapped or immutable, and zero errors when you verify and test restores. It closes the two biggest gaps in plain 3-2-1: backups that attackers can reach, and backups nobody has checked.

A few terms are worth defining plainly:

• Offline (air-gapped) backup: a copy with no live network connection to your systems, such as a disconnected drive or tape stored away from the data center.
• Immutable backup: a copy that, once written, cannot be changed or deleted until a set retention date passes, even by an administrator. Cloud "object lock" and write-once storage are common ways to do this.
• Logical air gap: a cloud copy that stays online but is cut off by separate credentials, strict access rules and immutability, so a compromised production account cannot touch it.

Full, incremental or differential: which backup type should you use?

Most organizations use a mix: a full backup on a regular schedule, with incremental or differential backups in between. The right mix depends on how fast you need to restore and how much storage and backup time you can afford.

• Full backup: copies all selected data every time. It is the simplest to restore but the slowest to create and the largest to store.
• Incremental backup: copies only what changed since the last backup of any kind. It is fast and small, but a restore needs the last full backup plus every incremental since.
• Differential backup: copies everything that changed since the last full backup. It grows each day, but a restore needs only the full backup and the latest differential.

Backup type	What it copies	Backup speed and size	Restore speed	Typical use
Full	All selected data	Slowest, largest	Fastest, one set	Weekly or monthly baseline
Incremental	Changes since the last backup of any type	Fastest, smallest	Slowest, full plus every incremental	Daily or hourly between fulls
Differential	Changes since the last full backup	Medium, grows until next full	Medium, full plus latest differential	Daily when restore speed matters
Synthetic full	A full built from existing full and incremental copies	Low load on production systems	Fast, behaves like a full	Large data sets with short backup windows

Tie your schedule to your recovery targets. Your recovery point objective (RPO) is how much data you can afford to lose, measured in time. Your recovery time objective (RTO) is how long a system can be down. Our guide to disaster recovery plans, RTO and RPO explains how to set both. As the NCSC puts it, the more often you back up, the less data you lose if you are forced to recover. NIST's Cybersecurity Framework (CSF) 2.0 gives the same idea as an example: back up critical data continuously or in near real time, and other data on agreed schedules.

How do immutable and offline backups protect against ransomware?

They give you a clean copy that ransomware cannot encrypt or delete, so you can recover without paying. Attackers know this, so they often hunt for backup systems first.

The joint #StopRansomware Guide from CISA and its partners tells organizations to "maintain offline, encrypted backups of critical data" and explains that keeping backups offline is important because many ransomware variants try to find and delete or encrypt accessible backups. The guide also recommends keeping "golden images" of critical systems (clean, preconfigured system builds you can redeploy), enabling delete protection or object lock on storage, and turning on versioning so earlier copies of files survive.

The guide adds a caution: immutable storage does not meet compliance criteria for certain regulations, so check with legal and compliance before you lock data for long periods.

Cloud storage cannot be unplugged, so the NCSC suggests making it "digitally" offline instead:

• Protect every account that can reach backups with strong passwords and multi-factor authentication (MFA).
• Keep backup clients without valid credentials when storage is not in use, and keep the number of clients small.
• Allow only authorized clients to create or append backups, and deny connections while the storage is "cold."

Treat the backup system as a high-value target. Give it separate administrator accounts, apply least privilege through your identity and access management (IAM) program, and never join backup servers to the same domain an attacker could take over. These steps fit naturally into a zero trust architecture, where no user or device is trusted by default.

How often should you test restores, and how long should you keep backups?

Test restores on a regular schedule, at least once a year for every type of data and more often for critical systems, and set retention based on business, legal and ransomware recovery needs. A backup you have never restored is only a hope.

NIST CSF 2.0 includes a specific outcome, PR.DS-11: "Backups of data are created, protected, maintained, and tested." Its implementation examples include testing backups and restores for all types of data sources at least annually, and storing some backups offline and offsite. CISA's guide asks you to regularly test the availability and integrity of backups in a disaster recovery scenario.

Good restore testing goes beyond "the job finished":

• Restore individual files, whole virtual machines and full applications, not just one easy sample.
• Time each restore and compare it with your RTO.
• Include restores from the offline or immutable copy, since that is the one you will need after ransomware.
• Run at least one test per year as part of a wider exercise with your incident response plan.

Retention is how long you keep each backup before it expires. Set it in layers, for example daily copies kept for weeks, monthly copies kept for a year, and yearly copies kept as long as records rules require. Keep enough history to go back before an attacker first got in, because intruders often sit quietly for some time before they encrypt. Balance this against privacy rules on deleting personal data. Neither CISA nor the NCSC sets a single retention period, so agree yours with legal and compliance.

Who is responsible for backing up cloud and SaaS data?

In most cases, you are. Cloud and SaaS providers are generally responsible for keeping their infrastructure running, while the customer remains responsible for its own data, including recovery from accidental deletion, malicious insiders and ransomware that syncs into the cloud.

This is the shared responsibility model. Read each contract and service description closely. Many services keep deleted items only for a limited time, and native versioning is not the same as an independent backup. The NCSC's recovery rule asks you to confirm that your provider can restore earlier versions and recover deleted data, which it notes may only be possible "for a limited time after it was deleted."

• List every SaaS platform that holds business records: email, file sharing, CRM, HR, payroll and finance systems.
• Find out what the provider backs up, for how long, and how you request a restore.
• Where native protection falls short, back up to a separate account, region or provider. CISA suggests considering a multi-cloud approach for cloud-to-cloud backups to avoid vendor lock-in.
• If a managed service provider runs your backups, put responsibilities, testing and restore times in writing.

For broader controls on cloud data, see our article on ways to achieve data security in the cloud.

How do you build a backup strategy step by step?

Start from what the business needs to run, set recovery targets, then design, protect and test backups to meet them.

1. Inventory your data and systems. List applications, databases, file shares, endpoints and SaaS platforms, and name an owner for each.
2. Rank by business impact. Decide which systems you must restore first and assign each an RPO and RTO.
3. Choose backup types and schedules. Match full, incremental or differential schedules to each RPO.
4. Apply 3-2-1-1-0. Map where each of the three copies lives, which two storage types you use, which copy is offsite and which is offline or immutable.
5. Secure the backup system. Encrypt backups, use separate admin accounts with MFA, restrict network access and enable deletion protection.
6. Set retention rules. Agree retention periods with legal, compliance and records teams, and document them.
7. Cover cloud and SaaS. Confirm what each provider does and fill the gaps with independent backups.
8. Keep golden images and runbooks. Store clean system builds and step-by-step restore instructions where you can reach them during an outage, including on paper.
9. Monitor every job. Alert on failed or skipped backups and review reports weekly.
10. Test, record and improve. Run scheduled restore tests, record results against RTO and RPO, fix what failed and repeat.

Common mistakes in data backup strategy

• Treating sync as backup. File sync and replication copy deletions and encrypted files just as fast as good ones.
• Keeping every copy online. If one stolen admin account can reach every copy, you effectively have one copy.
• Never testing restores. Teams often find missing data, expired encryption keys or slow restores only during a real crisis.
• Ignoring SaaS data. Assuming the provider backs up your records leaves email, files and business data exposed.
• Short retention. If you keep only a few days of history, you may find every copy already contains the attacker's foothold.

Frequently asked questions

Is the 3-2-1 rule still enough?

It is a sound base but not enough on its own against ransomware, because it does not require an offline copy. Add at least one offline or immutable copy and regular restore testing, which is what the 3-2-1-1-0 variant describes.

Does cloud storage count as an offsite copy?

Yes, a copy in a separate cloud region or account can be your offsite copy. To also serve as your protected copy, it needs separate credentials, MFA, tight access rules and immutability or deletion protection.

How often should you back up data?

Back up as often as your RPO requires. Critical systems may need continuous or hourly backups, while less critical data may be fine with daily backups. NIST CSF 2.0 gives backing up critical data continuously or in near real time as an example.

Do backups help with cyber insurance?

Often, yes. Insurers commonly ask about backups, MFA and incident plans when they assess risk. Our guide to cyber insurance for small businesses covers what to expect.

What to do next

Pick your three most critical systems this week. For each one, write down where every backup copy lives, whether any copy is offline or immutable, and the date of the last successful restore test. Any gap you find is your first project.

Then schedule a restore test from your protected copy, time it against your RTO, and turn the ten steps above into a short policy with named owners.

Sources

• CISA and partners: #StopRansomware Guide
• NIST: The Cybersecurity Framework (CSF) 2.0
• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
• UK NCSC: Offline backups in an online world
• UK NCSC: Backing up your data

Last reviewed: November 2026.