Incremental backups randomly misbehave and a full backup is created where the sparseness of the disk image is not preserved

[jamesdrake101]

I have a VM where the nominal size of the main drive is 1TB, however the qcow2 file only takes a few gigabytes (it's sparse). I can do a full backup just fine, and I can also do several incremental backups on top of it just fine, until at some point, seemingly randomly, the incremental backup will result in a MASSIVE disk footprint because the backed-up disk inflates to its FULL nominal size (1TB!).

I can't file a bug report just yet because I didn't keep all the receipts (I'll make sure I do the next time), but I was wondering if there is any known reason why this could happen, or someone else is experiencing it.

[abbbi]

Fstrim running in vm Or filesystems wirth trim option mounted? Fstrim can cause this bcs many blocks will be tracked as changed after

[jamesdrake101]

filesystems wirth trim option mounted

Ooooh, might be and I didn't see that coming. I'll check.

[abbbi]

Generally the blocks to be backed up are tracked by the qemu block layer, not virtnbdbackup itself. Things like fstrim will touch lots of blocks which results in a big changed block footprint

[jamesdrake101]

Fuck me...

Jan 20 00:41:42 VM1 systemd[1]: Starting fstrim.service - Discard unused blocks on filesystems from /etc/fstab...
Jan 20 00:42:05 VM1 fstrim[25073]: /: 739.3 GiB (793837420544 bytes) trimmed on /dev/sda1
Jan 20 00:42:05 VM1 systemd[1]: fstrim.service: Deactivated successfully.
Jan 20 00:42:05 VM1 systemd[1]: Finished fstrim.service - Discard unused blocks on filesystems from /etc/fstab.
Jan 20 00:42:05 VM1 systemd[1]: fstrim.service: Consumed 2.444s CPU time, 2.2M memory peak.```

[abbbi]

See issue #250