Subscribe

SMSQL 5.1 and SnapMgrMountPoint Issue

All,

I'm running into a new dilema regarding SMSQL 5.1 backup and restore that I wasn't seeing in 5.0. For my SQL job that performs transaction log backups, the command line originally included the text "-mp  –mpdir 'C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint'". This worked fine in 5.0. But with 5.1, SMSQL errors out with the message "Mount point directory path for mounting snapshot on clustered instance should be a share disk on the SQL Server cluster group." Fine. I created a new folder named SnapMgrMountPoint on the root of my root mount point and changed the command line to be "-mp  –mpdir 'I:\SnapMgrMountPoint'". The job runs fine now.

So yesterday, I had to perform a restore on a database. SMSQL errored out with the message "Operating System does not support mounting non-shared disk on a shared volume. Please change disk type or select different mount point". So the restore operation doesn't like the MountPointDir to be on a shared disk which is what the backup complains about. Changing the MountPointDir registry value back to 'C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint' fixes the restore operation.

So what's the deal here? How do I fix the backup vs restore constraints regarding SnapMgrMountPoint?

SMSQL 5.1

SQL 2008 SP1 Active/Passive Cluster

Using mount points for SQL directories

Thanks,

Erick

Re: SMSQL 5.1 and SnapMgrMountPoint Issue

did you try to upgrade SDW too? only a recent version can leverage this new feature of SMSQL regarding verification, maybe 6.1P1 I don't remember exactly

Re: SMSQL 5.1 and SnapMgrMountPoint Issue

The server in question is running SD 6.2.1.

Erick

Re: SMSQL 5.1 and SnapMgrMountPoint Issue

Hi Erick ,

Can you please test with SnapDrive 6.3P1 release ?

Regards,

Abhishek

Re: SMSQL 5.1 and SnapMgrMountPoint Issue

I installed SD 6.3P1 on both of my server nodes and experienced the same issue.

Erick

Re: SMSQL 5.1 and SnapMgrMountPoint Issue

This issue has nothing to do with SDW.

  1. If you are running log backup only, you don’t need to specify mount point directory. Mount point directory is needed if you want to do DBCC checkdb for full backup verification.
  2. New in SMSQL 5.1, you can use clustered instance for running verification. That is why if you specify a clustered instance as your verification server, the default C:\program file\NetApp\SnapManager…\ will NOT work, as it is not a shared disk. So it appeared that you changed your verification server from a standalone server to a clustered instance. If you continue using a standalone verification server as you did in 5.0, the default c:\program file\.. should continue to work.
  3. For restoring individual db from multiple dbs configuration, you do need to use an non-shared disk as mount point directory (specified in backup verification server settings), for example, c:\program files\... as you did.
  4. For clone to a clustered instance, you would need to specify a shared disk (you specify it same in backup verification server setting).

From what you described, you already know how to workaround this issue, which is to reset the mount point directory path to shared disk and non-shared disk back and forth, depending what you are about to do (e.g., verification, restore, or clone). Engineering is working on a fix to address this problem.

If you don’t use the new feature from SMSQL 5.1, your old configuration should work fine.

Thanks, Qing

Re: SMSQL 5.1 and SnapMgrMountPoint Issue

Qing,

1. The mount point directory syntax was inserted automatically by the "Backup Wizard" when I created my job to do transaction log backups in which I said to verify log backups. So is this why it's part of the job?

2. I'm using the same standalone verification server in 5.1 that I used in 5.0.

So my old configuration is not working with 5.1. When you say Engineering is working on a fix, is the fix to not use a non-shared disk (as it was in 5.0 for backups and restores) or to use a shared disk?

Erick

Re: SMSQL 5.1 and SnapMgrMountPoint Issue

If you are doing log backup ONLY, you don't need to specify mount point path. Even if you do, it would not affect anything.

Obvisouly the software was using clustered instance, or you would not get this error "Mount point directory path for mounting snapshot on clustered instance should be a share disk on the SQL Server cluster group". I suggest you check the report file to see why it was giving such error.

Engineering is working on a fix which you wouldn't need to switch mount point path back and forth for everything to work, i.e., you don't need to change the mount point path for individual db restore to work after the fix. But it is still up to you to make sure you are providing the right mount point path (shared or non-shared) for doing the verification.

Re: SMSQL 5.1 and SnapMgrMountPoint Issue

Using SMSQL 5.0 on a clustered instance, my mount point directory path was the default C:\Program Files\... and my verification server was a standalone SQL instance. But in the exact setup, SMSQL 5.1 complains about C:\Program Files\..., hence the "Mount point directory path for mounting snapshot on clustered instance should be a share disk on the SQL Server cluster group" error. SMSQL 5.0 didn't complain.

Erick

Re: SMSQL 5.1 and SnapMgrMountPoint Issue

Hi Erick,

I just tested the same scenarios that you have mentioned in the initial post and they worked fine for me.

Here is what I have done:

1. Installed SMSQL 5.0 on my 2-Node W2K8 setup.

2. Specified a stand alone remote server as the verification server.

3. Ran backups (log backups also) & restores, which went fine.

4. Created a scheduled job which takes only log backup of 3 dbs's (Vdisk scenario), which went fine.

5. Upgraded SMSQL to 5.1 on both the nodes.

6. Did not change any settings.

7. Checked the schedule job for log backups created in step4 as well as manually executed transaction log backup for the same 3 db's using new-backup powershell cmdlet.

8. Both operations were successful.

9. Also checked the restore of 3 db's together, which was successful. SMSQL did not complain about any mount point directory settings.

10. I even checked restore of individual db out of the 3 db's, which also was successful.

Can you please update your database layout, so that I can try to replicate the same and see if the issue mentioned by you can be reproduced.?

Let me know for further details.

Thanks,

Deva