3-2-1 Backup Strategy

The 3-2-1 backup strategy (also written 3-2-1 rule) is a data-protection heuristic requiring that any dataset worth protecting exist as at least three total copies, stored across at least two different storage media or systems, with at least one of those copies kept at a location or system genuinely separate from where the primary working copy lives. All three conditions have to hold at the same time — extra copies sitting on identical media in the same room, or a single offsite copy with no local redundancy behind it, do not satisfy the rule on their own. The phrasing is widely credited to photographer Peter Krogh, who distilled it into a memorable rule of thumb in The DAM Book: Digital Asset Management for Photographers; U.S. federal guidance on ransomware recovery and data backup, including CISA’s own backup-options guidance, has since adopted the same 3-2-1 framing as a baseline architecture, alongside newer variants such as 3-2-1-1-0 that add an immutable/air-gapped copy and verified recovery testing.

The three conditions, precisely

• 3 copies — the working copy plus at least two additional copies. “Three copies” means three independent instances of the data, not three references to the same underlying file.
• 2 media types — the copies are not all stored on the same kind of storage technology. Two copies on two different internal hard drives in the same machine, or two files on the same cloud account, do not count as two media types; a local disk plus tape, or local disk plus a separate cloud object-storage service, does.
• 1 offsite copy — at least one copy is physically or logically separated from the location housing the working copy, so a single localized event (fire, flood, theft, a compromised network segment, a ransomware attack that encrypts everything reachable from one machine) cannot destroy every copy at once.

A storage arrangement that satisfies only two of the three conditions is not “mostly” 3-2-1 compliant — it has a specific, identifiable single point of failure that the missing condition exists to close.

Why this matters specifically for research data management

Backup guidance is often written for generic business IT, where the framing is business continuity: how fast can operations resume after data loss. Research data management has an added, sharper edge: a large share of research data is irreplaceable in a way most business data is not. A destroyed spreadsheet of sales figures can often be reconstructed from other records; a lost dataset from a single field season, a discontinued longitudinal cohort, a now-decommissioned instrument run, or clinical trial visits that can never be re-consented and re-collected cannot be regenerated at any cost. For this class of data, backup failure isn’t an inconvenience to route around — it’s a permanent loss of the underlying research output.

Funder and institutional policy compounds this. Major funders increasingly require a documented data management and sharing approach as a condition of award — see CASRAI’s Data Management Plan (DMP) entry — and federal award terms typically carry their own record-retention floor: for example, 2 CFR 200.334 sets a baseline three-year retention window (measured from submission of the award’s final financial report) for records related to a federal award, with longer retention triggered by an open audit, claim, or litigation. A backup strategy for research data has to remain intact and restorable across that entire retention window, not just survive the life of the active project — a distinction generic “back up your laptop” advice does not carry.

How 3-2-1 fits into a Data Management Plan’s storage and preservation section

Every major DMP template asks investigators to describe how data will be stored and backed up during the active project, separately from how it will be preserved after the project ends (CASRAI’s preservation commitment (in DMP) entry covers that latter, post-project piece specifically). A vague line such as “data will be backed up regularly” gives a DMP reviewer nothing concrete to evaluate. Naming the 3-2-1 structure explicitly — which two media types, which system holds the offsite copy, and who is responsible for running and checking each backup — turns that section into something a reviewer can actually assess for feasibility. CASRAI’s guide to DMP review criteria notes this directly: a plan that promises regular backups to a repository with no named person responsible for running them reads as infeasible to an experienced reviewer even though the section is technically present. Naming a concrete backup architecture, and a concrete owner for it, closes exactly that gap.

Repository deposit is not automatically the “1” in 3-2-1 — and backup is not versioning

Two distinctions come up constantly once a research team tries to actually implement 3-2-1, and both are worth being precise about:

