2011-05-12 08:01 AM
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?
SQL 2008 SP1 Active/Passive Cluster
Using mount points for SQL directories
2011-05-31 09:39 AM
This issue has nothing to do with SDW.
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.
2011-05-31 01:20 PM
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?
2011-05-31 03:48 PM
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.
2011-06-01 02:37 PM
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.
2011-06-03 04:12 AM
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.