Which Proxmox Storage Should You Use?

Which Proxmox Storage Should You Use?

After building a three-node Proxmox cluster with Ceph, the bigger question is whether your HomeLab actually needs that complexity. In this video, I’ll compare local LVM storage, NFS, ZFS with replication, and Ceph, explain the different availability and failure models, and map each option to single-node systems, NAS-backed setups, small clusters, and real HA clusters.

The right choice depends on the availability you need, the hardware and network you already have, and how much operational complexity you want to maintain.

Quick comparison

This is my preferred shortlist for common HomeLab setups, not Proxmox's complete storage table. See the official Proxmox storage overview for every supported backend and capability.

Storage	Model	Shared between nodes	Main advantage	Main trade-off
Directory	Local file storage	No	Simple and flexible content storage	Tied to one node unless backed by shared storage
LVM	Local block storage	No	Straightforward fixed-size VM volumes	Reserves the complete virtual disk size
LVM-thin	Local thin-provisioned block storage	No	Efficient allocation, snapshots, and linked clones	Can be overcommitted and must be monitored
ZFS	Local block/file storage	No	Checksums, compression, snapshots, and disk redundancy	Still unavailable when the node is down
ZFS replication	Scheduled copies between local ZFS pools	No	Practical middle ground without a NAS or Ceph	Asynchronous; recent writes may be missing after failure
NFS	Central shared file storage	Yes	Simple migration and shared access when a NAS already exists	NAS and network become critical dependencies
Ceph RBD	Distributed shared block storage	Yes	Cluster-wide storage without one central NAS	Highest hardware, capacity, network, and maintenance cost

Important: Shared storage is not automatically redundant or highly available. It only means multiple Proxmox nodes can access the same storage.

Directory, LVM, and LVM-thin

The default Proxmox installation usually separates two local storage targets:

• local is directory storage for files such as ISO images, container templates, backups, and snippets.
• local-lvm is normally an LVM-thin pool for VM and container disks.

LVM allocates the complete virtual disk size immediately. LVM-thin allocates physical space as data is written and supports snapshots and linked clones.

Warning: Thin provisioning allows the virtual disks to exceed the physical capacity of the pool. Monitor free space and keep independent backups.

Local storage has the fewest moving parts, but another node cannot directly use those VM disks. A migration therefore needs to transfer the disk data to the destination node.

ZFS and replication

ZFS provides checksums, compression, snapshots, and software-defined redundancy through mirrors or RAIDZ. Proxmox normally stores VM disks on ZFS as block devices called zvols.

ZFS works best with direct access to the disks instead of a hardware RAID controller hiding them. Redundant copies are also required if ZFS should repair corrupted data or survive a disk failure.

ZFS remains local storage. Proxmox Storage Replication can copy a ZFS-backed VM or container to another node on a schedule. The first job transfers the complete data set; later jobs send only changes.

Important: ZFS replication is asynchronous and is not shared storage. If the source fails, the replicated copy may not contain the most recent writes. Configure Proxmox HA separately if workloads should restart automatically.

NFS

NFS lets a NAS or storage server export a directory that every allowed Proxmox node can mount. VM disks remain on the NFS server, so moving a VM between nodes does not require copying its complete disk.

NFS is often the simplest shared-storage option when a reliable NAS already exists. It can also store ISO images, templates, and backups.

Warning: Every workload on NFS depends on the storage server and network remaining available. A NAS running as a VM on one cluster node demonstrates shared access, but it does not provide storage high availability when that node fails.

Ceph RBD

Ceph RBD distributes block storage across several cluster nodes. Every Proxmox node can access the same VM disk, while Ceph stores redundant copies across its OSDs.

This removes the single central NAS dependency and supports cluster-wide storage, migration, and high-availability designs. It also requires multiple nodes, dedicated storage devices, suitable networking, and more operational maintenance.

Capacity note: With three replicas, roughly three units of raw storage are required for one unit of stored data.

Use the separate Ceph installation tutorial for the deployment steps rather than treating this comparison as a deployment guide.

Which option fits?

• One Proxmox node: Start with LVM-thin. Use ZFS when its integrity, snapshot, and local redundancy features justify the additional planning.
• Cluster with an existing reliable NAS: NFS is usually the simplest path to shared storage.
• Small cluster without shared storage: Local ZFS with scheduled replication can be a practical middle ground when some recovery-point loss is acceptable.
• Three or more nodes requiring distributed storage: Consider Ceph when shared VM disks and node-level availability justify its hardware and operational cost.

There is no reason to replace storage that already meets your requirements. Move to the next model when you need more capacity, faster migration, or a different failure model—not only because the option exists.

Backup reminder: Snapshots, RAID, ZFS replication, NFS, and Ceph do not replace independent backups.