Magic, eh?īut our genius support folks did come up with a way to nail this problem down.
#Vmware 6.0 cbt issues full#
Which made CBT the next suspect - but the following troubleshooting steps revealed that the corruption could occur even when restoring from an active full backup! On the other hand, the issue would not reproduce when CBT was disabled completely.
This normally points at storage corruption – but production VMs did not have these issues, while backup files' content was matching the checksums.
#Vmware 6.0 cbt issues windows#
The customer was experiencing classic data corruption issues after full VM restores – the restored VMs had Windows firing up chkdsk, and checkdb was reporting corruptions in Microsoft SQL Server databases. It all started from a support case coming from a fresh vSphere 6.0 deployment running VMs with thin disks hosted on VVols backed by Nimble storage. However, there's a hope that the bug is isolated to the particular storage model and/or Virtual Volumes (VVols) only – otherwise, we'd probably have way more customers reporting failed recoveries. We've already demonstrated this bug to VMware support using naked API, so everyone is at risk no matter what vSphere backup product they are using. Now, I recognize this may look like an April Fool's joke, so to be clear – this is NOT one. What can be worse than a new vSphere changed block tracking (CBT) bug? The CBT bug that even an Active Full backup does not help against! And unfortunately, we have just confirmed such bug to exist. Nimble may not be the only affected vendor and Veeam havent said which Nimble array the issue was reported on.
The message references "vSphere 6.x, Nimble Storage, Thin Disks, VVols". HPE Blog, Austria, Germany & Switzerlandįor those who do not subscribe to the Veeam Community Forums Digest, yesterday Gostev advised of a new vSphere CBT issue which is causing " corruption issues after full VM restores".
0 kommentar(er)
