You can use SnapLock for SnapVault to WORM-protect Snapshot copies on secondary storage. You perform all of the basic SnapLock tasks on the vault destination. The destination volume is automatically mounted read-only, so there is no need to explicitly commit the Snapshot copies to WORM; therefore, creating scheduled Snapshot copies on the destination volume using SnapMirror policies is not supported.

Before you begin

The source and destination aggregates must be 64-bit.
The source volume cannot be a SnapLock volume.
The source and destination volumes must be created in peered clusters with peered SVMs.

For more information, see ETERNUS AX/HX series Cluster and SVM Peering Express Guide.
If volume autogrow is disabled, the free space on the destination volume must be at least five percent more than the used space on the source volume.

About this task

The source volume can use Fujitsu or non-Fujitsu storage.

You cannot rename a Snapshot copy that is committed to the WORM state.

You can clone SnapLock volumes, but you cannot clone files on a SnapLock volume.

LUNs are not supported on SnapLock volumes. Although it is possible to move LUNs onto a SnapLock volume using legacy technology, this is not a supported operation, nor is any other operation involving LUNs on a SnapLock volume. Beginning with ONTAP 9.9.0, LUNs on a SnapLock volume are supported in SnapLock only for SnapVault relationships where a Snapshot copy of a non-SnapLock source volume is replicated and locked on a SnapLock destination. These Snapshot copies can contain LUNs.

Beginning with ONTAP 9.13.1, you can instantaneously restore a locked Snapshot copy on the destination SnapLock volume of a SnapLock vault relationship by creating a FlexClone with the snaplock-type option set to “non-snaplock” and specifying the Snapshot copy as the “parent-snapshot” when executing the volume clone creation operation. Learn more about creating a FlexClone volume with a SnapLock type.

For MetroCluster configurations, you should be aware of the following:

You can create a SnapVault relationship only between sync-source SVMs, not between a sync-source SVM and a sync-destination SVM.
You can create a SnapVault relationship from a volume on a sync-source SVM to a data-serving SVM.
You can create a SnapVault relationship from a volume on a data-serving SVM to a DP volume on a sync-source SVM.

The following illustration shows the procedure for initializing a SnapLock vault relationship:

This illustration shows the procedure for initializing a SnapLock vault relationship: identifying the destination cluster

Steps

Identify the destination cluster.
On the destination cluster, install the SnapLock license, initialize the Compliance Clock, and, if you are using an ONTAP release earlier than 9.10.1, create a SnapLock aggregate, as described in SnapLock workflow.

On the destination cluster, create a SnapLock destination volume of type DP that is either the same or greater in size than the source volume:

volume create -vserver SVM_name -volume volume_name -aggregate aggregate_name -snaplock-type compliance|enterprise -type DP -size size

Beginning with ONTAP 9.10.1, SnapLock and non-SnapLock volumes can exist on the same aggregate; therefore, you are no longer required to create a separate SnapLock aggregate if you are using ONTAP 9.10.1. You use the volume -snaplock-type option to specify a Compliance or Enterprise SnapLock volume type. In ONTAP releases earlier than ONTAP 9.10.1, the SnapLock mode, Compliance or Enterprise, is inherited from the aggregate. Version-flexible destination volumes are not supported. The language setting of the destination volume must match the language setting of the source volume.

The following command creates a 2 GB SnapLock Compliance volume named dstvolB in SVM2 on the aggregate node01_aggr:

cluster2::> volume create -vserver SVM2 -volume dstvolB -aggregate node01_aggr -snaplock-type compliance -type DP -size 2GB

On the destination cluster, set the default retention period, as described in Set the default retention period.

A SnapLock volume that is a vault destination has a default retention period assigned to it. The value for this period is initially set to a minimum of 0 years for SnapLock Enterprise volumes and a maximum of 30 years for SnapLock Compliance volumes. Each Fujitsu Snapshot copy is committed with this default retention period at first. The retention period can be extended later, if needed. For more information, see Set retention time overview.

Create a new replication relationship between the non-SnapLock source and the new SnapLock destination you created in Step 3.

This example creates a new SnapMirror relationship with destination SnapLock volume dstvolB using a policy of XDPDefault to vault Snapshot copies labeled daily and weekly on an hourly schedule:
```
cluster2::> snapmirror create -source-path SVM1:srcvolA -destination-path SVM2:dstvolB -vserver SVM2 -policy XDPDefault -schedule hourly
```
Create a custom replication policy or a custom schedule if the available defaults are not suitable.
On the destination SVM, initialize the SnapVault relationship created in Step 5:

snapmirror initialize -destination-path destination_path

The following command initializes the relationship between the source volume srcvolA on SVM1 and the destination volume dstvolB on SVM2:
```
cluster2::> snapmirror initialize -destination-path SVM2:dstvolB
```
After the relationship is initialized and idle, use the snapshot show command on the destination to verify verify the SnapLock expiry time applied to the replicated Snapshot copies.

This example lists the Snapshot copies on volume dstvolB that have the SnapMirror label and the SnapLock expiration date:
```
cluster2::> snapshot show -vserver SVM2 -volume dstvolB -fields snapmirror-label, snaplock-expiry-time
```

Related information

ETERNUS AX/HX series Cluster and SVM Peering Express Guide

ETERNUS AX/HX series Volume Backup Using SnapVault®Express Guide