The 3-2-1 backup rule on Proxmox

What 3-2-1 really means on a hypervisor

The rule predates virtualization, so it's worth translating. For a Proxmox VE cluster:

• Copy 1 is the running VM — the production disks. It counts as a copy, but it's the one every disaster starts with.
• Copy 2 is a backup on a different system in the same failure domain — a Proxmox Backup Server on separate hardware, or at minimum vzdump files on a NAS. Same building is fine; same disks is not.
• Copy 3 is the offsite copy — a PBS in another location that survives fire, flood, theft, and site-wide ransomware. This is the copy the rule exists for.

Where Proxmox setups quietly fail the rule

• Backups on the same ZFS pool as the VMs. One pool failure takes copies 1 and 2 together. Different system, not different dataset.
• "Offsite" that shares credentials with production. If the same root password or token reaches both sites, ransomware treats them as one site. Scope the offsite credential so it can write but not destroy — our immutability guide covers the token model.
• Snapshots counted as backups. A ZFS or VM snapshot on the same storage is a rollback point, not a copy.
• Copy 3 exists but has never restored anything. An unverified offsite copy is a hypothesis. Test it — a quarterly drill is enough.

Topology 1: the small shop (no local PBS)

A handful of VMs, one Proxmox host or a small cluster, no spare hardware for a backup server. Back up directly offsite: point Proxmox VE at a hosted PBS datastore and let the nightly job be your copies 2 and 3 in one hop — different system and different site.

This is exactly what our Dynamic plan is for: $6.95/month with the first 1TB included, connection details pasted into PVE, running in about five minutes. Purists will note it's 3-2-1 with an asterisk — two of the copies live with one provider — but for a small shop it beats the usual alternative, which is no offsite copy at all. Add a periodic vzdump to a USB disk or NAS if you want a third leg you physically control.

Topology 2: SMB with a local PBS

The textbook setup. Your PVE cluster backs up to a local PBS on its own hardware (copy 2 — fast restores, minutes to recover a VM). The local PBS then runs a push sync job to a hosted PBS offsite (copy 3), sending only changed chunks each night over a single outbound TLS connection.

Push (PBS 3.3+) is self-service and works from behind NAT and strict firewalls — the full setup is in our offsite & DR guide. Give the push job a token that can write but not prune, keep Remove vanished off, and the offsite history survives even a full compromise of the primary site.

Topology 3: multi-site

Two or more locations, each with its own PVE cluster and local PBS. Each site pushes to one hosted PBS offsite — a Dedicated Instance with a namespace per site keeps the copies separated, with per-namespace retention and per-site tokens.

The hosted copy becomes the neutral third location no single site failure can touch, and the namespace layout means site A's compromise can't reach site B's history. MSPs run the same pattern with a namespace per client.

The 3-2-1 audit checklist

• Name the three copies of your most important VM. If you hesitate, you have two.
• Would one power event, one pool failure, or one stolen credential reach two of them? Then they're not independent.
• Is the offsite copy on separate credentials that can't delete history?
• When did the offsite copy last restore something? If the answer is "never," schedule the drill this week.
• Does retention on each copy match its job — short and fast locally, longer offsite?