Cluster vs HA vs DR: the terminology · Proxmox VE

Why this matters in production

“We have HA” is the most overused and misunderstood phrase in infrastructure. Operators and stakeholders use the same word to mean very different things. This lesson draws the lines.

The four interlocking concepts

flowchart TB
  A[Cluster] --> B[Centralised management]
  A --> C[Quorum-based safety]
  A --> D[Live migration with shared storage]
  E[High Availability] --> F[Automatic failover on host failure]
  G[Backup] --> H[Restore from a point in time]
  I[Disaster Recovery] --> J[Recover at a different site]

Concept	What it addresses	What it does NOT address
Cluster	Operational complexity	Outages, data loss, site failure
HA	Host failure	Data loss, site failure
Backup	Data loss in time	Quick recovery (restores take time)
DR	Site failure	Host failure (that’s HA)

Cluster

A cluster is a group of Proxmox nodes that share configuration, quorum, and (with shared storage) live migration. A cluster provides operational benefits. It does not provide HA, backup, or DR automatically.

HA — automatic failover

HA adds automatic recovery when a VM’s host fails. The HA manager detects the failure (via fencing/watchdog), selects a new host for the VM, and restarts it there.

Prerequisite	Why
Cluster of 3+ nodes	Quorum requires majority
Shared or distributed storage	The VM’s disk must be accessible from a surviving node
HA-enabled VM (configured)	Only managed VMs auto-failover
HA rules (node affinity)	Decide where the VM can run
Capacity for one host failure	Survivors must have room

Backup

A backup captures the VM state at a point in time and stores it independently of the cluster. Backups address data loss events that HA cannot.

Disaster recovery

DR is the ability to recover at a different site. It addresses:

Site failure (power, fire, network).
Catastrophic data loss (cluster-wide).
Geographic compliance requirements.

DR typically uses off-site backup sync, replication to a second cluster, or both.

The combinations

Need	Combination
Operational simplification	Cluster
Survive host failure	Cluster + HA + shared storage
Survive data loss	+ Backup (PBS)
Survive site failure	+ DR (off-site PBS sync or secondary cluster)
Survive ransomware	+ Encrypted + immutable + tested restore

Why the four cannot substitute for each other, stated once

The reason these are four things rather than four settings of one thing is that each addresses a different loss, and the mechanisms are structurally incapable of covering each other’s.

HA restarts a guest from its own disks. It never consults a backup. So it faithfully restarts a corrupted guest, an encrypted guest, or a guest with a bad deploy - as many times as its restart counters allow. Anything wrong inside the guest is preserved perfectly across an HA recovery, because recovery means “run this same disk image somewhere else”.

Backup preserves history; replication propagates state. A DR mechanism with a seconds-scale RPO carries a deletion to the far site within seconds. That is not a defect - keeping two sites identical is its job - but it means a fast DR copy has no recovery from a mistake. Only a mechanism with retention does. This is developed further in choosing a replication strategy.

A cluster is a management boundary, not a resilience one. Three nodes sharing configuration and quorum is convenient and buys nothing about outages until HA is enabled on top of it and the prerequisites hold.

The general shape: HA is about time, backup is about time-travel, DR is about place, and a cluster is about people. Four axes, no substitutions.

Asking the right questions when someone requests “HA”

The word arrives from a stakeholder meaning “I do not want this to be down”. Four questions turn that into something buildable, and they are worth asking in this order because each one changes what the next one means.

Question	Why it changes the answer
Down from what cause?	Host failure is HA. Corruption is backup. Site loss is DR. Bad deploy is neither.
How long may it be down?	Minutes means HA plus fast storage. Hours means restore is acceptable, which is far cheaper.
How much data may be lost?	Zero means shared storage or synchronous replication. Fifteen minutes permits ZFS replication. A day permits nightly backup.
What is the cost of being wrong?	This is the budget. Everything above is a price list.

What happens if you build HA and skip the backup layer?

You get an estate that survives the failures it will meet a few times a decade and none of the ones it will meet this year.

Node failure is genuinely rare on decent hardware in a decent facility. The things that actually take services down, in rough order of frequency:

Someone deleted or changed something.
A deploy went wrong.
A filesystem or database corrupted itself.
A certificate expired.
Storage filled up.
A node failed.

HA addresses number six. It does nothing for one through five, and for number three it makes matters slightly worse by restarting the corrupt guest until its counters run out.

The distinctive damage is not the missing capability - it is the false confidence. An organisation that has invested in a cluster, shared storage and HA reasonably believes it has bought resilience, and that belief shows up in decisions: backup retention gets trimmed, restore drills get deprioritised, the DR line item does not survive the budget round. The failure, when it comes, is discovered at the worst possible moment by people who thought they were covered.

The order to build in, if the budget arrives in stages:

Backup, with a tested restore. It covers the most failures per pound and it is the only layer with no substitute.
Offsite copy of that backup. Cheap, and it converts a backup into a DR capability for the slow case.
Cluster and shared storage. Operational leverage plus the precondition for the next step.
HA. Now it protects something you can also recover.

Building in the reverse order is the common path, because HA is the part that demos well.

Production considerations

Common mistakes

Calling a 3-node cluster without HA “highly available.”
Calling daily backups “disaster recovery.”
Believing DR is unnecessary because “the cluster is HA.”

Key takeaways

Cluster, HA, backup, and DR are different concepts.
They stack: cluster + HA + backup + DR is the full answer.
Each addresses different failure modes.

Knowledge check

Why this matters

This lesson has no commands in it, and it prevents more expensive mistakes than most that do.

“We need HA” is a sentence that arrives fully formed from somewhere else in the organisation, and it is almost always shorthand for something more specific that the speaker has not decomposed. Building it literally produces an estate with an impressive cluster and no answer for the failures it will actually meet - because host failure, the one thing HA covers, is not the thing that takes services down most weeks.

The four questions are worth memorising precisely because they are boring: cause, duration, data loss, cost. They take five minutes, they cost nothing, and they turn a word into a design with a price attached. An engineer who asks them ends up building the right thing and can explain the bill. An engineer who does not ends up defending a cluster that did not prevent the outage everyone is now discussing.