6.1.2 does not use CBT anymore

[SnakeSK]

On several systems we are seeing that vaw reports:
22.05.2024 21:13:38 :: Changed block tracking map was changed for volume \\?\Volume{b39b4b04-3364-4cb9-8dcc-1cd047756bf5}: current map 8dbc0312-17ad-11ef-a0f1-806e6f6e6963, previous map c3f83467-15e4-11ef-a0ed-806e6f6e6963

Computer did not have dirty shutdown or anything like that, it started right after upgrade from previous version, anyone seeing similiar? or should we reinstall.

Thank you

[Gostev]

Does it repeat every backup run, or just first run after upgrade?

[SnakeSK]

Every single one, even VBR has servers that does not show [CBT] in the backup job logs. VAW (standalone on my workstation) at least shows the error (green checkmark however)

[Gostev]

Then perhaps something is off with those several systems. VAW was patched in this release due to a security vulnerability and perhaps some server configuration conflicts with the fix. I recommend you let support investigate before trying to reinstall.

[SnakeSK]

Even standalone agent does that. I opened a support case #07274845

[Dima P.]

Hello SnakeSK,

Thank you for the case details and the logs. We are reviewing all the details, stay tuned for updates via our support channels.

[Gostev]

@SnakeSK your issue has now been understood.

This requires a number of conditions to trigger:
1. A 512e hard drive.
2. A misaligned disk partition.
3. Machine is rebooted or powered off between backups.

Hotfix is now in the works.

[SnakeSK]

But I have nvme

[mjr.epicfail]

But I have nvme

What does that have to do with 512e (nvme also exist as 512e and also 4kn)
The type of drive doesn't matter here

[Dima P.]

Correct, the issue is not related to the particular disk model but the way how the data is aligned on the disk whenever such allocation supported. Stay tuned for the updates / private fix via our support channel and thank you for reporting this issue so fast!