Backups of certain vSAN-based .vmdk files are failing with "Checksum errors"

Products

• VMware vSAN

Issue/Introduction

Taking a backup of certain vSAN-based .vmdk files are failing and ''Checksum" errors are seen in the vmkwarning.log - see example listed below.

 

When querying the .vmdk components in the vmkwarning.log you will notice the following.

 

2025-05-25T18:49:22.879Z cpu8:2099032)WARNING: LSOM: LSOMReadVerifyChecksum:4397: Throttled: Checksum error detected on component ########-####-####-####-############, comp offset ########### (computed CRC 0x0 != saved CRC ########## (faked: Y))
esx-esx##.#####.###-2025-05-26--10.10-83618774/var/run/log/vmkwarning.log
2025-05-24T07:02:59.691Z cpu10:2099027)WARNING: LSOM: LSOMReadVerifyChecksum:4397: Throttled: Checksum error detected on component ########-####-####-####-############, comp offset ########### (computed CRC 0x0 != saved CRC ############ (faked: Y))

Environment

ESXi7.X

Cause

A component may encounter a checksum error and may have no other mirror to rebuild from.  The object's contents in this situation would be 'damaged'.  

 

The block in question would be marked as bad, and will return an unreadable exception to the guest.

 

 

Resolution

• If backups don't exist then Create a no-checksum storage policy 
• Apply that policy to all affected object(s) 
• Clone the affected object(s)
    a) If downtime is not allowed for the VM, clone the entire VM
    b) If downtime is allowed for the VM clone just the affected vmdk with vmkfstools -i <disk-with-checksum-errors>.vmdk <new>.vmdk -W vsan
    c) If downtime is not allowed for the VM and you just want to work with the affected vmdk then create a new vmdk of equal size to the affected disk, attach it to the VM, and then do a file-level copy
• Once the cloned VM(s)/vmdk(s) data integrity has been restored with a no-checksum policy applied you may delete the old VM(s)/vmdk(s) with checksum errors
• The components identified with Checksum" errors should not be reporting "Checksum" errors any longer as those bad blocks should have been reallocated to no longer be used.
• If the components are still reporting "Checksum" errors then the hardware vendor should be engaged to perform a replacement disk of the disk or remove the bad disk from the disk group if dedupe is disabled and add it back. If dedupe is enabled then recreate the disk group : How to manually manage and configure a vSAN disk group using esxcli commands