• An institutional or trusted digital repository can legitimately serve as the offsite leg — but only for data that has actually been deposited. During active data collection and analysis, the dataset usually isn’t in a fit state for repository deposit yet (it’s incomplete, unreviewed, or contains material that needs curation or de-identification first). A repository deposit at the end of a project is a real, valid offsite copy for the finalized dataset, but it does not retroactively protect the working data through the months or years of active work that preceded it. Active data still needs its own ongoing 3-2-1 cycle, distinct from the eventual archival deposit. See CASRAI’s guide on choosing an open data repository and the institutional repository and trusted digital repository entries for what makes a given repository a credible offsite/preservation location in the first place — not every storage location marketed as a “repository” carries the same durability guarantees.
• Version control is not backup. A version-controlled workflow (Git for code, or a repository platform that retains prior versions of a deposited dataset) preserves a history of changes to one logical copy of the data. It answers “what did this look like before the last edit?” — it does not, on its own, answer “do I have an independent copy if this entire storage system is destroyed or compromised?” Versioning and 3-2-1 backup solve different failure modes and are complementary, not substitutes for each other: a version history that lives on only one storage medium in one location is still exposed to the same single point of failure 3-2-1 is designed to eliminate.

It’s also worth distinguishing 3-2-1 from fixity checking: 3-2-1 is about having enough independent copies that losing one is recoverable; fixity checking is about confirming that the copies you have are actually still intact and unaltered. A repository can faithfully back up a corrupted file for years without fixity checking ever catching the corruption — the two practices answer different questions and a mature research-data storage plan needs both.

Practical considerations for implementing 3-2-1 on a research project

• Separate the cadence for active vs. archival data. Working data under active analysis typically needs frequent (daily or continuous) backup of the two non-archival copies; a deposited, finalized dataset in a repository is checked and refreshed on a much longer cycle appropriate to preservation, not active work.
• Choose media types that fail independently. A common, practical combination for a research team is: working copy on a lab workstation or departmental network-attached storage, a second copy on institutional or cloud object storage (a different failure domain from local disk), and a third, offsite copy in an institutional repository, a domain-specific repository appropriate to the data type (see CASRAI’s domain repository and generalist repository entries), or an institutionally managed offsite/cloud backup service.
• Name a responsible person, not just a system. A backup architecture with nobody accountable for verifying it’s actually running is a common, quiet failure point — see CASRAI’s guide on data stewardship and the data curator role for how this responsibility is typically assigned within a lab or institution.
• Test restores, not just backups. A backup that has never been restored is unverified. Ransomware-recovery guidance (including CISA’s) increasingly frames 3-2-1 alongside a fourth and fifth element — one immutable or offline copy, and zero errors confirmed through tested recovery (the “3-2-1-1-0” variant) — specifically because an untested backup can fail silently at the exact moment it’s needed.
• Plan for team turnover. Backup arrangements set up by a graduate student or postdoc who later leaves the lab are a recurring, avoidable cause of research data loss if responsibility and access aren’t documented and transferred, not just technically configured.

Worked examples

• A genomics lab keeps its working sequencing dataset on a departmental network-attached storage array, an automated nightly copy on a separate university tape-backup service, and a deposited copy in a discipline-specific repository hosted in a different data center from either university copy — three copies, two media types (disk and tape), and one genuine offsite copy.
• A qualitative-methods researcher keeps interview transcripts as a working copy on an encrypted laptop, a continuously synced copy in the institution’s managed cloud storage, and an end-of-project deposit in a CoreTrustSeal-certified repository — again three copies, two media types, and one geographically distinct copy, with the repository deposit only becoming the valid “offsite” leg once the transcripts are actually finalized and deposited.

Counter-example: A dataset saved as a master copy on a lab workstation, with a second copy on an external hard drive kept in the same room, technically has “two copies” but does not satisfy 3-2-1: both copies sit on similar disk media in the same physical location, so a single fire, theft, or ransomware event affecting that room can destroy both at once. There is no media diversity and no offsite copy — the arrangement fails the rule even though a naive read of “keep backups” would consider it done.

References

• Peter Krogh, The DAM Book: Digital Asset Management for Photographers — widely credited origin of the “3-2-1” phrasing.
• Cybersecurity and Infrastructure Security Agency (CISA), data backup guidance and the #StopRansomware Guide — U.S. federal adoption of 3-2-1 (and the 3-2-1-1-0 variant) as a baseline backup architecture.
• 2 CFR 200.334 (Uniform Guidance) — baseline federal-award record-retention requirement relevant to how long a research backup/preservation strategy needs to remain restorable.
• National Digital Stewardship Alliance, Levels of Digital Preservation — treats storage/geographic location and file fixity as related but distinct functional areas alongside redundant-copy practice.