Most write-ups treat this as a ranking exercise, which is why so many clusters end up with one pool holding guests, templates and their own backups. The useful framing is by role: what a guest disk needs is not what an ISO library needs, and neither is what a backup destination must be. That, plus an honest account of the online move command, matters more than picking a winner.
The storage choice made during a Proxmox install tends to be permanent, because changing it later means moving every guest. It also decides which features exist: snapshots, thin provisioning, live migration between nodes and whether a failed machine's guests can restart anywhere else all follow from it.
The Question That Comes First
Before comparing filesystems, answer whether storage is local to a node or shared across the cluster. Everything else is secondary to this.
Local storage is faster, cheaper and simpler, and a guest on it can only run on that node. Lose the machine and the guest's disk is on a machine you have lost. Shared storage lets any node run any guest, which is what makes live migration and automatic failover possible at all.
A single-node deployment can reasonably use local storage and rely on backups. A cluster built for availability cannot: HA restarts a guest on a surviving node, and it can only do that if the disk is reachable from there. Our walkthrough for building a Proxmox HA cluster treats shared storage as a prerequisite rather than an option, for this reason.
The Backends, and What Each Gives Up
| Backend | Snapshots / thin | Best for |
|---|---|---|
| LVM-thin (local) | Yes / yes | Single node, block storage, low overhead |
| LVM (thick, local or shared LUN) | No / no | Shared SAN LUNs where nothing better exists |
| ZFS (local) | Yes / yes | Single node wanting checksums and replication |
| Directory on ext4 or XFS | Qcow2 only / qcow2 only | ISOs, templates, simple setups |
| Ceph RBD (shared) | Yes / yes | Clusters; the default answer for HA |
| NFS (shared) | Qcow2 only / qcow2 only | Backups, ISOs, modest shared guest storage |
| iSCSI or Fibre Channel | Depends on layer above | Existing SAN investment |
The snapshot column is where surprises live. Thick LVM cannot snapshot a guest at all, which people discover the first time they want a rollback point before an upgrade. A directory backend can snapshot, but only because qcow2 implements it in the image format, which costs performance relative to a block backend doing it properly.
ZFS Is Excellent, and Local
ZFS gives checksummed data with self-healing on redundant pools, cheap snapshots, transparent compression that usually improves both space and throughput, and send/receive replication between nodes.
Two things to be clear about. Its replication is asynchronous, so the target is minutes behind and a failover loses whatever happened since the last send. That is a good disaster recovery story and it is not shared storage, so it does not give you live migration or automatic failover with no data loss.
And its performance depends heavily on pool layout, where the choice between striped mirrors and RAID-Z changes write behaviour substantially. Our explainer on ZFS write penalties and vdev layouts covers the arithmetic; the short version is that mirrors suit virtual machine workloads and RAID-Z suits bulk sequential data.
Give ZFS RAM. The ARC is what makes it fast, and a host that has allocated nearly all its memory to guests leaves ZFS nothing to cache with, which presents as storage that is inexplicably slow.
Ceph Is the Cluster Answer
For a cluster of three or more nodes intended to survive a machine failing, Ceph RBD is the backend that makes the rest of Proxmox's features work as advertised. Every block is replicated across nodes, any node can attach any guest's disk, and a lost node's guests restart elsewhere with their data intact.
The costs are real and worth stating. It wants its own network, ideally 10 GbE or better and separate from cluster and guest traffic. It wants at least three nodes and behaves much better with more, since recovery needs somewhere to put the re-replicated data. It rewards SSD or NVMe and punishes spinning disks harder than most storage does. And size 3, min_size 2 is the configuration to run: size 2 forces a choice between stopping writes and risking data loss the moment one copy is unavailable.
Our walkthrough for setting up Ceph on Proxmox covers the network separation and the replication settings, including the capacity planning that people get wrong by forgetting the replica factor applies to usable space.
What Goes Where
Not all storage on a host should be the same storage, and separating by role is cheap.
Guest disks belong on a block backend, so Ceph RBD on a cluster or LVM-thin and ZFS on a single node. Block avoids the filesystem-in-a-file overhead of qcow2 on a directory.
ISOs, templates and container images belong on a directory or NFS backend. They are read-mostly, benefit from being shared, and do not need snapshots.
Backups belong somewhere that is not the storage they protect, which is the entire point. A Proxmox Backup Server datastore, or at minimum an NFS export on separate hardware.
Putting backups on the same Ceph pool as the guests is the arrangement that feels tidy and fails completely, since one storage incident takes the data and the means of recovering it. Our guide to Proxmox Backup Server covers the deduplication and verification that make a separate server worth running.
Migrating a Decision You Regret
Moving a guest's disk between backends is supported and online, which makes a bad initial choice recoverable rather than permanent.
qm move-disk 101 scsi0 ceph-pool --delete 1
pct move-volume 201 rootfs ceph-pool --delete 1
qm config 101 | grep scsi0It is still a full copy of every block, so it is slow, it is I/O heavy, and it should happen outside peak hours one guest at a time. Verify the guest is running on the new storage before removing the old volume, and expect a large migration to take considerably longer than the arithmetic suggests, because it competes with the guests still serving traffic.
Snapshots do not always come along. Moving a disk from a backend that supported snapshots to one that does not, or between formats, can drop snapshot history. Check what you are relying on before you move.
Or Start on Storage That Is Already Built
Commissioning Ceph properly, with separated networks and enough nodes for recovery to have somewhere to go, is the largest single piece of work in building a cluster you can trust.
MassiveGRID's platform runs Ceph underneath, replicating every block three times across independent NVMe drives, with Proxmox high-availability clustering restarting a lost node's guests automatically and a 100% uptime SLA over it. A Linux VPS is priced per resource at $2.87 per CPU core, $0.80 per GB of RAM and $0.01 per GB of SSD per month, so storage is bought in the size you need rather than in fixed tiers. HA cloud storage and backup services at $0.01 per GB cover the separate destination that backups require, and Proxmox support from $99 per node per month covers the storage design for a cluster you build yourself.
Infrastructure can be ordered across a partner footprint of more than 700 datacenters in 85 metros, 30 countries and six continents, with auto-provisioning in New York, London, Frankfurt and Singapore.