I am working with an environment using CommVault 10.x for VM level disk snapshots that previously had been using iDataAgent to do SQL and File level backups without issue. About 3 months go the change was made to VM level snapshots and twice in the last month with 2 hours of the snapshot SQL reports Error 824 in one or more pages in the Clustered Index of the same table. All other tables/indexes in the same database are fine according to DBCC CheckDatabase. The change was made to support a RTO without much consideration to the backup process within SQL. The database is in FULL recovery mode and currently nothing is backing up and clearing the logs so they are growing out of control and there essentially is no point in time recovery. The have other maintenance issues such as indexes not being maintained as well. I am advising that they return back to the prior method that has worked for years with the same VM utilizing without issue which is CommVault FULL and TLog backups and File Level to grab backup files, etc. They could still do VM snapshots, but mostly just before maintenance items like updates, services packs, etc where I would still recommend they have the native SQL backups as well.
My only thought is could high I/O activity during a VSS snapshot of a SQL instance actually cause a clustered index to become corrupt?