SnapManager for SQL not updating SnapMirror

[GOODFELLA2071]

I have an SQL server which I have configured the following job through SnapManager for SQL:

"C:\Program Files\NetApp\SnapManager for SQL Server\SMSQLJobLauncher.exe" new-backup  –svr 'SQLSERVER1'  -d  'SQLSERVER1\INST1', '1', 'DB1',  'SQLSERVER1\INST2', '7', 'DB1', 'DB2', 'DB3', 'DB4', 'DB5', 'DB6', 'DB7',  'SQLSERVER1\INST3', '3', 'DB1', 'DB2', 'DB3' -RetainBackups  6 -lb -bksif -RetainSnapofSnapInfo 3 -trlog  -updmir  –mgmt standard

All the necessary SnapVault and SnapMirror relationships are already in place.  I have also attached a screenshot of the Backup & Verify process (obviously blanking out my server names etc) that shows all the necessary boxes ticked.  I do now however have two questions that I hope you are able to help with.

1.     I wish to update the SnapMirror after operation.  Clearly from the screenshot this tick box is greyed out.  The only way I can tick this box is if I click on 'Verify on available SnapMirror destination volumes' then untick this option as well as the 'Verify databases after backup (run DBCC CHECKDB)' option.

          As previously stated the SnapMirror relationship already exists so why is this greyed out?  I have found a workaround but I am sure that this is not normal.

2.     When the job runs there are no error messages displayed and the SnapManager reports that a Full database backup completed sucessfully.  When I check the controller and run 'snapvault status' and 'snapmirror status' the lags are still present but when I check the snapshots created on the volumes within System Manager I find that they have been created sucessfully.

Am I missing a trick here?  I need the SnapVault and SnapMirror to run.  How can I get this to work?

I look forward to all responses in the anticipation that I might get this to work.

[gdekhayser]

This should be an easy one.  In your command line, add the "-UpdateMirror" switch.  That will do it.  There are some bugs (I understand) in the wizards that don't properly set some of the snapmirror related switches properly, for instance the "-CloneOnMirrorDestination" does NOT get set in the new clone resync wizards. 

[gdekhayser]

I see your "-updmir" switch- replace that one. Not sure if that's it.

Also make sure that your SMSQL box can log into the remote netapp for snapmirror!  that's where the update has to be triggered....

[GOODFELLA2071]

OK, I have now changed the switch from -updmir to -UpdateMirror but this still hasn't fixed the issue.  I have however since found that the SnapVault has in fact updated sucessfully which is a bonus.  I am now halfway there!  Now all I need to get fixed is the SnapMirror!!

I have continued to investigate this issue and I believe I have found why we are unable to conduct a SnapMirror.  I have looked at the mapped LUNs within SnapDrive on the affected server and have found that the SnapMirror option is set to 'No' under the Disk Details.  Surely since the SnapMirror relationship already exists then this option should be available to me and set to 'Yes'??

Is there a setting that needs to be adjusted at the Volume level on the Filer? I have looked at the NetApp manual and have found the following option:

snapmirrored off

If SnapMirror is enabled, the filer automatically sets this option to on. Set this option to off if SnapMirror is no longer to be used to update the mirror. After setting this option to off, the mirror becomes a regular writable volume. This option can only be set to off; only the filer can change the value of this option from off to on.

Would this be the right thing to look at?  Again, any help and assistance would be gratefully appreciated.

[gdekhayser]

On both filers....do a "snapmirror status" and see what the state is for both sides?

[GOODFELLA2071]

Hi, I have conducted a 'snapmirror status' on both filers and the status for both sides is 'idle'.  I have broken the SnapMirror and also released it and recreated it.  This did nothing but reduce my SnapMirror lag timings down which is great, but I obviously need this to run automatically.

In my opinion, there is nothing actually wrong with the physical SnapMirror relationship.  I believe may have something to do with the LUN configuration.  I have therefore investigated the following:

When I run sdcli on the SQL server and run 'sdcli disk list' I am presented with all disks/LUNs that are attached to the server (a total of 4 in this case) with a whole plethora of information.  The part that I am most concerned with is Snapmirror source.  The current status of all LUNs that are attached to this server is that Snapmirror source is set to 'No'.  This (again, in my opinion), should be Snapmirror source = Yes.

If I am correct in my assumption, how do I go about changing this field to 'Yes'?  I then believe if this field is changed to Yes then the SnapMirror scheduled task that is run through SnapManager for SQL will then run correctly.

I look forward as always to all answers.  Thank you in anticipation.

[NETAPPTNT]

I came here hoping to find answer. I am running snapdrive 6.5 and encountered the same issue you were experiencing.

It was just moments ago I was able resolve this issue.

The Fix is that you have to "initialize" the snapmirror relationships in conjunction to that, you also have to enter the 'updmir' as mentioned before.

Once this is done the status on the LUNS would be snapmirrored = YES! from there you can go ahead and update your mirrors.

[GOODFELLA2071 · Accepted solution]

We have now found a solution to this problem.  It seems that SnapDrive 6.3.1 does not recognise SnapMirror relationships for LUNs in a qtree.  We have now downgraded to SnapDrive 6.3P2 which had no detrimental affect on the server (did not require a reboot).  After the new installation both jobs (on both servers) were run and we now have fully running SnapShots, SnapVaults and SnapMirrors.

Thank you all for your support with this particular incident.  I look forward to hopefully helping some of you in the near future.

[ITSUPPORTLOWRY]

I can confirm using SnapDrive 6.3.1 and the -UpdateMirror switch works for me using LUNs sitting in qtrees. SnapDrive 6.3P2 shouldn't be used as it contains a bug where the SnapDrive logs are not removed from the C:\Program Files\NetApp\ Folder and therefore fill up the drive.

Message was edited by: Jason Edwards