{"id":14430,"date":"2015-11-23T10:00:55","date_gmt":"2015-11-23T09:00:55","guid":{"rendered":"http:\/\/nolabnoparty.com\/en\/?p=14430"},"modified":"2023-07-16T11:25:00","modified_gmt":"2023-07-16T09:25:00","slug":"vmware-vsphere-6-0-cbt-issue-during-backup","status":"publish","type":"post","link":"https:\/\/nolabnoparty.com\/en\/vmware-vsphere-6-0-cbt-issue-during-backup\/","title":{"rendered":"VMware vSphere 6.0 CBT issue during backup"},"content":{"rendered":"

\"vsphere60cbtissue01\"<\/p>\n

A critical vSphere 6.0 CBT issue during backup has been recently discovered that results in inconsistent incremental virtual machine backups.<\/p>\n

All incremental backups which utilize CBT are potentially affected and you should disable the CBT function wherever is possible to avoid data loss.<\/p>\n

Changed Block Tracking (CBT), a native VMware feature, backs up only the blocks that have changed, rather than backing up every block of every VM in the infrastructure. This backup solution allows to save disk space and requires less time to complete.<\/p>\n

\"vsphere60cbtissue02\"<\/p>\n

This issue occurs due to a problem with CBT in the disklib area<\/strong>, which results in the change tracking information of I\/Os that occur during snapshot consolidation to be lost. The main backup payload data is never lost and it is always written to the backend device. However, the corresponding change tracking information entries which occur during the consolidation task are missed. The vSphere API SubsequentQueryDiskChangedAreas()<\/em> calls do not include these missed blocks and therefore a backup based on this CBT data is inconsistent<\/strong>.<\/p>\n

The problem is reported in the KB 2136854<\/a>.<\/p>\n

 <\/p>\n

Fix<\/h2>\n

No solution<\/strong> is currently available to fix this matter and the only workaround is to disable CBT or downgrade the ESXi hosts <\/strong>to version 5.5.<\/p>\n

If Veeam or Trilead backup solutions<\/strong> are used in your environment, the CBT feature can be disabled<\/strong> performing regular backups that remain consistent.<\/p>\n

Update\u00a027\/11\/2015<\/strong><\/span>: VMware released the patch<\/a>\u00a0to fix the CBT issue.<\/p>\n

 <\/p>\n

Veeam Backup & Replication<\/h4>\n

Veeam users can disable the use of CBT<\/strong> in the job configuration keeping the incremental backups but space and time required are increased. In the screenshot, an example of backup using CBT.<\/p>\n

\"vsphere60cbtissue03\"<\/p>\n

To disable CBT, edit the Backup Job<\/strong> and select the Storage<\/strong> section. Click on Advanced<\/strong> button to access the advanced job settings.<\/p>\n

\"vsphere60cbtissue04\"<\/p>\n

Select vSphere<\/strong> tab and disable the Use changed block tracking data (recommended)<\/strong>\u00a0option then click OK<\/strong> to confirm.<\/p>\n

\"vsphere60cbtissue05\"<\/p>\n

Click Finish<\/strong> to save the backup job with CBT disabled.<\/p>\n

\"vsphere60cbtissue06\"<\/p>\n

 <\/p>\n

Trilead VM Explorer<\/h4>\n

To disable CBT in Trilead Explorer, access the web console and select Datacenter<\/strong> tab. Right click the affected ESXi hosts and select the Edit Server<\/strong> option.<\/p>\n

\"vsphere60cbtissue07\"<\/p>\n

Select Advanced Setting<\/strong> section and disable the Use VD Service<\/strong>. Click Finish<\/strong> to save the configuration.<\/p>\n

\"vsphere60cbtissue08\"<\/p>\n

If your environment is still running vSphere 5.5, keep going this way. Due to the\u00a0current issues with the new release, not sure if time to upgrade to version 6.0 has arrived.<\/p>\n

\"firma\"<\/p>\n","protected":false},"excerpt":{"rendered":"

A critical vSphere 6.0 CBT issue during backup has been recently discovered that results in inconsistent incremental virtual machine backups. All incremental backups which utilize CBT are potentially affected and you should disable the CBT function wherever is possible to avoid data loss.<\/p>\n","protected":false},"author":3,"featured_media":14440,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rop_custom_images_group":[],"rop_custom_messages_group":[],"rop_publish_now":"initial","rop_publish_now_accounts":{"facebook_2879994398731222_17841400390232720":"","mastodon_115463926174894442_115463926174894442":"","linkedin_93tdZWzMZc_93tdZWzMZc":"","bluesky_did:plc:tkabz5kl2rukzdwtuongv3kz_did:plc:tkabz5kl2rukzdwtuongv3kz":""},"rop_publish_now_history":[],"rop_publish_now_status":"pending","footnotes":""},"categories":[903,2701],"tags":[579,1630,699,700],"class_list":["post-14430","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-vmware-en","category-vsphere-en","tag-backup-en","tag-cbt","tag-vmware-en","tag-vsphere-en","has_thumb"],"_links":{"self":[{"href":"https:\/\/nolabnoparty.com\/en\/wp-json\/wp\/v2\/posts\/14430","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nolabnoparty.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nolabnoparty.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nolabnoparty.com\/en\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/nolabnoparty.com\/en\/wp-json\/wp\/v2\/comments?post=14430"}],"version-history":[{"count":0,"href":"https:\/\/nolabnoparty.com\/en\/wp-json\/wp\/v2\/posts\/14430\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nolabnoparty.com\/en\/wp-json\/wp\/v2\/media\/14440"}],"wp:attachment":[{"href":"https:\/\/nolabnoparty.com\/en\/wp-json\/wp\/v2\/media?parent=14430"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nolabnoparty.com\/en\/wp-json\/wp\/v2\/categories?post=14430"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nolabnoparty.com\/en\/wp-json\/wp\/v2\/tags?post=14430"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}