You kick off a backup job at 2 AM, check on things the next morning, and find a note in the task log that a VM stalled for ninety seconds mid-backup. Or maybe you saw it happen live: a Windows VM's mouse cursor froze, a Linux VM's SSH session stopped responding, and then everything picked back up right as the backup finished. Nothing crashed. Nothing corrupted. But for a minute or two, that VM was effectively unusable.
That's not a fluke and it's not your hardware failing. It's how Proxmox VE's backup process is designed to work by default, and it gets worse the slower your backup target is — an NFS share over a home network, a Proxmox Backup Server on the other side of a VPN, anything that can't keep up with how fast your VM writes to disk.
Proxmox VE 8.1 added a setting that fixes this for most people: backup fleecing. It's not turned on by default, it's buried in an "Advanced" tab most people never open, and there isn't much explained about it in the GUI itself. This guide covers what it actually does, when you should turn it on, and the storage requirements that trip people up the first time they try.
What You Will Learn
- Why a VM can freeze or slow to a crawl during a backup, even though nothing is wrong with it
- What backup fleecing actually does at the storage level
- How to enable it through the GUI and from the command line
- What kind of storage you need for fleecing to actually help instead of just filling up your disk
- The errors people hit most often, and how to avoid them
What Is This Feature?
To explain fleecing, you first need to know what Proxmox does to back up a running VM without shutting it down. When a backup starts, QEMU (the piece of software actually running your VM) installs something called a copy-before-write filter on the VM's disk. Every time the guest OS tries to write to a block of data that hasn't been backed up yet, that filter steps in first: it copies the old version of that block to the backup target, and only then lets the write through.
That's how Proxmox backs up a disk while it's still in use without giving you a corrupted, half-written mess. The tradeoff is speed. If your backup target — an NFS share, a Proxmox Backup Server, whatever it is — can only handle 50 MB/s, then every guest write into "cold" data has to wait for that 50 MB/s copy to finish first. A guest that would normally write at disk speed suddenly writes at backup-target speed. On a slow target, that can mean seconds of guest I/O stalling per write, which is exactly the freeze you saw.
Backup fleecing changes where that copied data goes. Instead of sending the "old data" straight to the (possibly slow) backup target, Proxmox writes it to a fast local disk first — the "fleecing image." The actual backup job reads from that fleecing image at its own pace afterward. The guest write only has to wait on fast local storage, not on your NFS share or your backup server's network link.
Two terms will come up a lot here, so it's worth defining them now. Thin provisioning means a virtual disk only actually uses as much physical space as the data written to it, instead of reserving its full size up front — a 32 GB thin disk with 4 GB of data used only takes 4 GB on the real storage. Discard (sometimes called TRIM) is the mechanism that lets a thin-provisioned disk give space back after data on it is deleted. Both matter a lot for fleecing, because the fleecing image needs to shrink back down once the backup is done — otherwise you'd need permanent free space equal to your entire VM disk, just sitting there unused between backups.
Why Would You Use It?
Fleecing earns its keep in one specific situation: you're backing up a busy VM to a target that's slower than your local storage. That covers more setups than you'd think — Proxmox Backup Server accessed over a home internet connection or a site-to-site VPN, an NFS or CIFS share on a NAS with a single spinning disk, or even a fast target that's just saturated because five VMs are backing up to it at once.
If you've ever opened a VM's console mid-backup and watched the mouse stop moving, or had a database VM start throwing timeout errors right when the nightly backup job runs, that's the copy-before-write bottleneck at work. Fleecing decouples "the guest can keep writing" from "the backup target can keep up," which is exactly the fix for that.
On the other hand, if your VMs already back up to genuinely fast storage — a Proxmox Backup Server on the same 10-gigabit LAN, for instance — you may never notice a difference either way. Fleecing adds a small amount of local I/O and requires spare fast storage, so there's no reason to switch it on for a VM that already backs up cleanly. I'd only bother enabling it once you've actually seen the freeze, or you know your backup target is the slow link in the chain.
One more thing worth knowing up front: fleecing is a QEMU feature. It applies to virtual machines. It has no effect on LXC containers, which back up through a different mechanism entirely.
Prerequisites
Before you start, make sure you have:
- Proxmox VE 8.1 or later (this guide was written against 9.2, but the setting hasn't changed since it was introduced)
- At least one QEMU virtual machine with an existing backup job, or the ability to run a manual backup with
vzdump - Root or an account with
PVEAdmin/ backup-related permissions on the node - A second piece of storage on the node — separate from your backup target — that's fast and ideally supports thin provisioning and discard. Local LVM-thin, ZFS, or Ceph RBD all qualify. A plain local directory works too, with one caveat covered below.
You don't need to touch anything about your existing backup job's destination. Fleecing storage is a separate, temporary staging area — it's not where your backups end up living.
Step-by-Step Tutorial
The GUI is the easiest way to turn this on for a single backup job, so start there.
- Log in to the Proxmox VE web interface and click Datacenter in the left-hand tree.
- Click Backup in the menu below it. You'll see your existing backup jobs listed, one per row.
- Select the job you want to change and click Edit (or click Add if you're creating a new one).
- In the job editor, click the Advanced tab. This is the tab most people skip, since the default view only shows schedule, storage, and mode.
- Find the Fleecing section. Tick the Enabled checkbox.
- In the Storage dropdown right next to it, pick the fast local storage you want to use for the fleecing image — your LVM-thin pool, ZFS pool, or local directory.
- Click OK to save the job.
That's it for the GUI. The setting applies to every VM included in that backup job — you don't configure it per VM.
If you'd rather test it on a single VM without touching a scheduled job, you can run a one-off backup from the shell instead. SSH into the node and run:
vzdump 123 --fleecing enabled=1,storage=local-lvmReplace 123 with your VM's ID and local-lvm with whatever fast storage you want to use. This runs a manual backup with fleecing turned on for that single run, using whatever backup target and mode your node is already configured to use by default.
If you want fleecing on by default for every manual vzdump run on a node — not tied to any GUI job — add it to /etc/vzdump.conf:
fleecing: enabled=1,storage=local-lvmSave the file and any future vzdump command on that node picks it up automatically, unless overridden on the command line.
A Note on Storage That Doesn't Support Discard
If the only fast local storage you have is something without discard support — an NFS mount used as a plain directory storage, for example — you can still use it for fleecing, but you need to open its storage configuration in Proxmox and set Preallocation to off. Skipping this step is one of the more common ways people end up with a fleecing image that never shrinks back down.
Commands Explained
| Command / Option | What It Does |
|---|---|
vzdump <vmid> | Runs a manual backup of the specified VM or container ID from the command line. |
--fleecing enabled=1 | Turns fleecing on for this backup run. Default is 0 (off). |
--fleecing ...,storage=<id> | Tells Proxmox which storage to use for the temporary fleecing image. Must be a storage the node can already see and write to. |
fleecing: in vzdump.conf | Sets the same options as a node-wide default, applied to every manual vzdump run unless overridden. |
You won't see a separate command to "clean up" the fleecing image afterward — Proxmox removes it automatically once the backup job finishes, whether it succeeded or failed partway through.
Common Errors
The errors here are almost always storage-related, not fleecing-related as such.
Backup job fails immediately after enabling fleecing, citing insufficient space. This shows up on storage that isn't thin-provisioned — plain LVM or ZFS without the sparse option turned on. On that kind of storage, Proxmox has to reserve the full size of the original disk for the fleecing image up front, not just the size of what's actually changed. A 100 GB VM disk needs 100 GB free on the fleecing storage before the backup will even start, regardless of how little data actually changes during the backup window.
Fleecing storage fills up over the course of a long backup. This happens on thin-provisioned storage when the guest rewrites a large portion of its disk while the backup is still busy processing an earlier volume — common on VMs with more than one disk, where a database disk keeps getting hammered while a slower secondary disk is still backing up. The fleecing image can, in the worst case, grow close to the full size of the original disk even on thin storage.
Fleecing image space isn't being reclaimed after backups finish. Almost always a missing discard/TRIM setting somewhere — either the storage type doesn't support it, or a file-based storage needs Preallocation set to off as covered in the tutorial section above.
Troubleshooting
If a backup job fails right after you enable fleecing, check free space on the fleecing storage first — go to Datacenter > Storage, click the storage you selected, and look at the used/available figures. Compare that to the size of the VM disk you're backing up, not just the amount of data it's using.
If space usage on your fleecing storage keeps creeping up between backups instead of returning to normal, confirm the storage actually supports discard. LVM-thin and ZFS support it natively. For a directory-based storage sitting on NFS, open Datacenter > Storage, edit the storage entry, and set Preallocation to off — the option lives right there in the storage's own configuration, not in the backup job.
If you're still seeing guest I/O stalls with fleecing enabled, the fleecing storage itself might be the slow part now. Fleecing only helps if the fleecing storage is meaningfully faster than your backup target. Putting a fleecing image on a storage that's just as slow — or on a storage that's already busy serving other VMs — won't buy you much. Move it to something with spare I/O headroom, ideally an SSD or NVMe-backed pool that isn't hosting your other VM disks.
Check the backup job's task log (Datacenter > Backup, click the job, then the log for that run) if a run fails partway through. Fleecing-related failures usually say so explicitly, mentioning the fleecing storage by name rather than the backup target.
Best Practices
- Point fleecing at a local SSD or NVMe pool with thin provisioning and discard — LVM-thin and ZFS are the easiest to get right without extra configuration.
- Don't reuse the disk that hosts your busiest VMs as fleecing storage. You'll just move the I/O contention instead of fixing it.
- Turn it on for VMs backing up to Proxmox Backup Server over a WAN link, VPN, or anything slower than gigabit LAN — that's where the benefit is largest.
- Skip it for VMs that already back up cleanly with no visible slowdown. There's no real downside to leaving fleecing off where it isn't needed, and it's one less thing to think about.
- If you're using file-based storage without discard, remember to flip Preallocation to off in the storage config — this is the single most common setup mistake.
- Watch free space on the fleecing storage for the first few backups after enabling it, especially on non-thin storage where the full disk size gets reserved.
Frequently Asked Questions
Does fleecing work for LXC containers?
No. Fleecing relies on QEMU's block layer, so it only applies to virtual machines. LXC backups use a different snapshot mechanism entirely.
Do I need to change my backup destination to use fleecing?
No. Fleecing storage is a separate, temporary staging location. Your backup job still writes its final backup to whatever storage you already configured — PBS, NFS, or otherwise.
Will fleecing make my backups finish faster?
Not directly. It doesn't speed up the transfer to your backup target — it stops the guest VM from being blocked while that transfer happens. The backup job itself takes roughly the same amount of time either way.
How much extra storage does fleecing actually need?
On thin-provisioned storage, usually just a fraction of the disk's size, proportional to how much data changes during the backup. On storage without thin provisioning, Proxmox reserves the full size of the source disk up front, which can be significant.
Can I enable fleecing for just one VM instead of a whole backup job?
Yes, using the vzdump <vmid> --fleecing enabled=1,storage=<id> command from the shell for a manual, one-off run. GUI backup jobs apply the fleecing setting to every VM included in that job.
Conclusion
Backup fleecing is one of those settings that solves a very specific, very recognizable problem: a VM that freezes or crawls every time a backup job runs. If you've never seen that happen, you probably don't need to touch it. If you have, the fix is a checkbox and a storage dropdown in the Advanced tab of your backup job — as long as you point it at fast, thin-provisioned local storage and remember the preallocation setting for anything file-based. Once it's set up correctly, backups stop being something your VMs have to survive.