Proxmox has spent the last year closing the gap that used to separate it from "enterprise" hypervisors. Between Proxmox VE 9 and Proxmox Backup Server 4, a lot of the features that made VMware or dedicated SAN-backed platforms feel necessary are now just there. Here's what's actually new and why it matters if you're running Proxmox in production.
Proxmox VE 9: Built on Debian 13 "Trixie"
The foundation update alone is worth noting. Proxmox VE 9.0 moved to Debian 13 "Trixie," running a 6.14.8 kernel as the stable default, with Ceph Squid (19.2.3), QEMU 10.0.2, LXC 6.0.4, and ZFS 2.3.3 under the hood. That's a meaningful refresh across the entire stack, not just a version bump.
Snapshots as volume chains. This is the headline storage feature. Proxmox VE 9 introduces vendor-agnostic snapshot support for any storage backend that supports block storage, including iSCSI and Fibre Channel-attached SANs. If you've been running VMs on a SAN and had to work around the lack of native snapshot support, that limitation is gone.
SDN Fabrics. Proxmox's software-defined networking gets a real upgrade with SDN Fabrics, designed to simplify configuring complex routed networks. It supports multiple paths between nodes with automatic failover across NICs, which means you can now build proper two-layer spine-leaf network architectures directly in Proxmox instead of hand-rolling it at the switch layer.
Live RAID-Z expansion. ZFS now supports adding new devices to an existing RAID-Z pool with minimal downtime. Growing storage used to mean rebuilding the pool. Now it doesn't.
Taken together, these three changes push Proxmox meaningfully further into "real SAN and real network fabric" territory. This isn't just a hypervisor for a couple of local-disk hosts anymore.
Proxmox Backup Server 4.2: S3 Goes Stable
PBS has had just as significant a release cycle. Proxmox Backup Server 4.0 shipped with technology-preview support for S3-compatible object storage as a backup backend, along with ZFS 2.3 (bringing RAID-Z expansion to the backup side too) and the ability to auto-trigger sync jobs when a removable datastore gets mounted, handy for rotating offsite drives.
PBS 4.2, released in spring 2026, took S3 support out of tech preview entirely. A few things worth knowing if you're considering it:
S3 is now fully supported, opening the door to backing up to MinIO, Ceph RGW, AWS S3, or any compatible provider, not just local disk or tape.
Local caching is required. Even though the data lives in the object store, PBS needs a local persistent cache to keep performance reasonable and cut down on backend requests. Proxmox recommends 64 to 128 GiB for that cache, so budget local disk accordingly.
Request/traffic statistics are now visualized right in the datastore summary, which makes it much easier to spot unexpected traffic spikes early, useful both for cost control and for catching something that looks off.
One real gotcha: PBS does not support S3 Object Lock or bucket versioning, and turning on Object Lock at the bucket level can actually corrupt the datastore structure. If you're pairing this with an immutable-backup requirement for ransomware protection, don't reach for Object Lock. Handle immutability at the PBS layer instead.
Why This Roundup Matters
None of these are flashy, standalone headline features. They're the unglamorous plumbing that determines whether a platform can actually run your production environment instead of just your test lab. Snapshot support on SAN storage, spine-leaf networking, live pool expansion, and stable S3-backed offsite backup are exactly the kind of gaps that used to send people back to VMware or a commercial SAN vendor. With VE 9 and PBS 4.2, those gaps are a lot smaller.
Combined with Veeam's growing native support for Proxmox (replication, instant recovery, and full Web UI management as of Veeam 13.1), the case for treating Proxmox as a first-tier platform, not just a budget option, keeps getting stronger.
If you're on an older Proxmox VE 8.x or PBS 3.x deployment, it's worth planning the upgrade path now rather than waiting. As always with major version jumps, test the upgrade in a non-production cluster first. Happy to help you plan it out.
Want this reviewed against your environment?
We'll walk your stack with you and tell you plainly what we'd change first.