ONTAP Discussions

SnapMirror Custom Schedule Issue

jeff_mercier
3,494 Views

Hi All,

I have a quick question on making a custom schedule for SnapMirror and updating the mirror purely from the SnapManager backup jobs.

I created a mirror relationship between 2 SANs - Did initial transfer successfully.

Went in the SnapManager, created a manual backup with the option "Update SnapMirror" checked - This worked successfully.

Went in the snapmirror.conf config file and edited the job to show this (got this from doing some research):

<srcSAN>:<srcVol> <destSAN>:<destVol> - - - -

Now the relationship still shows inside FilerView with a schedule of Custom:

Source (Filer:Location):<srcSAN>:<srcVol>
Destination (Filer:Location):<destSAN>:<destVol>
Maximum Transfer Rate (kb/s):-
Restart Mode:Schedule Priority
Schedule:-
Base Snapshot:<destSAN>Snapshot.20
Base Timestamp:Sun Dec 06 12:52:51 CST 2009
Lag Time (hh:mm:ss):54:36:58
Status:idle
State:snapmirrored
Content State:Replica
Current Transfer Size (Kb):0
Current Transfer Type:-
Last Transfer Size (Kb):32556
Last Transfer Duration (secs):8
Last Transfer Type:-


Here is my issue - As soon as I change that custom schedule, the mirror update doesn't work anymore from inside the SnapManager even though this shows when I run a backup:

Starting SnapMirror update...

Querying disk list for SnapMirror update...

Requesting SnapMirror update for LUN [S] on volume <vol> of filer [srcSAN]...

Request for SnapMirror update for LUN [S] was completed successfully.

Yet you can see above my mirror has been idle for over 50 hours.  Anyone have any ideas on this?  I don't want the SAN itself to initiate a mirror, only the SnapManager.

Thanks in advance for all the help.

Jeff.

2 REPLIES 2

netappnasadmin
3,494 Views

some times the Lag time wont update when you configure to update the snapmirror through snapmanager.

But can you break the mirror & see the destination volume data is same as source or not ..?

Thanks

Naveen.

jeff_mercier
3,494 Views

I thought about that and looked at the Destination volume and compared the available snaps to the source snaps and they did not match.

Public