The 3-2-1 backup rule is a data protection guideline that calls for three copies of the data, on two different types of storage, with one copy kept offsite. In backup & recovery, it is the most widely used baseline for deciding how many backups a server, a business or a household needs and where they should live.
The rule does not prescribe software, schedules or retention periods. It describes a distribution of copies designed so that no single event, whether a disk failure, an accidental deletion, a fire or a ransomware attack, can destroy every copy at once. Its strength lies in being simple enough to audit in a minute yet strict enough to prevent the most common causes of permanent data loss.
What each number in the 3-2-1 rule means
Each digit addresses a different category of risk. Together they eliminate single points of failure across hardware, media and location, which is why the rule has remained relevant through several generations of storage technology.
| Part | Requirement | Risk it addresses |
|---|---|---|
| 3 copies | The production data plus two backups | Failure or corruption of any one copy |
| 2 media types | Backups on at least two different storage technologies | Failures shared by one media type or device |
| 1 offsite copy | At least one copy in a separate location | Fire, flood, theft or site-wide outage |
Three copies means the live data counts as one of them, so the rule asks for two independent backups. Two media types originally meant, for example, internal disks and tape; today it is often interpreted more broadly as two independent storage systems, such as a local backup appliance and cloud object storage, because two disks in the same server share the same controller, power supply and failure risks.
One offsite copy must be far enough away that a disaster affecting the primary site cannot reach it. A backup drive in the same rack does not qualify, and neither does a second building on the same flood plain. Cloud storage in another region, a remote data center or rotated media stored elsewhere are the usual answers.
Why copies alone are not enough
The 3-2-1 rule counts copies, but not every copy is a backup. A copy only protects data when it is independent, versioned and restorable. Synchronization tools that mirror changes in real time replicate deletions and encryption just as faithfully as useful edits.
The table shows which common forms of copy satisfy the intent of the rule.
| Type of copy | Counts as a backup | Reason |
|---|---|---|
| RAID mirror | No | Replicates deletion and corruption instantly |
| File synchronization service | Only with version history | Mirrors changes unless older versions are kept |
| Snapshot on the same system | Partly | Fast rollback, but lost with the system |
| Versioned backup on separate storage | Yes | Independent and restorable to earlier points |
| Immutable or air-gapped backup | Yes, strongest form | Cannot be altered by an attacker |
Snapshots are valuable for quick recovery from mistakes, but they normally live on the same storage pool as the data. If that pool fails or an administrator account is compromised, the snapshots disappear with it, so they should complement, not replace, separate backups.
Modern extensions of the rule
Ransomware changed the threat model. Attackers now look for backup servers and backup credentials first, deleting or encrypting backups before they encrypt production systems. Several extended variants therefore add requirements on top of the classic formula.
| Variant | Additional requirement | Main benefit |
|---|---|---|
| 3-2-1-1-0 | One immutable or offline copy and zero verification errors | Ransomware resistance and proven restores |
| 4-3-2 | Four copies, three locations, two offsite | Higher resilience for critical data |
| 3-2-2 | Two offsite copies instead of one | Protection if one provider or site fails |
An immutable backup uses write-once storage or object lock so that no one, including an administrator, can delete it before its retention period ends. An air-gapped backup is physically or logically disconnected from the network. The final zero in 3-2-1-1-0 stands for zero errors in restoration tests, a reminder that an untested backup is only an assumption.
Applying the 3-2-1 rule in practice
Implementing the rule starts with the recovery objectives. The recovery point objective (RPO) sets how much recent data the organization can afford to lose, which drives backup frequency. The recovery time objective (RTO) sets how quickly systems must be back, which decides whether the fastest restore comes from a local copy or a remote one.
A common layout keeps a local backup for fast restores and an offsite or cloud copy for disasters. The table shows how the rule translates into concrete setups for different environments.
| Environment | Local backup | Offsite copy |
|---|---|---|
| Home or freelancer | External drive with versioned backups | Encrypted cloud backup service |
| Small office server | NAS with daily incremental backups | Cloud object storage with object lock |
| Virtualized data center | Backup appliance with snapshots | Replica in a second region plus tape |
| Cloud-native workload | Backups in a separate account | Copy in another region or provider |
- Use separate credentials for backup storage so that a compromised server account cannot delete backups.
- Encrypt offsite copies and store the keys where they remain available after a disaster.
- Schedule regular restoration tests, including a full restore of at least one critical system.
- Document what is backed up, because unlisted databases and configuration files are often forgotten.
Limitations of the 3-2-1 rule
The rule is a minimum, not a complete backup strategy. It says nothing about retention length, backup frequency, encryption or how quickly data can be restored. An organization can technically satisfy 3-2-1 and still lose a week of work if backups run only weekly, or wait days for a large restore from a slow offsite link.
It also assumes that the copies are truly independent. Two backups managed by the same console with the same administrator password share a single point of failure, even if they sit on different media in different places.
A non-technical view
The 3-2-1 rule is a simple recipe for not losing important files. Keep three copies, use two different kinds of storage, and keep one copy somewhere else.
Think of the only key to your home. You would keep a spare in a drawer and give another to a trusted neighbor. If you lose one key, the drawer has another. If the house burns down, the neighbor still has one. Backups work the same way. One accident should never take away every copy.
A concrete example
A small architecture firm stores about 4 TB of project files on an office file server. Its backup plan follows the 3-2-1 rule: the server holds the live data, a NAS in the office receives incremental backups every hour, and a nightly job copies those backups to cloud object storage with a 30-day object lock.
One morning, ransomware encrypts the file server and reaches the NAS through a shared administrator account. The local backups are damaged, but the immutable cloud copy cannot be altered. The firm restores the most important active projects within the same day and the full archive over the next two days.
Afterward, the firm gives the backup system separate credentials and starts quarterly restoration tests. Data loss was limited to a few hours of work, instead of years of drawings and contracts.