Ceph, StarWind, or Something Else? The Awkward Middle Ground of HA Storage in Proxmox

There's a very specific moment every Proxmox admin hits. You've got a small cluster humming along. Live migration works. HA restarts mostly behave. Your dashboards look clean. And then you ask the forbidden question: what if I want my storage to just stay up when a node dies? Not "eventually recover." Not "degraded but fine if I don't touch it." You want boring, enterprise-style availability. Same IP. Same mount. Same Samba or NFS share. One node disappears and everything keeps chugging like nothing happened. That's where things get weird. On paper, Proxmox gives you options. Lots of them. In practice, most people end up stuck in an uncomfortable middle ground between "this technically works" and "why is this so much harder than my Synology." And that tension is exactly where Ceph, StarWind VSAN, clustered filesystems, and DIY NAS ideas start colliding. ## The Synology-shaped hole in Proxmox If you've ever run Synology High Availability, you know how spoiled it makes you. Two boxes. One active, one passive. A floating IP. CIFS and NFS don't care which box is alive. Plex doesn't panic. Containers don't need therapy afterward. Trying to replicate that experience inside a Proxmox cluster feels like reverse engineering a magic trick. You can absolutely get shared storage. You can get redundancy. You can even get decent performance. What's hard is getting all of those at once without turning your setup into a science experiment. Most people come into this thinking, "I already have HA storage, so I'll just layer network services on top of it." That's where reality starts pushing back. ## Ceph: the answer everyone gives, even when it hurts Ceph comes up immediately in these conversations, for good reason. It's native. It's integrated. Proxmox practically nudges you toward it every time you click "Datacenter." Block storage with RBD? Solid. HA VM disks? Great. CephFS for shared access? Now things get interesting. CephFS can give you a single, shared filesystem that multiple nodes mount at once. That sounds like exactly what you want for media, surveillance footage, and bulk storage workloads. In theory, you point your containers at CephFS and call it a day. In practice, CephFS inherits all of Ceph's baggage. Small clusters struggle. Two-node pools are a durability nightmare. Running size=2 replicas might look fine until something corrupts and Ceph has no idea which copy is "correct." HDD-backed pools feel slow unless you throw more spindles and faster networking at the problem. And recovery traffic can stomp all over your normal workloads unless you've designed the network correctly from day one. Ceph doesn't fail gracefully. It fails loudly, with opinions. That's why experienced admins keep saying the same thing: Ceph works best when every node participates, the failure domain is hosts, and the network is fast enough to absorb rebuilds without flinching. Anything less and you're accepting risk, whether you admit it or not. ## StarWind VSAN: great block storage, awkward file services StarWind VSAN sits in an interesting spot. As a replicated iSCSI solution, it does exactly what it promises. High availability block devices. Predictable behavior. Fewer moving parts than Ceph. For VM disks, it's clean and reliable. For bulk file access, things get complicated. The moment you say "I want Samba or NFS with a floating IP," you've stepped outside StarWind's comfort zone. Now you need something on top of that replicated block device that understands clustering, fencing, and failover. Mounting the same LVM-backed volume group from multiple nodes is a hard no. That's how you corrupt data fast. So you start looking at clustered filesystems like GFS2 or OCFS2, and suddenly your simple storage question turns into a thesis defense. Clustered filesystems work, but they're not forgiving. Locking behavior matters. Latency matters. Containers don't always behave nicely with them. And troubleshooting becomes an exercise in reading man pages written by people who assume you already know the answers. StarWind gives you strong primitives. It doesn't give you a Synology-style experience out of the box. ## The "just pass it to containers" trap A common instinct is to avoid VMs entirely and just pass storage straight into containers. It sounds elegant. Less overhead. Fewer layers. More control. This works until you remember that containers don't magically solve shared-write problems. If multiple nodes might run the same container, or restart it during failover, they all need consistent access to the same data. That means either a clustered filesystem or a single active node at any given time. Once you introduce "single active," you're basically rebuilding HA from scratch. You need a leader election. You need IP failover. You need to ensure the storage is mounted in exactly one place at a time. At that point, you're halfway to running a NAS VM anyway. ## Why "active-active NAS" is rarer than you think People often ask why more open solutions don't just do what NetApp or enterprise arrays do. The answer is simple: it's hard, and it's expensive. True active-active NAS requires tight coordination, rock-solid locking, and decades of edge-case handling. NetApp charges what it charges because that polish didn't happen overnight. Open-source projects tend to pick a lane. Ceph focuses on distributed storage primitives. TrueNAS focuses on being a NAS. Proxmox focuses on virtualization. None of them fully replace the others without tradeoffs. You can run TrueNAS on top of HA storage. You can float IPs using keepalived or Corosync. You can glue this all together. But no one pretends it's simple. ## Performance expectations vs reality A lot of these debates come down to expectations. Wanting 200 MB/s read and write speeds isn't outrageous. What trips people up is how that performance behaves during failure. Two-node replication means every write goes to both nodes. Lose one node and you're instantly degraded. Rebuilds hammer the remaining disk. Latency spikes. Services stutter. That doesn't mean it's unusable. It means you need to be honest about what "high availability" actually looks like at home. Sometimes it means "it comes back quickly." Not "no one notices." ## The quiet truth: backups matter more than perfect HA One of the most grounded takes in these discussions is also the least exciting: focus on backups. Running Proxmox Backup Server, replicating to a NAS, keeping local short-term backups and off-node long-term ones — that setup saves more homelabs than any exotic HA design. HA keeps things running. Backups save your data. Confusing the two is how people end up angry at Ceph for doing exactly what it was designed to do. ## So what's the least bad answer? There isn't a single one. That's the uncomfortable part. If you want tight Proxmox integration and can scale properly, Ceph remains the cleanest solution — especially if you accept its rules and design around them. If you already trust StarWind VSAN, treat it as block storage and layer services carefully, knowing you're building something custom. If you want Synology-level polish, there's no shame in letting a NAS be a NAS and focusing Proxmox on compute. The middle ground exists. It's just not smooth. And that's the part no one really warns you about.