VM optimization 0%

[bcsupport]

One of our machines in one of our VM policies always says 0.0% optimization.  We have many other machines in the same policy that have no issue with optimization rates ranging from 99% to 65%.  This one machine takes a long time to backup because it seems that the accelerator is not working and is always sending the full machine, even on differential backups.  I have checked the setting for the vm to make sure it is enabled to use change tracking, with the VM parameters:ctkEnabled=True.  This is a 2019 windows server backing up to MSDP on 5240 appliance.  Like I said no other machine has an issue in the policy.  Also this is a File server, so most of the files don't change, it should be getting much better dedup and optimization, but it's not.  Any ideas on where else to investigate?

[StefanosM]

share the snapshot and backup activity monitor details (attach them as file)
Also post the netbackup and vmware versions

[bcsupport]

Here are the activity logs for that machine.

[StefanosM]

What is your backup version?

Not only do you have 0% acceleration, but you have poor deduplication (10%) as well. Have all the backups of this client such poor deduplication?
Try to do some full backups with accelerator disabled (move the client to another policy) and check if deduplication is still ~10%.

[bcsupport]

appliance 5240 is on 5.0.0.1 MR4 

Yes it seems to be just that client that consistently has 0 accel and low dedup

[bcsupport]

I will try a different policy and see what happens.

[StefanosM]

For this test, do not use accelerator to the new policy.I want to see the deduplication ratio. if it run a few days ok then enable accelerator.

Your main problem is not the time of backup but the space it consumes to the backup storage. At the end and depending your retention, it will consume a big amount of storage.

[davidmoline]

Hi @bcsupport 

My thoughts are to check the VM itself and whether any Windows volume or VMDK encrpytion or compression is being used. Compare the problem VM to the others that do behave as expected and see what the differences are. 

Cheers
David

[bcsupport]

So the machine in question is encrypted with VMware's standard encryption key.  We have at least one other machine in that same policy(lets call machine B) and same vcenter that is also encrypted and gets good dedup and optimization, <90%.  Albiet it is 1/4 of the size but takes minutes to backup compared  to hours for the other.  The only other difference i can spot is that the machine in question is thick lazy zeroed, but the machine B is also encrypted and thick lazy zeroed.  The rest in that Vcenter are typically thin provisioned.

[bcsupport · Accepted solution]

Thanks for the suggestions, we finally found the issue. Upon examing the configuration parameters of the VM, there is an entry for change block tracking to be enabled(ctkEnabled=True), but there was also an entry further down in the config to disallow Change block tracking(ctkDisallowed=True).  The second entry was removed and it was working properly.