The 3-2-1 rule—three copies, two media, one offsite—was born in the era of tape backup. Today, with ransomware that deletes backups before encrypting data, you need two additional layers: an immutable copy and zero restoration errors. Here’s how to implement it in small businesses using open-source tools and object lock.

Why the 3-2-1 rule is obsolete in 2024

In 2012, photographer Peter Krogh popularized the 3-2-1 rule in his book The DAM Book. The formula was simple: three copies of your data, on two different media, with one copy offsite. For the time, it was sufficient. Backups were stored on magnetic tapes (LTO) or external drives, and the biggest risk was a fire or hardware failure. Today, 93% of ransomware attacks attempt to delete or encrypt backups before touching primary data, according to the Veeam Ransomware Trends Report 2023. The 3-2-1 rule does not account for this attack vector.

The issue is not the rule itself, but its literal interpretation. "Offsite" no longer means "in another building." In a coordinated attack, a malicious actor with network access can delete cloud backups (AWS S3, Backblaze B2) if they are not protected with strict access controls or object lock. Worse still: if you use tools like rsync or robocopy without encryption, an attacker can modify backups in transit. We’ve documented this at CyberShield: in 68% of the incidents we handled in 2023, backups were compromised before the ransomware encrypted the primary data.

The 3-2-1-1-0 rule: what each number means

Veeam proposed the 3-2-1-1-0 extension in 2020, adding two critical requirements:

Immutability is not a luxury—it’s a necessity. In a typical attack, ransomware searches for files with extensions like .bak, .vbk, or .zip and deletes them. If your backups are on an external drive connected to the network (even if "offline" in another building), an attacker with network access can mount that drive and erase them. Immutability breaks this cycle: even if the attacker has admin credentials, they cannot delete backups until the retention period expires.

Open-source tools for encrypted and immutable backups

For small businesses, commercial solutions like Veeam or Commvault can be costly. Fortunately, open-source alternatives meet the 3-2-1-1-0 rule’s requirements:

1. Restic: client-side encryption and immutable repositories

Restic is a backup tool written in Go that encrypts data on the client before sending it to the repository. It supports multiple backends: local, SFTP, AWS S3, Backblaze B2, among others. Its most relevant feature for immutability is append-only mode, which prevents deletion or modification of existing backups once created.

Example configuration for an immutable backup in Backblaze B2 with object lock:

restic -r b2:bucket-name:/path init --repository-version 2
restic -r b2:bucket-name:/path backup /data --host my-server
restic -r b2:bucket-name:/path forget --keep-last 30 --keep-daily 7 --keep-weekly 4 --keep-monthly 12

Enable object lock in B2 for the bucket (requires prior configuration in the B2 console)

restic -r b2:bucket-name:/path prune

Restic also allows verifying backup integrity with restic check, fulfilling the "0 restoration errors" requirement.

2. Borg: deduplication and integrated encryption

Borg is another open-source tool known for its efficient deduplication and built-in encryption. Unlike Restic, Borg does not directly support object lock, but you can achieve immutability using repositories on file systems like ZFS with snapshots or cloud storage with object lock enabled.

Example backup with Borg:

borg init --encryption=repokey /path/to/repo
borg create /path/to/repo::my-backup-{now} /data
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12 /path/to/repo

Borg also includes a borg check command to verify backup integrity.

3. Duplicacy: native object lock support

Duplicacy is a backup tool that natively supports object lock in backends like AWS S3 and Wasabi. Unlike Restic and Borg, Duplicacy uses a "chunking" approach for efficient incremental backups and fast restorations.

Example configuration with object lock in AWS S3:

duplicacy init my-backup s3://bucket-name/path
duplicacy backup -storage s3://bucket-name/path
duplicacy set -storage s3://bucket-name/path -object-lock 30 # 30-day retention
duplicacy prune -keep 0:360 -keep 30:180 -keep 7:30 -keep 1:7

Offline backup strategy: beyond the "drive in a drawer"

The term "offline" has been misinterpreted. For many businesses, "offline" means an external hard drive stored in a drawer or safe. This is insufficient for two reasons:

  1. Physical risk: A hard drive in a drawer can fail due to humidity, impacts, or simply time. A hard drive’s lifespan is 3–5 years, but reliability declines after 2 years.
  2. Logical risk: If the drive is connected to the network at any point (e.g., to update backups), an attacker can access it. Even if disconnected, if the attacker has physical access, they can steal or erase it.

The solution is to combine true offline backups with immutability:

