ZFS vs Ceph for a small homelab: when is Ceph worth it?

Choose ZFS for one or two homelab hosts, backup targets, media storage, and any setup where a short recovery window is acceptable. Choose Ceph only when at least three always-on hosts must access the same VM or container storage and an acknowledged write cannot wait for the next asynchronous replication job. Ceph is not a faster replacement filesystem for a single ZFS box; it is a distributed storage system that buys host-level availability with network, capacity, memory, drive-endurance, and operational cost. Our August 6, 2026 three-node failure model found that both designs can recover from one failed host, but a ZFS-replicated guest may return with data as old as its replication interval. A correctly configured three-replica Ceph pool keeps the acknowledged-write recovery point at zero while two hosts remain in quorum.

The decision in one table

Question	Local ZFS with replication	Ceph replicated pool
Smallest sensible shape	One storage host; two hosts if you want a remote replica	Three storage hosts and three monitors; more hosts improve failure margin and scale
Storage access	Local pool; remote copies arrive on a schedule	Shared RBD, CephFS, or object storage across the cluster
Single-host failure	Recover from the latest replica; possible data gap	Remaining hosts can keep serving acknowledged data when quorum and min_size are met
Network floor	1GbE can be enough for light scheduled replication; faster links shorten sync and migration	Proxmox recommends at least dedicated 10Gbps for Ceph traffic
Raw-capacity cost	Depends on local vdev layout and number of remote replicas	Replicated size=3 stores three copies, so about one-third of raw capacity is logical before reserve and metadata
Operational burden	Scrub, snapshots, replication, backups, and pool monitoring	All ZFS-like hardware duties plus monitors, OSDs, placement groups, recovery, quorum, and cluster networking
Best reason to choose it	Simplicity and strong single-host data integrity	Shared storage with host-failure continuity and zero-RPO acknowledged writes

If your actual question is how to arrange four drives inside one server, use our tested four-bay ZFS mirror vs RAIDZ2 guide. This comparison starts one level higher: whether the storage system itself must span hosts.

ZFS and Ceph are not direct equivalents

OpenZFS combines a filesystem, volume manager, end-to-end checksums, snapshots, and local redundancy. zfs send and zfs receive can transfer a full snapshot and then only changed blocks to another pool. That makes ZFS excellent for a single NAS, a virtualization host, and scheduled disaster-recovery copies.

Ceph distributes objects across OSD daemons and exposes them as block storage through RBD, files through CephFS, or objects through RGW. Its CRUSH placement system, monitors, and placement groups exist to keep data available while machines and disks enter or leave the cluster. Comparing “ZFS vs Ceph performance” without naming the topology is therefore misleading: local ZFS serves an I/O from one machine, while Ceph may place and acknowledge several copies across a network.

The relevant homelab comparison is usually local ZFS plus Proxmox replication versus a hyper-converged Ceph RBD pool. Proxmox calls ZFS replication an alternative for smaller clusters but explicitly warns that it is asynchronous and may lose data written after the last successful job. Its Ceph guidance instead treats the pool as shared storage.

TopInsight test: what one failed host changes

We published a reproducible Node.js decision matrix. Run it with:

node zfs-ceph-homelab-decision-matrix-2026-08-06.mjs --interval=15

Tested on August 6, 2026, with Windows 11 and Node.js 24.16.0. The model uses three hosts, three VMs, local two-drive ZFS mirrors, one scheduled replica of each VM on the next host, and a Ceph pool with size=3, min_size=2, and host-level failure domains. It enumerates every combination of zero through three failed hosts.

Failure	ZFS automatic recovery path	ZFS maximum recovered-data age	Ceph writable	Ceph acknowledged-write RPO
Host A	Yes; one VM uses its remote replica	15 minutes	Yes	0 minutes
Host B	Yes; one VM uses its remote replica	15 minutes	Yes	0 minutes
Host C	Yes; one VM uses its remote replica	15 minutes	Yes	0 minutes
Any two hosts	No automatic HA quorum	Not applicable	No monitor quorum / below min_size	Not applicable

All three one-host cases passed. With six 1TB data devices, the same script also shows the copy-factor upper bounds before metadata, free-space reserve, and uneven placement: two-disk local mirrors plus one remote copy provide 1.5TB of unique fully replicated VM data, while Ceph size=3 provides 2TB. That is not a promise of usable production capacity; it explains that mirrored ZFS plus a second mirrored host writes four physical copies, whereas Ceph’s default replicated pool writes three.

This is a topology and recovery test, not an IOPS benchmark. Ceph was not installed on this Windows workstation, no disk or network latency was measured, and we do not present calculated availability as firsthand cluster uptime. Before a real migration, repeat the failure test on the exact switches, NICs, drives, Proxmox release, Ceph release, and workload that will carry production data.

What the test actually proves

Both approaches can survive one host failure when they are built correctly. The difference is the state of the recovered guest:

• A ZFS replica is a snapshot from a scheduled point in time. At a 15-minute interval, the failed guest can lose up to roughly 15 minutes of writes. The minimum Proxmox interval can be shorter, but tighter replication increases I/O and network pressure and still is not synchronous shared storage.
• A Ceph client receives a successful acknowledgement only after the pool’s replica rule and minimum-size condition are satisfied. With size=3 and the usual derived minimum of two, one host can fail and the pool can continue serving acknowledged data from two copies.
• Neither design makes a three-node cluster safe after two host failures. Two failed monitors remove majority quorum; with only one host online, a three-copy pool also cannot meet min_size=2. ZFS copies may physically exist on the survivor, but Proxmox HA should not auto-start workloads without quorum.

