Backup size larger than it should be

tjkreidl

@kamil-v4 If you have another SR with space available, one option would be to move the VM to it and then back again, which should in principle reclaim the space. On the SR that you move thee VM to, it should show up coalesced. Sure you don't have any hidden snapshots or such that might be contributing to the bloated space?

kamil-v4

@tjkreidl I can't see any hidden snapshots, only a single snapshot created by the delta backup.
I will try moving the VM to another host, thanks for the advice.

tjkreidl

@kamil-v4 Not to another host, to another SR! The VM has to be moved to a different storage device. The host is irrelevant if within the same pool.

kamil-v4

@tjkreidl I had no other storage repository connected to that host, so I had to attempt to move it to another host, which has its own storage repository. Unfortunately, the VM/Backup size is still nearly 190GB.

florent

@kamil-v4 hi kami,

the backup size is the size of the data block that have been used at least once, even if you remove the data, the blocks stays allocated, thus are saved when doing a key backup.

I am not sure of what would be the best strategy to deflate this VHD on XCP-ng side, as I am working more on the backup side of the XCP-ng.XO stack

tjkreidl

@florent I am perplexed because thin provisioning should allow for coalescing. I would still try moving the VM to another SR and back again would again be my suggestion.

florent

@tjkreidl thin mode doesn't allocate space that is not needed. But once allocated, they stays there.
I am curious if migration from on Sr to another works. If not I will look into this

On the backup side, you can use a block based repository, each block are individually compressed. It should reduce a lot , especially if the blocks are full of zeros

olivierlambert

Yes, don't mix coalesce and trim. SMAPIv1 doesn't support trim, so only regenerating the VHD (eg by moving it or copy it) will get rid of those empty blocks.

tjkreidl

@olivierlambert Ah, for SSD drives, yes, trimming is a whole separate thing.

olivierlambert

I'm talking about VHD trimming, which is unrelated on how it's stored behind Obviously, to do this, the Dom0 needs to know from the VM which blocks are unused, which is given by trim commands.

Surprisingly, trim is available in the blkif protocol (used to communicate between the VM and the Dom0 & Xen). But it's not used in SMAPIv1, probably because of shared LVM on HBA or iSCSI (suspecting it cause some corruptions). It should work locally but was never implemented.

kamil-v4

@olivierlambert @florent thank you for the suggestions.
So far I have attempted to do the following:

Remote backup to NFS
Remote backup to NFS target which is connected to another storage server using iSCSI
Move the VM from one SR to another (on a completely different pool)
Copy the VM to another pool

Unfortunately, my VM size is not reducing.

@florent said in Backup size larger than it should be:

thin mode doesn't allocate space that is not needed. But once allocated, they stays there.

This looks like an answer to me.
In the worst-case scenario, I will have to recreate the VM and copy the data onto it