What it actually is

Storage replication, usually just called pvesr after the CLI tool and systemd timer behind it, periodically copies a guest’s disk from one node to another using zfs send and zfs receive under the hood. It is not a general-purpose backup, and it is not Ceph. It’s narrower than both: a scheduled, incremental, ZFS-to-ZFS copy of a specific guest’s disk onto a specific other node in the same cluster, kept close enough to current that HA can start that guest on the target node if the source node disappears.

Because it rides on ZFS send/receive, the mechanics are the same ones covered in the ZFS send/receive article on this site, just wired into Proxmox’s own scheduler and HA stack instead of something you run by hand or glue together with sanoid/syncoid. The first replication run is a full send of the dataset; every run after that is an incremental send of only the blocks that changed since the last successful sync, which is why replication stays cheap even on guests with large disks, as long as the actual write rate between syncs is modest.

What it requires

This only works if the requirements line up, and homelabs trip on these more often than the feature itself:

• Both the source and target node need ZFS-backed storage, and the storage ID has to exist with the same name on both nodes. Proxmox validates the job against that name, not against the underlying pool layout, so a storage named local-zfs on one node has to be named local-zfs on the other too, even if the actual pools underneath differ in size or layout.
• The guest’s disk has to actually live on that ZFS storage. A VM with its disk on local-lvm or a directory-backed store can’t be replicated this way at all; LVM-thin and plain directory storage have no send/receive equivalent Proxmox can drive. If a guest you want covered is sitting on the wrong storage type, you move the disk to a ZFS-backed store first (qm move-disk for VMs, pct move-volume for containers), then set up the replication job.
• Both nodes have to be in the same cluster. Replication is a cluster-aware feature, not a point-to-point tool you can aim at an arbitrary remote host the way a manual zfs send | ssh ... zfs receive pipeline can.
• LXC containers are covered the same way as VMs, since a container’s root filesystem on ZFS storage is just another dataset Proxmox can snapshot and send, not a special case.

Setting up a job

From the GUI, it’s attached to the guest, not the storage: open the VM or container, go to Replication, and add a job specifying the target node and a schedule. The schedule uses the same cron-like syntax as Proxmox’s backup jobs, and a short interval (commonly set to every few minutes to every fifteen minutes, depending on how much data loss is acceptable) is typical for anything HA is meant to fail over automatically. The CLI equivalent is pvesr create-local-job, useful for scripting this across a fleet of guests instead of clicking through each one.

Once the job exists, Proxmox snapshots the source dataset, sends it (full the first time, incremental after), and tracks the last successfully replicated snapshot on both ends so the next run knows exactly where to resume the incremental chain from.

How this plugs into HA

HA failover for a guest with no shared storage works by having Proxmox start that guest on the replication target node using the most recently replicated snapshot, if the source node is confirmed down by the cluster’s fencing and quorum mechanics. That’s the entire trick, and it’s also the entire limitation: the guest comes back up from whatever state existed at the last successful replication, not the actual moment the node died. Anything written between the last sync and the failure is gone. This is a real, bounded Recovery Point Objective measured in however long your replication interval is, not the zero-RPO guarantee Ceph or a real shared SAN gives you, and it’s worth being explicit with yourself about that gap before leaning on it for anything where losing the last few minutes of writes would actually hurt (a database, anything transactional), versus something where it plainly wouldn’t (a reverse proxy, most stateless services, a media server whose state is mostly read-only).

The gotchas worth knowing before you hit them

A manual snapshot outside the replication job can break the incremental chain. pvesr tracks a specific snapshot lineage to compute each incremental send. If something else deletes or renames the snapshot it’s expecting, the next replication run can’t find a common point to diff against and falls back to a full resync, which on a large disk means a slow, bandwidth-heavy re-copy instead of a quick incremental one. Leave the snapshots pvesr creates alone, and if you’re also running your own ZFS snapshot schedule on the same dataset for other reasons, be deliberate about not deleting the ones with the replication job’s naming pattern.

Changing a job’s target node forces a full resync, not an incremental move. The new target has no prior snapshot to diff against, so switching where a guest replicates to means paying the full-send cost again, scaled to however big that disk actually is. Plan replication topology with that cost in mind rather than shuffling targets casually.

A failed replication run doesn’t fail loudly on its own. A transient network blip or a target node that’s briefly unreachable just means that cycle’s sync didn’t happen; the job retries on its next scheduled run. The risk isn’t a single missed cycle, it’s a replication job that’s been silently failing for a while, during which the RPO gap just keeps growing without anyone noticing. Check the Replication tab in the GUI (it shows last-run status per job) or journalctl for pvesr periodically, the same way you’d want to notice a failed backup job rather than assume it’s fine.

Failover with replication is crash-consistent, not graceful. The guest that comes up on the target node is in the state a dataset-level snapshot captured it in, which is roughly equivalent to yanking the power on that VM at the last sync point. Most modern filesystems and databases handle that correctly on their own recovery path, but it’s a meaningfully different guarantee than a clean live migration, and it’s worth knowing which one you’re actually getting before you need it.

When this is the right tool, and when it isn’t

Storage replication earns its keep in the common small-cluster homelab shape: two or three nodes, ZFS already the storage backend of choice (which it usually already is, for the same reasons covered in the ZFS pool layout article), a handful of guests worth protecting automatically, and an RPO of a few minutes being genuinely acceptable for those guests. It gets you real automatic failover without standing up Ceph’s OSD/MON/MGR stack and its own hardware and network overhead, and without a NAS serving shared storage over NFS or iSCSI.

It’s the wrong tool if you need zero data loss on failover, since no replication-interval-based scheme gives you that, Ceph or a real shared SAN is the honest answer there. It’s also not a replacement for actual backups; a replicated disk that gets corrupted or has something deleted from it replicates that corruption or deletion to the target just as faithfully, on schedule, with no independent history to roll back to unless you’re separately keeping Proxmox Backup Server snapshots as well. And if every guest you care about is already sitting on LVM-thin or directory storage for reasons that make sense for your setup, converting just to unlock replication is a real migration project, not a config toggle, so weigh that cost against just accepting manual recovery for the guests that would need it.

Bottom line

Proxmox’s storage replication feature is the practical middle ground between “no failover plan at all” and “stand up Ceph,” and it’s already built into a cluster you likely have running today if you’re on ZFS storage. It buys real automatic HA failover at the cost of a bounded, interval-sized RPO and a few operational habits (don’t touch its snapshots, expect a full resync after changing targets, watch for silently failing jobs) that are easy to live with once you know they exist. For the two or three node ZFS-based homelab cluster this site keeps assuming as the default shape, it’s very often the right amount of complexity for the problem it solves.