Upgrade OpenZFS on Proxmox VE or PBS Without Data Loss

Upgrading OpenZFS on a Proxmox VE or Proxmox Backup Server (PBS) host comes down to two mechanical steps: update the zfs-dkms packages and reboot so the new kernel module loads. But the part almost everyone under-prepares is the gate before that reboot. If you snapshot your critical VMs, confirm a backup exists, and check your pool's feature versions first, the upgrade is low-risk — skip those and a single irreversible on-disk feature flag can stop older nodes in a cluster from importing your pool. This is the upgrade-readiness workflow I actually run before touching the ZFS stack.

Key Takeaways

• Snapshot first: Take a clean zfs snapshot of each VM disk and verify a real backup exists before you touch anything.
• Check feature versions: Run zpool upgrade to see which on-disk features would flip, because once enabled they cannot be undone.
• Reboot is mandatory: ZFS is a kernel module, so no change takes effect until the host restarts and loads the new zfs module.
• Feature upgrades are irreversible: A pool promoted to a newer feature version will not import on nodes running older OpenZFS.
• Rollback is asymmetric: Data rolls back instantly with zfs rollback; the stack itself only rolls back if you never enabled a new feature version.

How do I confirm the exact ZFS version I'm running?

Before you can plan an upgrade you need to know three things at once: the userspace tools version, the kernel module version, and what your package manager is offering. These can all differ, and mismatches are a common source of "the pool won't import" panic.

The userspace version comes from zfs and zpool:

zfs --version
zpool --version

The output has two lines — one for the userspace tools and one for the loaded kernel module. If those two numbers disagree, your running module is stale and you've already hit the reboot problem.

Then confirm what's actually installed and what's available to install:

dpkg -l | grep zfs
apt-cache policy zfs-dkms

The apt-cache policy output shows Installed: versus Candidate:. If the candidate is newer than the installed version, a package-level upgrade will move you to the new OpenZFS. On Proxmox VE you never compile ZFS from source — the Proxmox team packages OpenZFS for Debian and you pull it through the normal apt channel, so the candidate version is the version you'll get.

Finally, confirm the module built for your current kernel, not just some kernel:

modinfo zfs | grep version
dkms status

If dkms status doesn't list zfs, <version>, <kernel> as installed, the module hasn't been built for the kernel you're running and a plain reboot won't fix it.

What actually changed in the 2.4.x point release?

OpenZFS opens a new stable series with a major release, then ships point releases — 2.4.1, 2.4.2, 2.4.3, 2.4.4 — that are almost entirely fixes rather than new features. The 2.4.4 release that arrived on August 21 2026 fits that pattern: dozens of bug fixes plus explicit support for the Linux 7.2 kernel.

That last point is the one that matters for Proxmox. OpenZFS ships as a DKMS kernel module, which means it must be compiled against the exact kernel you're running. When a new major kernel like 7.2 lands, the ZFS module has to be rebuilt for it — and that rebuild is why point-release timing and kernel version are entangled. If your host is on the 7.2 kernel but your ZFS module predates 2.4.4, you can see module-version warnings or a pool that fails to import until the rebuild completes.

The honest tradeoff here is that point releases are the safest kind of ZFS change — they rarely introduce new on-disk formats — but the module-to-kernel coupling means the upgrade isn't truly "just run apt." You're also updating whatever kernel that rebuild targets, so plan for a reboot and a brief window where the host is unavailable.

How do I get ready before the upgrade?

The upgrade itself is quick; the prep is where a bad upgrade day is prevented or caused. Treat it like a change window, not a surprise.

First, verify a backup actually exists and is restorable. If you use Proxmox Backup Server for your VM backups, confirm the latest run succeeded:

pbs backup list --datastore <datastore>

If offsite replication matters to you, check that a recent copy landed somewhere off the host before you start, since a bad upgrade is exactly when you want an offsite safety net. Setting up parallel sync jobs to S3 is a good idea long before an upgrade, not during one.

Next, run a health check on the storage itself:

zpool status
zfs list -o name,health,size,allocated

You want to see ONLINE across all vdevs and no errors. If a pool already shows DEGRADED or FAULTED, fix that first — an upgrade is not a debugging tool.

Then snapshot the VM disks you care about. On Proxmox VE, VM disks live as ZFS datasets under rpool/data, so a snapshot looks like this:

zfs snapshot rpool/data/vm-100-disk-0@pre-zfs-upgrade
zfs snapshot rpool/data/vm-101-disk-0@pre-zfs-upgrade

A full VM snapshot of a 100 GB disk on a zpool under light load usually completes in well under a minute, so a handful of VMs is fast. Verify them:

