thuizenga wrote:What about replication jobs? Do i just run the CBT reset on the source VM's or is there a different procedure that needs to be done to make sure the destination machines aren't corrupted? Am i also suppose to run the CBT against the replicated VM's and if so do i need to commit existing snapshots first.
Yes, you are supposed to run the CBT against the VMs you are replicating as well. There is no need to commit any snapshots though, as you only need to reset CBT for "source" (production) VMs, which should not have any snapshots. You don't need to reset CBT for "target" (replica) VMs which you are probably talking about here.
teknomage wrote:I understand that resetting CBT is required and I've run those scripts before, but I'm curious to the difference between running the scripts and toggling the "Changed block tracking" option in individual backup jobs.
Great question, Mike! The difference is that resetting CBT recreates and re-populates CBT map file, which is essential to do when they may contain inconsistency due to the bug discussed in this topic. The option you are talking about simply makes the job not use CBT data - and while disabling this option solves the issue, this is not a type of setup that most people will be happy to live with forever due to the associated performance penalty of "full scan" incremental runs.