SMSQL with VMDKs - SnapDrive showing snapshots that don't actually exist

[#1]

Hi,

I've recently switched my SQL Server 2008 setup from iSCSI LUNs to VMDKs on NFS shares. I know some people had issues with this setup but it's working great for me.

The SMSQL snapshots are scheduled daily at 6pm and delete any backups older than 7 days. Usually this works fine, but once every few weeks the backup fails and I end up with a flexclone of my volume and an additional datastore mounted to the VM.

I looked into this today and saw that the backup from 08/10/2012 failed to delete a snapshot from over a month ago.

[18:14:13.027]  DELETING BACKUP - [#1]
[18:14:13.027]  Deleting snapshot copy sqlsnap__svmsql01_07-12-2012_12.00.37 of LUN D
[18:14:22.098]  [SnapDrive Error]: Deletion of backup (sqlsnap__svmsql01_07-12-2012_12.00.37) failed. Reason: (The backup sqlsnap__svmsql01_07-12-2012_12.00.37 was not deleted successfully. Reason : The virtual entity ff6da25f-3297-41f5-9d03-dd50918c54b5 is mounted from backup sqlsnap__svmsql01_07-12-2012_12.00.37. Please unmount it and try again. ).
(SnapDrive Error Code: 0xc0041054)

I checked the NetApp, thinking there might be a stale and locked snapshot there, but that snapshot (sqlsnap__svmsql01_07-12-2012_12.00.37) doesn't exist.

FAS2020-1> snap list NFS_SQL01
Volume NFS_SQL01
working...
  %/used       %/total  date          name
----------  ----------  ------------  --------
  3% ( 3%)    1% ( 1%)  Aug 13 22:00  vsp032(0135099854)_rhf_sm_nfs_sql01.23 (snapmirror)
  4% ( 1%)    2% ( 1%)  Aug 13 18:06  sqlinfo__svmsql01_08-13-2012_18.02.36
  4% ( 0%)    2% ( 0%)  Aug 13 18:05  sqlsnap__svmsql01_08-13-2012_18.02.36
  5% ( 1%)    3% ( 1%)  Aug 12 18:03  sqlinfo__svmsql01_08-12-2012_18.01.24
  5% ( 0%)    3% ( 0%)  Aug 12 18:03  sqlsnap__svmsql01_08-12-2012_18.01.24
  7% ( 2%)    3% ( 1%)  Aug 11 18:03  sqlinfo__svmsql01_08-11-2012_18.01.30
  7% ( 0%)    3% ( 0%)  Aug 11 18:03  sqlsnap__svmsql01_08-11-2012_18.01.30
  9% ( 2%)    5% ( 1%)  Aug 10 18:04  sqlinfo__svmsql01_08-10-2012_18.02.07
  9% ( 0%)    5% ( 0%)  Aug 10 18:04  sqlsnap__svmsql01_08-10-2012_18.02.07
 14% ( 6%)    8% ( 3%)  Aug 09 18:04  sqlinfo__svmsql01_08-09-2012_18.01.36
 14% ( 0%)    8% ( 0%)  Aug 09 18:03  sqlsnap__svmsql01_08-09-2012_18.01.36
 16% ( 3%)    9% ( 1%)  Aug 08 18:03  sqlinfo__svmsql01_08-08-2012_18.01.27
 16% ( 0%)    9% ( 0%)  Aug 08 18:03  sqlsnap__svmsql01_08-08-2012_18.01.27
 17% ( 2%)   10% ( 1%)  Aug 07 18:04  sqlinfo__svmsql01_08-07-2012_18.01.34
 17% ( 0%)   10% ( 0%)  Aug 07 18:03  sqlsnap__svmsql01_08-07-2012_18.01.34

Next I'm checking SnapDrive on the server and the snapshot shows up there!

Any ideas where that snapshots comes from and how to remove it? I'm thinking that SnapDrive might get it from VSC, but I can't even find a list of snapshots in VSC to check this.

[#2]

hi uuwe_rhf__

can you please share your details, procedure .. how you moved LUNs to Shares.

[#3]

I created the vmdk and migrated the sql files within Windows. The migration happened in June, so the July-12 snapshot it's looking for was at some point a valid snapshot for the vmdk setup.

[#4 · Accepted solution]

Try this:

https://kb.netapp.com/support/index?page=content&id=2016617

[#5]

Thank you, this was pretty much the solution.

The article refers to VSC, but in SMVI the instructions didn't quite work. Renaming the files didn't have any effect, so I had to edit the backups.xml and delete the entries for the stale snapshots.

[#6]

I ran into this issue with one of my customers today and it resolved the problem, but the procedure was slightly different.   I had to restart the VSC services and SnapDrive service on the SQL server a couple times before it took effect.  Anyway, I am glad you got it working.