If you built a ZFS pool in Proxmox VE, you probably noticed a "Compression" dropdown during setup and clicked past it without thinking much about it. It defaults to on, which sounds vague enough to ignore. Most people do exactly that, then wonder months later why their 500 GB pool somehow holds 620 GB of VM disks.
That's compression doing its job quietly in the background. But "on" isn't the only option, and it isn't always the best one for your hardware. This guide walks through what ZFS compression actually does in Proxmox VE, how to check whether it's helping you right now, and how to switch between lz4 and zstd without breaking anything.
What You Will Learn
- What ZFS compression actually does to the data on your disks
- How to check the current compression setting and see real space savings
- The practical difference between
lz4andzstd - How to change compression on a pool, a dataset, or a single VM disk
- Why changing the setting doesn't instantly shrink your existing VMs
- Common mistakes and the exact errors they produce
What Is This Feature?
ZFS is the storage system Proxmox VE uses to manage disks, and it does a lot more than a normal filesystem. It handles RAID, snapshots, checksums, and compression all at once, without needing a separate hardware RAID card. Compression is one of its built-in features: before ZFS writes a block of data to disk, it runs that block through a compression algorithm, and it decompresses the block automatically when something reads it back. You never see this happen. Proxmox, your VMs, and your backups all just see normal files.
Two algorithms matter here. lz4 is the long-standing default in ZFS on Linux, chosen because it's extremely fast and barely touches your CPU. zstd is a newer algorithm, developed at Facebook, that trades a bit more CPU time for noticeably better compression ratios. Both are safe, both are production-ready, and Proxmox VE 8.x and 9.x support either one out of the box.
Why Would You Use It?
Two reasons, and they're not equally obvious. The first is space: a typical Debian or Ubuntu VM disk full of text-heavy config, logs, and package files can shrink by 30–50% with compression turned on. Databases and application logs compress especially well.
The second reason is speed, and this one surprises people. Reading and writing less physical data to disk can actually make things faster, not slower, because modern CPUs compress and decompress data far quicker than a spinning disk (or even most SSDs) can move the uncompressed version. You're trading a small, mostly-idle CPU cost for less disk I/O. On a homelab box where the CPU sits at 5% most of the day, that's a trade worth making.
It won't help everything. Data that's already compressed, like video files, JPEGs, or an encrypted backup archive, won't shrink further no matter which algorithm you pick. ZFS is smart enough to detect this early and skip wasting CPU on it, but it's worth knowing up front so you don't expect miracles from your Jellyfin media library.
Prerequisites
- Proxmox VE 8.x or 9.x (this guide was written against 9.2) with at least one ZFS pool already created
- Root access to the host, either through the web-based Shell or SSH
- Comfort typing a handful of commands — nothing here requires scripting experience
- A few minutes of downtime tolerance if you plan to rewrite existing VM disks, since that involves a disk move
Step-by-Step Tutorial
Step 1: Check what's actually set right now
Open a Shell session on your Proxmox node (Datacenter → your node → Shell, or SSH in) and run:
zfs get compression rpoolReplace rpool with the name of your pool if it's not the default. You'll get output like:
NAME PROPERTY VALUE SOURCE
rpool compression on defaultA value of on here actually means lz4 — it's an alias. ZFS has used lz4 as the meaning of "on" since it became fast enough to make gzip's old default look pointless, back in OpenZFS's early years. So if you never touched this setting, you're already running lz4.
Step 2: See what you're actually saving
This is the step people skip, and it's the one that tells you whether any of this is worth your time. Run:
zfs get compressratio rpool/dataYou'll see something like 1.42x. That means the logical data stored is 1.42 times larger than what's physically written to disk — a real 42% saving. If your ratio sits close to 1.00x, your data isn't compressing well (common if you're storing mostly media files or already-encrypted backups), and switching algorithms won't move the needle much.
Step 3: Decide between lz4 and zstd
Here's the comparison that actually matters for a homelab or small business server:
| Algorithm | CPU cost | Typical ratio | Best for |
|---|---|---|---|
| lz4 | Very low | 1.3x–1.6x on mixed VM data | Everything, especially older or low-core-count hardware |
| zstd (default level 3) | Moderate | 1.5x–2.2x on mixed VM data | Modern CPUs with cores to spare, backup targets, log-heavy VMs |
| zstd-1 through zstd-19 | Scales up with level | Higher levels squeeze more, slower | Cold data or backup datasets where write speed matters less |
Honestly, for most people running a handful of VMs on a 4-8 core box, plain zstd (which defaults to level 3) is a reasonable upgrade over lz4. You'll notice better disk usage and rarely notice the CPU cost. I'd only stick with lz4 if you're running on genuinely old or weak hardware — something like an early Celeron NUC or a repurposed thin client — where every CPU cycle counts.
Step 4: Change the setting
To switch your data pool to zstd:
zfs set compression=zstd rpool/dataFor a specific compression level instead of the default:
zfs set compression=zstd-9 rpool/dataYou can also do this from the GUI, but only when creating a brand new ZFS pool: go to your node → Disks → ZFS → Create: ZFS, and pick your algorithm from the Compression dropdown before you click Create. There's no GUI toggle for changing compression on a pool that already exists — that part is CLI-only.
Step 5: Understand what just happened (and what didn't)
Run the compressratio check again immediately after changing the setting, and you'll probably see no difference. That's not a bug. ZFS never rewrites data that's already on disk just because you changed a property — the new setting only applies to blocks written from this point forward. Your existing VM disks are still compressed with whatever algorithm was active when they were written.
Step 6 (optional): Set compression per VM disk
Every VM disk on ZFS storage is its own dataset, named something like rpool/data/vm-100-disk-0. You can override compression on just that disk without touching the whole pool:
zfs set compression=zstd rpool/data/vm-100-disk-0This is handy if you've got one VM running a database that would benefit from a higher zstd level, while leaving everything else on lz4.
Step 7: Actually apply the new setting to existing data
If you want your existing VMs to benefit, not just new ones, you need to force ZFS to rewrite the data. The cleanest way inside Proxmox is to move the disk to a different storage and back, which reads every block and writes it fresh under the current compression setting:
qm move-disk 100 scsi0 rpool-data --delete 0Then move it back the same way if you only have one ZFS storage target. Shut the VM down first — a live move works in most cases, but a stopped VM avoids any chance of I/O contention slowing things down mid-move. For a 32 GB disk this took about 90 seconds on a SATA SSD in my testing; a spinning disk will take considerably longer.
Commands Explained
zfs get compression <dataset>— shows the current compression algorithm for a pool or dataset, and whether it's inherited or explicitly set.zfs get compressratio <dataset>— shows the real, measured ratio between logical and physical size. This is your actual proof of savings, not a theoretical number.zfs set compression=<value> <dataset>— changes the algorithm going forward. Acceptsoff,on,lz4,zstd,zstd-1throughzstd-19,gzip,gzip-1throughgzip-9, and a few older options likelzjbandzle.zfs list -o name,used,logicalused,compressratio— a quick way to see used space, logical space, and ratio for every dataset at once.zpool status— confirms your pool is healthy before you go changing settings on it. Always worth a glance first.qm move-disk <vmid> <disk> <target-storage>— moves a VM's virtual disk to a different storage target, rewriting every block under the current settings of the destination.
Common Errors
cannot set property for 'rpool': invalid property 'compress'
This happens when you type compress instead of compression. ZFS doesn't accept the shortened form as a property name — spell it out.
cannot set property for 'rpool': pool and or dataset must be upgraded to set this property
You'll see this if you try to set zstd on a pool created with a very old ZFS version that predates the zstd feature flag. Check with zpool get all rpool | grep zstd — if it shows disabled, run zpool upgrade rpool to enable it. Do this deliberately, not on autopilot: upgrading feature flags on your boot pool is one-way, and an older rescue environment or a much older Proxmox ISO won't be able to import the pool afterward.
cannot open 'rpool/dat': dataset does not exist
A plain typo in the dataset path. Run zfs list first to copy the exact name rather than typing it from memory.
Troubleshooting
If your compressratio is still sitting at 1.00x after switching algorithms, that's almost always because nothing new has been written yet. Compression only applies to fresh writes, not existing blocks — go back to Step 7 and force a rewrite if you want existing VMs to shrink.
If you notice higher CPU usage after moving to a high zstd level, drop back down. zstd-19 squeezes out impressive ratios but can meaningfully slow writes on a two- or four-core system. Start at plain zstd (level 3) and only go higher if you've got CPU headroom to spare and you've actually measured the improvement.
If a specific VM's ratio barely moves no matter what you set, check what's inside it. A VM running Plex or Jellyfin with a media library mounted as a second disk won't compress that media meaningfully — video and audio files are already compressed at the codec level, and ZFS's compression will mostly skip them once it detects that.
Best Practices
Leave your root/boot pool (rpool/ROOT) on lz4 unless you have a specific reason to change it. It's small, it's not usually where your space pressure comes from, and there's no upside to adding CPU overhead to your boot filesystem.
Set compression on your data pool where VM and container disks actually live — that's where the savings show up. If you're storage-constrained and running on a CPU with cores to spare, zstd is worth the switch. If you're on genuinely tight hardware, lz4 remains a perfectly good default; nobody running lz4 is doing anything wrong.
Measure before and after with compressratio rather than guessing. It takes ten seconds and tells you definitively whether the change was worth it on your actual data, not someone else's benchmark.
Don't bother enabling heavy compression on datasets you know hold incompressible data — encrypted backups, already-compressed archives, media libraries. You'll pay the CPU cost for the early-abort check on every block and get nothing back.
Frequently Asked Questions
Does changing compression risk any data loss?
No. Compression is a property that only affects how new writes are stored on disk; it doesn't touch or re-encode existing data unless you explicitly force a rewrite. You can change it back and forth safely.
Which algorithm does the Proxmox VE installer use by default?
The installer's Advanced Options screen defaults to on, which means lz4. You can change it during install if you want zstd from the start.
Will zstd slow down my VMs?
On modern hardware (anything from roughly the last six or seven years), the difference is usually not noticeable for everyday VM workloads. Heavy sequential write workloads on very high zstd levels are the exception — that's where you'd feel it.
Can I mix compression settings within one pool?
Yes. Compression is set per dataset, and every VM disk is its own dataset, so you can run lz4 pool-wide and bump a specific VM's disk to zstd if it holds compressible data like database dumps or logs.
Is there a way to compress existing data without moving disks around?
Not directly through Proxmox. A zfs send to a new dataset and zfs receive back, or the qm move-disk method shown above, are the practical ways to force a rewrite under new settings.
Conclusion
Compression is one of those ZFS features that quietly does its job whether you understand it or not — but knowing what's actually happening under the hood means you can make a real decision instead of leaving a default in place out of uncertainty. Check your ratio, pick lz4 or zstd based on what your hardware can spare, and don't be afraid to set it differently across datasets depending on what's actually stored there. It's a five-minute change that can buy back real disk space on a homelab box that's always a little tighter on storage than you'd like.