SMSQL 5.1 and SnapMgrMountPoint Issue

[elarin010]

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

[padoan]

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

[elarin010]

The server in question is running SD 6.2.1.

Erick

[abhisek]

Hi Erick ,

Can you please test with SnapDrive 6.3P1 release ?

Regards,

Abhishek

[elarin010]

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

Erick

[qzhang]

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

[elarin010]

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

[qzhang]

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.

[elarin010]

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

[draj]

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

[stalnake]

Hello,

Is there a way to track the status of this fix?

-Robert

[sandravigil]

I'm running SMSQL 5.1P1 and, oddly, having just the opposite experience, even though this version purports to fix this problem.  This is a brand new environment with an A/P failover cluster and a remote verification server, all running SQL 2008 R2. 

In my case, the backups, with defaults, worked just fine - mostly setup using the wizard defaults.  It was the restore operation that fails with this error. 

My workaround was to configure and schedule the backups as SQL Agent jobs with the mountpoint directory set to the default:  C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint.  Then, I changed the registry setting under HKEY_LOCAL_MACHINE\SOFTWARE\Network Appliance\SnapManager for SQL Server\Server\MountPointDir to point to an empty directory I created under the mount point directory used by my SQL instance, in my case M:\MPdir.  This allowed me to execute a restore successfully via the GUI.  (I had to do this via the registry since doing it through the GUI tries to verify that this directory exists on the verification server (It doesn't.  I only have a C: drive there) and errors out.

So, I'm a little baffled that the release notes for 5.1P1 claim to fix this problem. 

[jason_fay]

I'd like to add my experience with this.  I have an Active/Active cluster with a sql instance on one node and another sql instance on the second node.  During some troubleshooting with using a third server as a remote verification server and named instances, I changed the remote verification server to the local instance that I was backing up.  I had to change the mount point to a folder on the clustered disk (as is expected).  However, I could not change the remote verification server back to the third physical server and the mountpoint back to the default C:\Program Files\NetApp\Snap Manager For SQL\SnapManagerMountPoint\ or whatever the exact path is through the SMSQL GUI.  It would come up with a message similar to "The mount point and the verification server must be both shared or both non-shared".   I had to edit the value HKEY_LOCAL_MACHINE\SOFTWARE\Network Appliance\SnapManager for SQL Server\Server\MountPointDir to the C:\Program Files directory that I wanted on the 3rd Remote Verification server.  SMSQL build 5.1.0.676.

[bengelstad]

Does anyone know the BURT for this issue?  I'm seeing the same thing but with the clones. 

Thanks!

[joakimklein]

I'm running into somewhat the same problems. I'm running a two node windows 2k8r2 cluster with 2 sql server 2008 instances in two different cluster groups. On the first cluster group everything works fine and I have verification pointing at a shared disk in the cluster group. Verification, restore cloning all works. It always mount to one shared disk of the cluster group.

The problem I have is in the second cluster node. Im using the same verification server (the first instance). Verification fails. It also tries to use the mount path from the first instance making the restore and cloning fail since the shared disk is owned by the first cluster group (and don´t necessarily exist on the same physical server).  

I haven´t found any way to set different paths for different cluster groups. It all looks like the thing I can change is the verification server (and the path it uses) and that path is also used for mounting clones and backups. To me it feels like it should be different paths for different things. The path for clones and backups really should be pointed to the cluster group of the sql server instance so that it can follow the server if we change the node.

The install and admin guide tells us that multiple instances are supported but it does a poor job of telling us how to actually configure it. 😕

[joakimklein]

Have you succeded in havning mounted clones on both nodes(instances) at the same time?