SnapManager for SQL backup fails

[sushantaghosh]

Hi All, really need your help to fix a long pending issue with our SM SQL backup. We have a few VMware Guests hosted on ESX server running ESXi 4.1. All drives allocated are from datastores with separate drives for SQL-database, transactional logs, temp-db and snapinfo. There is no archiving set up, only local snapshots to be retained for 35 days. Full backups are scheduled once a day while transactional log backups are scheduled every hour. OS disks are backed up using Virtual Storage Console.

Occasionally we have received the following error:

**** FULL DATABASE BACKUP RESULT SUMMARY #1 **** Backup Time: 09-10-2014_20.00.11 Backup Group [#1]:

#1 : [GLBWITOKDB2 - distribution] Error : Failed to create snapshot [GLBWITOKDB2 : distribution].

#1 : [GLBWITOKDB2 - distribution] Error Details: [SnapDrive Error]: Creation of backup (sqlsnap__glbwitokdb2_09-10-2014_20.00.11__daily) failed. Reason: (At least one disk is part of VMware snapshot. Disk(s) part of VMware snapshot cannot be part of backup).

(SnapDrive Error Code: 0xc0041074)

#2 : [GLBWITOKDB2 - TokenVault] Error : Failed to create snapshot [GLBWITOKDB2 : TokenVault].

#2 : [GLBWITOKDB2 - TokenVault] Error Details: [SnapDrive Error]: Creation of backup (sqlsnap__glbwitokdb2_09-10-2014_20.00.11__daily) failed. Reason: (At least one disk is part of VMware snapshot. Disk(s) part of VMware snapshot cannot be part of backup).

(SnapDrive Error Code: 0xc0041074)

I have checked and confirmed that no other snapshots (except created using snapmanager) exist for the disks on which the database is hosted.

Has anyone seen this error before?

[welch]

Two thoughts here.  First, are you runing any VMWare snapshots on any of your database drives, and second, have you tried running through the configuration wizard to see if it likes your database layouts?

[AndyD]

This is one of those errors that means what it says.

(At least one disk is part of VMware snapshot. Disk(s) part of VMware snapshot cannot be part of backup)

This indicates that the datastore/VMs on which the VMDKs reside is also being snapshot, either using VMware's native snapshot or via NetApp's Virtual Storage Console (which in turn calls the VMware snapshot API).

To resolve, two steps need to occur:

1. Ensure that no VMware snapshots exist for the VMDKs containing the user database MDF/LDF files or the SnapInfo VMDK.  If VMware snapshots exist, delete them.

2. Configure your scheduled snapshots to only snapshot the datastore containing the system (C:\) VMDK.

3. If your data VMDKs reside on the same datastore as the system VMDKs, migrate them to a new datastore (VMFS or NFS) on a new volume on the storage controller.  If licensed in vCenter, you could use storage vMotion to migrate the data with no downtime (just ensure that no SMSQL backups are running during the storage migration).