Data Backup According to BSI: The 3-2-1-1-0 Principle in Practice

TL;DR

The classic 3-2-1 principle (3 copies, 2 different media, 1 offsite) has been extended to 3-2-1-1-0: one additional immutable copy and zero errors in restore tests.
Immutable backups are the most important protection against ransomware because they cannot be deleted or encrypted even by attackers with administrator privileges.
The zero in 3-2-1-1-0 stands for zero errors during recovery. Regular restore tests are mandatory, not optional.
A realistic backup setup for 100 employees costs between 500 and 1,500 euros monthly, depending on data volume and chosen tools.
Both BSI IT-Grundschutz and NIS2 require a documented data backup concept with regular tests and clear responsibilities.

The 3-2-1 Rule: A Classic That Has Aged

The 3-2-1 backup rule dates from a time when the greatest threat to data was a hard drive failure or a fire in the server room. The rule is simple and memorable: keep at least 3 copies of your data, store them on at least 2 different media types, and keep at least 1 copy at an offsite location.

That was and remains a good starting point. Three copies mean that simultaneous failure of all copies is extremely unlikely. Two different media types protect against media-specific failures (if all backups sit on the same RAID configuration and the RAID controller fails, all are affected). An offsite location protects against local disasters like fire, flooding, break-in, or a burst pipe in the server room.

What the 3-2-1 rule doesn't address are two threats that have gained massive significance in recent years: ransomware that specifically encrypts backups, and backup errors that only surface during a restore. Both scenarios can leave you with three copies on two media types at an offsite location and still unable to restore anything.

The Evolution: 3-2-1 Becomes 3-2-1-1-0

The security community has therefore gradually extended the 3-2-1 rule. First came the 3-2-1-1 rule, which requires an additional immutable (unchangeable) or air-gapped (physically separated) copy. Then followed the 3-2-1-1-0 rule, which additionally demands zero errors in restore tests.

Each digit represents a concrete requirement for your backup strategy:

3: At least three copies of the data
2: On at least two different media types
1: At least one copy at an offsite location
1: At least one copy immutable or air-gapped
0: Zero errors in restore tests

Each digit is explained in detail below, with concrete examples and the most common mistakes companies make.

The 3: At Least Three Copies of Your Data

The first copy is your production data — the data on the live system you work with daily. The second and third copies are your backups.

Why three and not two? If you have only one backup and the production system fails, you have exactly one copy of your data. If that one copy is faulty — which you'll only notice during restore — you have nothing left. Three copies mean: even if one backup copy is faulty, you still have a second one.

Practical example: A mid-market company with a file server and an ERP system has the following three copies: the production data on the server, a daily backup to a local NAS (Network Attached Storage), and a daily backup to the cloud. This meets the minimum requirement of the "3."

Common mistake: Counting snapshots or RAID as backup. A snapshot is not a backup because it resides on the same storage system. If the storage hardware fails, production data and snapshots are lost together. RAID protects against the failure of individual hard drives, not against logical errors, ransomware, or accidental deletion.

The 2: At Least Two Different Media Types

The second digit requires that backups reside on at least two different storage media. The goal: protection against media-specific failures and common failure modes.

What counts as a different media type? The distinction is less strict than in the past, when one differentiated between hard drives and tape drives. Today it's more about different storage technologies and failure domains. A local NAS and a cloud object store are two different media types, even though both ultimately run on hard drives. Two NAS systems from the same manufacturer in the same data center are not, because a firmware vulnerability could hit both simultaneously.

Practical example: Combination 1 is local NAS plus cloud storage (S3, Azure Blob, Backblaze B2). This is the most common and pragmatic combination for SMEs. Combination 2 is local hard drive/NAS plus LTO tape drive. Tapes are impervious to ransomware (offline, no network access) and are excellent for long-term archival, but require manual handling. Combination 3 is cloud backup with Provider A plus cloud backup with Provider B. Avoids a single point of failure with one cloud provider, but increases complexity and costs.

Common mistake: Counting two partitions on the same hard drive as "two media types." This protects against nothing except accidental deletion.

The 1 (First): At Least One Copy Offsite

The third digit has existed since the original 3-2-1 principle and remains unchanged in importance. At least one backup copy must be stored at a physically separate location. This protects against local disasters: fire, flooding, break-in, power failure with hardware damage, or simply a burst pipe in the server room.

"Offsite" means: a different building, ideally in a different fire protection zone. Not the safe in the next room, and certainly not the USB hard drive on the desk next to the server.

Practical example: For most mid-market companies, cloud backup is the simplest implementation of the offsite copy. The data automatically resides in a data center that can be hundreds of kilometers away. Alternative: a second company location or a rented rack in a colocation data center.

Common mistake: The offsite copy is created, but the transfer isn't monitored. If the cloud backup job has been failing for three weeks and nobody notices, you effectively have no offsite copy.

The 1 (Second): At Least One Immutable or Air-Gapped Copy

