3-2-1-1-0: The Extended Backup Formula for 2026

The classic 3-2-1 rule — three copies, two media, one copy offsite — has been the gold standard for decades. It comes from a time when the main threat was a burst water pipe in the server room, not an automated ransomware attack that specifically hunts for your Veeam repository. In 2026, that is no longer enough. Modern attackers dwell in networks for weeks on average before striking — and the first target today is almost always the backup system itself.

The extended 3-2-1-1-0 formula closes these gaps. It adds two digits to the classic rule that address exactly the two weak spots where backups have failed most often in recent years: an immutable or physically air-gapped copy — and rigorous verification of every restore. In this article we explain what each digit means in an SMB context, what a clean implementation with TrueNAS SCALE, Proxmox Backup Server and S3 object storage looks like, and where the typical pitfalls lie.

The Formula at a Glance

Each digit in the formula addresses a specific failure scenario. Drop any one number and you no longer cover that particular threat class:

Digit	Meaning	Addresses
3	Three total copies of the data (production + two backups)	Single-point failures, data corruption
2	Two different media or storage classes	Silent corruption, firmware bugs, media failure
1	One copy geographically offsite	Fire, water damage, theft
1	One copy immutable or air-gapped	Ransomware, insider threats, misconfiguration
0	Zero errors on restore tests	Blind trust in green backup jobs

The key observation: the first three digits protect against technical failures, the fourth against active attackers, and the fifth against yourself. And the last one is by far the most commonly overlooked.

The Extra 1: Immutable or Air-Gapped

Ransomware operators know that backups destroy their business model. That is why the first step after a breach today is finding the backup server, its credentials, and deleting or encrypting the repositories. A simple “backup to NAS” is worthless if the NAS is reachable via a domain account or SMB share.

There are three practical ways to implement this extra 1 in a mid-market environment:

a) ZFS snapshots with retention lock: On a TrueNAS system, snapshots are created via task scheduler and protected by a retention policy. The repository user (e.g. the PBS datastore) only has access to the live dataset, not to the .zfs/snapshot/ directories. Even if an attacker encrypts the datastore, the snapshots survive — a recursive zfs destroy is impossible without root access.

b) Object Lock via S3: Storj, Wasabi, AWS S3, or a self-hosted MinIO/Ceph offer S3 Object Lock in compliance mode. Objects cannot be overwritten or deleted for the defined retention period — not even by the account root. Proxmox Backup Server 3.4 and Veeam 13 speak S3 natively.

c) Classic air gap: A removable medium (LTO tape, USB drive) is physically disconnected after the backup. Cumbersome, but the only option that is also absolutely safe against zero-day attacks on the storage firmware. For many SMB customers we run a combination of a) and b).

The 0: Verified Restores

The most important digit in the formula is the 0. A backup that has never been restored is, strictly speaking, an act of faith. In our customer projects we regularly see situations where the backup job has been reporting green for months — but the restore fails on a corrupt deduplication chunk, a changed encryption passphrase, or simply on a missing verify configuration.

Proxmox Backup Server offers two built-in mechanisms for this that together catch nearly all failure classes:

# Weekly deep verify of all snapshots in the datastore
# (validates chunk integrity against stored SHA-256 hashes)
proxmox-backup-manager verify-job create weekly-verify \
    --store main \
    --schedule "sat 02:00" \
    --outdated-after 7 \
    --ignore-verified true

# Automated test restore of a VM into an isolated network
qm importsnapshot 9999 backup:vm/101/2026-08-25T22:00:00Z \
    --storage restore-test --target-vlan 4094

The second building block is the automated restore test: a small selection of critical VMs is restored weekly into an isolated VLAN (typically VLAN 4094 on the OPNsense in our setups), booted, and functionally checked via a simple HTTP or SSH probe. Anyone who does not test real restores is also not testing their runbooks — and in the real event you then discover that AD login does not work without a DC, because the DC itself has not been restored yet.

Reference Setup for the Mid-Market

A typical backup setup that we roll out at DATAZONE for 20-100-employee environments looks like this:

• Copy 1 — Production: Proxmox cluster with ZFS-based datastores, local ZFS snapshots every 15 minutes (24h retention).
• Copy 2 — Primary backup: Proxmox Backup Server 3.4 with a dedicated TrueNAS datastore, encrypted, daily backups, weekly verify.
• Copy 3 — Secondary backup: PBS sync job to a second TrueNAS SCALE 25.10 at a second site or in the DATAZONE data center, connected via WireGuard.
• The extra 1 — Immutable: Additional sync job to Storj with Object Lock (30-day compliance mode) for the last 4 weeks of business-critical snapshots.
• The 0 — Verify: Weekly deep verify of all snapshots plus a monthly test restore of the top three VMs into an isolated VLAN.

This setup covers all five digits, can be realized with exclusively open-source software, and scales into the double-digit TB range with a very manageable storage budget. The combination of local PBS and object-storage copy is deliberate: local PBS delivers fast restores for everyday failures (accidentally deleted VM, corrupted guest OS), while the immutable Storj copy is reserved strictly for the disaster case.

Common Implementation Mistakes

Even with the right concept, implementations fail on the same recurring points. The four most common:

1. One domain account for everything: The PBS server is joined to the domain, and the service account has access to every repository. After a DC compromise, everything is lost. Backup systems belong in a separate authentication domain with local accounts and MFA.
2. One network for everything: Backup traffic and production traffic share a VLAN, and the backup server is reachable via SMB or web UI from the client LAN. Backup networks belong in a separate security zone with strict firewall rules — connections may only be initiated from the backup server to the target.
3. Retention without immutability: A “30-day retention” in the backup tool is a housekeeping feature, not a security control. If you want to prevent deletion, you need ZFS snapshots with retention lock or S3 Object Lock — period.
4. Verify is optional: The job report shows “OK”, but verify is disabled or only runs on new chunks. Silent bit rot on HDD pools then surfaces for the first time during a real restore.

Migrating from 3-2-1 to 3-2-1-1-0

Anyone running a functioning 3-2-1 setup today does not need to start from scratch. The path to the extended formula takes three manageable steps: first, the existing backup repository is migrated from a classic SMB share to a PBS datastore with ZFS-snapshot-based immutability — or an additional object-storage sync with Object Lock is configured. Next, verify jobs and a weekly test-restore playbook are established. Only then follows the organizational hardening: separate auth domain for the backup systems, dedicated firewall zone, MFA for all administrative access.

In practice, the second step is the most expensive — not in licenses, but in process discipline. An automated restore playbook that runs monthly and whose result lands on a dashboard is the difference between “we have backup” and “we can recover”.

---

DATAZONE supports mid-market IT teams in building backup infrastructures according to the 3-2-1-1-0 formula — from concept through implementation with TrueNAS, Proxmox Backup Server and immutable object storage to the documented disaster-recovery playbook. If you want to audit your existing backup setup or design a new one, get in touch — we will review your current concept against all five digits and show you concretely where the gaps are.