Protection Manager....snapmirror / snapvault which one???

[sswain123]

I'm looking for a little clarification regarding SM and SV using PM. I've configured my PM policy as 'Back up' and have added the Protection policy to a number of my datasets...what i'm seeing is that all my replications are snapmirror qsm... I understand that SV uses qsm under the hood but, all the relationships created are SM.  I was under the impression that if I use PM policy 'Back up' policy that SV would be used not SM. 

- If sv_ontap_pri and sv_ontap_sec are licensed across the filers as required and snapvault.access is set correctly, why was SV not used?

- if SM and SV are licensed, which one wins when secondary storage is provisioned and replications started (it would appear that SM wins)

- should SV not be used as SV is more used for backups than SM?

- is there a way to convert a SM to a SV (will 'snapvault convert' work the other way)?

Any help on the above would be appreciated.

Thanks,
Scott

[adaikkap]

Hi Scott,

You must change this option to make SV as your preferred backup method.

By default its QSM.Thats the reason you see its QSM wining in spite of all SV license being enabled.

# dfm options list pmQSMBackupPreferred

Option Value

[sswain123]

My assumption is that any newly protected data would us SV is this change is made; what happen with the existing SM qsm's?

Could i do a SM quiesce//break...then a 'snapvault update -S ' to resync using the most common snapshot?

[adaikkap]

My assumption is that any newly protected data would us SV is this change is made;

Yes. your assumptions is correct.

what happen with the existing SM qsm's?

They stay as it is.

Could i do a SM quiesce//break...then a 'snapvault update -S ' to resync using the most common snapshot?

Don’t know if this would work, give it a try.

Regards

adai

[smoot]

Hi Scott --

There are other things we take into account:

o If you select a DR-enabled backup, that's always QSM

o If you create the dataset through SME or SMSQL, we always use SV (SV can restore LUNs without disrupting Windows clustering, but QSM cannot).

o If you have a schedule which updates more frequently than once an hour, we use QSM

We do look at licenses but do not double check the snapmirror.access or snapvault.access options.  I think that's the whole list.

