[SOLVED] Backup too large (includes "free" space)

[proxmox_user_2020]

Hello,

I've been struggling to solve this issue for a few days with no luck.

The config:
The node: latest Proxmox, Seagate Constellation HDDs in RAID1 (dell controller)
The VM: A mail server on Centos 7 with Cpanel (latest versions), XFS on LVM
/etc/lvm/lvm.conf issue_discards = 1 (made no difference)
/usr/lib/systemd/system/fstrim.service looks fine (no excludes)

One VM has about 77G of data, however the backup size (ZST snapshot) is about 100G. LZO is about 150G and uncompressed about 190G.

Found this: https://pve.proxmox.com/wiki/Shrink_Qcow2_Disk_Files
fstrim - prompts xxxG trimmed but actutally does nothing
dd if=/dev/zero of=/mytempfile rm -f /mytempfile - works and gets the backup to 40G

But... it only takes a few days until files get written and deleted and the backup size gets bigger and bigger.

Most likely the "free space" is not discarded and the Proxmox backup is including all those "free" sectors that are actually containing data.
But... why? Is it the fault of Centos? Is it the fault of Proxmox? Is it the fault of the HDDs? Is it just "normal" behavior for my config?

Thank you for reading and I'll appreciate any input on this.

 

[oguz]

hi,

have you tried activating the 'discard' option on your disk?

But... it only takes a few days until files get written and deleted and the backup size gets bigger and bigger.

well, that's to be expected. you can run it regularly with a cronjob.

But... why? Is it the fault of Centos? Is it the fault of Proxmox? Is it the fault of the HDDs? Is it just "normal" behavior for my config?

see the link you've sent:

Over time a guest's *.qcow2 disk files can grow larger than the actual data stored within them, this happens because the Guest OS normally only marks a deleted File as zero, it doesn't gets actually deleted (performance reasons), so the underlying qcow2 file cannot differentiate between allocated and used and allocated but not used storage.

In order to shrink the *.qcow2 files you've two options, enable TRIM support or zero out all free space of the partitions contained within the guest and then reconvert the image with qemu-img.

so this is pretty normal behavior with qcow2 disks.

follow the advice on the link, if you get stuck write again

 

[proxmox_user_2020]

Thank you for your quick reply!

have you tried activating the 'discard' option on your disk?

Thanks! I feel like an idiot... all that time wasted trying to "solve" something that was one box tick missing...

Now it's solved: backup is 2,5 times smaller and

So for anyone having a similar config and issue:
Go to the VM > Hardware > Hard Disk > check discard, reboot VM
Likely /etc/lvm/lvm.conf also needs issue_discards = 1
And enable the fstrim and fstrim timer:

systemctl start fstrim systemctl enable fstrim systemctl start fstrim.timer systemctl enable fstrim.timer ​

 

[oguz]

great!

you can mark the thread as [SOLVED] so others know what to expect

 

[rockbot]

Thank you for your quick reply!


Thanks! I feel like an idiot... all that time wasted trying to "solve" something that was one box tick missing...

Now it's solved: backup is 2,5 times smaller and

So for anyone having a similar config and issue:
Go to the VM > Hardware > Hard Disk > check discard, reboot VM
Likely /etc/lvm/lvm.conf also needs issue_discards = 1
And enable the fstrim and fstrim timer:

systemctl start fstrim systemctl enable fstrim systemctl start fstrim.timer systemctl enable fstrim.timer ​

Hai brother, this config /etc/lvm/lvm.conf also needs issue_discards = 1 , for VM or Proxmox Node?

 

[Ivan Gersi]

Hai brother, this config /etc/lvm/lvm.conf also needs issue_discards = 1 , for VM or Proxmox Node?

Of course VM, there is no hardware option in node menu.