The fourth digit is the most important extension over the classic 3-2-1 principle and the direct response to ransomware. An immutable copy cannot be modified or deleted after writing — not even by an administrator and not even by an attacker who has obtained administrator privileges.

Why Is This So Important?

Modern ransomware attacks follow a pattern: attackers gain access to the network, move laterally through the infrastructure, obtain administrator privileges, and specifically seek out backup systems. Only when they're certain that the backups are also encrypted or deleted do they activate the ransomware on production systems. If your backups are accessible through the same admin account as the production systems, they're worthless in such an attack.

Immutable Backups: How Does It Work?

There are various technical approaches to immutability.

Object Lock in cloud storage: AWS S3 Object Lock, Azure Immutable Blob Storage, and Backblaze B2 offer the ability to make objects unchangeable for a defined period. In Compliance mode, even the root account cannot delete the data until the retention period expires. This is the simplest and most cost-effective method for immutability.

Immutable repositories in backup software: Veeam has offered the "Hardened Linux Repository" since version 11, where backup files are marked with the Linux immutable attribute. The backup software has no root access to the repository, so even a compromised backup server cannot delete the data. Similar concepts exist at Commvault, Cohesity, and other enterprise backup solutions.

WORM storage (Write Once, Read Many): Specialized storage systems like NetApp SnapLock or dedicated WORM appliances offer hardware-backed immutability. This solution is the most secure but also the most expensive.

Air-gapped backups: Physical separation is the oldest and still most effective form of immutability. An LTO tape in a safe cannot be attacked over the network. USB hard drives that are physically disconnected after backup and locked away also serve this purpose, but require manual discipline.

Recommendation for SMEs

For mid-market companies, the combination of cloud backup with Object Lock and a local hardened repository is the best compromise between security, cost, and effort. The cloud copy is automatically offsite and immutable; the local repository enables fast restores for smaller incidents.

The 0: Zero Errors in Restore Tests

The fifth and final digit is perhaps the most frequently ignored and simultaneously the most important. A backup that can't be restored is not a backup. It's an illusion of security.

Why Do Restores Fail?

The reasons are diverse and often mundane: the backup software reports "Backup successful" even though individual files were skipped. The backup data is consistent, but the application can't import it because of a version incompatibility. The backup includes the data but not the application configuration, so the restore works but the application won't start afterward. The network bandwidth to the cloud storage isn't sufficient to download the data within an acceptable time. The restore procedure is documented but nobody has ever performed it, and in an emergency, credentials or licenses are missing.

How to Test Properly?

Restore tests should occur at various levels. File restores (restoring individual files or folders) should happen monthly and are quick to perform. They test the basic integrity of the backup.

Application restores (restoring a complete application with database and verifying it works) should happen quarterly. They're more involved but uncover problems that a pure file restore won't reveal.

Full bare-metal restores (restoring a complete system from scratch) should happen at least semi-annually, preferably quarterly. They test the entire recovery process including operating system, drivers, configuration, and applications.

Disaster recovery tests (restoring entire business operations at an alternative location) should happen annually. This is the ultimate test that shows whether your business continuity plan works.

Documenting the Tests

Every restore test must be logged: date, system tested, type of test, result (successful/failed), recovery duration (RTO measurement), data loss (RPO measurement — the time between the backup timestamp and the failure), identified problems, and corrective measures initiated.

These logs are invaluable during audits. An auditor who sees that you conduct quarterly restore tests, document the results, and systematically address problems will find little to criticize.

Sample Setup: 100-Employee Company

To make the 3-2-1-1-0 principle tangible, here's a concrete backup setup for a typical mid-market company with about 100 employees.

Starting Point

The company operates the following systems: a file server with 5 TB of user data, an ERP system (e.g., SAP Business One or Microsoft Dynamics) with a SQL database (200 GB), Exchange Server or Microsoft 365 for email, Active Directory with group policies and certificates, various line-of-business applications on two to three application servers, and 100 Windows clients.

Backup Architecture

Copy 1 (Production): The live data on production servers. Daily snapshots on the storage for quick rollbacks after accidental deletion (not a backup replacement, but useful for daily operations).

Copy 2 (Local backup): A dedicated backup server with Veeam Backup & Replication. Local repository on a Synology NAS with 20 TB (RAID 6). Daily incremental backups with weekly Synthetic Full. Retention: 30 days. This backup enables fast restores (Gigabit LAN speed) and is the primary recovery target for everyday use.

Copy 3 (Cloud backup, offsite + immutable): Veeam Scale-out Backup Repository with Capacity Tier on Backblaze B2 or AWS S3. Object Lock activated with 60-day retention. Daily offload of local backups to the cloud. This backup simultaneously fulfills the "1" for offsite and the "1" for immutable.

Additionally (air-gapped): Monthly full backup to a USB hard drive (encrypted with AES-256), stored in a bank safe or fire-resistant safe at a different location. Rotation of three hard drives. This sounds old-fashioned, but it's the ultimate protection against everything network-related.