Adai is right, if you change the preference option, we don't convert QSM relationships to SV.  If you convert that by hand, you'll have to import the resulting SV relationship (because we won't think we own the relationship).

-- Pete

[sswain123]

I ran the 'dfm options set pmQSMBackupPreferred=yes' as directed by Adai however, nothing changed in the way that the Backup policy ran...I was still using SM over SV.  Looking at the command, it really only specify QSM, not specific to SM or SV.  After making the change, I created a new dataset, added a volume and gave it a ‘Back up’ protection policy.... I even went as far as turning snapmirror off.... when conformance ran, I was erroring out because Snapmirror was off. No joy, SV wasn't even mentioned.

Is there anywhere else I need to make a change to get this to start using SV?

Also, I was able to go into priv set diag and use 'snapvault convert' to change the SM qsm to SV qsm but, DFM was not able to recognize the change and I ran into issue updating the SV...  so, once i can get SV to work, I’m going to rebaseline.

Thanks for the info fellas.

[adaikkap]

Hi Scott,

     You must make this option

dfm options set  pmQSMBackupPreferred=no and not yes to make SV.

Also after converting your relationships from QSM to SV how long did you wait ?

Did the snapvault monitor run to discover the new SV relationship ?

Regards

adai

[sswain123]

The DFM option was originally set to 'dfm options set  pmQSMBackupPreferred=no'.  I assumed that because it was NO and it was not working, that i had to change this to YES.

I had waited about 45minutes to see what was happening with SV's .. and again checked this morning...about 20hrs later.  Were can I manually kick off 'snapvault monitor' ??

When I check out the Job status, I'm erroring out at step 'Relationship Create Progress'....Event Descriptions: type=mirror, Error Message=filername Snapmirror is off. 

I don't understand why it's trying to use SM...

Thanks Adai!

[adaikkap]

Ok.Let me give you all the possiblity of how  PM decides to create SV/QSM relationships.Based on this check where you are.

To create SV relationship using backup policy dataset (Not DR Backup policy as they always create QSM relationships irrespective of the below items.)

1.The options pmQSMBackupPreferred=no

2.The Source Filer must have sv_ontap_pri license.

3.The Destination fielr must have sv_ontap_sec license.

4.The Schedule should not be more frequent than an hour

F all the above 4 condition are satisfied you dataset with Backup Policy will create SV.

Even if one of them fails and SnapMirror was licensed it will create QSM.

Also check this FAQ.

http://now.netapp.com/NOW/knowledge/docs/DFM_win/rel40/html/faq/index.shtml#_16.1

Now coming to your second question.

you can manually kickoff the monitors by running the below command.

dfm host discover <filer name/id>

Run this command on both source and destination.

BTW what is the version of dfm you are running ?

Regards

adai.

[sswain123]

All 4 conditions you mentioned have been met...I've double checked. The schedule running is the default from the 'Back up' policy..I just changed retention periods to meet my Corp. requirements.  I would assume that the schedule predefined by NetApp should work without me having to make any chnages.

I'm currently running DFM3.8....I have a change scheduled for Monday night to upgrade to DFM3.8.1.

[adaikkap]

Can you try to create one more dataset and just send us the dry run results?

Can you also get us the output details of the below command from Primary and Secondary filers ?

# dfm detail 98 | grep -i svPrimaryIsLicensed

svPrimaryIsLicensed Yes

# dfm detail 101 | grep -i svSecondaryIsLicensed

svSecondaryIsLicensed Yes

#

Regards

adai

[sswain123]

A Correction to my last reply...

I did verify that all 4 conditions has been met however; my Primary Data was set 'Local Backup Schedule' to 'Sunday at midnight with daily and hourly' and my Primary data to Backup was set 'Sunday at midnight with daily and hourly'.  I've since changed the schedule on both to Sunday at 8:00pm plus daily'....  I’ve created a test dataset, applied this newly changed policy but, I’m still getting Snapmirror relationships. 

No clue what else to try...any suggestions?

Thanks.

[smoot]

Hi Scott --

I'm running out of simple ideas.  You might need to open a case with NGS to turn on some extra debugging logs.

Grasping at straws here, did you by chance use the "DR Backup" policy instead of "Backup"?

You haven't mentioned what DFM release you're using.  By chance, do your storage systems have both the SV primary and secondary licenses?  If so, you need the just releases 4.0 code.

Try running the host diagnostic wizard for both your hosts.  Verify that SnapVault is enabled and that ProtMgr knows about the licenses.

You can also try creating SV relationships using the old BCO code. Either go to the main "Backup" tab in Operations Manager, or use the "dfbm" ("b" as in "Easter Bunny", not "p" as in "Passover") command.  The sequence should be:

     dfbm primary host add primary-filer-name

     dfbm secondary host add secondary-filer-name

     dfbm secondary volume add secondary-volume-name

     dfbm primary dir add secondary-volume-name primary-qtree-name

-- Pete

[smoot]

Oh, I forgot to clarify one thing.  I'm hoping at least one of the dfbm commands will fail with an explaintory error message.  That should help us figure out why you're not getting SV relationships.

[sswain123]

Thanks Pete... i'm running 3.8 and have a change scheduled for tonight to upgrade to 3.8.1.  OM4.0 is still a while away...i'm waiting for my TGA to give the thumbs up for that upgrade. Though, i may be forced if we can'te resolve this wiht 3.8.1.

I'm in he process of cleaning up the environment...I havea WebEx in a couple hours with Adai...

Thanks.

[adaikkap · Accepted solution]

The problem was due to scheduled dedupe being enabled in the secondary provisioning policy that was being used in the backup node.

Bug 406552 to add this to our existing FAQ of when is SV and QSM chosen when both are licensed, to the existing FAQ.

Regards

adai