Skip to content

The 3-2-1 backup rule is a basic strategy for protecting important data from hardware failures, human error, disasters, and other incidents.

  • 3: Keep a total of 3 copies of your data
    • 1 primary copy
    • 2 backup copies
  • 2: Store the copies on 2 different types of media or storage
    • Example: server disk + external storage
    • Example: on-premises storage + cloud storage
  • 1: Keep at least 1 copy offsite
    • This protects against events that can affect an entire location, such as fire, earthquakes, theft, or ransomware.

In short:

Keep 3 copies of your data, use 2 different storage types, and keep at least 1 copy in another location.


Having only one backup is not enough. If that backup is corrupted or incomplete, recovery may fail.

Even if multiple copies exist, keeping all of them on the same server, network, or physical site can expose them to the same failure.

Examples include:

  • Hardware failure
  • Human error
  • Ransomware
  • Fire or flooding
  • Storage-system failure
  • Backup-system failure

The important point is therefore not only the number of copies, but also the diversity of storage methods and locations.


Peter Krogh, who is widely associated with popularizing the 3-2-1 rule, originally described the “2” as storing copies on two different media types.

Examples include:

  • HDD + tape
  • HDD + optical media
  • Local storage + cloud storage

Simply keeping two hard drives on the same network may not provide enough protection, because both copies can still be affected by the same outage, attack, or administrative mistake.


During production of Pixar’s Toy Story 2 around 1998, a large amount of production data was accidentally deleted.

A deletion command was reportedly executed from the wrong location on a Unix-based system, and a large portion of the movie’s production files—often described as roughly 90%—was deleted.

Normally, the data should have been recoverable from backup.

However, there was another serious problem:

The backup system had not been working correctly, so recent production data could not be fully restored from the normal backups.

Fortunately, Galyn Susman, who was working from home after having a baby, had a relatively recent copy of the production files on her home computer.

That computer was brought back to Pixar, and the data on it was combined with the remaining production data to help reconstruct the project.


The incident illustrates several important lessons about backup design.

  1. Having a backup is not enough

    • You need to verify that backups are actually being created successfully.
  2. Restore testing is essential

    • A backup is only useful if the data can actually be restored.
  3. Do not keep every copy in the same location

    • In this case, the copy stored at Galyn Susman’s home effectively acted as an offsite copy.
  4. Backup systems themselves can fail

    • It is dangerous to assume that a backup system is reliable simply because it exists.

3 copies
2 different media / storage types
1 offsite copy

A simple way to remember it is:

Keep 3 copies
Use 2 different storage methods
Keep 1 copy somewhere else

In an AWS-based system, the concept could be applied like this:

Production data
↓
Backup #1: AWS Backup / Snapshot
↓
Backup #2: Separate AWS account / Separate AWS Region

For systems requiring stronger resilience, you could add another failure domain:

Copies in AWS
+
Another cloud / On-premises storage / Offline media

For stronger protection against ransomware and administrative mistakes, also consider:

  • Separate AWS accounts
  • Cross-Region copies
  • Immutable backups
  • Separate permissions for deleting backups
  • Regular restore testing

The goal is not simply to increase the number of copies, but to separate the failure domains and administrative boundaries.



A good backup strategy is not just about how many copies you have; it is about storing them in different ways and locations, and regularly confirming that they can actually be restored.