Costs

The costs for this setup break down as follows: Veeam Backup & Replication for 100 instances costs approximately 3,000 euros per year. A Synology NAS (e.g., RS1221RP+ with 8 x 4 TB) costs around 3,500 euros one-time. Cloud storage on Backblaze B2 for an estimated 8 TB (after deduplication and compression) costs approximately 50 euros per month. Three USB hard drives (8 TB each, encryption-capable) cost about 500 euros one-time. And the working time for setup, monitoring, and tests is estimated at 4-8 hours per month.

In total, you land at approximately 500 to 800 euros monthly when you spread the one-time costs over three years. For a 100-employee company, this is a reasonable amount, especially when weighed against the costs of data loss.

Alternative for Smaller Budgets

If Veeam is too expensive, there are alternatives. Proxmox Backup Server is open source and free (support subscription optional), supports incremental backups with deduplication, and offers backup verification — though only for Proxmox VMs and Linux systems. Restic or BorgBackup are open-source backup tools with deduplication and encryption that work well with cloud storage. They require more manual setup but are extremely flexible and free. Duplicati offers a graphical interface, supports numerous cloud providers, and is also open source.

With these tools, a 3-2-1-1-0-compliant setup can be realized for under 200 euros monthly (primarily cloud storage costs), provided you're willing to invest more time in setup and maintenance.

BSI Recommendations for Data Backup

BSI's IT-Grundschutz Compendium includes several building blocks that address data backup. The most important are CON.3 (Data Backup Concept) and OPS.1.2.2 (Archiving).

CON.3: Data Backup Concept

Building block CON.3 requires a documented data backup concept that addresses the following points.

Data inventory: What data exists, where is it stored, and how critical is it? The protection needs assessment provides the foundation for this. Without this inventory, you can't define a meaningful backup strategy because you don't know what you need to back up.

Influencing factors: How large is the data volume, how frequently does the data change, what availability requirements exist (RTO and RPO), and how much data loss is tolerable?

Backup methods: Which methods are used (full backup, incremental, differential)? At what intervals? With which software?

Retention periods: How long are backups retained? Are there legal retention requirements that must be considered?

Responsibilities: Who is responsible for data backup? Who monitors backup jobs? Who conducts restore tests?

Recovery tests: Regular recovery tests are not a recommendation but a requirement. The building block states this unambiguously.

NIS2 and Data Backup

NIS2 Article 21 No. 3 requires the maintenance of operations, including backup management and disaster recovery. This is more broadly formulated than the BSI building blocks but means essentially the same thing: you need a documented concept, must implement it, and must be able to demonstrate that it works.

If you build your data backup concept according to the 3-2-1-1-0 principle, consider the BSI requirements from CON.3, and document regular restore tests, you meet both BSI requirements and NIS2 obligations in this area.

Common Mistakes and How to Avoid Them

Backup without monitoring. The backup job runs every night, but nobody checks whether it succeeded. Failed jobs are only noticed when a restore is needed. Solution: automated notifications on failure and a weekly review of backup logs.

No test of recovery time. The backup works, but restoring 5 TB from the cloud at 100 Mbit/s takes almost five days. If the RTO is 24 hours, that's a problem. Solution: measure recovery time with every restore test and compare against the RTO.

Backup credentials in the same system. The credentials for the cloud backup storage are in the password manager on the server being backed up. If the server is compromised, the attacker also has access to the backup storage. Solution: store backup credentials separately and use Object Lock so that even with the credentials, deletion isn't possible.

Microsoft 365 not backed up. Many companies assume Microsoft backs up their data. But Microsoft only guarantees the availability of the infrastructure, not the recoverability of individual emails, SharePoint documents, or Teams data after accidental deletion or ransomware. Solution: a dedicated Microsoft 365 backup with tools like Veeam for Microsoft 365, AvePoint, or Hornetsecurity.

Encryption key lost. The backup is encrypted (good), but the key only exists on the server that just failed (bad). Solution: store encryption keys and recovery keys at a secure, separate location (e.g., in a bank safe, together with the air-gapped backup hard drives).

From Rule to Concept

The 3-2-1-1-0 principle is a framework, not a finished concept. It tells you what properties your backup strategy must have, but not how to implement it for your specific company. Implementation depends on factors such as data volume and change rate, availability requirements (RTO/RPO), budget and existing infrastructure, regulatory requirements (GDPR retention periods, GoBD), and your IT team's expertise.

Use the 3-2-1-1-0 principle as a checklist: do you have three copies? Two media types? One offsite copy? One immutable copy? Regular restore tests with zero errors? In ISMS Lite, you document your data backup concept, plan restore tests, and demonstrate that all five points are met. The tool covers all ISMS modules 500 Euro pro Jahr, with no user limits or hidden costs. If you can check off all five points and have it documented, you're well positioned on data backup — better than the vast majority of mid-market companies in Germany.