Operation Manager Data Protection Manager Lag error

[dalemarshall]

Hi all,

I'm getting email alerts from Ops manager claiming there's a Dataset Lag protection errors on a few of our datasets. However when I check in DFM and snapmirror status the lag time is correct according to the schedule.

I've checked the lag thresholds in the policy, warning is set to 1.5d and error to 2.5. We're getting a successful sync every night yet I still see this email alert claiming there is an eror.

Any ideas greatly appreciated.

[smoot]

Check the lag settings on the primary node. A dataset lag warning can mean the most recent backup of the primary data is too old.

[dalemarshall]

Thanks for the reply

Is there a dataset lag setting other than those in the protection policies? I've checked these and they're set to warning 1.5d and error 2d. The lag is never anymore that 24 hours so not sure why we should be getting error alerts.

[adaikkap]

Can you get the event detail and the output of the following command for the dataset on which this event is generated ?

dfpm dataset list –R <dataset-name-or-id>

Regards

adai

[lovik_netapp]

What is the version of your Ontap as it might be an old SMTP misreporting issue, check BURT#382019 to be sure you are not hitting that.

[dalemarshall]

Thanks for the suggestions so far. Tried editing the threshold policy and this resolved the issue for a day before it returned.

Looks like some kind of bug to me so I've logged it with support. I'll update when I have a resolution.

[adaikkap]

Hi Marshall,

     Can you give us below info as what kind of relationships are they ? SV/QSM/VSM.

Is you snapmirror monitor running fine ? You can check the same by running dfm host discover <fielrname-or-id> .

Are you finding any kind of erros in the smmon.log under <installdir>/NTAP/DFM/log

Regards

adai

[dalemarshall]

I eventually logged this with NetApp support.

It appears to be a limitation of SNMPv1. Their suggestion is to upgrade DFM v4.0d13 and then enable SNMPv3. I'm due to carry out the upgrade this week.

Related BURTS are 382019 and 367643

[dalemarshall]

Resolved this in the end. It was just a case of clearing the lag thresholds on the primary source, something we weren't monitoring anyway.