CBT Reset in v9

[mcrape]

In the release notes for V9, on page 21, Step 11 states that CBT needs to be reset for all VMs in the environment and it points towards KB 1940.

I took a look at KB 1940 and although it seems to be related to a different issue, it does have instructions on resetting CBT. Two questions:
* What is required to reset CBT in V9? The V8 instructions indicate it is done automatically.
* What sort of performance hit will this have on the next backup?

Thanks

[VladV]

Is it mandatory to reset the CBT after the upgrade or it is because of the multiple bugs in vSphere? I wouldn't want to reset it a 3rd time in 2 months.

[kjstech]

I too am curious as to what this is about. I'm holding off upgrading until there is a clear answer here. Will this cause backups to take a very long time? If so I will do it over the weekend. Is there a quick script to automatically reset cbt and what effect if any does it have on a running production virtual machine where downtime is not an option?

[jeremyve]

I'd like to know what it will do to my replication job. Any ideas?

[VladV]

A reset in CBT data will trigger any virtual backup software to read the whole VM as it can't know which blocks were modified between increments. The resulting backup restore point will have a normal incremental size, the only thing that is affected is the speed of the actual backup or replication for the first run after the reset.

I was more curios why they mentioned that you need to reset the CBT in the upgrade procedure. Is it only for those that didn't already reset it following vSphere 6U1b or is it because of something else.

[PenguinSSH]

I hope this is the reason because reading through 30tb of data on vmware is not fun. It already does this on HYPER-V because of the upgrade of the components.

[Gostev]

To put it short, all recent VMware releases had some different CBT issue that may result in current CBT files content being invalid. As a result, it is a best practice to perform CBT reset after new Veeam installs and updates.

Obviously, it is not necessary to reset CBT again if you already did that after vSphere build that addresses known CBT issues of the corresponding vSphere version. In case of vSphere 6.0, this would be vSphere 6.0 Update 1b released just a few days ago (and I don't remember specific updates for previous vSphere releases, but the latest ones should all be fine obviously).

The best way for me to ensure that people will do this is to put it in the Install/Upgrade procedure. This way, their backups with v9 will be guaranteed to be consistent.

If you have suggestions on how the wording can be improved, please let me know. I can easily fix and re-upload release notes.

[mcrape]

Thanks for the 'official response' Gostev; if I am reading that correct then folks on 5.5 likely wont be affected as i don't recall a CBT issue there for awhile - is that correct?

Also, what is the method to do this for V9? It isn't highlighted in that KB article.

[Pat490]

CBT reset is done on VMware and so independent of Veeam version.
https://www.veeam.com/kb1113

[k00laid]

Matt there have been CBT issues with 5.5 recently as well fixed in the latest patch.

[kjstech]

How about those of us still on VMWare 5.0 U3 patch 11? Don't care for the SSO Service, or the web gui nonsense. IMO 5.0 is the best version. Will explore 6.0 update 1b in the next 30 days after that update gets out there though.

[larry]

Maybe it is time for an checkbox, full monthly with CBT reset. To protect us from unknown VMware CBT bugs.

[kjstech]

Well the Veeam KB article says there are two ways to reset the CBT. One is powering off the VM, that is a no go. The next is a VM CLI Powershell, which I can certainly do, but it states that it creates a snapshot then removes it which can stun the guest VM. This action DOES stun our vm's which is why we run backup windows and Veeam runs after hours (so when those snapshots are told to consolidate, no-one is here to experience anything, and our website is just slow or down for a minute or two).

So I agree if Veeam could do this to the VM right before it performs that VM's backup, great! Of course you wouldn't want this every time but scheduled would be ok. Perhaps monthly? Or perhaps after the restore points recycle (ie if you hold 14 restore points, backup #15 resets cbt then recycles oldest restore point and begins new backup).

But what should I do now? I'm not sure I have CBT bugs because I restored a few machines in the past, and My latest SureBackup lab seemed to work. Granted it was not the entire environment, just a very small percentage of backups, but shucks, I really want to upgrade and now this is in our way.

We are on ESXi 5.0.0 2312428

[kjstech]

I upgraded to v9 anyway and ran all the backups last night, and picked a few random machines to bring up in a SureBackup lab. The machines came up fine in the lab so I would suspect the backups are good and my ESXi 5.0 U3 2312428 did not experience any CBT bugs. Its an old tried and true release before the demise of VMWares QA so maybe that has something to do with it.

[Cragdoo]

Does this also apply to replication jobs ?

[Gostev]

Yes, anything that uses CBT.

[m.novelli]

Maybe it is time for an checkbox, full monthly with CBT reset. To protect us from unknown VMware CBT bugs.

Love this idea!

Marco

[HannesK]

SureBackup protects you from unknown CBT Bugs

[bzooz1]

Is the CBT reset required for VMware v5.5? Answer I got from support was that it was recommended, but not required.

[Gostev]

Every recent VMware release had some CBT bug at some point, so for safety reasons CBT reset is recommended as a part of the upgrade.

[frankive]

should we reset or do active full backup after upgrading v8 to v9 or are we good to go after the component updates?

[frankive]

need to do this with hyper-v too? in v9 the first backup did not take longer than nromally. That is a different from the upgrades to v7 and v8.

[foggy]

CBT should reset automatically for Hyper-V after Veeam B&R upgrade (you should see the corresponding message in the job session log during its next run). Probably performance improvements justified the need to re-read the entire VM data?

[GriffGB]

I still don't understand it. If I'm on Esxi 5.5 patch 4, and the problem is apparently in VMware, which I've not updated or expanded any disks on, why would updating Veeam cause a problem with the CBT of the backup?

[foggy]

Updating Veeam B&R will not cause a problem, resetting CBT as part of the upgrade process is a recommendation called upon to make sure you will have valid backups from this moment on (since CBT data can already be corrupted due to recent VMware issues). If you've already reset CBT upon installing ESXi 5.5 patch 4, you do not need to do that again.

[jsprinkleisg]

Love this idea!

I agree, it might be nice to have the option to schedule CBT reset within VBR, for users who understandably still don't completely trust CBT after all the issues. How about adding a job option to automatically reset CBT any time an Active Full Backup is performed? This way, if you're doing periodic full backups anyway, resetting CBT at that time shouldn't alter your expected backup window much. One potential issue might be other jobs' runtimes being affected the next time they run against the same VMs. A note in the UI could be added when selecting the option, to warn about this possibility.

[veremin]

I think what you can do for now is to create a PowerShell script and specify it as a pre-job activity. The script will check whether it's a full backup day and reset CBT for VMs chosen as a source for a backup job. Thanks.

[Gostev]

How about adding a job option to automatically reset CBT any time an Active Full Backup is performed?

Excellent idea, thanks James.

[nmace]

Looking to upgrade from v8 to v9 this week. One of the steps in the upgrade steps is to reset the CBT file for all of the VMs. Is that really necessary? I've got a 100+ VMs, I don't have time to power them off and reset CBT that way, so I'd have to do it online. And it looks to be a very manual process.

[foggy]

It might be necessary depending on the vSphere version and whether you've already done that before. Please see details above.