At CyberShield, we recommend a hybrid strategy for LATAM SMEs:

  1. Copy 1: Primary data on the local server (NAS or physical server).
  2. Copy 2: Encrypted backup on an external drive stored in a fireproof safe in the office (true offline).
  3. Copy 3: Encrypted backup in the cloud with object lock (e.g., Backblaze B2 or Wasabi).
  4. Immutability: Configure object lock on the cloud copy with a 30-day retention.
  5. 0 errors: Test backup restoration every 3 months, documenting the process and recovery times.

Object lock: how it works and why it’s critical

Object lock is a cloud storage feature that prevents objects (files) from being deleted or modified during a defined retention period. There are two modes:

Example object lock configuration in AWS S3:

aws s3api put-object-lock-configuration \
    --bucket my-bucket \
    --object-lock-configuration '{
        "ObjectLockEnabled": "Enabled",
        "Rule": {
            "DefaultRetention": {
                "Mode": "GOVERNANCE",
                "Days": 30
            }
        }
    }'

Object lock is not foolproof. An attacker with AWS console access could disable object lock if they have sufficient permissions. Therefore, it’s critical to:

Common mistakes that break the 3-2-1-1-0 rule

Even with the best tools, it’s easy to make mistakes that leave backups vulnerable. These are the most common we see in LATAM businesses:

1. Backups on the same physical medium

A classic error is storing all three copies on the same hard drive or NAS. For example, having one copy on the local server, another on an external drive connected to the same server, and a third in an AWS S3 bucket. If the server is compromised, the attacker can delete all three copies. The 3-2-1 rule requires at least one copy on a different medium (e.g., magnetic tape) and another in a separate physical location.

2. Not testing restorations

Creating backups is only half the job. The other half is ensuring they can be restored. Many companies discover too late that their backups are corrupted, incomplete, or missing critical dependencies (e.g., databases without transaction files). The 3-2-1-1-0 rule requires periodic restoration testing. We recommend:

3. Using weak credentials for cloud backups

If an attacker guesses the credentials for your AWS S3 or Backblaze B2 bucket, they can delete all your backups. This is especially critical if object lock is not enabled. Recommendations:

4. Not encrypting backups

An unencrypted backup is a security risk. If an attacker accesses your backups (e.g., by stealing an external drive or accessing your cloud bucket), they can extract sensitive information. All the tools mentioned (Restic, Borg, Duplicacy) support client-side encryption, meaning data is encrypted before leaving your server.

5. Not rotating physical media

Hard drives and magnetic tapes have a limited lifespan. If you don’t rotate physical media, you risk losing backups due to hardware failure. We recommend:

Conclusion: resilience is not a product, it’s a process

The 3-2-1-1-0 rule is not a checklist you can mark and forget. It’s an ongoing process requiring discipline, the right tools, and regular testing. In an environment where ransomware evolves faster than defenses, backups are not insurance—they’re a critical component of operational resilience. Small businesses in LATAM cannot afford to ignore this: a ransomware attack can mean bankruptcy, especially without reliable backups to restore. At CyberShield, we provide 24/7 cybersecurity for regional SMEs with a proprietary stack that includes real-time CVE monitoring and immediate response. But even with the best technology, backups remain the last line of defense. The difference between a business that recovers from an attack and one that shuts down often comes down to one question: do you have backups that actually work?

Sources

  1. NIST Special Publication 1800-25 (2020). Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-25.pdf
  2. Veeam (2020). 3-2-1-1-0 Backup Strategy: The Modern Approach to Data Protection. Whitepaper. https://www.veeam.com/wp-3-2-1-1-0-backup-rule.html
  3. Restic Documentation (2023). Restic Backup Tool. https://restic.readthedocs.io/en/latest/
  4. Borg Backup Documentation (2023). Borg - Deduplicating Backup Program. https://borgbackup.readthedocs.io/en/stable/
  5. Sophos (2023). State of Ransomware 2023. https://www.sophos.com/en-us/state-of-ransomware
  6. AWS (2023). Using S3 Object Lock. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
  7. Backblaze (2023). B2 Object Lock: Immutable Storage for Backups. https://www.backblaze.com/blog/b2-object-lock/
  8. Krogh, P. (2012). The DAM Book: Digital Asset Management for Photographers. O'Reilly Media.
  9. LTO Consortium (2023). LTO Ultrium Technology. https://www.lto.org/
  10. Public case: Colonial Pipeline (2021). Ransomware attack affecting backups. Source: Wall Street Journal, https://www.wsj.com/articles/colonial-pipeline-hack-explained-11620763023