The SnapMirror Engine

The SnapMirror engine is used to replicate the data in a source volume 
to a destination volume.
It is used for the Load Sharing Mirror, Data Protection Mirror, and 
SnapVault features.
The volume is the unit of replication. 
The source volume is read‐write, the destination is read‐only. Having 
only one writable copy of the data ensures it remains consistent.
The SnapMirror Engine
After an initial baseline transfer, only incremental changes are replicated 
from the source to the destination volumes.
Snapshot copies are used by the source volume to update destination 
volumes. 
Updates can be performed manually or using an automated schedule.
Mirror copies are updated asynchronously. Minimum time between 
replications is one minute.
Synchronous vs Asynchronous Replication

Synchronous 
Replication

Asynchronous 
Replication
How Replication Works
Initial (baseline) transfer
‒ A snapshot copy is created of all data on the source volume and 
transferred to the destination volume
Manual or Scheduled updates
‒ A new snapshot copy is taken
‒ The current SnapMirror Snapshot copy is compared with the previous 
SnapMirror Snapshot copy
‒ Incremental changes are synchronized from the source to the 
destination
‒ Data is replicated at the block level
Storage Efficiency and Volume Moves
Deduplication and compression savings are replicated from the 
source to the destination volume.
SnapMirror software does not inflate or decompress the data 
during the transfer.

SnapMirror source or destination volumes can be moved to 
another aggregate in their cluster without breaking SnapMirror
relationships.
Load Sharing Mirrors
Load sharing mirrors are mirror copies of FlexVol volumes which provide 
redundancy and load balancing.
They provide load balancing for read traffic only, write requests always 
go to the source volume to keep the data consistent.
LS mirrors are always in the same cluster as the source volume. They 
provide intra‐cluster replication, not inter‐cluster.
Load sharing mirrors are automatically mounted into the namespace 
with the same path as the source volume and provide redundancy for 
read access with no intervention.
SnapMirror DP Mirrors
Data Protection Mirrors can replicate a source volume to a destination 
volume in the same or in a different cluster.
They can be used for the following reasons:
– To replicate data between volumes in different clusters for Disaster 
Recovery. Intervention is required to fail over to the DR site.
– To provide load balancing for read access across different sites. 
– Data migration between clusters.
– To replicate data between SVMs in the same cluster.
– To replicate data to a centralized tape backup location.
When we talk about SnapMirror in general, we’re talking about DP 
Mirrors.
SnapMirror DP Mirrors
Unlike LS mirrors, DP mirror copies are not automatically mounted into 
the namespace and implicitly accessed by clients.
DP mirror copies can be mounted through a junction into the 
namespace by the administrator.

DP mirrors are a licensed feature.
SnapMirror DP Mirrors
The main functionality of DP mirrors is as a Disaster Recovery solution. If 
the primary site is lost, you can make the destination volumes writable.
A FlexClone copy can also be taken on the destination to get a separate 
writable copy without disrupting SnapMirror operations.
DP mirrors maintain 2 snapshots. When replication occurs, the oldest 
snapshot is deleted. The new snapshot is compared to the previous one 
to determine the incremental changes to replicate.
DP mirrors keep the source and destination volumes in the same state 
(with some lag as determined by your schedule). If data is corrupted in 
the source volume, it will be corrupted in the destination volume as 
well.
DP mirrors provide DR but they do not provide backups.
SnapVault
SnapVault is Data ONTAP’s long term disk‐to‐disk backup solution.
It has the same functionality as traditional tape backups but is much 
faster, more convenient and requires less storage space.
Data is replicated from the source volume to a destination volume on a 
centralized backup cluster.

SnapVault is a licensed feature.
SnapVault
Unlike DP mirrors, SnapVault can retain multiple snapshots as backups 
over a long time period.
Data can be restored to the original source volume or to a different 
volume.
The destination volume cannot be made writable so it is a backup, not a 
DR solution.
Separate FlexClone copies can however be made of the snapshot 
backups.
LS Mirror, DP Mirror, and SnapVault Summary
LS Mirrors, DP Mirrors and SnapVault all use the SnapMirror engine to 
replicate data between volumes.
LS Mirrors are used for redundancy and load balancing within the same 
cluster for read‐only volumes. No license is required.
The main function of DP mirrors is as a Disaster Recovery solution 
between clusters. They can also be used to move data between SVMs or 
clusters.
SnapVault is a long term disk‐to‐disk backup solution.
DP Mirror and SnapVault Compatibility
The source and destination nodes can be different models of controller
You can use inexpensive SATA drives on the destination volume for cost 
savings.

SnapMirror became available in Clustered Data ONTAP 8.1
SnapVault became available in Clustered Data ONTAP 8.2
The version of Data ONTAP that is running on the destination volume 
must be the same or a later version than the one running on the source 
volume
Version Flexible SnapMirror is available from Data ONTAP 8.3 which 
allows different versions to be run on the source and destination.
Data ONTAP 7‐Mode volumes cannot be used in clustered Data ONTAP 
systems, and vice versa.
Mirror Configuration Steps on Destination Cluster
Create a destination mirror volume: volume create
Create a Snapvault Policy: snapmirror policy create
Create a mirror relationship: snapmirror create -schedule
Creating a mirror relationship does not cause an initial update to be 
performed.
Perform baseline replication:
– DP and SnapVault: snapmirror initialize
– LS: snapmirror initialize-ls-set
Perform scheduled or manual incremental replication: 
‒ DP and SnapVault: snapmirror update
‒ LS: snapmirror update-ls-set

(The update command also carries out baseline synchronization if not 
already done.)
Destination Volumes
The destination volume must be created when adding an LS, DP or 
SnapVault mirror.
It must be configured as a SnapMirror volume. SnapMirror volumes are ro.
LS, DP and SnapVault destination volumes all use type ‘DP’.
The source and destination volumes of a mirror relationship must have the 
same language setting.
cluster1::> volume create -vserver DeptA -volume DeptA_root_lsm1 -aggregate aggr1
-size 20m –type DP

dr::> volume create -vserver DeptA_DP -volume vol1_mirror -aggregate aggr1 -size
100g –type DP

vault::> volume create -vserver DeptA_SV -volume vol1_vault -aggregate aggr1 -size
100g -type DP
Mirror Type
The mirror type is set when configuring the mirror relationship between 
the source and destination volumes.
cluster1::> snapmirror create -source-path DeptA:DeptA_root -destination-path
DeptA:DeptA_root_lsm1 -type LS -schedule hourly

DR::> snapmirror create source-path DeptA:vol1 -destination-path

DeptA_DP:vol1_mirror -type DP -schedule 10min

Vault::> snapmirror create source-path DeptA:vol1 -destination-path

DeptA_SV:vol1_vault -type XDP -policy DeptA_vol1_policy -schedule
DeptA_vol1_schedule