ONTAP Discussions



I thought this might be helpful to other, when I searched for vsdr.schedule.unavailable the only article I found was not in English and there was nothing from NetApp.


I had a snapmirror relationship that was not healthy between an svm and an SVM-DR on two different clusters, I have three SVM-DRs, two I can do transfers between source and destination and they are healthy, the 3rd was not healthy and in Events there was the error mesage below.  I looked at the snapshot-policy schedules, they were OK, I looked at the vserver policy it was OK.


The problem was the Storage Efficiency Policy names that I created on the two clusters were not identical, on one cluster the schdule name was 1207am dedupe, on the other it was 1207AM dedupe, after I made them both 1207AM dedupe, the transfers worked and the the relationships are all healthy.  Scheduled dedupe was not configured configured on the two source vservers so they were unaffected.


After the fact I discovered the command bosnapcls002::snapmirror> show-history -fields additional-info
which showed exactly what the problem was, below is the output


dr_ams_nfs:      9e8c4967-1111-11e8-a5ea-00a098cd9c9f Transaction ID: 6522177562938968579 snapshot: vserverdr.0.ac95c0e2-d525-11e7-96e8-00a098cd9c9f.2018-02-13_180000Failed to apply the source Vserver configuration. Reason: Unrecoverable error during configuration replication, requires manual intervention. Error: Schedule "1207am dedupe" not found.



Thank you


Error Message:

Event: vsdr.schedule.unavailable: Configuration replication for policy "default" in Vserver "dr_ams_nfs" has failed because the schedule mentioned in the policy is not available.

This message occurs when a schedule is not available on the secondary site for replication of policies for a Vserver in a MetroCluster(tm) configuration or Vserver DR setup.
reate a new job schedule on the remote site that is identical to that on the source site by using the 'job schedule cron create' command. If this is a SnapMirror(R) or MetroCluster(tm) environment, run the "snapmirror resync" command or the "metrocluster vserver resync" command respectively to resynchronize the Vserver configuration.


I had the same issue on 9.3P2. Replication was unhealthy because of default policy.

I changed default deduplication policy on source SVM and run brake, dalete, create, resync snapmirror replication.