The 3-2-1 Backup Rule: The Gold Standard Against Data Loss (SVG Infographic)

Quick Answer

• The classic rule: keep 3 copies of data, on 2 different media types, with 1 copy off-site; it is the foundation of every modern strategy.
• The modern 3-2-1-1-0 version adds the requirement of 1 immutable (or air-gapped) copy and a restore test with 0 errors.
• An immutable backup means WORM or object-lock protected storage that ransomware cannot encrypt, a critical layer against ransomware.
• A backup that has never been restore-tested does not count; a full restore drill at least once a quarter is recommended.
• Organizations that apply 3-2-1 recover from ransomware in about 24 hours on average, while for those that do not, recovery time stretches to 2 to 4 weeks.

Most customers who come to the data recovery lab say the same sentence: "I had a backup, but..." Behind that word "but" you usually find the same stories. The backup was on the same computer, and the ransomware encrypted it too. The backup was on an external disk, and the disk fell off a shelf. The backup was on a NAS, and when the user accidentally deleted the NAS folder, the backup was gone too. There was a backup, but nobody had ever tried to restore it, and the files turned out to be corrupt.

All of these stories share a single trait: they violate the 3-2-1 backup rule. In this article we cover the original form of the 3-2-1 rule, the modern 3-2-1-1-0 extension, the logic of immutable backups, and practical ways to apply it for SMBs and individual users. The article also includes an inline SVG infographic measuring 600px x 400px; it stays sharp at every scale, from screen to print.

What Is the 3-2-1 Backup Rule?

The 3-2-1 backup rule was first formulated around 2005 by the US photographer Peter Krogh for digital asset management, and was later adopted as a corporate data protection standard by organizations such as CISA (US-CERT) and Veeam. The rule consists of three very simple components.

3 copies: You should have a total of 3 copies of the data. That means 1 production copy plus 2 backups. A single backup is not enough; two independent backups create a safer fallback zone.

2 different media: Backups should be kept on two different storage types. Two SSDs of the same brand and model count as the same medium; a manufacturing defect or a firmware bug could affect both at the same time. The right combination might be HDD and SSD, or a local disk and a cloud bucket. NAS and tape is also a classic mix.

1 offsite copy: At least one backup should be kept in a physically different location. In scenarios of office fire, flooding, theft, and ransomware, an offsite copy is a lifesaver. A cloud bucket is the modern equivalent, a bank safe deposit box the classic one.

CISA's official guide (cisa.gov/news-events/news/data-backup-options) recommends these three components as the fundamental backup standard for individual and corporate users alike. The NIST SP 800-34 Contingency Planning Guide for Federal Information Systems also makes it mandatory to spread backup distribution across multiple geographic locations.

SVG Infographic: A Visual Explanation of the 3-2-1 Rule

