Data Backup and Recovery

How to restart snapmirror initialize after abort ?


ONTAP version
NetApp Release 8.1.4P3 7-Mode



We have FilerA:vol1 to FilerB:vol1 snapmirror relationship now.

We're going to snapmirror initialize from FilerB:vol1 to FilerC:vol1 on non-office hours(night time).

So we have to abort the new snapmirror initialize from FilerB:vol1 to FilerC:vol1 on office hours(day night).


Our vol1 data is about 3TB,so we have to snapmirror initialize for many times.

We can transfer about 100GB data when snapmirror initialize per night.

Our expectation:

1st night, start snapmirror initialize , transferred data about 100GB,then abort on next morning.

2nd night, start snapmirror initialize again, transferee data about 100GB, then we can have 200GB.

more nights, we can complete the snapmintialize finally to transfer 3TB that possible?




How can we complete the snapmirror initialize the 3TB data?

How can we ensure the next snapmirror initialize restart from the current data transferring(for example 100GB)?



Hi Alex,


Would it be an option for you to throttle your snapmirror transfer to a much lower throughput during business hours then increase it to unlimited throughput after hours? Rather than abort the transfer you could limit it 1KB during business hours to keep the transfer extremely slow during the day then use all available bandwidth post business hours. See the "-MaxTransferSize" parameter of the the "Set-NcSnapMirror" cmdlet.


    Set-NcSnapmirror [-DestinationCluster <String>] -DestinationVserver <String> -DestinationVolume <String>
    [-SourceCluster <String>] [-SourceVserver <String>] [-SourceVolume <String>] [-Schedule <String>] [-Tries <Int32>]
    [-MaxTransferRate <Int64>] [-Policy <String>] [-Controller <NcController[]>] [-ZapiRetryCount <Int32>]

    -MaxTransferRate <Int64>
        Specifies the upper bound, in bytes per second, at which data is transferred between clusters.  The default is unlimited (0) which permits the SnapMirror 
        relationship to fully utilize the available network bandwidth.  This option does not affect load-sharing mirrors and other SnapMirror relationships confined 
        to a single cluster.

This could be achieved either via script\scheduled task or a WFA workflow. One other point to consider would be to ensure you account for any timezone differences if you are transferring to a remote site in a geo-graphically disperse infrastructure to ensure you the snapmirror transfer schedule is modified at the appropriate business hours of the destination system.


Hope that gives you some ideas.



If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.