zfs list -t snapshot -o name,creation -s creation

If you'd rather script the whole pre-upgrade health and snapshot pass, the kind of reusable checklist scripts covered in the homelab backup and health-check guide are perfect for this — they turn "did I remember to snapshot VM-100?" into an automated gate.

How do I perform the upgrade on Proxmox VE?

With snapshots taken and backups verified, update the packages. Update the package index, then do a full upgrade so the kernel and module can move together:

apt update
apt full-upgrade

full-upgrade (rather than plain upgrade) is important here, because pulling in a new kernel alongside the rebuilt ZFS module often requires removing or replacing other packages that a plain upgrade won't touch.

Confirm what landed:

dpkg -l | grep zfs
zfs --version

The kernel module line in zfs --version should now match the new userspace version. If dkms status shows the module as installed for your current kernel, you're ready to restart.

Reboot to load the freshly built module:

systemctl reboot

After the host comes back, verify the import succeeded and the pool is healthy:

zpool status
zfs --version

If zpool status reports the pool online with no errors, the module loaded cleanly. If it doesn't import, boot into the previous kernel from the GRUB menu and investigate the DKMS build before trying again.

How does the process differ on Proxmox Backup Server?

PBS stores its datastore as ZFS by default, so the upgrade path is essentially the same — update zfs-dkms, reboot, verify — with one extra courtesy.

Because PBS is the backup target itself, snapshot the datastore dataset before upgrading, so you have a rollback point for any metadata or backup data if something goes wrong:

zfs snapshot <datastore>/backup@pre-zfs-upgrade

Then follow the same apt full-upgrade and reboot steps. After reboot, confirm the datastore is healthy and that PBS can still see your existing backups:

zpool status
pbs backup list

The key difference is philosophical: on PBS you're upgrading the very system that protects your other VMs, so the "verify the backup exists" step isn't optional ceremony — it's the whole point.

How do pool feature versions work, and why are they irreversible?

This is the single most important concept in a ZFS upgrade, and the one that turns a routine update into an emergency.

OpenZFS uses "feature versions" to mark new on-disk capabilities. When you run zpool upgrade, it lists any pool that has upgrades available:

zpool upgrade

If a pool is already current, you'll see something like "This pool has no upgrades available." If upgrades exist, you can apply them everywhere with:

zpool upgrade -a

Enabling a feature version modifies the pool's on-disk format metadata. The catch is that this is forward-only. Once a pool advertises a newer feature version, an older ZFS installation cannot import it. In a Proxmox cluster, that means if you promote a shared or replicated pool on one node, a sibling node still on the old OpenZFS version will fail to import that pool — which can take down storage for the whole cluster.

So the rule is: only run zpool upgrade -a once every node in a cluster is on the same, compatible OpenZFS version. For most single-node homelab hosts this is a non-issue, but it's the exact failure mode that bites production clusters.

How do I roll back if something breaks?

Rollback works on two different layers, and they are not symmetric.

For the data, rollback is instant and safe:

zfs rollback rpool/data/vm-100-disk-0@pre-zfs-upgrade

This returns the dataset to the snapshot state and destroys any snapshots taken afterward. You can also destroy the upgrade snapshot once you're satisfied everything works:

zfs destroy rpool/data/vm-100-disk-0@pre-zfs-upgrade

For the stack, rollback is harder. If the new module misbehaves, you can boot an older kernel from GRUB (the DKMS module for that kernel is usually still present) or downgrade the package, but this only works if you never enabled a new pool feature version. Once you have, the data layer pins you forward.

Here's the reversibility reality:

Component	What changes on upgrade	Reversible?
ZFS kernel module (zfs-dkms)	Rebuilt for the running kernel, loaded at reboot	Yes — boot an older kernel or downgrade the package
ZFS userspace packages (zpool, zfs)	apt full-upgrade pulls the new version	Mostly — downgrade the package, but the module must still match
Pool feature version	zpool upgrade enables new on-disk features	No — forward-only, cannot be disabled or downgraded

That last row is why the pre-upgrade checks exist. The feature version is the point of no return, and it's entirely within your control to avoid crossing it until you're confident.

Conclusion

Upgrading OpenZFS on Proxmox VE or PBS is mechanically simple — update zfs-dkms, reboot, verify the pool imports — but the risk lives entirely in the steps before the reboot. Snapshot your VMs, confirm a backup exists, check zpool upgrade, and hold off on zpool upgrade -a until every cluster node is compatible. Do that and the next point release is a five-minute job; skip it and an irreversible feature flag can strand your storage. Your next step is to run zfs --version and zpool upgrade on your hosts today so you know exactly where you stand before the next release lands.