09-28-2023 05:59 AM
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?
Solved! Go to Solution.
10-12-2023 04:30 AM
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.
09-28-2023 06:09 AM
share the snapshot and backup activity monitor details (attach them as file)
Also post the netbackup and vmware versions
09-28-2023 06:32 AM
Here are the activity logs for that machine.
09-28-2023 06:44 AM
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%.
09-28-2023 07:28 AM
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
09-28-2023 08:37 AM
I will try a different policy and see what happens.
09-28-2023 12:23 PM
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.
09-28-2023 05:19 PM
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
09-29-2023 06:01 AM
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.
10-12-2023 04:30 AM
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.