The infographic below explains the 3-2-1 rule at a glance. DSET red (#FF0027) is used as the primary accent color.

The three boxes in the infographic convey the message "3 copies, 2 different media, 1 offsite" in order. The bottom section summarizes the 3-2-1-1-0 extension.

The Modern 3-2-1-1-0 Extension: Veeam's Interpretation

The classic 3-2-1 rule was born in 2005, when ransomware was not at today's scale. Starting in 2020, Veeam updated the rule to 3-2-1-1-0 in its official documentation (veeam.com). The two added digits respond to today's threat landscape.

+1 immutable copy: At least one of the backups must be immutable. Even if an attacker gains domain admin privileges, they cannot delete, encrypt, or modify this backup. In practice, this is achieved with AWS S3 Object Lock, Azure Blob immutable storage, Backblaze B2 Object Lock, or a tape library (air-gapped).

+0 errors: The backups must have passed a restore test successfully. Error code = 0 means the backup files have passed integrity verification and an actual restore attempt successfully. If the backup file sits on disk but will not open, you do not have a backup at all.

The field findings in Veeam's 2024 Data Protection Trends report (the report text was published on their own site) show that restore failure cases make the existence of a backup meaningless. In roughly one third of the corporate cases that come to our lab, we see the picture of "there is a backup, but the restore does not work"; I am not presenting this number as an official statistic, only stating it as a field observation.

Scenario 1: Individual User

Photo archive, tax documents, personal video recordings. A total of 500 GB of data.

• Copy 1 (production): Laptop SSD.
• Copy 2 (local backup): A 2 TB external USB HDD, with a weekly automatic backup (macOS Time Machine or Windows File History).
• Copy 3 (offsite): Backblaze Personal Backup or iCloud / Google One / OneDrive cloud backup.

The annual cost ranges between 700 TL and 1,500 TL. Details are in the cost section below.

Scenario 2: SMB (5 to 25 employees)

Accounting, customer database, and project files on an office NAS. A total of 4 TB of production data.

• Copy 1 (production): A Synology NAS with RAID protection using an SHR configuration.
• Copy 2 (local backup): A second NAS or a rotated external disk (swapped weekly).
• Copy 3 (offsite immutable): AWS S3 Glacier Deep Archive or Backblaze B2 + Object Lock.

The most common mistake SMBs make is thinking "I have a backup" simply because the production NAS is RAID 5. RAID is not a backup; it is a layer of protection against hardware failure, and a RAID 5 failure is a real scenario. A 3-2-1 backup plan must be layered on top of the RAID configuration.

Scenario 3: Enterprise (50+ employees)

ERP database, email server, file servers, virtual machines. A total of 50 TB.

• Copy 1 (production): Production storage (SAN or hyperconverged).
• Copy 2 (local backup): Veeam Backup & Replication, a dedicated backup repository.
• Copy 3 (offsite + immutable): A cloud tier (Azure Blob immutable, AWS S3 Object Lock) or a Veeam Hardened Repository (Linux + immutable flag).

At this scale, in addition to 3-2-1-1-0, an IR (incident response) playbook and the first 24 hours after ransomware protocols should also be in effect.

Cloud Backup Options

The default address for a modern offsite copy is a cloud bucket. Four major options:

AWS S3: S3 Standard for hot data, S3 Glacier Instant Retrieval for medium-frequency access, S3 Glacier Deep Archive for archives. The Object Lock feature supports immutable backups. The AWS Backup service automatically backs up resources such as RDS, EC2, and EBS. Official guide: aws.amazon.com/backup.

Azure Blob Storage + Azure Backup: Microsoft's official documentation (learn.microsoft.com/en-us/azure/backup) explains features such as immutable backup, soft delete, and multi-user authorization with the Azure Backup Vault. The hot / cold / archive access tiers are similar to S3.

Google Cloud Storage: Standard, Nearline, Coldline, and Archive tiers. Bucket Lock retention policies provide immutability.

Backblaze B2: One of the most economical options, and it supports Object Lock. An attractive price point for SMBs.

Whatever the provider, there are three headings to watch out for in your choice: egress (data retrieval) fees, retrieval time (Glacier Deep Archive can introduce delays of up to 12 hours), and immutability support.

Immutable Backup and Object Lock

An immutable backup is a type of backup in which a file cannot be deleted, overwritten, or modified until the defined retention period expires. The technologies that provide this feature:

• AWS S3 Object Lock: Governance mode (root override possible) and Compliance mode (no one can delete).
• Azure Blob immutable storage: Time-based retention and legal hold modes.
• WORM tape: Write Once Read Many, tape cartridges that physically cannot be overwritten.
• Veeam Hardened Repository: A backup protected with the immutable attribute (chattr +i) on a Linux file system.

In ransomware attacks, the attacker chooses the backup server as the first target. If they can encrypt or delete the backup, the likelihood of the ransom being paid increases dramatically. An immutable copy breaks this chain.

Restore Testing: The Only Proof That a Backup Exists

There is only one criterion for a backup to count as existing: when was the last restore test of that backup performed, and with what result? This is the practical equivalent of the "0 errors" criterion.

Recommended test frequency:

• Individual: At least once a year, restore your critical files as a sample to a different device.
• SMB: Every three months, restore a VM or a file server backup to a test lab.
• Enterprise: A full restore scenario once a month (tabletop or real), and a full disaster recovery drill annually.

As a field observation, we can say that roughly half of the customers who say they take backups without performing restore tests have integrity problems in their backups. I am not turning the number into a statistic without a source; I am only emphasizing it as a pattern.

Ransomware Protection: Air-Gapped and Offline Backups

After 2020, ransomware authors shifted to the "double extortion" model: first the data is stolen, then it is encrypted. The first three systems the attacker targets are usually Active Directory, the file server, and the backup server. If the backup is accessible, the backup is encrypted too.

Protection layers:

1. Offline backup: A rotated external disk, stored in a safe, connected to the network only at the moment of backing up.
2. Air-gapped backup: A system completely separated from the network; a tape library is the classic example.
3. Immutable cloud copy: S3 Object Lock or Azure immutable blob.
4. Backup account separation: A credential that only the backup service can use to access the backup system, with no connection to a domain account.

In the SMB cybersecurity basic package article, there is a concrete cost table of these layers for medium-sized businesses.

Example Annual Cost for 1 TB of Office Data

A rough calculation (prices based on early 2026 lists, may vary by provider):

• Local backup (4 TB NAS, RAID 1): A one-time hardware investment of 8,000 to 12,000 TL. Amortized annually (over 5 years), 1,600 to 2,400 TL.
• Backblaze B2 cloud (1 TB): Around 6 USD/month, in the range of 2,500 TL per year.
• AWS S3 Glacier Deep Archive (1 TB): The storage line item is very cheap (a few hundred TL per year), but once egress and retrieval costs are added, the total can rise to the range of 1,500 to 3,000 TL per year.
• Backup software (Veeam Community or Synology Active Backup): A free start is possible at SMB scale.

Total: at the enterprise level, a 3-2-1-1-0 backup plan for 1 TB of data sits in the range of 5,000 to 8,000 TL per year. That is far below the cost of data loss (the cost that can result from a single RAID failure can be in the range of 10,000 to 60,000 TL).

The 7 Common Mistakes

1. The backup is on the same machine as the production system. Ransomware hit, and everything was gone.
2. The backup external disk is on top of the desk. In the event of theft, fire, or a fall, both the production data and the backup share the same fate.
3. The backup NAS is accessed with a domain admin account. If the attacker obtains domain admin, they can encrypt or delete the backup.
4. A restore test has never been performed. The backup file is corrupt, and no one notices.
5. The folder thought to contain a backup is empty. The backup software fails silently, but no one checks the logs.
6. There is a cloud backup, but versioning is off. The attacker encrypted the file and had it synced to the cloud, and there is no older clean version.
7. The backup retention is too short. The attacker infiltrated the system, lay dormant for 90 days, then encrypted. The backups are only 30 days old, and returning to a clean version is impossible.

KVKK and Backup Data

If the backup files contain personal data, they fall within the scope of KVKK. Although the law does not address backups specifically, the "Data Security Guide" published by the Personal Data Protection Authority states that backup processes are also within the scope of technical and administrative measures. When choosing a cloud provider, cross-border data transfer, contractual guarantees, and encryption layers should be assessed as part of KVKK compliance.

Frequently Asked Questions (FAQ)

Question 1: Is RAID a backup? No. RAID provides protection against hardware failure, but in scenarios such as accidental deletion, ransomware, controller failure, and office fire, RAID provides no protection. A 3-2-1 backup plan must be layered on top of RAID.

Question 2: Does a snapshot count as a backup? Not on its own. A snapshot is kept on the same storage; when the storage is gone, the snapshot is gone too. A backup must be on a different system.

Question 3: Is cloud sync (Dropbox, OneDrive, Google Drive) a backup? Not quite. Sync is not a versioning feature; if the production data is encrypted, the cloud copy is encrypted via sync as well. Some providers offer 30 to 365 days of versioning, which can be useful but is not the same as a dedicated backup.

Question 4: How often should backups be taken? Based on the RPO (recovery point objective) target. For data that changes hourly, hourly incremental + daily full is appropriate. For office files that change rarely, a daily full is enough.

Question 5: How long should a cloud backup be kept (retention)? Corporate practice is between 90 and 365 days. Certain KVKK justifications and sector regulations (BDDK, SPK) may impose longer retention requirements.

Question 6: What happens if the key for an encrypted backup is lost? The backup becomes inaccessible. The corporate best practice is to keep key management in a separate vault (HashiCorp Vault, AWS KMS, Azure Key Vault) and under dual control (multi-party approval).

Question 7: Which is better for backup, HDD or SSD? For cold archives, HDD still makes more sense; an SSD left for a long time in a powered-off environment carries the risk of bit fade. We go into detail on this topic in the HDD vs SSD lifespan comparison article.

Question 8: We already take backups, so what do we need from DSET? Restore testing, immutable layer design, and KVKK compliance verification. We test whether the backup plan works in the field, not just on paper.

DSET Backup Strategy Consulting

At DSET, we provide data recovery services from our ISO 5 cleanroom lab at Hacettepe Teknokent, Ankara. After recovery, the most critical question is always the same: what should be done to avoid going through this again? This is where backup strategy consulting comes in.

Service scope: taking inventory of the current backups, 3-2-1-1-0 compliance analysis, immutable layer design, setting up a restore test procedure, defining RPO and RTO targets, and KVKK compliance checks. We carry out on-site assessments at SMB and enterprise scale.

Contact: +90 536 662 38 09. Hacettepe University Teknokent, Ankara.

For a comprehensive guide to the data recovery process, you can check out our Turkey 2026 data recovery main guide, and for the first response after ransomware, the first 24 hours emergency protocol.

---

This article was prepared on 2026-06-01 by the DSET Data Recovery team. All independent sources in the content (CISA, Veeam, Microsoft, AWS, NIST, KVKK) are linked to the official documentation of their original publishers. Statements given as field observations are written not as statistics, but as pattern warnings.