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

[Foodrinks]

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
OR
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.

 

[Chris]

Hi,
do you have the discard option enabled? Otherwise no trim will be performed, which frees unused space. See https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_hard_disk

 

[Foodrinks]

Thx for the reply, VM disks are VirtIO SCSI "raw", so there is no "thin provisioning" and no "discard" option.....

 

[LnxBil]

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

 

[Foodrinks]

Thx, there are other tools too: sfill and zerofree .... The only solution.