Ceph therefore becomes worthwhile when the recovery-point objective, not enthusiasm for clustering, demands it.

Stay with ZFS when these statements are true

Use ZFS when most of the following describe your lab:

1. There is one main storage server or one virtualization host.
2. A service can be restarted manually or can lose the last few minutes of writes.
3. The workload is media, backups, documents, or replaceable lab VMs rather than a write-heavy shared VM fleet.
4. You have fewer than three storage-capable hosts, or the third machine is only a quorum device.
5. Your network is 1GbE or shared 2.5GbE and a dedicated cluster fabric is not in budget.
6. You would rather restore a service than operate distributed storage during a disk, host, or network incident.

ZFS still needs real operational work: persistent device paths, scrubs, SMART alerts, snapshots, tested zfs send replication, and backups outside the pool. For file synchronization rather than VM HA, our TrueNAS and Syncthing guide separates live sync, versioning, snapshots, and backup instead of treating them as interchangeable.

Move to Ceph only when these statements are true

Ceph earns its cost when all or nearly all of these are true:

1. At least three hosts run continuously and each has a dedicated raw OSD device.
2. VMs or containers must restart on another host without first copying their disks.
3. The acceptable RPO for acknowledged VM-disk writes is zero during one-host failure.
4. You can dedicate at least 10Gbps networking to Ceph traffic, monitor latency, and test recovery while clients are busy.
5. Capacity planning can absorb three replicas plus free space for recovery and rebalancing.
6. The drives have appropriate endurance and power-loss behavior for the write workload.
7. Someone will respond to HEALTH_WARN, slow requests, full-ratio alerts, failed OSDs, and monitor quorum problems.

Ceph’s August 2026 upstream stable release is 20.2.2 Tentacle. OpenZFS’s current release used for this comparison is 2.4.2. Those upstream numbers are not permission to install unsupported packages into a hypervisor: on Proxmox, follow the Ceph train and upgrade path supported by the exact Proxmox release.

The hardware floor is higher than “three mini PCs and spare SSDs.” Current Ceph documentation calls for at least 4GB of memory per OSD daemon, recommends enterprise SSDs with power-loss protection for production work, and warns that replication and recovery can saturate 10GbE or even 25GbE on dense or NVMe nodes. Proxmox recommends at least three preferably identical servers and a network of 10Gbps or more used exclusively for Ceph traffic.

You can experiment on 1GbE or 2.5GbE; that makes a useful learning cluster, not evidence that the topology meets a production recovery objective. If the aim is to learn Ceph, say so and score success by installation, failure injection, and recovery—not by beating local ZFS latency.

Reddit and video evidence, reconciled

Recent r/Proxmox discussions expose the real tradeoff better than a slogan. In a July 2026 three-host lab thread, one operator reported good results with multiple NVMe drives and dual 10GbE, while another said a powerful three-node Ceph deployment stalled under backup load and improved after moving to ZFS replication. The same thread’s practical consensus was narrower: three nodes are useful for learning, but small-node performance depends heavily on drives, network, workload, and recovery behavior.

A May 2026 thread from a satisfied three-node Ceph operator still called the system resource-hungry and overkill, then compared ZFS replication, external NAS, and other distributed options. A February thread repeated the network split: some light homelabs work on dedicated 2.5GbE, but experienced users recommend 10GbE because each write and every rebuild crosses the storage network. These are individual experiences, not vendor specifications; they show why a hardware label cannot predict results.

The videos emphasize the attractive side. Craft Computing demonstrates the integrated Proxmox/Ceph workflow, Kello Labs tests failure and VM restart on a three-node build, and Lawrence Systems explains the architectural ZFS/Ceph split. The demonstrations prove that small Ceph can work. Reddit adds the missing operational counterweight: the same design can feel effortless on a light, well-networked lab and disappointing on consumer SSDs or congested links.

TopInsight’s conclusion is therefore conditional, not “YouTube says yes, Reddit says no”: Ceph is justified by an availability requirement you can test. Without that requirement, ZFS is the better homelab default.

A safe adoption plan

1. Write down RPO and RTO first. If 15 minutes of possible data loss and a manual restart are acceptable, test ZFS replication before buying cluster hardware.
2. Build the network and monitoring before the pool. Measure latency, packet loss, and sustained recovery traffic on the intended Ceph interfaces.
3. Use dedicated OSD devices and keep the hypervisor boot disk separate. Do not place Ceph on top of a hardware RAID virtual disk.
4. Start with disposable workloads. Pull one host, one OSD, one NIC, and the Ceph switch path separately while recording guest I/O latency and recovery time.
5. Keep an independent backup. Ceph replication and ZFS redundancy both replicate deletion, corruption, credentials, and operator mistakes.
6. Recheck capacity at degraded-state limits, not just healthy-state totals. A cluster that is nearly full may be unable to recover safely after losing a host.

Our three-node Proxmox HA guide covers the surrounding compute and quorum design. Read it as a build companion, but use the stricter hardware and network thresholds in this 2026 comparison where the older article differs. The Proxmox VE review provides the broader hypervisor decision context.

Final verdict

For most small homelabs, start with ZFS. Add snapshots, off-host replication, monitoring, and tested restore before adding distributed storage. Choose Ceph when three or more always-on hosts need the same storage, one failed host must not create an asynchronous-write gap, and you can fund and operate the network and drive layer that make that promise credible.

Ceph is not the next level after ZFS; it solves a different failure domain. If the service can tolerate a short gap and restart, ZFS is simpler. If acknowledged writes and shared VM disks must remain available through one host failure, Ceph is the tool—and the reproducible failure drill, not the cluster diagram, is the proof.