Technical

Backup Size vs Bootsize? Proxmox Backs Up Allocated Blocks, Not What the Guest Reports

Backup Size vs Bootsize? Proxmox Backs Up Allocated Blocks, Not What the Guest Reports

Backup size vs bootsize? The backup size is almost never what the guest OS reports as used. Proxmox backs up allocated blocks on the host, not the files inside the VM. That’s the whole mystery in one sentence.

Detailed view of a hard drive circuit board showing components and connections in Mérida, Venezuela.

Why the numbers don’t match

Inside the VM, df -h says 20 GB used. The Proxmox backup task says 35 GB. Annoying, right? The difference is block-level allocation. The guest filesystem writes to virtual disk blocks, and the host tracks which blocks have ever been touched. Deleted files don’t zero those blocks—they just get marked free in the guest’s filesystem. So the host still sees them as allocated and backs them up.

Thin provisioning makes this worse. A 100 GB virtual disk that’s only 10% full might only allocate 10 GB on the host. But if you copy a 50 GB file in and delete it, the host allocation jumps to 50 GB and stays there. The backup then reads all 50 GB, even though the guest shows only 10 GB used.

What Proxmox actually backs up

Proxmox uses vzdump with a format that understands thin provisioning. For QEMU VMs, it reads the qcow2 or raw file and skips unallocated clusters. For LXC containers, it walks the filesystem but still respects sparse files. The key point: it backs up what the host has allocated, not what the guest thinks is used.

You can see the real allocation with qemu-img info on the host:

qemu-img info /var/lib/vz/images/100/vm-100-disk-0.qcow2

Look for “disk size” vs “virtual size”. Disk size is what the backup will read. Virtual size is the max the disk can grow to.

Vintage 1990s removable disk drive with a diskette inserted, isolated on white.

How to shrink the backup

If the backup is bloated, you need to reclaim unused blocks. Inside the VM, run fstrim on Linux or defrag + sdelete on Windows. Then on the host, use qemu-img convert with -o preallocation=metadata to compact the qcow2 file. For raw disks, you’ll need to copy to a new file with cp --sparse=always.

For LXC containers, just delete the big files and run fstrim on the container’s mount point. The backup will skip the freed extents.

My take

Don’t overthink it. If the backup size is close to the host’s allocated size, that’s normal. The guest’s df output is a lie for backup purposes. If you really need to shrink it, trim and compact. Otherwise, let it be—storage is cheap.

Related: if you’re fighting NFS storage errors during backup, check these three things.

Leave a comment

Comments are reviewed before they appear. Your email is never published.