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 DatacenterDude.com.
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.
1 2 3 4 5 6 7 8 9 10 11 |
# show current peers Get-NcClusterPeer # create a peer Add-NcClusterPeer -Address $peerIclAddress -Credential (Get-Credential) # check peer connectivity for ICLs Get-NcClusterPeer -Name $clusterPeerName | Get-NcClusterPeerHealth # remove a peer Get-NcClusterPeer -Name $clusterPeerName | Remove-NcClusterPeer |
1 2 3 4 5 6 7 8 9 10 11 12 13 |
# show current peers Get-NcVserver -Name $svmName | Get-NcVserverPeer # create a new SVM peer relationship New-NcVserverPeer -Vserver $svmName -PeerCluster $remoteClusterName ` -PeerVserver $remoteSvmName -Application snapmirror # after submitting a peering request, you will need to confirm the # relationship on the destination cluster Confirm-NcVserverPeer -Vserver $localSvmName -PeerVserver $removeSvmName # remove all peers for an SVM Get-NcVserver -Name $svmName | Get-NcVserverPeer | Remove-NcVserverPeer |
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
# view policy details Get-NcSnapmirrorPolicy -Name $policyName # create a policy $splat = @{ # a unique name for the policy 'Name' = $newPolicyName; # whether or not to restart if interrupted 'Restart' = 'always'; # async_mirror = SnapMirror, vault = SnapVault # mirror_vault = both 'Type' = 'async_mirror'; # use, or not, network compression 'EnableNetworkCompression' = $true; } New-NcSnapmirrorPolicy @splat # enable network compression for an existing policy Get-NcSnapmirrorPolicy -Name $policyName | Set-NcSnapmirrorPolicy -EnableNetworkcCompression $true |
SnapMirror
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 |
# show protected volumes, note this will display both # mirrored and vaulted volumes Get-NcSnapmirror # show mirrored volumes Get-NcSnapmirror | Where-Object { $_.RelatiopnshipType -eq "data_protection" } # show unhealthy relationships (both mirror and vault) Get-NcSnapmirror | Where-Object { $_.IsHealthy -eq $false } # show lag time for relationships (both mirror and vault) Get-NcSnapmirror | Select-Object SourceLocation,DestinationLocation,` @{ 'N'="Lag Time Hours"; 'E'={ [Math]::Round($_.LagTime / 60 / 60, 2) } } # create a new SnapMirror relationship $splat = @{ # the cluster is optional "Source" = "$srcCluster://$srcSvmName/$srcVolumeName"; # cluster is again optional if you are not configuring # replication between two clusters "Destination" = "$dstCluster://$dstSvmName/$dstVolumeName"; # dp = SnapMirror "Type" = "dp"; # DPDefault = SnapMirror # or use a custom policy of your own with a type of async-mirror "Policy" = "DPDefault"; # view the available policies using the # Get-NcJobCronSchedule cmdlet "Schedule" = "daily" } New-NcSnapmirror @splat # initialize the relationship Invoke-NcSnapmirrorInitialize -Source "$srcCluster://$srcSvmName/$srcVolumeName" ` -Destination "$dstCluster://$dstSvmName/$dstVolumeName" # manually update a relationship Invoke-NcSnapmirrorUpdate -Source "$srcCluster://$srcSvmName/$srcVolumeName" ` -Destination "$dstCluster://$dstSvmName/$dstVolumeName" # quiesce and break the relationship Invoke-NcSnapmirrorQuiesce -Source "$srcCluster://$srcSvmName/$srcVolumeName" ` -Destination "$dstCluster://$dstSvmName/$dstVolumeName" Invoke-NcSnapmirrorBreak -Source "$srcCluster://$srcSvmName/$srcVolumeName" ` -Destination "$dstCluster://$dstSvmName/$dstVolumeName" # resync the relationship (note that his will cause any # changes since the last SnapMirror snapshot on the # destination to be lost) Invoke-NcSnapmirrorResync -Source "$srcCluster://$srcSvmName/$srcVolumeName" ` -Destination "$dstCluster://$dstSvmName/$dstVolumeName" # release a relationship. this will remove # snapshots related to the relationship from the source # and destination volumes. after releasing, the relationship # cannot be resumed with a reinitialization. Invoke-NcSnapmirrorRelease -Source "$srcCluster://$srcSvmName/$srcVolumeName" ` -Destination "$dstCluster://$dstSvmName/$dstVolumeName" |
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, orvault
when using the PowerShell Toolkit - A version flexible SnapMirror policy must be used (default polices are
DPDefault
,MirrorAllSnapShots
,MirrorLatest
, andMirrorAndVault
). This is a policy which has a type ofasync-mirror
ormirror-vault
, but notvault
(that would make it a SnapVault relationship).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
# create a version flexible SnapMirror $splat = @{ # the cluster is optional "Source" = "$srcCluster://$srcSvmName/$srcVolumeName"; # cluster is again optional if you are not configuring # replication between two clusters "Destination" = "$dstCluster://$dstSvmName/$dstVolumeName"; # use vault when creating a version flexible mirror "Type" = "vault"; # Make sure to use the correct policy type. using "XDPDefault" # here will make this a snapvault relationship, which is not # the desired/intended result "Policy" = "MirrorLatest"; # view the available policies using the # Get-NcJobCronSchedule cmdlet "Schedule" = "weekly" } New-NcSnapmirror @splat # show version flexible snapmirror relationships Get-NcSnapmirror | Where-Object { $_.RelatiopnshipType -eq "extended_data_protection" } |
SnapVault
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).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
# Show vaulted volumes Get-NcSnapmirror | Where-Object { $_.RelationshipType -eq"vault" } # create a new SnapVault relationship $splat = @{ # the cluster is optional "Source" = "$srcCluster://$srcSvmName/$srcVolumeName"; # cluster is again optional if you are not configuring # replication between two clusters "Destination" = "$dstCluster://$dstSvmName/$dstVolumeName"; # vault = SnapVault "Type" = "vault"; # XDPDefault = SnapVault # or use a custom policy of your own with a type of "vault" "Policy" = "XDPDefault"; # view the available policies using the # Get-NcJobCronSchedule cmdlet "Schedule" = "hourly" } New-NcSnapmirror @splat |
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.
1 2 3 4 5 6 7 8 9 |
# create a load sharing relationship New-NcSnapmirror -Source "//$svmName/$srcVolume" ` -Destination "//$svmName/$dstVolume" -Type ls # initialize the load sharing mirror Invoke-NcSnapmirrorLsInitialize -Source "//$svmName/$srcVolume" # update the load sharing mirror Invoke-NcSnapmirrorLsUpdate -Source "//$svmName/$srcVolume" |
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?
Hello Henrik,
Thanks for reading!
Using regular PowerShell cmdlets to search a CIFS/SMB share for particular files will be the most efficient way. Once you have the list of files you could FlexClone them from a snapshot back into the current file system. I created an example of how to do this on this NetApp Community thread.
Hope that helps!
Andrew
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: (10.188.112.76:NcController) [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
Adrian
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.
Andrew