NetApp PowerShell Toolkit 101: Data Protection

Protecting data is arguably the most important job that your storage is entrusted with. Losing data is simply not an option, so it’s critical to protect data through the use of backups and replication.

There are different ways that you can replicate data in your clustered Data ONTAP system. First, you can replicate to a separate volume of the same SVM in the cluster. Second, to a volume that belongs to a different SVM in the same cluster. Finally, replication can be configured with another cluster entirely.

In this post we will cover:

  • Peering Relationships
    • Cluster Peers
    • SVM Peers
  • SnapMirror Policies
  • SnapMirror
    • Version Flexible SnapMirror
  • SnapVault
  • Load Sharing Mirrors

If you are interested in additional detail about SnapMirror and SnapVault in clustered Data ONTAP 8.3, please see the post I did over at

Peering Relationships

The first steps for configuring replication relationships is to configure the cluster and SVM to peer with each other. This is only necessary when you are traversing the respective boundaries. For example, if you are SnapMirroring to a volume which belongs to the same SVM as the source, you do not need to configure peer relationships.

Note: You will need to configure at least one inter-cluster LIF (ICL) before you can replicate between clusters.

Cluster Peers
SVM Peers

SnapMirror Policies

The SnapMirror policy, and it’s constituent rules, determine the type of protection relationship, which snapshots to transfer, and the number of snapshot copies to keep at the destination.


SnapMirror replicates a volume between source and destination, relying on SnapShots to determine what data has changed (or been added) and therefore needs to be replicated.

The life cycle of a SnapMirror relationship has many different phases, roughly in the following order:

  • Initialize – this is the initial data transfer
  • Update – resyncs the volumes, transferring any new and changed data
  • Quiesce – finishes current update, then disables future resync operations. Normally a precursor to ending the relationship.
  • Resume – resumes updating the mirror after it has been quiesced or broken.
  • Break – after being quiesced, this will make the destination volume writable.
  • Resync – after the reason for making the destination writable has gone away (testing? disaster?), resync the relationship to the current state at the source.

There are three types of SnapMirror relationship. The first one is data protection. This is what is commonly referred to as simply “SnapMirror” in the NetApp lexicon. It is a protection relationship which replicates data from the source volume to a read-only “DP” volume. This type of relationship is meant to provide disaster recovery protection by allowing the destination volume to be made writable if necessary.

Note that when creating this relationship type, the destination volume must have a type of dp.

SnapMirror is controlled from the destination, which means that all of the PowerShell commands should be targeted at the destination cluster.

Version Flexible SnapMirror

Clustered Data ONTAP 8.3 introduces a new type of SnapMirror relationship, known as “Version Flexible”. Traditionally the SnapMirror destination must be at the same version of Data ONTAP, or higher. When using a version flexible relationship this limitation has been removed, however there are some differences when creating the relationship:

  • The relationship type must be xdp when using the CLI, or vault when using the PowerShell Toolkit
  • A version flexible SnapMirror policy must be used (default polices are DPDefault, MirrorAllSnapShots, MirrorLatest, and MirrorAndVault). This is a policy which has a type of async-mirror or mirror-vault, but not vault (that would make it a SnapVault relationship).


SnapVault relationships are meant to provide backup and archive functionality for data. Snapshot retention can be configured for longer, meaning a larger window of available data exists to recover from.

Creating a SnapVault relationship is 99% the same as a SnapMirror relationship. The difference when setting up the relationship is the type, which must be set to xdp for CLI or vault when using PowerShell, and the policy should be a vault type (default is XDPDefault).

After creating the SnapVault relationship it can be managed using the same initialize, update, quiesce, and break commands as SnapMirror.

Load Sharing Mirror

Finally, we have a special type of relationship known as a load sharing mirror. This is most frequently used for SVM root volumes to ensure that they are accessible in the event of aggregate failure on the primary node. This is not a traditional SnapMirror and does not provide the same functionality, instead it is limited to mirroring data across nodes in a cluster to provide high availability and increased read performance for data that could be accessed from any node.

4 thoughts on “NetApp PowerShell Toolkit 101: Data Protection”

  1. Hi

    Thanks for your instructions.
    I have another dilemma/question.

    We have a lot of Cryptoware incidents on our fileserver SVMs:

    Is there a way to find and restore *.encrypted files via NPTK?

    What I´m looking for is a way to do file level restores on thousands of files in a folder/subfolder without restoring unaffected files located in the same.
    Maybe one can use NPTK to do some kind of SnapRestore, targeting only *.encrypted files?

    Do you have any idea?

  2. Hi Andrew,

    your content is a great read. Its helped me a lot.

    I wonder if you have ever used the “set-ncvolsize” command to reduce volume capacity on a snapmirror volume ?
    I have an issue when trying to resize the volume on the DR filer. Now, I am running cdot 8.3.2P1 on both prod and dr filers, and I know that I can run the “snapmirror update” command from the DR filer, but the volume size on the DR filer does not change. Therefore, I really need to run the command “set-ncvolsize” on prod and dr filers.

    I run the following command on the prod filer …. after logging into the filer with valid admin credentials ….

    PS c:\users\raf> Set-NcVolSize -VserverContext emdccn0005v50 dmef_fis_0001 8.628g

    The command above is successful btw.

    then I log into the DR filer vis PS , using admin credentials and run the command … but it gives me the following error …..

    PS C:\Users\raf> Set-NcVolSize -VserverContext emdccn0005v50dr dmef_fis_0001 8.628g -confirm:$false
    Set-NcVolSize : Unable to set volume attribute “size” for volume “dmef_fis_0001” on Vserver “emdccn0005v50dr”. Reason: The new volume size would be less than that of the replica file system.
    At line:1 char:1
    + Set-NcVolSize -VserverContext emdccn0005v50dr dmef_fis_0001 8.628g -confirm:$fal …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidOperation: ( [Set-NcVolSize], EONTAPI_EVOLOPNOTSUPP
    + FullyQualifiedErrorId : ApiException,DataONTAP.C.PowerShell.SDK.Cmdlets.Volume.SetNcVolSize

    PS C:\Users\d629924>

    I’ve tried the command without the -confirm:$false at the end, but the end result is the same.

    do I perhaps have to run the command … ( on the destination filer )

    Invoke-NcSnapmirrorUpdate -Source emdccn0005v50:dmef_fis_0001 -Destination emdccn0005v50dr:dmef_fis_0001

    in between the 2 commands noted above ?

    I would appreciate any help whatsoever….
    Many thanks

    • Hi Adrian,

      Thanks for reaching out! I think you are correct, you need to do a snapmirror update before the destination can be adjusted. Alternatively, simply make the destination volume thin provisioned, then regardless of the destination volume size it will never consume more than the size of the source volume.

      Hope that helps.



Leave a Reply