Skip to content
IT infrastructure & networks

3-2-1 Backup Strategy: Ransomware Protection

The 3-2-1 backup strategy explained: why ransomware targets backups first, what 3-2-1-1-0 adds and which common mistakes cause restores to fail.

Published on 4 min read

Three white archive boxes on a glass table, two side by side and one set apart, a city view behind.

A company with a working backup does not have to pay a ransom. Attackers know this and hunt for backups before encrypting, deleting all they can reach. The 3-2-1 backup strategy and its extension 3-2-1-1-0 describe a setup that survives such an attack.

Why backups are the target of ransomware

A ransomware attack begins days or weeks before encryption, as the article How hacker attacks work describes. Before encrypting, attackers obtain administrator rights and check where the company stores its backups.

A backup server in the same Windows domain, a NAS with domain administrator credentials or a permanently connected hard drive are just more files to an attacker with full rights. The BSI’s 2025 situation report notes that most reported ransomware attacks affect small and medium-sized companies.

The 3-2-1 rule and the 3-2-1-1-0 extension

The 3-2-1 rule is the minimum setup:

  • Three copies of the data: the original on the production system and two backups.
  • Two different media: for example a backup server with hard drives plus a tape drive or cloud object storage.
  • One copy off site: so that fire, water damage or theft cannot affect all copies.

Against an attacker in the network this is not enough, because all three copies may be reachable and deletable. The 3-2-1-1-0 extension adds two requirements:

  • One copy offline or immutable. Offline means physically disconnected, such as a tape in a safe. Immutable means the storage refuses deletion and overwriting for a defined period, even by administrators.
  • Zero errors in the restore test. An untested backup is an assumption.

Typical mistakes in practice

Restores rarely fail for lack of technology but because of unchecked assumptions:

  • Backup in the same domain. Whoever controls the domain controller also controls a backup server inside it.
  • NAS with domain administrator. The backup service accesses the share with a highly privileged account that can also delete the backups.
  • No versioning. The backup overwrites yesterday’s state every night; if encryption is noticed after two days, the backup already contains encrypted files.
  • Microsoft 365 without its own backup. Microsoft protects the platform, not the customer’s data against deletion by users or attackers with stolen credentials. Recycle bin and retention policies only cover a limited period.
  • Restore time never measured. Nobody knows whether restoring the file server takes four hours or four days.

Backup concept and restore test

Module CON.3 of the BSI IT-Grundschutz describes what a backup concept contains. In practice this condenses into six decisions per system:

  • RPO (Recovery Point Objective): acceptable data loss, for example one hour for accounting, 24 hours for the file server.
  • RTO (Recovery Time Objective): acceptable downtime, for example one working day for ERP, one week for the archive.
  • Retention: number and age of restore points, for example daily for 30 days, monthly for twelve months, yearly per statutory periods.
  • Encryption: on the medium and in transit, with keys stored separately.
  • Separation: backup system outside the domain, dedicated accounts, one copy immutable or offline.
  • Testing: one system every quarter, a full scenario once a year.

RPO and RTO are set not by IT but by management together with the business units. A cloud copy meets the off-site requirement if it is versioned, immutable for a defined period and not reachable with local network credentials. Criteria for data centre, cloud or tape are on the page Cloud, hybrid and on-premises.

The restore test is a recurring procedure with fixed roles and a documented result:

  1. Define the scenario, for example file server and domain controller encrypted by attackers with domain administrator rights.
  2. Provide an isolated environment, never the production systems.
  3. Restore from the immutable copy, not from the most convenient one.
  4. Measure time and check the result: note the duration, spot-check completeness, start the applications.
  5. Document deviations: missing credentials, unknown dependencies, outdated instructions, each as a task with an owner.
  6. Adjust the concept. If the measured time exceeds the RTO, the technology or the expectation changes.

Restore one system fully at least once a quarter and rehearse a full scenario once a year. If day-to-day business leaves no time, the routine belongs with an operator responsible for backup, monitoring and testing.

Key points

  • A backup that an attacker with administrator rights can reach does not protect against ransomware. At least one copy must be offline or immutable.
  • RPO and RTO are set by management together with the business units; the technology follows from them.
  • Only a regular restore test shows whether the backup holds up in an emergency and how long restoring takes.

How DEVACON handles backup, monitoring and restore tests as part of ongoing operations is described on the page Managed IT Services.

Topics Backup Ransomware Data protection Business continuity IT-Grundschutz

This article comes from the DEVACON blog and was editorially revised for the new website.