Proxmox Homelab: ZFS Replication, Quorum and HA

My homelab started with a single Proxmox node running virtual machines for web servers, databases and cloud storage. Consolidating those workloads simplified management, but it also concentrated risk: one failed host could take everything offline.

Adding a second node let me explore ZFS replication and high availability. The important lesson is that a cluster, a replica and a backup solve different problems. Having two servers does not, by itself, guarantee uninterrupted service or zero data loss.

This is an architectural account of that homelab, not a version-specific installation runbook. The original setup did not record enough version and configuration detail to present its commands as a reproducible deployment guide.

What changes when you add a second node?

Proxmox VE combines KVM virtual machines, LXC containers and cluster management. A second host provides somewhere else to run a workload, but recovery still depends on several prerequisites:

The surviving host needs enough spare CPU, memory and storage for the workloads it must recover.
Guest disks must be accessible on that host, through shared storage or a supported replication setup.
Network bridges and other guest dependencies must exist on the recovery target.
The cluster must be able to make safe decisions about ownership.
Resources need to be explicitly managed by HA; joining a cluster does not enable HA for every guest.

Network design matters as much as the hosts. Replication traffic should not starve latency-sensitive cluster communication. Size and test the network against the data change rate rather than assuming that a particular link speed guarantees a working cluster.

Why I chose local ZFS replication

I chose ZFS for the two-node setup rather than adding the operational complexity of Ceph. That is a choice about the size and constraints of this homelab, not a general recommendation against distributed storage.

Proxmox storage options serve different purposes:

Storage	Main consideration
LVM	Block storage backed by logical volumes; it is not a replication system.
LVM Thin	Thin provisioning and snapshots, with careful free-space monitoring.
Directory	File-based storage whose durability depends on the underlying filesystem and devices.
Local ZFS	Checksums, snapshots and support for Proxmox’s storage replication framework.
Ceph	Distributed storage with its own resource, network and operational requirements.

Local ZFS replication is not shared storage. Proxmox periodically transfers guest-volume snapshots to another node, sending changes incrementally after the initial synchronization. The target contains the last successfully replicated state, not necessarily the latest application write.

For an illustrative timeline, suppose the last successful snapshot represents 12:00 and the source fails at 12:04. Writes after that snapshot may be missing on the recovery target. A shorter configured interval can reduce exposure, but failed or slow replication jobs can make the actual gap much larger.

Monitor the age of the last successful replication and its errors, not just whether a schedule exists. ZFS checksums also do not mean that every corruption can be repaired: repair depends on a valid redundant copy. Compression and deduplication are separate features; deduplication should not be enabled casually without understanding its resource costs.

Quorum and the two-node trade-off

With only two voting hosts, losing one creates a quorum problem. My homelab account used a Raspberry Pi Zero as an external tie-breaker. In a two-node design, an external quorum device can help arbitrate votes, but it is not another compute host and does not hold the guest replicas.

The official HA guide recommends at least three cluster nodes for reliable quorum. Treat a two-node homelab with a quorum device as a design with additional failure cases to understand, not as an equivalent substitute for a fully redundant production cluster.

The tie-breaker also needs suitable power and network placement. Losing both a host and access to the tie-breaker can remove the remaining host’s ability to operate safely. Do not work around partitions by casually forcing quorum.

Failover is not live migration

Live migration moves a running guest while its source host is still available. After a host has failed, HA recovery instead involves safely restarting a resource on an eligible surviving host.

That distinction matters for applications: in-memory state and active connections may be lost, and a database may need crash recovery. Fencing prevents the old owner from continuing to operate while another host takes over. Quorum and fencing are complementary parts of safe recovery, not interchangeable features.

Total downtime includes failure detection, fencing, guest startup and application recovery. The original article’s one-to-two-minute statement was not a documented benchmark and should not be treated as a recovery-time guarantee.

Replication is not a backup

A replica can include an accidental deletion or an unwanted application change. Maintain independently retained backups, protect their access, and test restoration separately from host failover.

Before relying on the design, validate these scenarios in a disposable lab with recoverable test data:

A replication job fails because the target is full or unreachable, and monitoring reports the stale replica.
A host fails, the remaining partition has safe quorum, and the old owner is fenced before recovery.
A recovered guest starts with the expected networking and the application passes its health checks.
The source host returns without creating a second active owner.
A backup restores into an isolated environment and its application data can be verified.

Record the Proxmox version, topology, guest dependencies, last replicated data and measured application recovery time. Those observations are more useful than an unqualified claim that the cluster is highly available.