Offline encrypted backup: the 3-2-1 rule that survives ransomware

The 3-2-1 rule—three copies, two media, one offsite—no longer stops attackers who delete backups before encrypting data. The updated 3-2-1-1-0 standard adds immutability and zero restoration errors, but demands modern tooling like Restic or Borg to implement without relying on cloud providers.

Why the classic 3-2-1 rule fails against ransomware

In 2012, photographer Peter Krogh popularised the 3-2-1 backup rule as the gold standard: three copies of data, on two different media, with one copy offsite. The issue isn’t the rule itself, but its literal interpretation in a landscape where attackers prioritise deleting backups before encrypting files. According to Veeam’s 2023 report, 93% of ransomware attacks attempt to delete or encrypt backups, succeeding in 75% of cases.

The common mistake is assuming "offsite" equals "secure." If the offsite backup is mounted as a network drive (e.g., a NAS synced to the cloud), an attacker with compromised credentials can access it. We’ve documented cases at CyberShield involving SMEs that lost critical data because their "offsite copy" was an automatically synced Google Drive: the ransomware deleted local files, and the sync propagated the deletion.

Available literature suggests the average time between initial infection and backup deletion is 4.5 hours (NIST SP 1800-25, 2020). This means any backup accessible from the compromised system—even if on a separate server—is vulnerable.

The 3-2-1-1-0 update: immutability and zero errors

Veeam proposed the 3-2-1-1-0 extension in 2019, where the two additional digits represent:

1 immutable copy: stored on media that cannot be modified or deleted for a defined period (e.g., S3 object lock, WORM tape).
0 restoration errors: automatic validation that backups are recoverable, not just that they exist.

Immutability is critical because 60% of SMEs that pay ransoms do so because their backups were corrupted or incomplete (Sophos, 2023). However, implementing it in small environments faces two obstacles:

Cloud providers charge premiums for object lock (e.g., AWS S3 Glacier Deep Archive with object lock costs ~$0.0036/GB/month vs $0.00099 without lock).
Traditional solutions like Veeam or Commvault require complex infrastructure (backup servers, licences, dedicated storage).

For SMEs, the pragmatic alternative is to use open-source tools that support encryption and immutable storage on affordable media:

Restic: supports immutable repositories with `--append-only` and AES-256 encryption. Can write to local disks, SFTP, or S3 buckets with object lock.
Borg: offers compression and deduplication, with append-only repositories. Ideal for backups on encrypted external drives.
Duplicacy: enables incremental backups with storage across multiple destinations (e.g., local + Backblaze B2 + USB drive).

Implementing 3-2-1-1-0 with Restic: a concrete example

Consider an SME with 500 GB of critical data (databases, documents, emails). The strategy would be:

Copies (3+):
- 1: encrypted local disk (e.g., Veracrypt) with daily snapshots.
- 2: Restic repository in an S3 bucket with object lock (30-day retention).
- 3: encrypted external USB drive (LUKS) stored in a separate physical location (e.g., bank safe). Rotated weekly.
Media (2):
- 1: disk storage (local + USB).
- 2: object storage (S3).
Offsite (1): the S3 bucket and USB drive are kept off-premises.
Immutable (1): the S3 bucket has object lock configured for 30 days. Restic runs with `--append-only` to prevent accidental deletions.
Zero errors (0): a validation script randomly restores 1% of files weekly and verifies checksums.

The command to initialise the Restic repository in S3 would be:

restic -r s3:s3.amazonaws.com/bucket-name init --repository-version 2
restic -r s3:s3.amazonaws.com/bucket-name backup /data --append-only
restic -r s3:s3.amazonaws.com/bucket-name forget --keep-last 30 --keep-daily 7 --group-by paths,tags

The monthly cost for 500 GB in S3 with object lock would be ~$1.80 (vs $0.50 without lock), but the difference is marginal compared to the risk of data loss.

The myth of "cloud backup" as a standalone solution

Many SMEs rely on services like Google Drive, Dropbox, or OneDrive as their "offsite copy." This is dangerous for three reasons:

Bidirectional sync: if ransomware deletes local files, the sync deletes them in the cloud too. Dropbox, for example, retains versions for only 30 days on its basic plan.
Lack of immutability: while some services offer "versioning," it’s not the same as object lock. An attacker with credentials can delete all versions.
Encryption in transit ≠ encryption at rest: services like Google Drive encrypt data in transit but don’t offer client-side encryption. This means Google holds the keys to decrypt data, making it vulnerable to internal breaches or legal requests.

The alternative is to use services that support client-side encryption and immutable repositories, such as:

Backblaze B2 with object lock + Restic.
Wasabi (S3-compatible) + Duplicacy.
Tahoe-LAFS (for environments with extreme privacy requirements).

At CyberShield, we’ve verified that SMEs combining Restic with Backblaze B2 achieve costs of ~$3/month for 500 GB, with immutability and client-side encryption.

The weakest link: rotating offline media

The offline copy (e.g., USB drive) is the most secure against ransomware but also the most prone to failure due to:

Human error: forgetting to rotate the drive, storing it insecurely, or failing to encrypt it.
Physical degradation: USB drives have a lifespan of ~5 years. If not rotated, they may fail when needed for restoration.
Lack of validation: many SMEs assume the drive "is fine" because it’s stored, but don’t verify data recoverability.

The solution is to automate rotation and validation:

Use two USB drives rotated weekly (e.g., Drive A Week 1, Drive B Week 2).
Store them in separate physical locations (e.g., one in the office, one in a bank safe).
Automatically validate backups with a script that mounts the drive, verifies checksums, and alerts on failure.

A sample validation script for Restic:

#!/bin/bash
USB_DRIVE="/mnt/backup_usb"
RESTIC_REPO="restic -r $USB_DRIVE::repo"
$RESTIC_REPO check --read-data-subset=1%
if [ $? -ne 0 ]; then
  echo "USB backup error" | mail -s "ALERT: Corrupt backup" admin@company.com
fi

Trade-offs: what to sacrifice when the budget is limited

Implementing 3-2-1-1-0 in a resource-constrained SME requires prioritisation. These are the trade-offs we’ve observed at CyberShield:

Priority	What to sacrifice	What not to sacrifice
1. Immutability	Use object lock only for the most critical copy (e.g., databases).	Never sacrifice immutability for at least one copy.
2. Encryption	Use client-side encryption only for sensitive data (e.g., legal documents).	Never store backups without encryption at rest.
3. Validation	Validate only a subset of files (e.g., 10%) instead of all.	Never assume a backup is recoverable without testing it.
4. Offsite	Use a USB drive in a separate physical location (e.g., owner’s home) instead of cloud.	Never keep all copies in the same physical location.

The worst trade-off is sacrificing immutability. Without it, an attacker can delete all copies, reducing 3-2-1-1-0 to 0-0-0-0-0.

An SME’s resilience against ransomware doesn’t depend on expensive tools, but on operational discipline: encrypted, immutable, and validated backups stored on diverse media in separate locations. The 3-2-1-1-0 rule isn’t a product—it’s a process that requires modern tooling like Restic or Borg to be viable without cloud provider dependency. In a landscape where 60% of SMEs close after a ransomware attack (National Cyber Security Alliance, 2023), the question isn’t whether you can afford to implement this rule, but whether you can afford not to.

The CyberShield team provides 24/7 cybersecurity for LATAM SMEs with a proprietary stack that includes real-time CVE monitoring and automated response. In an environment where attackers evolve faster than budgets, the only sustainable advantage is the one you build yourself: backups that cannot be deleted, encrypted, or corrupted.