vzdump and excluded VM's disk with "no backup" option flagged in VM's configuration


Active Member
Jan 25, 2018
I have this situation:
VM with 2TB disk, and 2 x 500GB disks.
The 2TB is the main disk for a debian VM, mainly a Samba fileserver.
The 2 x 500GB disks are mounted on the Samba structure for containing files NOT TO BE BACKED UP.
So, in VM config, hardware, advanced, i flag the "no backup" option.
The data of the 2 x 500GB disk where initially on the main 2TB disk, and from the operating system, i "move" the files in the relative directory in the 2 x 500GB mounted directory in the samba server.
Now, when the backup scheduled start, the log is formally ok

2019-10-12 23:00:01 INFO: Starting Backup of VM 101 (qemu)
2019-10-12 23:00:01 INFO: status = running
2019-10-12 23:00:01 INFO: update VM 101: -lock backup
2019-10-12 23:00:01 INFO: VM Name: ufficioNUOVO
2019-10-12 23:00:01 INFO: include disk 'virtio0' 'local:101/vm-101-disk-0.raw' 2T
2019-10-12 23:00:01 INFO: include disk 'virtio1' 'local:101/vm-101-disk-1.raw' 10G
2019-10-12 23:00:01 INFO: exclude disk 'virtio2' 'backup2:101/vm-101-disk-0.raw' (backup=no)
2019-10-12 23:00:01 INFO: exclude disk 'virtio3' 'backup2:101/vm-101-disk-1.raw' (backup=no)
2019-10-12 23:00:01 INFO: backup mode: snapshot
2019-10-12 23:00:01 INFO: ionice priority: 7
2019-10-12 23:00:01 INFO: creating archive '/backup2/dump/vzdump-qemu-101-2019_10_12-23_00_01.vma.gz'
2019-10-12 23:00:02 INFO: started backup task 'c57346c7-0104-43dc-af6e-13707b2cc048'

but the backup dimension is really "greater" than the files occupation of the 2TB disk + 10G disk.
root@pve:/backup2/dump# l vzdump-qemu-101-2019_10_12-23_00_01.vma.gz
-rw-r--r-- 1 root root 505862528929 Oct 13 05:49 vzdump-qemu-101-2019_10_12-23_00_01.vma.gz

root@pve:/backup2/dump# gzip -l vzdump-qemu-101-2019_10_12-23_00_01.vma.gz
compressed uncompressed ratio uncompressed_name
505862528929 1861939712 -27068.6% vzdump-qemu-101-2019_10_12-23_00_01.vma

root@fileserver:~# df
File system Dim. Usati Dispon. Uso% Montato su
/dev/mapper/fileserver--vg-root 2,0T 333G 1,6T 18% /
/dev/vda1 236M 37M 187M 17% /boot
/dev/vdc1 492G 153G 314G 33% /home/software/VirtualMachine
/dev/vdd1 492G 52G 415G 12% /home/software/ISOIMAGE

As you can see, the 2T disk has 335G used, so i expected that the vzdump backup of this disk would be less than its used part, especially using the gzip algorithm.

So, the problem is:
1 - the vzdump exclude didn't work
2 - the filesystem after a move is not cleaned and "junk data" are on the filesystem and are backed up with vzdump

Simone Benini c/o SOASI.
Thx for the reply, VM disks are VirtIO SCSI "raw", so there is no "thin provisioning" and no "discard" option.....
Thx for the reply, VM disks are VirtIO SCSI "raw", so there is no "thin provisioning" and no "discard" option.....

Then overwrite the free space manually. Without thin-provisioning, you always have to do this manually:

dd if=/dev/zero of=zero bs=64k; sync; sync; sync; rm -f zero

this has to run in each mountpoint on your "to-be-backed-up" disks
  • Like
Reactions: oguz and Chris


The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!