Data protection overview with ONTAP System ManagerThe topics in this section show you how to
configure and manage data protection with ONTAP System Manager in ONTAP 9.7 and later releases. Protect your data by creating and managing Snapshot copies, mirrors, vaults, and mirror-and-vault relationships. SnapMirror is disaster recovery technology, designed for failover from primary storage to secondary storage at a geographically remote site. As its name implies, SnapMirror creates a replica, or mirror, of your working data in secondary storage from which you can
continue to serve data in the event of a catastrophe at the primary site. A vault is designed for disk-to-disk Snapshot copy replication for standards compliance and other governance-related purposes. In contrast to a SnapMirror relationship, in which the destination usually contains only the Snapshot copies currently in the source volume, a vault destination typically retains point-in-time Snapshot copies created over a much longer period. Beginning with ONTAP 9.10.1, you
can create data protection relationships between S3 buckets using S3 SnapMirror. Destination buckets can be on local or remote ONTAP systems, or on non-ONTAP systems such as AWS. For more information, see S3 object storage management. Create custom data protection policiesYou can create custom data protection policies with ONTAP System Manager when the existing default protection policies are not appropriate for your
needs. Beginning with ONTAP 9.11.1, you can use ONTAP System Manager to create custom mirror and vault policies, to display and select legacy policies. This capability is also available in ONTAP 9.8P12 and later patches of ONTAP 9.8. Create custom protection policies on both the source and destination cluster. Steps Click Protection > Local Policy Settings. Under Protection Policies, click
. In the Protection Policies pane, click . Enter the new policy name, and select the policy scope. Choose a policy type. To add a vault-only or mirror-only policy, choose Asynchronous, and click Use a
legacy policy type. Complete the required fields. Click Save. Repeat these steps on the other cluster.
You can create Snapshot copy policies to specify the maximum number of Snapshot copies that are automatically created and how frequently they are created. The policy specifies when to create Snapshot
copies, how many copies to retain, and how to name them. This procedure creates a Snapshot copy policy on the local cluster only. Steps Click Protection > Overview > Local Policy Settings. Under Snapshot Policies, click , and then click
. Type the policy name, select the policy scope, and under Schedules, click to enter the schedule details.
Calculate reclaimable space before deleting Snapshot copiesBeginning with ONTAP 9.10.1, you can use ONTAP System Manager to select Snapshot copies you want to
delete and calculate the reclaimable space before you delete them. Steps Click Storage > Volumes. Select the volume from which you want to delete Snapshot copies. Click Snapshot Copies. Select one or more Snapshot copies. Click Calculate Reclaimable Space.
Enable or disable client access to Snapshot copy directoryBeginning with ONTAP 9.10.1, you can
use ONTAP System Manager to enable or disable client systems to access to a Snapshot copy directory on a volume. Enabling access makes the Snapshot copy directory visible to clients and allows Windows clients to map a drive to the Snapshot copies directory to view and access its contents. You can enable or disable access to a volume’s Snapshot copy directory by editing the volume settings or by editing the volume’s share settings. Enable or disable client access to Snapshot copy
directory by editing a volumeThe Snapshot copy directory on a volume is accessible to clients by default. Steps Click Storage > Volumes. Select the volume containing the Snapshot copies directory you want to either show or hide. Click and select Edit. -
In the Snapshot Copies (Local) Settings section, select or deselect Show the Snapshot copies directory to clients. Click Save.
The Snapshot copy directory on a volume is accessible to clients by default. Steps Click Storage > Shares. Select the volume containing the Snapshot copies directory you want to either show or hide. -
Click and select Edit. In the Share Properties section, select or deselect Allow clients to access Snapshot copies directory. Click Save.
Prepare for mirroring and vaultingYou can protect your data by replicating it to a remote cluster for data backup and disaster recovery purposes. Several default protection policies are available. You must have created your
protection policies if you want to use custom policies.
Steps In the local cluster, click Protection > Overview. Expand Intercluster Settings. Click Add Network Interfaces and add intercluster network
interfaces for the cluster. Repeat this step on the remote cluster. In the remote cluster, click Protection > Overview. Click in the Cluster Peers section and click Generate Passphrase. Copy the generated passphrase and paste it in the local cluster. In the local cluster, under
Cluster Peers, click Peer Clusters and peer the local and remote clusters. Optionally, under Storage VM Peers, click and then Peer Storage VMs to peer the storage VMs. Click Protect Volumes to protect your volumes. To protect your LUNs, click Storage > LUNs, select a
LUN to protect, and then click . Select the protection policy based on the type of data protection you need. To verify the volumes and LUNs are successfully protected from the local cluster, click Storage > Volumes or Storage > LUNs and, expand the volume/LUN view.
Create a mirror and vault of a volume to protect data in case of a disaster and to have multiple archived versions of data to which you can roll back. Only the combined
mirror-and-vault policy is supported. You cannot specify separate mirror and vault policies. This procedure creates a mirror-and-vault policy on a remote cluster. The source cluster and destination cluster use intercluster network interfaces for exchanging data. The procedure assumes the intercluster network interfaces are created and the clusters containing the volumes
are peered (paired). You can also peer storage VMs for data protection; however, if storage VMs are not peered, but permissions are enabled, storage VMs are automatically peered when the protection relationship is created.
Steps Select the volume or LUN to protect:
click Storage > Volumes or Storage > LUNs, and then click the desired volume or LUN name. Click . Select the destination cluster and storage VM. The asynchronous policy is selected by default. To select a synchronous policy, click More Options. Click
Protect. Click the SnapMirror (Local or Remote) tab for the selected volume or LUN to verify that protection is set up correctly.
Using ONTAP System Manager, you can create an storage VM disaster recovery (storage VM DR) relationship to replicate one storage VM configuration to another. In the
event of a disaster at the primary site, you can quickly activate the destination storage VM. Complete this procedure from the destination. If you need to create a new protection policy, for instance, when your source storage VM has SMB configured, you should use ONTAP System Manager to create the policy and select the Copy source storage VM configuration option in the Add Protection Policy window.
For details see
Create custom data protection policies. Steps On the destination cluster, click Protection > Relationships. Under Relationships, click Protect and choose Storage VMs (DR). Select a protection policy. If you created a custom protection
policy, select it, then choose the source cluster and storage VM you want to replicate. You can also create a new destination storage VM by entering a new storage VM name. Click Save.
Serve data from a SnapMirror destinationTo serve data from a mirror destination when a source becomes unavailable, stop scheduled transfers to the destination, and then break the SnapMirror
relationship to make the destination writable.
Steps Select the desired protection relationship: click Protection > Relationships, and then click the desired volume name. Click
. Stop scheduled transfers : click Pause. Make the destination writable: click Break. Go to the main Relationships page to verify that the relationship state displays as "broken off".
Next steps: When the disabled source volume is available
again, you should resynchronize the relationship to copy the current data to the original source volume. This process replaces the data on the original source volume. Resynchronize a protection relationshipWhen your original source volume is available again after a disaster, you can resynchronize data from the destination volume and reestablish the protection
relationship. This procedure replaces the data in the original source volume in an asynchronous relationship so that you can start serving data from the original source volume again and resume the original protection relationship. Steps Click Protection > Relationships and then click the broken off relationship you want to resynchronize. Click
and then select Resync. Under Relationships, monitor the resynchronization progress by checking the relationship state. The state changes to "Mirrored" when resynchronization is complete.
Restore a volume from an earlier Snapshot copyWhen data in a volume is lost or corrupted, you can roll back your data by restoring from an earlier Snapshot copy. This procedure replaces the current data on the source volume
with data from an earlier Snapshot copy version. You should perform this task on the destination cluster. Steps Click Protection > Relationships, and then click the source volume name. Click and then select Restore. Under Source, the source volume is selected by default.
Click Other Volume if you want to choose a volume other than the source. Under Destination, choose the Snapshot copy you want to restore. If your source and destination are located on different clusters, on the remote cluster, click Protection > Relationships to monitor the restore progress.
Recover from Snapshot copiesYou can recover a volume to an earlier point in time by restoring from a Snapshot copy. This procedure restores a volume from a Snapshot copy. Steps Click
Storage and select a volume. Under Snapshot Copies, click next to the Snapshot copy you want to restore, and select Restore.
Restore to a new volumeBeginning with ONTAP 9.8, you can use ONTAP System Manager to restore backed up data on the destination volume to a volume other than the original source. When you restore to a different volume, you can
select an existing volume, or you can create a new volume. Steps Select the desired protection relationship: click Protection > Relationships. Click and click Restore. Under Relationships, monitor the restore progress by viewing Transfer Status for
the relationship.
Reverse Resynchronizing a Protection RelationshipBeginning with
ONTAP 9.8, you can use ONTAP System Manager to perform a reverse resynchronization operation to delete an existing protection relationship and reverse the functions of the source and destination volumes. Then you use the destination volume to serve data while you repair or replace the source, update the source, and reestablish the original configuration of the systems. When you perform a reverse resynch operation, any data on the source volume that is newer than the data in the common
Snapshot copy is deleted. Steps Select the desired protection relationship: click Protection > Relationships. Click and click Reverse Resync. Under Relationships, monitor the reverse resynchronization progress by viewing Transfer Status for the
relationship.
Reactivate a source storage VMBeginning with ONTAP 9.8, you can use ONTAP System Manager to reactivate a source storage VM
after a disaster. Reactivating the source storage VM stops the destination storage VM, and it reenables replication from the source to the destination. Steps Select the desired protection relationship: click Protection > Relationships. Click and click Reactivate Source Storage VM. Under
Relationships, monitor the source reactivation progress by viewing Transfer Status for the protection relationship.
Resynchronize a destination storage VMBeginning with ONTAP 9.8, you can use ONTAP System Manager to resynchronize the data and configuration details from the source storage VM to the destination storage
VM in a broken protection relationship and reestablish the relationship. You perform the resync operation only from the destination of the original relationship. The resync deletes any data in the destination storage VM that is newer than the data in the source storage VM. Steps Select the desired protection relationship: click Protection > Relationships. Click
and click Resync. Under Relationships, monitor the resynchronization progress by viewing Transfer Status for the relationship.
Back up data to the cloud using SnapMirrorBeginning with ONTAP 9.9.1, you can back up your data to the cloud and to restore your data from cloud storage to a different volume by using ONTAP System
Manager. You can use ONTAP S3 as your cloud object store. Before using the SnapMirror Cloud feature, you should generate a SnapMirror Cloud API license key. Add a cloud object storeBefore
you configure SnapMirror Cloud backups, you need to add a ONTAP S3 cloud object store. Steps Click Protection > Overview > Cloud Object Stores. Click .
Back up using the default policyYou can quickly configure a SnapMirror Cloud backup for an existing volume using the default cloud protection policy, DailyBackup. Steps Click Protection
> Overview and select Back Up Volumes to Cloud. If this is your first time backing up to the cloud, enter your SnapMirror Cloud API license key in the license field as indicated. Click Authenticate and Continue. Select a source volume. Select a cloud object store. Click Save.
Create a custom cloud backup policyIf you do not want to use the default DailyBackup cloud policy for your SnapMirror Cloud backups, you can create your own policy. Steps Click
Protection > Overview > Local Policy Settings and select Protection Policies. Click Add and enter the new policy details. In the Policy Type section, select Back up to Cloud to indicate that you are creating a cloud policy. Click Save.
Create a backup from the Volumes pageYou can use the ONTAP System Manager Volumes page to when you want to select and create cloud backups for multiple volumes at one time or
when you want to use a custom protection policy. Steps Click Storage > Volumes. Select the volumes you want to back up to the cloud, and click Protect. In the Protect Volume window, click More Options. Select a policy. You can select the default policy, DailyBackup, or a custom cloud policy you created. Select a cloud object store.
Click Save.
Restore from the cloudYou can use ONTAP System Manager to restore backed up data from cloud storage to a different volume on the
source cluster. Steps Click Storage > Volumes. Select the Back Up to Cloud tab. Click next to the source volume you want to restore, and select Restore. Under Source, select a storage VM and then enter the name of the volume to
which you want the data restored. Under Destination, select the Snapshot copy you want to restore. Click Save.
Delete a SnapMirror Cloud relationshipYou can use ONTAP System Manager to delete a cloud relationship. Steps Click Storage > Volumes and select the volume you want
to delete. Click next to the source volume and select Delete. Select Delete the cloud object store endpoint (optional) if you want to delete the cloud object store endpoint. Click Delete.
Remove a cloud object storeYou can use ONTAP System Manager to remove a cloud object store if it is not part of a cloud backup relationship. When a cloud object store is part of a cloud backup relationship, it cannot be deleted.
Steps Click Protection > Overview > Cloud Object Stores. Select the object store you want to delete, click and select Delete.
Back up data using Cloud BackupBeginning with ONTAP 9.9.1, you can use ONTAP System Manager to back up data in the cloud using Cloud Backup.
|
| Cloud Backup supports FlexVol read-write volumes and data-protection (DP) volumes. FlexGroup volumes and SnapLock volumes are not supported.
|
Before you begin You should perform the following procedures to establish an account in Cloud Manager. For the service account, you need to create the role as "Account Admin". (Other service account roles do not have the required privileges needed to establish a connection from ONTAP System Manager.) Create an account in Cloud Manager. Create a connector in Cloud Manager with one of the following cloud providers:
Subscribe to Cloud Backup Service in Cloud Manager (requires the appropriate license). Generate an access key and a secret key using Cloud Manager.
Register the cluster with Cloud ManagerYou can register the cluster with Cloud Manager by using either Cloud Manager or ONTAP System Manager. Steps In ONTAP System Manager, go to
Protection Overview. Under Cloud Backup Service, provide the following details: Client ID Client secret key
Select Register and Continue.
Enable Cloud BackupAfter the cluster is registered with Cloud Manager, you need to enable the Cloud Backup and initiate the first backup to the cloud. Steps In ONTAP System Manager, click Protection >
Overview, then scroll to the Cloud Backup Service section. Enter the Client ID and Client Secret.
|
| Beginning with ONTAP 9.10.1, you can learn about the cost of using the cloud by clicking Learn more about the cost of using the cloud.
|
Click Connect and Enable Cloud Backup Service. On the Enable Cloud Backup Service page, provide the following details, depending on the provider you selected.
For this cloud provider… | Enter the following data… |
|---|
Azure
|
| AWS
| AWS Account ID Access key Secret key Region
| Google Cloud Project (GCP)
|
|
Select a Protection policy: Existing policy: Choose an existing policy. New Policy: Specify a name and set up a transfer schedule.
|
| Beginning with ONTAP 9.10.1, you can specify whether you want to enable archiving with Azure or AWS.
|
|
| If you enable archiving for a volume with Azure or AWS, you cannot disable the archiving.
|
If you enable archiving for Azure or AWS, specify the following: The number of days after which the volume is archived. The number of backups to retain in the archive. Specify “0” (zero) to archive up to the latest backup. For AWS, select the archive storage class.
Select the volumes you want to back up. Select Save.
Edit the protection policy used for Cloud BackupYou can change which protection policy is used with Cloud Backup.
Steps In ONTAP System Manager, click Protection > Overview, then scroll to the Cloud Backup Service section. Click , then Edit. Select a Protection policy: Existing policy: Choose an existing policy. New
Policy: Specify a name and set up a transfer schedule.
|
| Beginning with ONTAP 9.10.1, you can specify whether you want to enable archiving with Azure or AWS.
|
|
| If you enable archiving for a volume with Azure or AWS, you cannot disable the archiving.
|
If you enable archiving for Azure or AWS, specify the following: The number of days after which the volume is archived. The number of backups to retain in the archive. Specify “0” (zero) to archive up to the latest backup. For AWS, select the archive storage class.
Select Save.
Protect new volumes or LUNs on the cloudWhen you create a new volume or LUN, you can establish a SnapMirror protection relationship that enables backing up to the cloud for the volume or LUN. Before
you begin You should have a SnapMirror license. Intercluster LIFs should be configured. NTP should be configured. Cluster must be running ONTAP 9.9.1.
About this task You cannot protect new volumes or LUNs on the cloud for the following cluster configurations: Steps When provisioning a volume or LUN, on the Protection page in ONTAP System Manager, select the checkbox labeled Enable SnapMirror (Local or Remote). Select the Cloud Backup policy type. If the Cloud Backup is not enabled, select Enable Cloud Backup Service.
Protect existing volumes or LUNs on the cloudYou can establish a SnapMirror protection relationship for existing volumes and LUNs.
Steps Select an existing volume or LUN, and click Protect. On the Protect Volumes page, specify Backup using Cloud Backup Service for the protection policy. Click Protect. On the Protection page, select the checkbox labeled Enable SnapMirror (Local or Remote). Select Enable Cloud Backup Service.
Cluster and SVM peering overview with the CLIYou can create peer relationships between source and destination clusters and between source and destination storage virtual machines (SVMs). You
must create peer relationships between these entities before you can replicate Snapshot copies using SnapMirror. ONTAP 9.7 offers enhancements that simplify the way you configure peer relationships between clusters and SVMs. The cluster and SVMs peering procedures are available for all ONTAP 9 versions. You should use the appropriate procedure for your version of ONTAP. You perform the procedures using the command-line interface (CLI), not ONTAP System Manager or an automated
scripting tool. Peering basicsYou must create peer relationships between source and destination clusters and between source and destination SVMs before you can replicate Snapshot copies using
SnapMirror. A peer relationship defines network connections that enable clusters and SVMs to exchange data securely. Clusters and SVMs in peer relationships communicate over the intercluster network using intercluster logical interfaces (LIFs). An intercluster LIF is a LIF that supports the "intercluster-core" network interface service and is typically created using the "default-intercluster" network interface service policy. You must create intercluster LIFs on every node in the
clusters being peered. Intercluster LIFs use routes that belong to the system SVM to which they are assigned. ONTAP automatically creates a system SVM for cluster-level communications within an IPspace. Fan-out and cascade topologies are both supported. In a cascade topology, you need only create intercluster networks between the primary and secondary clusters and between the secondary and tertiary clusters. You need not create an intercluster network between the primary and the
tertiary cluster.
|
| It is possible (but not advisable) for an administrator to remove the intercluster-core service from the default-intercluster service policy. If this occurs, LIFs created using "default-intercluster" will not actually be intercluster LIFs. To confirm that the default-intercluster service policy contains the intercluster-core service, use the following command: network interface service-policy show -policy default-intercluster
|
Prerequisites for cluster peeringBefore you set up cluster peering, you should confirm that the connectivity, port, IP
address, subnet, firewall, and cluster-naming requirements are met. Connectivity requirementsEvery intercluster LIF on the local cluster must be able to communicate with every intercluster
LIF on the remote cluster. Although it is not required, it is typically simpler to configure the IP addresses used for intercluster LIFs in the same subnet. The IP addresses can reside in the same subnet as data LIFs, or in a different subnet. The subnet used in each cluster must meet the following requirements: The subnet must belong to the broadcast domain that contains the ports that are used for intercluster communication. The subnet must have enough
IP addresses available to allocate to one intercluster LIF per node. For example, in a four-node cluster, the subnet used for intercluster communication must have four available IP addresses.
Each node must have an intercluster LIF with an IP address on the intercluster network.
Intercluster LIFs can have an IPv4 address or an IPv6 address.
|
| ONTAP 9 enables you to migrate your peering networks from IPv4 to IPv6 by optionally allowing both protocols to be present simultaneously on the intercluster LIFs. In earlier releases, all intercluster relationships for an entire cluster were either IPv4 or IPv6. This meant that changing protocols was a potentially disruptive event.
|
Port requirementsYou can use dedicated ports for intercluster communication, or share ports used by the data network. Ports must meet the following requirements: All
ports that are used to communicate with a given remote cluster must be in the same IPspace. You can use multiple IPspaces to peer with multiple clusters. Pair-wise full-mesh connectivity is required only within an IPspace. The broadcast domain that is used for intercluster communication must include at least two ports per node so that intercluster communication can fail over from one port to another port. Ports added to a broadcast domain can be physical network ports,
VLANs, or interface groups (ifgrps). All ports must be cabled. All ports must be in a healthy state. The MTU settings of the ports must be consistent.
Firewall requirementsFirewalls and the intercluster firewall policy must allow the following protocols: ICMP service TCP to the IP addresses of all the intercluster LIFs over the ports 10000, 11104, and
11105
Bidirectional HTTPS between the intercluster LIFs Although HTTPS is not required when you set up cluster peering using the CLI, HTTPS is required later if you use ONTAP System Manager to configure data protection.
The default intercluster firewall policy allows access through the HTTPS protocol and from all IP addresses (0.0.0.0/0). You can modify or replace the policy if necessary. Cluster requirementClusters must meet the following requirement: You can use dedicated ports for intercluster
communication, or share ports used by the data network. In deciding whether to share ports, you need to consider network bandwidth, the replication interval, and port availability.
|
| You can share ports on one peered cluster while using dedicated ports on the other.
|
Network bandwidthIf you have a high-speed network, such as 10 GbE, you might have enough local LAN bandwidth to perform replication using the same 10 GbE ports used for data access. Even
then, you should compare your available WAN bandwidth to your LAN bandwidth. If the available WAN bandwidth is significantly less than 10 GbE, you might need to use dedicated ports.
|
| The one exception to this rule might be when all or many nodes in the cluster replicate data, in which case bandwidth utilization is typically spread across nodes.
|
If you are not using dedicated ports, the maximum transmission unit (MTU) size of the replication network should typically be the same as the MTU size of the data network. Replication intervalIf replication takes place in off-peak hours, you should be able to use data ports for replication even without a 10-GbE LAN connection. If replication takes place during normal business hours, you need to consider the
amount of data that will be replicated and whether it requires so much bandwidth that it could cause contention with data protocols. If network utilization by data protocols (SMB, NFS, iSCSI) is above 50%, you should use dedicated ports for intercluster communication, to allow for non-degraded performance if node failover occurs. Port availabilityIf you determine that replication traffic is interfering with data traffic, you can migrate intercluster LIFs to any other intercluster-capable shared port on the same node. You can also dedicate VLAN ports for replication. The bandwidth of the port is shared between all VLANs and the base port. Use custom IPspaces to isolate replication trafficYou can use custom IPspaces to separate the interactions that a
cluster has with its peers. Called designated intercluster connectivity, this configuration allows service providers to isolate replication traffic in multitenant environments. Suppose, for example, that you want replication traffic between Cluster A and Cluster B to be separated from replication traffic between Cluster A and Cluster C. To accomplish this, you can create two IPspaces on Cluster A. One IPspace contains the intercluster LIFs that you use to communicate with
Cluster B. The other contains the intercluster LIFs that you use to communicate with Cluster C, as shown in the following illustration. For custom IPspace configuration, see the Network Management Guide. You can configure intercluster LIFs on ports shared with the data network. Doing so reduces the number of ports you need
for intercluster networking. Steps List the ports in the cluster: network port show
For complete command syntax, see the man page. The following example shows the network ports in cluster01: cluster01::> network port show
Speed (Mbps)
Node Port IPspace Broadcast Domain Link MTU Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
cluster01-01
e0a Cluster Cluster up 1500 auto/1000
e0b Cluster Cluster up 1500 auto/1000
e0c Default Default up 1500 auto/1000
e0d Default Default up 1500 auto/1000
cluster01-02
e0a Cluster Cluster up 1500 auto/1000
e0b Cluster Cluster up 1500 auto/1000
e0c Default Default up 1500 auto/1000
e0d Default Default up 1500 auto/1000Create intercluster LIFs on the system SVM:
| Option | Description |
|---|
In ONTAP 9.7 and later:
| network interface create -vserver system_SVM -lif LIF_name -service-policy default-intercluster -home-node node -home-port port -address port_IP -netmask netmask
|
For complete command syntax, see the man page. The following example creates intercluster LIFs cluster01_icl01 and cluster01_icl02: cluster01::> network interface create -vserver cluster01 -lif cluster01_icl01 -service-
policy default-intercluster -home-node cluster01-01 -home-port e0c -address 192.168.1.201
-netmask 255.255.255.0
cluster01::> network interface create -vserver cluster01 -lif cluster01_icl02 -service-
policy default-intercluster -home-node cluster01-02 -home-port e0c -address 192.168.1.202
-netmask 255.255.255.0 Verify that the intercluster LIFs were created:
| Option | Description |
|---|
In ONTAP 9.7 and later:
| network interface show -service-policy default-intercluster
|
For complete command syntax, see the man page. cluster01::> network interface show -service-policy default-intercluster
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cluster01
cluster01_icl01
up/up 192.168.1.201/24 cluster01-01 e0c true
cluster01_icl02
up/up 192.168.1.202/24 cluster01-02 e0c trueVerify that the intercluster LIFs are redundant:
| Option | Description |
|---|
In ONTAP 9.7 and later:
| network interface show –service-policy default-intercluster -failover
|
For complete command syntax, see the man page. The following example shows that the intercluster LIFs cluster01_icl01 and cluster01_icl02 on the e0c port will fail over to the e0d port. cluster01::> network interface show -service-policy default-intercluster –failover
Logical Home Failover Failover
Vserver Interface Node:Port Policy Group
-------- --------------- --------------------- --------------- --------
cluster01
cluster01_icl01 cluster01-01:e0c local-only 192.168.1.201/24
Failover Targets: cluster01-01:e0c,
cluster01-01:e0d
cluster01_icl02 cluster01-02:e0c local-only 192.168.1.201/24
Failover Targets: cluster01-02:e0c,
cluster01-02:e0d
You can configure intercluster LIFs on dedicated ports. Doing so typically increases the available bandwidth for replication traffic.
Steps List the ports in the cluster: network port show
For complete command syntax, see the man page. The following example shows the network ports in cluster01: cluster01::> network port show
Speed (Mbps)
Node Port IPspace Broadcast Domain Link MTU Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
cluster01-01
e0a Cluster Cluster up 1500 auto/1000
e0b Cluster Cluster up 1500 auto/1000
e0c Default Default up 1500 auto/1000
e0d Default Default up 1500 auto/1000
e0e Default Default up 1500 auto/1000
e0f Default Default up 1500 auto/1000
cluster01-02
e0a Cluster Cluster up 1500 auto/1000
e0b Cluster Cluster up 1500 auto/1000
e0c Default Default up 1500 auto/1000
e0d Default Default up 1500 auto/1000
e0e Default Default up 1500 auto/1000
e0f Default Default up 1500 auto/1000Determine which ports are available to dedicate to intercluster communication: network interface show -fields home-port,curr-port
For complete command syntax, see the man page. The following example shows that ports e0e and e0f have not been assigned LIFs: cluster01::> network interface show -fields home-port,curr-port
vserver lif home-port curr-port
------- -------------------- --------- ---------
Cluster cluster01-01_clus1 e0a e0a
Cluster cluster01-01_clus2 e0b e0b
Cluster cluster01-02_clus1 e0a e0a
Cluster cluster01-02_clus2 e0b e0b
cluster01
cluster_mgmt e0c e0c
cluster01
cluster01-01_mgmt1 e0c e0c
cluster01
cluster01-02_mgmt1 e0c e0cCreate
a failover group for the dedicated ports: network interface failover-groups create -vserver system_SVM -failover-group failover_group -targets physical _or_logical_ports
The following example assigns ports e0e and e0f to the failover group intercluster01 on the system SVM cluster01: cluster01::> network interface failover-groups create -vserver cluster01 -failover-group
intercluster01 -targets
cluster01-01:e0e,cluster01-01:e0f,cluster01-02:e0e,cluster01-02:e0f Verify that the failover group was created: network interface failover-groups show
For complete command syntax, see the man page. cluster01::> network interface failover-groups show
Failover
Vserver Group Targets
---------------- ---------------- --------------------------------------------
Cluster
Cluster
cluster01-01:e0a, cluster01-01:e0b,
cluster01-02:e0a, cluster01-02:e0b
cluster01
Default
cluster01-01:e0c, cluster01-01:e0d,
cluster01-02:e0c, cluster01-02:e0d,
cluster01-01:e0e, cluster01-01:e0f
cluster01-02:e0e, cluster01-02:e0f
intercluster01
cluster01-01:e0e, cluster01-01:e0f
cluster01-02:e0e, cluster01-02:e0fCreate intercluster LIFs on the system SVM and assign them to the failover group.
| Option | Description |
|---|
In ONTAP 9.7 and later:
| network interface create -vserver system_SVM -lif LIF_name -service-policy default-intercluster -home-node node -home- port port -address port_IP -netmask netmask -failover-group failover_group
|
For complete command syntax, see the man page. The following example creates intercluster LIFs cluster01_icl01 and cluster01_icl02 in the failover group intercluster01: cluster01::> network interface create -vserver cluster01 -lif cluster01_icl01 -service-
policy default-intercluster -home-node cluster01-01 -home-port e0e -address 192.168.1.201
-netmask 255.255.255.0 -failover-group intercluster01
cluster01::> network interface create -vserver cluster01 -lif cluster01_icl02 -service-
policy default-intercluster -home-node cluster01-02 -home-port e0e -address 192.168.1.202
-netmask 255.255.255.0 -failover-group intercluster01 Verify that the intercluster LIFs were created:
| Option | Description |
|---|
In ONTAP 9.7 and later:
| network interface show -service-policy default-intercluster
|
For complete command syntax, see the man page. cluster01::> network interface show -service-policy default-intercluster
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cluster01
cluster01_icl01
up/up 192.168.1.201/24 cluster01-01 e0e true
cluster01_icl02
up/up 192.168.1.202/24 cluster01-02 e0f trueVerify that the intercluster LIFs are redundant:
| Option | Description |
|---|
In ONTAP 9.7 and later:
| network interface show -service-policy default-intercluster -failover
|
For complete command syntax, see the man page. The following example shows that the intercluster LIFs cluster01_icl01 and cluster01_icl02 on the SVMe0e port will fail over to the e0f port. cluster01::> network interface show -service-policy default-intercluster –failover
Logical Home Failover Failover
Vserver Interface Node:Port Policy Group
-------- --------------- --------------------- --------------- --------
cluster01
cluster01_icl01 cluster01-01:e0e local-only intercluster01
Failover Targets: cluster01-01:e0e,
cluster01-01:e0f
cluster01_icl02 cluster01-02:e0e local-only intercluster01
Failover Targets: cluster01-02:e0e,
cluster01-02:e0f
You can configure intercluster LIFs in custom IPspaces. Doing so allows you to isolate replication traffic in multitenant environments.
When you create a custom IPspace, the system creates a system storage virtual machine (SVM) to serve as a container for the system objects in that IPspace. You can use the new SVM as the container for any intercluster LIFs in the new IPspace. The new SVM has the same name as the custom IPspace. Steps List the ports in the cluster: network port show
For complete command syntax, see the man page. The following example shows the network ports in cluster01:
cluster01::> network port show
Speed (Mbps)
Node Port IPspace Broadcast Domain Link MTU Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
cluster01-01
e0a Cluster Cluster up 1500 auto/1000
e0b Cluster Cluster up 1500 auto/1000
e0c Default Default up 1500 auto/1000
e0d Default Default up 1500 auto/1000
e0e Default Default up 1500 auto/1000
e0f Default Default up 1500 auto/1000
cluster01-02
e0a Cluster Cluster up 1500 auto/1000
e0b Cluster Cluster up 1500 auto/1000
e0c Default Default up 1500 auto/1000
e0d Default Default up 1500 auto/1000
e0e Default Default up 1500 auto/1000
e0f Default Default up 1500 auto/1000Create custom IPspaces on the cluster: network ipspace create -ipspace ipspace
The following example creates the custom IPspace ipspace-IC1: cluster01::> network ipspace create -ipspace ipspace-IC1 Determine which ports are available to dedicate to intercluster communication: network interface show -fields home-port,curr-port
For complete command syntax, see the man page. The following example shows that ports e0e and e0f have not been assigned LIFs: cluster01::> network interface show -fields home-port,curr-port
vserver lif home-port curr-port
------- -------------------- --------- ---------
Cluster cluster01_clus1 e0a e0a
Cluster cluster01_clus2 e0b e0b
Cluster cluster02_clus1 e0a e0a
Cluster cluster02_clus2 e0b e0b
cluster01
cluster_mgmt e0c e0c
cluster01
cluster01-01_mgmt1 e0c e0c
cluster01
cluster01-02_mgmt1 e0c e0cRemove the available ports from the
default broadcast domain: network port broadcast-domain remove-ports -broadcast-domain Default -ports ports
A port cannot be in more than one broadcast domain at a time. For complete command syntax, see the man page. The following example removes ports e0e and e0f from the default broadcast domain: cluster01::> network port broadcast-domain remove-ports -broadcast-domain Default -ports
cluster01-01:e0e,cluster01-01:e0f,cluster01-02:e0e,cluster01-02:e0f Verify that the ports have been removed from the default broadcast domain: network port show
For complete command syntax, see the man page. The following example shows that ports e0e and e0f
have been removed from the default broadcast domain: cluster01::> network port show
Speed (Mbps)
Node Port IPspace Broadcast Domain Link MTU Admin/Oper
------ ------- --------- --------------- ----- ------- ------------
cluster01-01
e0a Cluster Cluster up 9000 auto/1000
e0b Cluster Cluster up 9000 auto/1000
e0c Default Default up 1500 auto/1000
e0d Default Default up 1500 auto/1000
e0e Default - up 1500 auto/1000
e0f Default - up 1500 auto/1000
e0g Default Default up 1500 auto/1000
cluster01-02
e0a Cluster Cluster up 9000 auto/1000
e0b Cluster Cluster up 9000 auto/1000
e0c Default Default up 1500 auto/1000
e0d Default Default up 1500 auto/1000
e0e Default - up 1500 auto/1000
e0f Default - up 1500 auto/1000
e0g Default Default up 1500 auto/1000Create a broadcast domain in the custom IPspace: network port broadcast-domain create -ipspace ipspace -broadcast-domain broadcast_domain -mtu MTU -ports ports
The following example creates the broadcast domain ipspace-IC1-bd in the IPspace ipspace-IC1: cluster01::> network port broadcast-domain create -ipspace ipspace-IC1 -broadcast-domain
ipspace-IC1-bd -mtu 1500 -ports cluster01-01:e0e,cluster01-01:e0f,
cluster01-02:e0e,cluster01-02:e0f Verify that the broadcast domain was created: network port broadcast-domain show
For complete command syntax, see the man page. cluster01::> network port broadcast-domain show
IPspace Broadcast Update
Name Domain Name MTU Port List Status Details
------- ----------- ------ ----------------------------- --------------
Cluster Cluster 9000
cluster01-01:e0a complete
cluster01-01:e0b complete
cluster01-02:e0a complete
cluster01-02:e0b complete
Default Default 1500
cluster01-01:e0c complete
cluster01-01:e0d complete
cluster01-01:e0f complete
cluster01-01:e0g complete
cluster01-02:e0c complete
cluster01-02:e0d complete
cluster01-02:e0f complete
cluster01-02:e0g complete
ipspace-IC1
ipspace-IC1-bd
1500
cluster01-01:e0e complete
cluster01-01:e0f complete
cluster01-02:e0e complete
cluster01-02:e0f completeCreate intercluster LIFs on the system SVM and assign them to the broadcast
domain:
| Option | Description |
|---|
In ONTAP 9.7 and later:
| network interface create -vserver system_SVM -lif LIF_name -service-policy default-intercluster -home-node node -home-port port -address port_IP -netmask netmask
|
The LIF is created in the broadcast domain that the home port is assigned to. The broadcast domain has a default failover group with the same name as the broadcast domain. For complete command syntax, see the man page. The following example creates intercluster LIFs cluster01_icl01 and cluster01_icl02 in the broadcast domain ipspace-IC1-bd: cluster01::> network interface create -vserver ipspace-IC1 -lif cluster01_icl01 -service-
policy default-intercluster -home-node cluster01-01 -home-port e0e -address 192.168.1.201
-netmask 255.255.255.0
cluster01::> network interface create -vserver ipspace-IC1 -lif cluster01_icl02 -service-
policy default-intercluster -home-node cluster01-02 -home-port e0e -address 192.168.1.202
-netmask 255.255.255.0 Verify that the intercluster LIFs were created:
| Option | Description |
|---|
In ONTAP 9.7 and later:
| network interface show -service-policy default-intercluster
|
For complete command syntax, see the man page. cluster01::> network interface show -service-policy default-intercluster
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
ipspace-IC1
cluster01_icl01
up/up 192.168.1.201/24 cluster01-01 e0e true
cluster01_icl02
up/up 192.168.1.202/24 cluster01-02 e0f trueVerify that the intercluster LIFs are redundant:
| Option | Description |
|---|
In ONTAP 9.7 and later:
| network interface show -service-policy default-intercluster -failover
|
For complete command syntax, see the man page. The following example shows that the intercluster LIFs cluster01_icl01 and cluster01_icl02 on the SVM e0e port fail over to the`e0f`port: cluster01::> network interface show -service-policy default-intercluster –failover
Logical Home Failover Failover
Vserver Interface Node:Port Policy Group
-------- --------------- --------------------- --------------- --------
ipspace-IC1
cluster01_icl01 cluster01-01:e0e local-only intercluster01
Failover Targets: cluster01-01:e0e,
cluster01-01:e0f
cluster01_icl02 cluster01-02:e0e local-only intercluster01
Failover Targets: cluster01-02:e0e,
cluster01-02:e0f
Create a cluster peer relationship (ONTAP 9.7 and later)You can use the cluster peer create command to create a peer relationship between a local and remote cluster. After the peer relationship has been created,
you can run cluster peer create on the remote cluster to authenticate it to the local cluster. What you’ll need Steps On the destination cluster, create a peer relationship with the source cluster: cluster peer create -generate-passphrase -offer-expiration MM/DD/YYYY HH:MM:SS|1…7days|1…168hours -peer-addrs peer_LIF_IPs -initial-allowed-vserver-peers svm_name,..|* -ipspace ipspace
If you specify both -generate-passphrase and -peer-addrs, only the cluster whose
intercluster LIFs are specified in -peer-addrs can use the generated password. You can ignore the -ipspace option if you are not using a custom IPspace. For complete command syntax, see the man page. If you are creating the peering relationship in ONTAP 9.7 or later and you do not want cross-cluster peering communications to be encrypted, you must use the -encryption-protocol-proposed none option to disable encryption. The following example creates a cluster peer relationship with an unspecified remote
cluster, and pre-authorizes peer relationships with SVMs vs1 and vs2 on the local cluster: cluster02::> cluster peer create -generate-passphrase -offer-expiration 2days -initial-allowed-vserver-peers vs1,vs2
Passphrase: UCa+6lRVICXeL/gq1WrK7ShR
Expiration Time: 6/7/2017 08:16:10 EST
Initial Allowed Vserver Peers: vs1,vs2
Intercluster LIF IP: 192.140.112.101
Peer Cluster Name: Clus_7ShR (temporary generated)
Warning: make a note of the passphrase - it cannot be displayed again.The following example creates a cluster peer relationship with the remote cluster at intercluster LIF IP addresses 192.140.112.103 and 192.140.112.104, and pre-authorizes a peer relationship with any SVM on the local cluster: cluster02::> cluster peer create -generate-passphrase -peer-addrs 192.140.112.103,192.140.112.104 -offer-expiration 2days -initial-allowed-vserver-peers *
Passphrase: UCa+6lRVICXeL/gq1WrK7ShR
Expiration Time: 6/7/2017 08:16:10 EST
Initial Allowed Vserver Peers: vs1,vs2
Intercluster LIF IP: 192.140.112.101,192.140.112.102
Peer Cluster Name: Clus_7ShR (temporary generated)
Warning: make a note of the passphrase - it cannot be displayed again.The following example creates a cluster peer relationship with an unspecified remote cluster, and pre-authorizes peer
relationships with SVMsvs1 and vs2 on the local cluster: cluster02::> cluster peer create -generate-passphrase -offer-expiration 2days -initial-allowed-vserver-peers vs1,vs2
Passphrase: UCa+6lRVICXeL/gq1WrK7ShR
Expiration Time: 6/7/2017 08:16:10 EST
Initial Allowed Vserver Peers: vs1,vs2
Intercluster LIF IP: 192.140.112.101
Peer Cluster Name: Clus_7ShR (temporary generated)
Warning: make a note of the passphrase - it cannot be displayed again.On source cluster, authenticate the source cluster to the destination cluster: cluster peer create -peer-addrs peer_LIF_IPs -ipspace ipspace
For complete command syntax, see the man page. The following example authenticates the local cluster to the remote cluster at intercluster LIF IP addresses 192.140.112.101 and 192.140.112.102: cluster01::> cluster peer create -peer-addrs 192.140.112.101,192.140.112.102
Notice: Use a generated passphrase or choose a passphrase of 8 or more characters.
To ensure the authenticity of the peering relationship, use a phrase or sequence of characters that would be hard to guess.
Enter the passphrase:
Confirm the passphrase:
Clusters cluster02 and cluster01 are peered.Enter the passphrase for the peer relationship when prompted. Verify
that the cluster peer relationship was created: cluster peer show -instance
cluster01::> cluster peer show -instance
Peer Cluster Name: cluster02
Remote Intercluster Addresses: 192.140.112.101, 192.140.112.102
Availability of the Remote Cluster: Available
Remote Cluster Name: cluster2
Active IP Addresses: 192.140.112.101, 192.140.112.102
Cluster Serial Number: 1-80-123456
Address Family of Relationship: ipv4
Authentication Status Administrative: no-authentication
Authentication Status Operational: absent
Last Update Time: 02/05 21:05:41
IPspace for the Relationship: DefaultCheck the connectivity and status of the nodes in the peer relationship: cluster peer health show
cluster01::> cluster peer health show
Node cluster-Name Node-Name
Ping-Status RDB-Health Cluster-Health Avail…
---------- --------------------------- --------- --------------- --------
cluster01-01
cluster02 cluster02-01
Data: interface_reachable
ICMP: interface_reachable true true true
cluster02-02
Data: interface_reachable
ICMP: interface_reachable true true true
cluster01-02
cluster02 cluster02-01
Data: interface_reachable
ICMP: interface_reachable true true true
cluster02-02
Data: interface_reachable
ICMP: interface_reachable true true true
Create an intercluster SVM peer relationship (ONTAP 9.7 and later)You can use the vserver peer create command to create a peer relationship between SVMs on local and remote
clusters.
What you’ll need About this task Previous releases of ONTAP let you authorize a peer relationship for only one SVM at a time. You needed to run the vserver peer accept command each time you authorized a pending SVM peer relationship. Beginning with ONTAP 9.7, you can "pre-authorize" peer
relationships for multiple SVMs by listing the SVMs in the -initial-allowed-vserver option when you create a cluster peer relationship. For more information, see Creating a cluster peer relationship (ONTAP 9.7 and later). Steps On the data protection destination cluster, display the SVMs that are pre-authorized for peering: vserver peer permission show
cluster02::> vserver peer permission show
Peer Cluster Vserver Applications
------------------- -------------------- --------------------
cluster02 vs1,vs2 snapmirror On the data protection source cluster, create a peer relationship to a pre-authorized SVM on the data protection destination cluster: vserver peer create -vserver local_SVM -peer-vserver remote_SVM
For complete command syntax, see the man page. The following example creates a peer relationship between the local SVM pvs1 and the pre-authorized remote SVM vs1: cluster01::> vserver peer create -vserver pvs1 -peer-vserver vs1 Verify the SVM peer relationship: vserver peer show
cluster01::> vserver peer show
Peer Peer Peering Remote
Vserver Vserver State Peer Cluster Applications Vserver
----------- ----------- ------------ ----------------- -------------- ---------
pvs1 vs1 peered cluster02 snapmirror vs1
Add an intercluster SVM peer relationshipIf you create an SVM after configuring a cluster peer relationship, you will need to add a peer
relationship for the SVM manually. You can use the vserver peer create command to create a peer relationship between SVMs. After the peer relationship has been created, you can run vserver peer accept on the remote cluster to authorize the peer relationship. Before you begin The source and destination clusters must be peered. About this task You can create a peer relationships between SVMs in the same cluster for local data backup. For more information, see the vserver peer create man
page. Administrators occasionally use the vserver peer reject command to reject a proposed SVM peer relationship. If the relationship between SVMs is in the rejected state, you must delete the relationship before you can create a new one. For more information, see the vserver peer delete man page. Steps On the data protection source cluster, create a peer relationship with an SVM on the data protection destination cluster: vserver peer create -vserver local_SVM -peer-vserver remote_SVM -applications snapmirror|file-copy|lun-copy -peer-cluster remote_cluster
The following example creates a peer
relationship between the local SVMpvs1 and the remote SVMvs1 cluster01::> vserver peer create -vserver pvs1 -peer-vserver vs1 -applications snapmirror -peer-cluster cluster02 If the local and remote SVMs have the same names, you must use a local name to create the SVM peer relationship: cluster01::> vserver peer create -vserver vs1 -peer-vserver
vs1 -applications snapmirror -peer-cluster cluster01
-local-name cluster1vs1LocallyUniqueName On the data protection source cluster, verify that the peer relationship has been initiated: vserver peer show-all
For complete command syntax, see the man page. The following example shows that the peer relationship between SVMpvs1 and
SVMvs1 has been initiated: cluster01::> vserver peer show-all
Peer Peer Peering
Vserver Vserver State Peer Cluster Applications
-------- -------- --------- ------------- ------------
pvs1 vs1 initiated Cluster02 snapmirrorOn the data protection destination cluster, display the pending SVM peer relationship: vserver peer show
For complete command syntax, see the man page. The following example lists the pending peer relationships for cluster02: cluster02::> vserver peer show
Peer Peer
Vserver Vserver State
----------- ----------- ------------
vs1 pvs1 pendingOn the data protection destination cluster, authorize the pending peer relationship: vserver peer accept -vserver local_SVM -peer-vserver remote_SVM
For complete command syntax, see the man page. The
following example authorizes the peer relationship between the local SVM vs1 and the remote SVM pvs1: cluster02::> vserver peer accept -vserver vs1 -peer-vserver pvs1 Verify the SVM peer relationship: vserver peer show
cluster01::> vserver peer show
Peer Peer Peering Remote
Vserver Vserver State Peer Cluster Applications Vserver
----------- ----------- ------------ ----------------- -------------- ---------
pvs1 vs1 peered cluster02 snapmirror vs1
Enable cluster peering encryption on an existing peer relationshipBeginning with ONTAP 9.7, cluster peering encryption is enabled by default on all
newly created cluster peering relationships. Cluster peering encryption uses a pre-shared key (PSK) and the Transport Security Layer (TLS) to secure cross-cluster peering communications. This adds an additional layer of security between the peered clusters. About this task Both clusters in the peering relationship must be running ONTAP 9.7 or later in order to enable cluster peering encryption. Steps On the destination cluster, enable encryption
for communications with the source cluster: cluster peer modify source_cluster -auth-status-admin use-authentication -encryption-protocol-proposed tls-psk
When prompted enter a passphrase. On the data protection source cluster, enable encryption for communication with the data protection destination cluster: cluster peer modify data_protection_destination_cluster -auth-status-admin use-authentication -encryption-protocol-proposed tls-psk
When prompted, enter the same passphrase entered on the destination cluster.
Remove cluster peering encryption from an existing peer relationshipBy default, cluster peering encryption is enabled on all peer relationships
created in ONTAP 9.7 or later. If you do not want to use encryption for cross-cluster peering communications, you can disable it. Steps On the destination cluster, modify communications with the source cluster to discontinue use of cluster peering encryption : To remove encryption, but maintain authentication enter: cluster peer modify source_cluster -auth-status-admin use-authentication -encryption none To remove encryption and authentication, enter: cluster peer modify source_cluster -auth-status no-authentication
When prompted enter a passphrase. On the source cluster, disable encryption for communication with the destination cluster: To remove encryption, but maintain authentication enter: cluster peer modify destination_cluster -auth-status-admin use-authentication -encrypt none To remove encryption and authentication, enter: cluster peer modify destination_cluster -auth-status no-authentication
When prompted, enter the same passphrase entered on the destination cluster.
Data protection overview with the CLIYou can use CLI commands to manage Snapshot copies on a local ONTAP system and to replicate Snapshot copies to a remote system using SnapMirror. You can replicate Snapshot
copies for disaster recovery or long-term retention. Use these procedures under the following circumstances: You want to understand the range of ONTAP backup and recovery capabilities. You want to use the command-line interface (CLI), not ONTAP System Manager, an automated scripting tool, or a SnapCenter product. You have already created peer relationships between the source and destination clusters and the source and destination SVMs.
You are backing up volumes or SVMs from ETERNUS AX or ETERNUS HX storage systems to ETERNUS AX or ETERNUS HX storage systems. You want to provide data
protection using online methods, not tape.
Manage local Snapshot copies overviewA Snapshot copy is a
read-only, point-in-time image of a volume. The image consumes minimal storage space and incurs negligible performance overhead because it records only changes to files since the last Snapshot copy. You can use a Snapshot copy to restore the entire contents of a volume, or to recover individual files or LUNs. Snapshot copies are stored in the directory .snapshot on the volume. In ONTAP 9.7 and later, a FlexVol volume can contain up to 1023 Snapshot copies.
|
| Beginning with ONTAP 9.8, FlexGroup volumes can contain 1023 Snapshot copies. For more information, see Volume administration.
|
A Snapshot policy defines how the system
creates Snapshot copies. The policy specifies when to create Snapshot copies, how many copies to retain, and how to name them. For example, a system might create one Snapshot copy every day at 12:10 a.m., retain the two most recent copies, and name the copies “daily.timestamp.” The default policy for a volume automatically creates Snapshot copies on the following schedule, with the oldest Snapshot copies deleted to make room for newer copies: A maximum of six hourly
Snapshot copies taken five minutes past the hour. A maximum of two daily Snapshot copies taken Monday through Saturday at 10 minutes after midnight. A maximum of two weekly Snapshot copies taken every Sunday at 15 minutes after midnight.
Unless you specify a Snapshot policy when you create a volume, the volume inherits the Snapshot policy associated with its containing storage virtual machine (SVM). If the default Snapshot policy is not appropriate for a volume, you can configure a custom policy that
modifies the frequency, retention, and name of Snapshot copies. The schedule will be dictated mainly by the rate of change of the active file system. You might back up a heavily used file system like a database every hour, while you back up rarely used files once a day. Even for a database, you will typically run a full backup once or twice a day, while backing up transaction logs every hour. Other factors are the importance of the files to your organization, your Service Level
Agreement (SLA), your Recovery Point Objective (RPO), and your Recovery Time Objective (RTO). Generally speaking, you should retain only as many Snapshot copies as necessary. Create a Snapshot job scheduleA Snapshot policy requires at least one Snapshot copy job schedule. You can use the job schedule cron create command to create a job schedule. About this task By default, ONTAP forms the
names of Snapshot copies by appending a timestamp to the job schedule name. If you specify values for both day of the month and day of the week, the values are considered independently. For example, a cron schedule with the day specification Friday and the day of the month specification 13 runs every Friday and on the 13th day of each month, not just on every Friday the 13th. Step Create a job schedule: job schedule cron create -name job_name -month month -dayofweek day_of_week -day day_of_month -hour hour -minute minute
For -month, -dayofweek, and
-hour, you can specify all to run the job every month, day of the week, and hour, respectively. Beginning with ONTAP 9.10.1, you can include the Vserver for your job schedule: job schedule cron create -name job_name -vserver Vserver_name -month month -dayofweek day_of_week -day day_of_month -hour hour -minute minute
The following example creates a job schedule named myweekly that runs on Saturdays at 3:00 a.m.: cluster1::> job schedule cron create -name myweekly -dayofweek "Saturday" -hour 3 -minute 0 The following example creates a schedule named myweeklymulti that specifies multiple days, hours and minutes: job schedule cron create -name myweeklymulti -dayofweek "Monday,Wednesday,Sunday" -hour 3,9,12 -minute 0,20,50
Create a Snapshot policyA Snapshot policy specifies when to create Snapshot copies, how many copies to retain, and how to name them. For example, a system might create one Snapshot copy every day at
12:10 a.m., retain the two most recent copies, and name them “daily.timestamp.” A Snapshot policy can contain up to five job schedules. About this task By default, ONTAP forms the names of Snapshot copies by appending a timestamp to the job schedule name: daily.2017-05-14_0013/ hourly.2017-05-15_1106/
daily.2017-05-15_0012/ hourly.2017-05-15_1206/
hourly.2017-05-15_1006/ hourly.2017-05-15_1306/ You can substitute a prefix for the job schedule name if you prefer. The snapmirror-label option is for SnapMirror replication. For more information, see
Defining a rule for a policy. Step Create a Snapshot policy: volume snapshot policy create -vserver SVM -policy policy_name -enabled true|false -schedule1 schedule1_name -count1 copies_to_retain -prefix1 snapshot_prefix -snapmirror-label1 snapshot_label … -schedule1 schedule5_name -count5 copies_to_retain-prefix5 snapshot_prefix -snapmirror-label5 snapshot_label
The following example creates a Snapshot policy named snap_policy_daily that runs on a daily schedule. The policy has a maximum of five Snapshot copies, each with the name daily.timestamp and the SnapMirror label daily: cluster1::> volume snapshot policy create -vserver vs0 -policy snap_policy_daily -schedule1 daily -count1 5 -snapmirror-label1 daily
Manage the Snapshot copy reserve overviewThe Snapshot copy reserve sets aside a percentage of
disk space for Snapshot copies, five percent by default. Because Snapshot copies use space in the active file system when the Snapshot copy reserve is exhausted, you might want to increase the Snapshot copy reserve as needed. Alternatively, you can autodelete Snapshot copies when the reserve is full. When to increase the Snapshot copy reserveIn deciding whether to increase the Snapshot reserve, it’s important to remember that a Snapshot copy records only changes to files since the last
Snapshot copy was made. It consumes disk space only when blocks in the active file system are modified or deleted. This means that the rate of change of the file system is the key factor in determining the amount of disk space used by Snapshot copies. No matter how many Snapshot copies you create, they will not consume disk space if the active file system has not changed. A FlexVol volume containing database transaction logs, for example, might have a Snapshot copy reserve as large
as 20% to account for its greater rate of change. Not only will you want to create more Snapshot copies to capture the more frequent updates to the database, you will also want to have a larger Snapshot copy reserve to handle the additional disk space the Snapshot copies consume.
|
| A Snapshot copy consists of pointers to blocks rather than copies of blocks. You can think of a pointer as a “claim” on a block: ONTAP “holds” the block until the Snapshot copy is deleted.
|
How deleting protected files can lead to less file space than expectedA Snapshot copy points to a block even after you delete the file that
used the block. This explains why an exhausted Snapshot copy reserve might lead to the counter-intuitive result in which deleting an entire file system results in less space being available than the file system occupied. Consider the following example. Before deleting any files, the df command output is as follows: Filesystem kbytes used avail capacity
/vol/vol0/ 3000000 3000000 0 100%
/vol/vol0/.snapshot 1000000 500000 500000 50% After deleting the entire file system and making a Snapshot copy of the volume, the df command generates the following output: Filesystem kbytes used avail capacity
/vol/vol0/ 3000000 2500000 500000 83%
/vol/vol0/.snapshot 1000000 3500000 0 350%
As the output shows, the entire 3 GB formerly used by the active file system is now being used by Snapshot copies, in addition to the 0.5 GB used before the deletion. Because the disk space used by the Snapshot copies now exceeds the Snapshot copy reserve, the overflow of 2.5 GB “spills” into the space reserved for active files, leaving you with 0.5 GB free space for files where you might reasonably have expected 3 GB. Monitor Snapshot copy disk consumptionYou can monitor Snapshot copy disk consumption using the df command. The command displays the amount of free
space in the active file system and the Snapshot copy reserve. Step Display Snapshot copy disk consumption: df The following example shows Snapshot copy disk consumption: cluster1::> df
Filesystem kbytes used avail capacity
/vol/vol0/ 3000000 3000000 0 100%
/vol/vol0/.snapshot 1000000 500000 500000 50%
Check available Snapshot copy reserve on a volumeYou might want to check how much Snapshot copy reserve is available on a volume by using the snapshot-reserve-available parameter with the volume show
command. Step Check the Snapshot copy reserve available on a volume: vol show -vserver SVM -volume volume -fields snapshot-reserve-available
For complete command syntax, see the man page. The following example displays the available Snapshot copy reserve for vol1: cluster1::> vol show -vserver vs0 -volume vol1 -fields snapshot-reserve-available
vserver volume snapshot-reserve-available
------- ------ --------------------------
vs0 vol1 4.84GB
Modify the Snapshot copy reserveYou might want to configure a larger Snapshot copy reserve to prevent Snapshot copies from using space reserved for the active file system. You can decrease the Snapshot copy reserve
when you no longer need as much space for Snapshot copies. Step Modify the Snapshot copy reserve: volume modify -vserver SVM -volume volume -percent-snapshot-space snap_reserve
For complete command syntax, see the man page. The following example sets the Snapshot copy reserve for vol1 to 10 percent: cluster1::> volume modify -vserver vs0 -volume vol1 -percent-snapshot-space 10
Autodelete Snapshot copiesYou can use the volume snapshot autodelete modify command to trigger automatic deletion of Snapshot copies when the Snapshot reserve is exceeded. By default, the oldest Snapshot copies are deleted first. About this
task LUN and file clones are deleted when there are no more Snapshot copies to be deleted. Step Autodelete Snapshot copies: volume snapshot autodelete modify -vserver SVM -volume volume -enabled true|false -trigger volume|snap_reserve
For complete command syntax, see the man page. The following example autodeletes Snapshot copies for vol1 when the Snapshot copy reserve is exhausted: cluster1::> volume snapshot autodelete modify -vserver vs0 -volume vol1 -enabled true -trigger snap_reserve
Restore a file from a Snapshot copy on an NFS or SMB clientA user on an NFS or SMB client can restore a file directly from a Snapshot copy without the
intervention of a storage system administrator. Every directory in the file system contains a subdirectory named .snapshot accessible to NFS and SMB users. The .snapshot subdirectory contains subdirectories corresponding to the Snapshot copies of the volume: $ ls .snapshot
daily.2017-05-14_0013/ hourly.2017-05-15_1106/
daily.2017-05-15_0012/ hourly.2017-05-15_1206/
hourly.2017-05-15_1006/ hourly.2017-05-15_1306/ Each subdirectory contains the files referenced by the Snapshot copy. If users accidentally delete or overwrite a file, they can restore the file to the parent read-write directory by copying the file from the
Snapshot subdirectory to the read-write directory: $ ls my.txt
ls: my.txt: No such file or directory
$ ls .snapshot
daily.2017-05-14_0013/ hourly.2017-05-15_1106/
daily.2017-05-15_0012/ hourly.2017-05-15_1206/
hourly.2017-05-15_1006/ hourly.2017-05-15_1306/
$ ls .snapshot/hourly.2017-05-15_1306/my.txt
my.txt
$ cp .snapshot/hourly.2017-05-15_1306/my.txt .
$ ls my.txt
my.txt Enable and disable NFS and SMB client access to Snapshot copy directoryTo determine whether the Snapshot copy directory is visible to NFS
and SMB clients to restore a file or LUN from a Snapshot copy, you can enable and disable access to the Snapshot copy directory using the -snapdir-access option of the volume modify command. Steps Check the Snapshot directory access status: volume show -vserver SVM_name -volume vol_name -fields snapdir-access
Example: clus1::> volume show -vserver vs0 -volume vol1 -fields snapdir-access
vserver volume snapdir-access
------- ------ --------------
vs0 vol1 false Enable or disable the Snapshot copy directory access: volume modify -volume vol_name -snapdir-access true|false
The following example enables Snapshot copy directory access on vol1: clus1::> volume modify -volume vol1 -snapdir-access true
Volume modify successful on volume vol1 of Vserver vs0.
Restore a single file from a Snapshot copyYou can use the volume snapshot restore-file command to restore a single file or LUN from a Snapshot copy. You can restore the file
to a different location in the parent read-write volume if you do not want to replace an existing file. About this task If you are restoring an existing LUN, a LUN clone is created and backed up in the form of a Snapshot copy. During the restore operation, you can read to and write from the LUN. Files with streams are restored by default. Steps List the Snapshot copies in a volume: volume snapshot show -vserver SVM -volume volume
For complete command syntax, see the man
page. The following example shows the Snapshot copies in vol1: clus1::> volume snapshot show -vserver vs1 -volume vol1
Vserver Volume Snapshot State Size Total% Used%
------- ------ ---------- ----------- ------ ----- ------ -----
vs1 vol1 hourly.2013-01-25_0005 valid 224KB 0% 0%
daily.2013-01-25_0010 valid 92KB 0% 0%
hourly.2013-01-25_0105 valid 228KB 0% 0%
hourly.2013-01-25_0205 valid 236KB 0% 0%
hourly.2013-01-25_0305 valid 244KB 0% 0%
hourly.2013-01-25_0405 valid 244KB 0% 0%
hourly.2013-01-25_0505 valid 244KB 0% 0%
7 entries were displayed.Restore a file from a Snapshot copy: volume snapshot restore-file -vserver SVM -volume volume -snapshot snapshot -path file_path -restore-path destination_path
For complete command syntax, see the man page. The following example restores the file myfile.txt: cluster1::> volume snapshot restore-file -vserver vs0 -volume vol1 -snapshot daily.2013-01-25_0010 -path /myfile.txt
Restore part of a file from a Snapshot copyYou can use the volume snapshot partial-restore-file command to restore a range of data from a Snapshot copy to a LUN or to an NFS or SMB container file, assuming you know the
starting byte offset of the data and the byte count. You might use this command to restore one of the databases on a host that stores multiple databases in the same LUN. Steps List the Snapshot copies in a volume: volume snapshot show -vserver SVM -volume volume
For complete command syntax, see the man page. The following example shows the Snapshot copies in vol1: clus1::> volume snapshot show -vserver vs1 -volume vol1
Vserver Volume Snapshot State Size Total% Used%
------- ------ ---------- ----------- ------ ----- ------ -----
vs1 vol1 hourly.2013-01-25_0005 valid 224KB 0% 0%
daily.2013-01-25_0010 valid 92KB 0% 0%
hourly.2013-01-25_0105 valid 228KB 0% 0%
hourly.2013-01-25_0205 valid 236KB 0% 0%
hourly.2013-01-25_0305 valid 244KB 0% 0%
hourly.2013-01-25_0405 valid 244KB 0% 0%
hourly.2013-01-25_0505 valid 244KB 0% 0%
7 entries were displayed.Restore part of a file from a Snapshot copy: volume snapshot partial-restore-file -vserver SVM -volume volume -snapshot snapshot -path file_path -start-byte starting_byte -byte-count byte_count
The starting byte offset
and byte count must be multiples of 4,096. The following example restores the first 4,096 bytes of the file myfile.txt: cluster1::> volume snapshot partial-restore-file -vserver vs0 -volume vol1 -snapshot daily.2013-01-25_0010 -path /myfile.txt -start-byte 0 -byte-count 4096
Restore the contents of a volume from a Snapshot copyYou can use the volume snapshot restore command to restore the contents of a volume from a Snapshot copy. About this task
If the volume has SnapMirror relationships, manually replicate all mirror copies of the volume immediately after you restore from a Snapshot copy. Not doing so can result in unusable mirror copies that must be deleted and recreated. Steps List the Snapshot copies in a volume: volume snapshot show -vserver SVM -volume volume
For complete command syntax, see the man page. The following example shows the Snapshot copies in vol1: clus1::> volume snapshot show -vserver vs1 -volume vol1
Vserver Volume Snapshot State Size Total% Used%
------- ------ ---------- ----------- ------ ----- ------ -----
vs1 vol1 hourly.2013-01-25_0005 valid 224KB 0% 0%
daily.2013-01-25_0010 valid 92KB 0% 0%
hourly.2013-01-25_0105 valid 228KB 0% 0%
hourly.2013-01-25_0205 valid 236KB 0% 0%
hourly.2013-01-25_0305 valid 244KB 0% 0%
hourly.2013-01-25_0405 valid 244KB 0% 0%
hourly.2013-01-25_0505 valid 244KB 0% 0%
7 entries were displayed.Restore the contents
of a volume from a Snapshot copy: volume snapshot restore -vserver SVM -volume volume -snapshot snapshot
For complete command syntax, see the man page. The following example restores the contents of vol1: cluster1::> volume snapshot restore -vserver vs0 -volume vol1 -snapshot daily.2013-01-25_0010
About SnapMirror volume replicationTraditionally, ONTAP replication technologies served the need for disaster recovery (DR) and data archiving. In ONTAP 9.7, these technologies were combined in a way that allows you to
configure disaster recovery and archiving on the same destination volume. Asynchronous SnapMirror disaster recovery
basicsSnapMirror is disaster recovery technology, designed for failover from primary storage to secondary storage at a geographically remote site. As its name implies, SnapMirror creates a replica, or mirror, of your working data in secondary storage from which you can continue to serve data in the event of a catastrophe at the primary site. If the primary site is still available to serve data, you can simply transfer any needed data back to it, and not
serve clients from the mirror at all. As the failover use case implies, the controllers on the secondary system should be equivalent or nearly equivalent to the controllers on the primary system to serve data efficiently from mirrored storage. Data protection relationshipsData is mirrored at the volume level. The relationship between the source volume in primary storage and the destination volume in secondary storage is called a data protection relationship.
The clusters in which the volumes reside and the SVMs that serve data from the volumes must be peered. A peer relationship enables clusters and SVMs to exchange data securely. The figure below illustrates SnapMirror data protection relationships. Scope of data protection relationshipsYou can create a data protection relationship directly between volumes or between the SVMs that own the volumes. In an SVM data protection relationship, all or
part of the SVM configuration, from NFS exports and SMB shares to RBAC, is replicated, as well as the data in the volumes that the SVM owns. You can also use SnapMirror for two special data protection applications: A load-sharing mirror copy of the SVM root volume ensures that data remains accessible in the event of a node outage or failover. A data protection relationship between SnapLock volumes lets you replicate WORM files to
secondary storage.
How SnapMirror data protection relationships are
initializedThe first time you invoke SnapMirror, it performs a baseline transfer from the source volume to the destination volume. The SnapMirror policy for the relationship defines the contents of the baseline and any updates. A baseline transfer under the default SnapMirror policy MirrorAllSnapshots involves the following steps: Make a Snapshot copy of the source volume. Transfer the Snapshot copy and all the data blocks it references
to the destination volume. Transfer the remaining, less recent Snapshot copies on the source volume to the destination volume for use in case the “active” mirror is corrupted.
How SnapMirror data protection relationships are updatedUpdates are asynchronous, following the schedule you configure. Retention mirrors the Snapshot policy on the
source.
At each update under the MirrorAllSnapshots policy, SnapMirror creates a Snapshot copy of the source volume and transfers that Snapshot copy and any Snapshot copies that have been made since the last update. In the following output from the snapmirror policy show command for the MirrorAllSnapshots policy, note the following: Create Snapshot is “true”, indicating that MirrorAllSnapshots creates a Snapshot copy when SnapMirror updates the relationship.
MirrorAllSnapshots has rules “sm_created” and “all_source_snapshots”,
indicating that both the Snapshot copy created by SnapMirror and any Snapshot copies that have been made since the last update are transferred when SnapMirror updates the relationship.
cluster_dst::> snapmirror policy show -policy MirrorAllSnapshots -instance
Vserver: vs0
SnapMirror Policy Name: MirrorAllSnapshots
SnapMirror Policy Type: async-mirror
Policy Owner: cluster-admin
Tries Limit: 8
Transfer Priority: normal
Ignore accesstime Enabled: false
Transfer Restartability: always
Network Compression Enabled: false
Create Snapshot: true
Comment: Asynchronous SnapMirror policy for mirroring all snapshots
and the latest active file system.
Total Number of Rules: 2
Total Keep: 2
Rules: SnapMirror Label Keep Preserve Warn Schedule Prefix
---------------- ---- -------- ---- -------- ------
sm_created 1 false 0 - -
all_source_snapshots 1 false 0 - -MirrorLatest policyThe preconfigured MirrorLatest policy works exactly the same way as MirrorAllSnapshots, except that only the Snapshot copy created by SnapMirror is transferred at initialization and update. Rules: SnapMirror Label Keep Preserve Warn Schedule Prefix
---------------- ---- -------- ---- -------- ------
sm_created 1 false 0 - -SnapMirror Synchronous disaster recovery basicsBeginning with ONTAP 9.7, SnapMirror Synchronous (SM-S)
technology is supported on all ETERNUS HX and ETERNUS AX series that have at least 16 GB of memory. SnapMirror Synchronous technology is a per-node, licensed feature that provides synchronous data replication at the volume level. This functionality addresses the regulatory and national mandates for synchronous replication in financial, healthcare, and other regulated industries where zero data loss is required. The limit on the number of SnapMirror Synchronous replication operations
per HA pair depends on the controller model.
Platform | Number of SnapMirror Synchronous operations that are allowed per HA pair in releases earlier than ONTAP 9.9.1 | Number of SnapMirror Synchronous operations that are allowed per HA pair in ONTAP 9.9.1 | Number of SnapMirror Synchronous operations that are allowed per HA pair in ONTAP 9.10.1 |
|---|
ETERNUS AX
| 80
| 160
| 200
| ETERNUS HX
| 40
| 80
| 80
|
Supported featuresThe following feature is supported for SnapMirror Synchronous technology in ONTAP 9.10.1; provided all nodes in the source and destination cluster are running ONTAP
9.10.1: In ONTAP 9.7 and later, SnapMirror Synchronous technology supports the NFSv3, FC, and iSCSI protocols over all networks for which the latency does not exceed 10ms. The following features are supported for SnapMirror Synchronous technology in ONTAP 9.7: Replication of application-created Snapshot copies Only the Snapshot copies with the SnapMirror label that match the rule associated with Sync or Strict Sync
policy. Scheduled Snapshot copies created using a Snapshot policy are not replicated. FC-NVMe LUN clones and NVMe namespace clones LUN clones backed by application-created Snapshot copies are also supported.
The following features are supported for SnapMirror Synchronous technology in ONTAP 9.7; provided all nodes in the source and destination cluster are running ONTAP 9.7: SVM DR A SnapMirror
Synchronous source can also be a SVM DR source, for example, a fan-out configuration with SM-S as one leg and SVM DR as the other. A SnapMirror Synchronous source cannot be an SVM DR destination because SM-S does not support cascading a DP source. You must release the synchronous relationship before performing an SVM DR flip resync in the destination cluster. A SnapMirror Synchronous destination cannot be an SVM DR source because SVM DR does not support
replication of DP volumes. A flip resync of the synchronous source would result in the SVM DR excluding the DP volume in the destination cluster.
NFSv4.0 and NFSv4.1 SMB 2.0 or later Mixed protocol access(NFSv3 and SMB) Antivirus on the primary volume of the SnapMirror Synchronous relationship Hard or soft quotas on the primary volume of the SnapMirror Synchronous relationship The quota rules
are not replicated to the destination; therefore, the quota database is not replicated to the destination. FPolicy on the primary volume of the SnapMirror Synchronous relationship SnapMirror Synchronous mirror-mirror cascade The relationship from the destination volume of the SnapMirror Synchronous relationship must be an asynchronous SnapMirror relationship. Timestamp parity between source and destination volumes for NAS Removal
of high metadata operation frequency limitation Security for sensitive data in-transit using TLS 1.2 encryption Clone autodelete
Unsupported featuresThe
following features are not supported with Synchronous SnapMirror relationships: MCC SFMoD SFCoD VVol AppDM Mixed SAN and NAS access The primary volume of a SnapMirror Synchronous relationship can either serve NAS data or SAN data. Both SAN and NAS access from the primary volume of a SnapMirror Synchronous relationship is not supported. Mixed SAN and NVMe access LUNs and NVMe
namespaces are not supported on the same volume or SVM. SnapLock volumes FlexGroup volumes FlexCache volumes SnapRestore DP_Optimized (DPO) systems Tape backup or restore using dump and SMTape on the destination volume Tape based restore to the source volume Throughput floor (QoS Min) for source volumes In a fan-out configuration, only one relationship can be a
SnapMirror Synchronous relationship; all the other relationships from the source volume must be asynchronous SnapMirror relationships. Global throttling
Modes of operationSnapMirror
Synchronous has two modes of operation based on the type of the SnapMirror policy used: Sync mode In Sync mode, an I/O to primary storage is first replicated to secondary storage. Then the I/O is written to primary storage, and acknowledgment is sent to the application that issued the I/O. If the write to the secondary storage is not completed for any reason, the application is allowed to continue writing to the primary storage. When the error condition
is corrected, SnapMirror Synchronous technology automatically resynchronizes with the secondary storage and resumes replicating from primary storage to secondary storage in Synchronous mode. In Sync mode, RPO=0 and RTO is very low until a secondary replication failure occurs at which time RPO and RTO become indeterminate, but equal the time to repair the issue that caused secondary replication to fail and for the resync to complete. StrictSync mode SnapMirror
Synchronous can optionally operate in StrictSync mode. If the write to the secondary storage is not completed for any reason, the application I/O fails, thereby ensuring that the primary and secondary storage are identical. Application I/O to the primary resumes only after the SnapMirror relationship returns to the InSync status. If the primary storage fails, application I/O can be resumed on the secondary storage, after failover, with no loss of data. In StrictSync mode RPO is always
zero, and RTO is very low.
Relationship statusThe status of a SnapMirror Synchronous relationship is always in the InSync status during normal operation. If the SnapMirror transfer
fails for any reason, the destination is not in sync with the source and can go to the OutofSync status. For SnapMirror Synchronous relationships, the system automatically checks the relationship status (InSync or OutofSync) at a fixed interval. If the relationship status is OutofSync, ONTAP automatically triggers the auto resync process to bring back the relationship to the InSync status. Auto resync is triggered only if the transfer fails due to any operation, such as unplanned storage
failover at source or destination or a network outage. User-initiated operations such as snapmirror quiesce and snapmirror break do not trigger auto resync. If the relationship status becomes OutofSync for a SnapMirror Synchronous relationship in the StrictSync mode, all I/O operations to the primary volume are stopped. The OutofSync state for SnapMirror Synchronous relationship in the Sync mode is not disruptive to the primary and I/O operations are allowed on the primary volume.
About workloads supported by StrictSync and Sync policiesStrictSync and Sync policies support
all LUN-based applications with FC, iSCSI, and FC-NVMe protocols, as well as NFSv3 and NFSv4 protocols for enterprise applications such as databases, VMWare, quota, SMB, and so on. Beginning with ONTAP 9.7, SnapMirror Synchronous can be used for enterprise file services such as electronic design automation (EDA), home directories, and software build workloads. For a Sync policy, you need to consider a few important aspects while selecting the NFSv3 or NFSv4 workloads. The amount of data
read or write operations by workloads is not a consideration, as Sync policy can handle high read or write IO workloads. Workloads that have excessive file creation, directory creation, file permission changes, or directory permission changes may not be suitable (these are referred to as high-metadata workloads). A typical example of a high-metadata workload is a DevOps workload in which you create multiple test files, run automation, and delete the files. Another example is parallel build
workload that generate multiple temporary files during compilation. The impact of a high rate of write metadata activity is that it can cause synchronization between mirrors to temporarily break which stalls the read and write IOs from the client. Beginning with ONTAP 9.7, these limitations are removed and SnapMirror Synchronous can be used for enterprise file services workloads that include multiuser environments, such as home directories and software build workloads.
Vault archiving using SnapMirror technologySnapMirror vault policies replace SnapVault technology in ONTAP 9.7 and later. You use a
SnapMirror vault policy for disk-to-disk Snapshot copy replication for standards compliance and other governance-related purposes. In contrast to a SnapMirror relationship, in which the destination usually contains only the Snapshot copies currently in the source volume, a vault destination typically retains point-in-time Snapshot copies created over a much longer period. You might want to keep monthly Snapshot copies of your data over a 20-year span, for example, to comply with government
accounting regulations for your business. Since there is no requirement to serve data from vault storage, you can use slower, less expensive disks on the destination system. The figure below illustrates SnapMirror vault data protection relationships. How vault data protection relationships are initializedThe SnapMirror policy for the relationship defines the contents of the baseline and any updates. A baseline
transfer under the default vault policy XDPDefault makes a Snapshot copy of the source volume, then transfers that copy and the data blocks it references to the destination volume. Unlike SnapMirror relationships, a vault backup does not include older Snapshot copies in the baseline. How vault data protection relationships are updatedUpdates are asynchronous, following the schedule you configure. The rules you define in the policy for the relationship identify
which new Snapshot copies to include in updates and how many copies to retain. The labels defined in the policy (“monthly,” for example) must match one or more labels defined in the Snapshot policy on the source. Otherwise, replication fails. At each update under the XDPDefault policy, SnapMirror transfers Snapshot copies that have been made since the last update, provided they have labels matching the labels defined in the policy rules. In the following output from the snapmirror policy show command for
the XDPDefault policy, note the following: Create Snapshot is “false”, indicating that XDPDefault does not create a Snapshot copy when SnapMirror updates the relationship.
XDPDefault has rules “daily” and “weekly”, indicating that all Snapshot copies with matching labels on the source are transferred when SnapMirror updates the relationship.
cluster_dst::> snapmirror policy show -policy XDPDefault -instance
Vserver: vs0
SnapMirror Policy Name: XDPDefault
SnapMirror Policy Type: vault
Policy Owner: cluster-admin
Tries Limit: 8
Transfer Priority: normal
Ignore accesstime Enabled: false
Transfer Restartability: always
Network Compression Enabled: false
Create Snapshot: false
Comment: Default policy for XDP relationships with daily and weekly
rules.
Total Number of Rules: 2
Total Keep: 59
Rules: SnapMirror Label Keep Preserve Warn Schedule Prefix
---------------- ---- -------- ---- -------- ------
daily 7 false 0 - -
weekly 52 false 0 - -SnapMirror unified replication basicsSnapMirror unified replication allows you to configure disaster recovery and archiving on the same destination volume. When unified replication is appropriate,
it offers benefits in reducing the amount of secondary storage you need, limiting the number of baseline transfers, and decreasing network traffic. How unified data protection relationships are initializedAs with SnapMirror, unified data protection performs a baseline transfer the first time you invoke it. The
SnapMirror policy for the relationship defines the contents of the baseline and any updates. A baseline transfer under the default unified data protection policy MirrorAndVault makes a Snapshot copy of the source volume, then transfers that copy and the data blocks it references to the destination volume. Like vault archiving, unified data protection does not include older Snapshot copies in the baseline. How unified data protection relationships are updatedAt each update under the MirrorAndVault policy, SnapMirror creates a Snapshot copy of the source volume and transfers that Snapshot
copy and any Snapshot copies that have been made since the last update, provided they have labels matching the labels defined in the Snapshot policy rules. In the following output from the snapmirror policy show command for the MirrorAndVault policy, note the following: Create Snapshot is “true”, indicating that MirrorAndVault creates a Snapshot copy when SnapMirror updates the relationship.
MirrorAndVault has rules “sm_created”, “daily”, and “weekly”, indicating that both the Snapshot copy created
by SnapMirror and the Snapshot copies with matching labels on the source are transferred when SnapMirror updates the relationship.
cluster_dst::> snapmirror policy show -policy MirrorAndVault -instance
Vserver: vs0
SnapMirror Policy Name: MirrorAndVault
SnapMirror Policy Type: mirror-vault
Policy Owner: cluster-admin
Tries Limit: 8
Transfer Priority: normal
Ignore accesstime Enabled: false
Transfer Restartability: always
Network Compression Enabled: false
Create Snapshot: true
Comment: A unified Synchronous SnapMirror and SnapVault policy for
mirroring the latest file system and daily and weekly snapshots.
Total Number of Rules: 3
Total Keep: 59
Rules: SnapMirror Label Keep Preserve Warn Schedule Prefix
---------------- ---- -------- ---- -------- ------
sm_created 1 false 0 - -
daily 7 false 0 - -
weekly 52 false 0 - -Unified7year policyThe
preconfigured Unified7year policy works exactly the same way as MirrorAndVault, except that a fourth rule transfers monthly Snapshot copies and retains them for seven years. Rules: SnapMirror Label Keep Preserve Warn Schedule Prefix
---------------- ---- -------- ---- -------- ------
sm_created 1 false 0 - -
daily 7 false 0 - -
weekly 52 false 0 - -
monthly 84 false 0 - -Protect against possible data corruptionUnified replication limits the contents of the baseline transfer to the Snapshot copy created by SnapMirror at initialization. At each update, SnapMirror creates
another Snapshot copy of the source and transfers that Snapshot copy and any new Snapshot copies that have labels matching the labels defined in the Snapshot policy rules. You can protect against the possibility that an updated Snapshot copy is corrupted by creating a copy of the last transferred Snapshot copy on the destination. This “local copy” is retained regardless of the retention rules on the source, so that even if the Snapshot originally transferred by SnapMirror is no longer
available on the source, a copy of it will be available on the destination. When to use unified data replicationYou need to weigh the benefit of
maintaining a full mirror against the advantages that unified replication offers in reducing the amount of secondary storage, limiting the number of baseline transfers, and decreasing network traffic. The key factor in determining the appropriateness of unified replication is the rate of change of the active file system. A traditional mirror might be better suited to a volume holding hourly Snapshot copies of database transaction logs, for example. XDP replaces DP as the SnapMirror defaultBeginning with ONTAP 9.7, SnapMirror extended data protection (XDP) mode replaces SnapMirror data
protection (DP) mode as the SnapMirror default. SnapMirror invoked in DP mode and SnapMirror invoked in XDP mode used different replication engines, with different approaches to version-dependence: SnapMirror invoked in DP mode used a version-dependent replication engine in which the ONTAP version was required to be the same on primary and secondary storage: cluster_dst::> snapmirror create -type DP -source-path ... -destination-path ... SnapMirror invoked in XDP mode used a version-flexible
replication engine that supported different ONTAP versions on primary and secondary storage: cluster_dst::> snapmirror create -type XDP -source-path ... -destination-path ...
With improvements in performance, the significant benefits of version-flexible SnapMirror outweigh the slight advantage in replication throughput obtained with version-dependent mode. For this reason, beginning with ONTAP 9.7, XDP mode has been made the new default, and any invocations of DP mode on the command line or in new or existing scripts are automatically
converted to XDP mode. Existing relationships are not affected. If a relationship is already of type DP, it will continue to be of type DP. Beginning with ONTAP 9.7, MirrorAndVault is the new default policy when no data protection mode is specified or when XDP mode is specified as the relationship type. The table below shows the behavior you can expect.
If you specify… | The type is… | The default policy (if you do not specify a policy) is… |
|---|
DP
| XDP
| MirrorAllSnapshots (SnapMirror DR)
| Nothing
| XDP
| MirrorAndVault (unified replication)
| XDP
| XDP
| MirrorAndVault (unified replication)
|
As the table shows, the default policies assigned to XDP in different circumstances ensure that the conversion maintains the functional equivalence of the old types. Of course, you can use different policies as needed, including policies for unified replication:
If you specify… | And the policy is… | The result is… |
|---|
DP
| MirrorAllSnapshots
| SnapMirror DR
| XDPDefault
| SnapVault
| MirrorAndVault
| Unified replication
| XDP
| MirrorAllSnapshots
| SnapMirror DR
| XDPDefault
| SnapVault
| MirrorAndVault
| Unified replication
|
The only exceptions to conversion are as follows: Beginning with ONTAP 9.7, SVM data protection relationships default to XDP mode. Root volume load-sharing data protection relationships continue to default to DP mode. Beginning with ONTAP 9.7, SnapLock data protection relationships default to XDP mode. Explicit invocations of DP continue to default to DP mode if you set the following cluster-wide
option: options replication.create_data_protection_rels.enable on This option is ignored if you do not explicitly invoke DP.
When a destination
volume grows automaticallyDuring a data protection mirror transfer, the destination volume grows automatically in size if the source volume has grown, provided there is available space in the aggregate that contains the volume. This behavior occurs irrespective of any automatic growth setting on the destination. You cannot limit the volume’s growth or prevent ONTAP from growing it. By default, data protection volumes are set to the grow_shrink autosize mode, which
enables the volume to grow or shrink in response to the amount of used space. The max-autosize for data protection volumes is equal to the maximum FlexVol size and is platform dependent. For example: Fan-out and cascade data protection deploymentsYou can use a fan-out deployment to extend data protection to multiple secondary systems. You can use a cascade deployment to extend data protection to
tertiary systems. Both fan-out and cascade deployments support any combination of SnapMirror DR, SnapVault, or unified replication; however, SnapMirror Synchronous relationships (supported beginning with ONTAP 9.7) support only fan-out deployments with one or more asynchronous SnapMirror relationships and do not support cascade deployments. Only one relationship in the fan-out configuration can be a SnapMirror Synchronous relationship, all the other relationships from the source volume
must be asynchronous SnapMirror relationships. SnapMirror Business Continuity (supported beginning with ONTAP 9.8) also supports fan-out configurations.
|
| You can use a fan-in deployment to create data protection relationships between multiple primary systems and a single secondary system. Each relationship must use a different volume on the secondary system.
|
|
| You should be aware that volumes that are part of a fan-out or cascade configuration can take longer to
resynchronize. It is not uncommon to see the SnapMirror relationship reporting
the status "preparing" for an extended time period.
|
How fan-out deployments workSnapMirror supports multiple-mirrors and mirror-vault fan-out deployments. A multiple-mirrors
fan-out deployment consists of a source volume that has a mirror relationship to multiple secondary volumes. A mirror-vault fan-out deployment consists of a source volume that has a mirror relationship to a secondary volume and a SnapVault relationship to a different secondary volume. Beginning with ONTAP 9.7, you can have fan-out deployments with SnapMirror Synchronous relationships; however, only one relationship in the fan-out configuration can be a SnapMirror Synchronous relationship, all the other relationships from the source volume must be asynchronous SnapMirror relationships. How cascade deployments workSnapMirror supports mirror-mirror,
mirror-vault, vault-mirror, and vault-vault cascade deployments. A mirror-mirror cascade deployment consists of a chain of relationships in which a source volume is mirrored to a secondary volume, and the secondary volume is mirrored to a tertiary volume. If the secondary volume becomes unavailable, you can synchronize the relationship between the primary and tertiary volumes without performing a new baseline transfer. Beginning with ONTAP 9.7, SnapMirror
Synchronous relationships are supported in a mirror-mirror cascade deployment. Only the primary and secondary volumes can be in a SnapMirror Synchronous relationship. The relationship between the secondary volumes and tertiary volumes must be asynchronous. A mirror-vault cascade deployment consists of a chain of
relationships in which a source volume is mirrored to a secondary volume, and the secondary volume is vaulted to a tertiary volume. Vault-mirror and, beginning with ONTAP 9.7, vault-vault cascade deployments are also supported: A vault-mirror cascade deployment consists of a chain of
relationships in which a source volume is vaulted to a secondary volume, and the secondary volume is mirrored to a tertiary volume. (Beginning with ONTAP 9.7) A vault-vault cascade deployment consists of a chain of relationships in which a source volume is vaulted to a secondary volume, and the secondary volume is vaulted to a tertiary volume.
SnapMirror licensing overviewBeginning with ONTAP 9.7, licensing has been simplified for replicating between ONTAP instances. In ONTAP 9 releases, the SnapMirror license supports both vault and mirror relationships. Users
can now purchase a SnapMirror license to support ONTAP replication for both backup and disaster recovery use cases. A SnapVault license was needed to configure vault relationships between ONTAP instances, where the DP instance could retain a higher number of Snapshot copies to support backup use cases where retention times are longer. A SnapMirror license was needed to configure mirror relationships between ONTAP instances, where each ONTAP instance would maintain the
same number of snapshot copies (that is, a mirror image) to support disaster recovery use cases where cluster failovers would be possible. Both SnapMirror and SnapVault licenses can continue to be used and supported for ONTAP 9.x releases. SnapVault licenses continue to function and are supported for ONTAP 9.x releases, but they are no longer being sold. The SnapMirror license continues to be available and can be used in place of SnapVault and can be used for both mirror and vault
configurations. For ONTAP asynchronous replication, beginning with ONTAP 9.7 a single unified replication engine is used to configure extended data protection mode (XDP) policies, where the SnapMirror license can be configured for a mirror policy, a vault policy, or a mirror-vault policy. A SnapMirror license is required on both the source and destination clusters. A SnapVault license is not required if a SnapMirror license is already installed. Data protection configuration limits
are determined using several factors, including your ONTAP version, hardware platform, and the licenses installed. SnapMirror Synchronous licenseBeginning with ONTAP 9.7,
SnapMirror Synchronous relationships are supported. You require the following licenses for creating a SnapMirror Synchronous relationship: The SnapMirror Synchronous license is required on both the source cluster and the destination cluster. The SnapMirror Synchronous license is enabled with either the Premium bundle or the Data Protection bundle. The SnapMirror license is required on both the source cluster and the destination cluster.
SnapMirror Cloud licenseBeginning with ONTAP 9.8, the SnapMirror Cloud license provides asynchronous replication of Snapshot copies from ONTAP instances to object storage endpoints.
Replication targets can be configured using both on-premises object stores as well as S3 and S3-compatible public cloud object storage services. SnapMirror Cloud relationships are supported from ONTAP systems to pre-qualified object storage targets. ONTAP 9.8 approved object storage targets include ONTAP S3, AWS S3 Standard, S3 Standard-IA, and S3 One Zone-IA, Microsoft Azure Blob Premium, Hot and Cool, and GCP Standard and Nearline storage. SnapMirror Cloud is not available as a
standalone license and is available only with purchase of the Hybrid Cloud Bundle. Beginning with ONTAP 9.8, the Hybrid Cloud Bundle includes licenses for both SnapMirror Cloud and FabricPool. Similarly, the SnapMirror license is not available as a standalone license and is available only with purchase of the Data Protection Bundle. You require the following licenses for creating a SnapMirror Cloud relationship: Both a SnapMirror license (purchased through Data
Protection Bundle, or through Premium Bundle) and a SnapMirror Cloud license (purchased through Hybrid Cloud Bundle) is replicating directly to the object store endpoint. When configuring a multi-policy replication workflow (for example, Disk-to-Disk-to-Cloud), a SnapMirror license is required on all ONTAP instances, while the SnapMirror Cloud license is only required for the source cluster which is replicating directly to the object storage endpoint.
SnapMirror
Cloud is an end user license which can be purchased from Fujitsu or from an approved Fujitsu reseller partner. The SnapMirror Cloud license provides end user entitlement but does not enable asynchronous ONTAP to object storage replication. To invoke ONTAP APIs for SnapMirror Cloud, a unique API key from an authorized application is required. Authorized and licensed applications used to orchestrate SnapMirror Cloud replication include ONTAP System Manager, and are also available from multiple
third-party application providers. These authorized applications will embed the unique API key to invoke ONTAP APIs. A combination of the SnapMirror Cloud end user license and an authorized third-party backup application is required to orchestrate and enable SnapMirror Cloud replication. A list of authorized SnapMirror Cloud third-party applications is published on the Fujitsu web site. Data Protection BundleBeginning with ONTAP 9.7, new ONTAP data protection features were packaged with the HX6100 as part of a solution called the Data Protection Bundle. This new hardware and software bundle included a new DP_Optimized (DPO)
license that provided unique ONTAP features for secondary workloads. With the introduction of ONTAP 9.7 the DPO license increased the number of volumes per node from 1,000 to 1,500. The DPO license was specifically designed for ONTAP clusters that were to be dedicated as secondary targets for SnapMirror replication. In addition to increasing the maximum volumes per node on the DPO controller, the DPO license also modified controller QoS settings to support greater replication traffic at
the expense of application I/O. For this reason, the DPO license should never be installed on a cluster that supports application I/O, as application performance would be impacted. Later, Data Protection Bundles based on the HX6100 were offered as a solution and included programmatic free licenses based on the customer environment. When purchasing the solution bundles, free SnapMirror licenses would be provided for select older clusters which replicated to the DPO secondary. Data Protection Optimized (DPO) LicenseData Protection hardware and software solution bundles were based on HX6100 only. As these platforms matured and new
platforms were introduced new requests to support ONTAP features for secondary replication use cases increased. The standalone DPO license was supported on both ETERNUS HX and ETERNUS AX series and could be purchased pre-configured with new clusters or added to deployed clusters as a software upgrade in the field. Because these new DPO licenses were not part of a hardware and software solution bundle they carried a lower price and free SnapMirror licenses for primary clusters were not
provided. Secondary clusters configured with the a la carte DPO license must also purchase a SnapMirror license, and all primary clusters replicating to the DPO secondary cluster must purchase a SnapMirror license. Additional ONTAP features were delivered with the DPO across multiple ONTAP releases.
Feature | 9.7+ |
|---|
Max vols/node
| 1500/2500
| Max concurrent repl sessions
| 200
| Workload bias*
| SnapMirror
| Cross volume aggregate deduplication for HDD
| Yes
|
Details about priority for the SnapMirror backoff (workload bias) feature: Client: cluster I/O priority is set to client workloads (production apps), not SnapMirror traffic. Equality: SnapMirror replication requests have equal priority to I/O for production apps. SnapMirror: all SnapMirror I/O requests have higher priority that I/O for production apps.
Table 1: Max FlexVolumes per
node across ONTAP releases
| 9.7—9.9.1 Without DPO | 9.7—9.9.1 With DPO |
|---|
HX2100
| 1000
| 1500
| HX2200
| 1000
| 1500
| AX2100
| 1000
| 1500
| HX6100
| 1000
| 2500
| AX4100
| 2500
| 2500
|
Considerations for all new DPO installationsAfter it is enabled, the DPO license feature
cannot be disabled or undone. Installation of the DPO license requires a re-boot of ONTAP or failover to enable. The DPO solution is intended for secondary storage workloads; application workload performance on DPO clusters may be impacted The DPO license is supported on a select list of Fujitsu storage platform models. DPO features vary by ONTAP release. Refer to the compatibility table for reference.
Install a SnapMirror Cloud licenseBeginning with ONTAP 9.8, SnapMirror Cloud provides asynchronous snapshot replication from ONTAP to object storage
endpoints. SnapMirror Cloud relationships can only be configured using pre-qualified third-party backup applications. To configure ONTAP to object storage replication, both SnapMirror and SnapMirror Cloud licenses are required on the ONTAP source cluster configured for replication to the object store endpoint. About this task The SnapMirror Cloud license is a single-instance cluster-wide license, which means it does not need to be installed on every node in the cluster. It is a
term-based license where both term and backup capacity are enforced. In addition to this end user license, SnapMirror Cloud requires an authorized and approved backup application to configure and invoke ONTAP APIs for replication. Both SnapMirror Cloud end user license and authorized app are necessary to utilize SnapMirror Cloud replication. SnapMirror Cloud licenses are acquired through purchase of the Hybrid Cloud Bundle, which can be purchased with 1 or 3 year terms in 1 TB
increments. The Hybrid Cloud Bundle includes a license for SnapMirror Cloud. Each license has a unique serial number. Purchases of the Hybrid Cloud Bundle are based on capacity, where the purchased capacity of the Hybrid Cloud Bundle is applied to the SnapMirror Cloud license. The SnapMirror Cloud license can be installed on the cluster using the ONTAP command line or ONTAP System Manager. Steps Download two License File for SnapMirror Cloud from the DVD included
in the Product. Use ONTAP System Manager to upload the SnapMirror Cloud License File to the cluster: Click Configuration > Licenses. In the Cluster Settings pane, click Licenses. In the Packages window, click Add. In the Add License Packages dialog box, click Choose Files
to select the License File you downloaded, and then click Add to upload the file to the cluster.
DPO systems feature
enhancementsBeginning with ONTAP 9.7, the maximum number of FlexVol volumes supported increases when the DP_Optimized (DPO) license is installed. Beginning with ONTAP 9.7, systems with the DPO license support SnapMirror backoff, cross-volume background deduplication, cross-volume inline deduplication, use of Snapshot blocks as donors, and compaction. Beginning with ONTAP 9.7, the maximum supported number of FlexVol volumes on secondary or data protection systems has
increased, enabling you to scale up to 2,500 FlexVol volumes per node, or up to 5,000 in failover mode. The increase in FlexVol volumes is enabled with the DP_Optimized (DPO) license. A SnapMirror license is still required on both the source and destination nodes. Beginning with ONTAP 9.7, the following feature enhancements are made to DPO systems: SnapMirror backoff: In DPO systems, replication traffic is given the same priority that client workloads are given. SnapMirror
backoff is disabled by default on DPO systems. Volume background deduplication and cross-volume background deduplication: Volume background deduplication and cross-volume background deduplication are enabled in DPO systems. You can run the storage aggregate efficiency cross-volume-dedupe start -aggregate aggregate_name -scan-old-data true command to deduplicate the existing data. The best practice is to run the command during off-peak hours to reduce the impact on performance. Increased savings by using Snapshot blocks as donors: The data blocks that
are not available in the active file system but are trapped in Snapshot copies are used as donors for volume deduplication. The new data can be deduplicated with the data that was trapped in Snapshot copies, effectively sharing the Snapshot blocks as well. The increased donor space provides more savings, especially when the volume has a large number of Snapshot copies. Compaction: Data compaction is enabled by default on DPO volumes.
SnapMirror replication workflowSnapMirror offers three types of data protection relationship: SnapMirror DR, archive (previously known as SnapVault), and unified replication.
You can follow the same basic workflow to configure each type of relationship. Beginning with general availability in ONTAP 9.9.1, SnapMirror Business Continuity (SM-BC) provides Zero Recovery Time Objective (Zero RTO) or Transparent Application Failover (TAF) to enable automatic failover of business-critical applications in SAN environments. SM-BC is supported in a configuration of either two ETERNUS AX clusters or two All SAN Array (ASA) clusters. For each type of SnapMirror data
protection relationship, the workflow is the same: create a destination volume, create a job schedule, specify a policy, create and initialize the relationship. Beginning with ONTAP 9.7, you can use the snapmirror protect command to configure a data protection relationship in a single step. Even if you use snapmirror protect, you need to understand each step in the workflow. Beginning with ONTAP 9.7, you can use the snapmirror protect command to configure a data protection relationship in a single step. You specify a
list of volumes to be replicated, an SVM on the destination cluster, a job schedule, and a SnapMirror policy. snapmirror protect does the rest. What you’ll need About this task The snapmirror protect command chooses an aggregate associated with the specified SVM. If no aggregate is
associated with the SVM, it chooses from all the aggregates in the cluster. The choice of aggregate is based on the amount of free space and the number of volumes on the aggregate. The snapmirror protect command then performs the following steps: Creates a destination volume with an appropriate type and amount of reserved space for each volume in the list of volumes to be replicated. Configures a replication relationship appropriate for the policy you
specify. Initializes the relationship.
The name of the destination volume is of the form source_volume_name_dst. In case of a conflict with an existing name, the command appends a number to the volume name. You can specify a prefix and/or suffix in the command options. The suffix replaces the system-supplied dst suffix. In ONTAP 9.7 and later, a destination volume can contain up to 1019 Snapshot copies.
|
| Initialization can be time-consuming. snapmirror protect does not wait for initialization to complete before the job finishes. For this reason, you should use the snapmirror show command rather than the job show command to determine when initialization is complete.
|
Beginning with ONTAP 9.7, SnapMirror Synchronous relationships can be created by using the snapmirror protect command. Step Create and initialize a replication relationship in one step: snapmirror protect -path-list SVM:volume|cluster://SVM/volume, … -destination-vserver destination_SVM -policy policy -schedule schedule -auto-initialize true|false -destination-volume-prefix prefix -destination-volume-suffix suffix
|
| You must run this command from the destination SVM or the destination cluster. The -auto-initialize option defaults to “true”.
|
The following example creates and initializes a SnapMirror DR relationship using the default MirrorAllSnapshots policy: cluster_dst::> snapmirror protect -path-list svm1:volA, svm1:volB -destination-vserver svm_backup -policy MirrorAllSnapshots -schedule replication_daily The following example creates and initializes a SnapVault relationship using the default XDPDefault policy: cluster_dst::> snapmirror protect -path-list svm1:volA, svm1:volB -destination-vserver svm_backup -policy XDPDefault -schedule replication_daily The following example creates and initializes a unified replication relationship using the default MirrorAndVault policy: cluster_dst::> snapmirror protect -path-list svm1:volA, svm1:volB -destination-vserver svm_backup -policy MirrorAndVault The following example creates and initializes a SnapMirror
Synchronous relationship using the default Sync policy: cluster_dst::> snapmirror protect -path-list svm1:volA, svm1:volB -destination-vserver svm_sync -policy Sync
After you finish Use the snapmirror show command to verify that the SnapMirror relationship was created. For complete command syntax, see the man page. Create a destination volumeYou can use the volume create command on the destination to create a destination volume. The destination volume should be the same or greater in size than the source volume. Step Create
a destination volume: volume create -vserver SVM -volume volume -aggregate aggregate -type DP -size size
For complete command syntax, see the man page. The following example creates a 2-GB destination volume named volA_dst: cluster_dst::> volume create -vserver SVM_backup -volume volA_dst -aggregate node01_aggr -type DP -size 2GB
Create a replication job scheduleYou can use the job schedule cron create command to create a replication job schedule. The job schedule determines when SnapMirror automatically updates the data protection relationship to
which the schedule is assigned. About this task You assign a job schedule when you create a data protection relationship. If you do not assign a job schedule, you must update the relationship manually. Step Create a job schedule: job schedule cron create -name job_name -month month -dayofweek day_of_week -day day_of_month -hour hour -minute minute
For -month, -dayofweek, and -hour, you can specify all to run the job every month, day of the week, and hour, respectively. Beginning with ONTAP 9.10.1, you can include the Vserver for
your job schedule: job schedule cron create -name job_name -vserver Vserver_name -month month -dayofweek day_of_week -day day_of_month -hour hour -minute minute
The following example creates a job schedule named my_weekly that runs on Saturdays at 3:00 a.m.: cluster_dst::> job schedule cron create -name my_weekly -dayofweek "Saturday" -hour 3 -minute 0
Create a custom replication policyYou can create a custom replication policy if the default policy for a relationship is not suitable. You might want to compress data in a network transfer, for example,
or modify the number of attempts SnapMirror makes to transfer Snapshot copies. You can use a default or custom policy when you create a replication relationship. For a custom archive (formerly SnapVault) or unified replication policy, you must define one or more rules that determine which Snapshot copies are transferred during initialization and update.You might also want to define a schedule for creating local Snapshot copies on the destination. The policy type of
the replication policy determines the type of relationship it supports. The table below shows the available policy types.
Policy type | Relationship type |
|---|
async-mirror
| SnapMirror DR
| vault
| SnapVault
| mirror-vault
| Unified replication
| strict-sync-mirror
| SnapMirror Synchronous in the StrictSync mode (supported beginning with ONTAP 9.7)
| sync-mirror
| SnapMirror Synchronous in the Sync mode (supported beginning with ONTAP 9.7)
|
|
| When you create a custom replication policy, it is a good idea to model the policy after a default policy.
|
Step Create a custom replication policy: snapmirror policy create -vserver SVM -policy policy -type async-mirror|vault|mirror-vault|strict-sync-mirror|sync-mirror -comment comment -tries transfer_tries -transfer-priority low|normal -is-network-compression-enabled true|false
For complete command syntax, see the man page. Beginning with ONTAP 9.7, you can specify the schedule for creating a common Snapshot copy schedule for SnapMirror Synchronous relationships by using the -common-snapshot-schedule parameter. By default, the common Snapshot copy schedule for SnapMirror Synchronous relationships is one hour. You can specify a value from 30 minutes to two hours for the
Snapshot copy schedule for SnapMirror Synchronous relationships. The following example creates a custom replication policy for SnapMirror DR that enables network compression for data transfers: cluster_dst::> snapmirror policy create -vserver svm1 -policy DR_compressed -type async-mirror -comment “DR with network compression enabled” -is-network-compression-enabled true The following example creates a custom replication policy for SnapVault: cluster_dst::> snapmirror policy create -vserver svm1 -policy my_snapvault -type vault The following example creates a custom replication policy for unified replication: cluster_dst::> snapmirror policy create -vserver svm1 -policy my_unified -type mirror-vault The following example creates a custom replication policy for SnapMirror
Synchronous relationship in the StrictSync mode: cluster_dst::> snapmirror policy create -vserver svm1 -policy my_strictsync -type strict-sync-mirror -common-snapshot-schedule my_sync_schedule
After you finish For “vault” and “mirror-vault” policy types, you must define rules that determine which Snapshot copies are transferred during initialization and update. Use the snapmirror policy show command to verify that the SnapMirror policy was created. For complete command syntax, see the man page. Define a rule for a policyFor custom policies with the “vault” or “mirror-vault” policy type, you must define at least one rule that determines which Snapshot copies are transferred during initialization
and update. You can also define rules for default policies with the “vault” or “mirror-vault” policy type. About this task Every policy with the “vault” or “mirror-vault” policy type must have a rule that specifies which Snapshot copies to replicate. The rule “bi-monthly”, for example, indicates that only Snapshot copies assigned the SnapMirror label “bi-monthly” should be replicated. You specify the SnapMirror label when you configure the Snapshot policy on the source.
Each policy type is associated with one or more system-defined rules. These rules are automatically assigned to a policy when you specify its policy type. The table below shows the system-defined rules.
System-defined rule | Used in policy types | Result |
|---|
sm_created
| async-mirror, mirror-vault, Sync, StrictSync
| A Snapshot copy created by SnapMirror is transferred on initialization and update.
| all_source_snapshots
| async-mirror
| New Snapshot copies on the source are transferred on initialization and update.
| daily
| vault,mirror-vault
| New Snapshot copies on the source with the SnapMirror label “daily” are transferred on initialization and update.
| weekly
| vault,mirror-vault
| New Snapshot copies on the source with the SnapMirror label “weekly” are transferred on initialization and update.
| monthly
| mirror-vault
| New Snapshot copies on the source with the SnapMirror label “monthly” are transferred on initialization and update.
| app_consistent
| Sync, StrictSync
| Snapshot copies with the SnapMirror label “app_consistent” on source are synchronously replicated to the destination. Supported Beginning with ONTAP 9.7.
|
Except for the “async-mirror” policy type, you can specify additional rules as needed, for default or custom policies. For example: For the default MirrorAndVault policy, you might create a rule called “bi-monthly” to match Snapshot copies on the source with the “bi-monthly” SnapMirror label. For a custom policy with the “mirror-vault” policy type, you might create a rule called “bi-weekly” to match Snapshot copies on the source with the
“bi-weekly” SnapMirror label.
Step Define a rule for a policy: snapmirror policy add-rule -vserver SVM -policy policy_for_rule -snapmirror-label snapmirror-label -keep retention_count
For complete command syntax, see the man page. The following example adds a rule with the SnapMirror label bi-monthly to the default MirrorAndVault policy: cluster_dst::> snapmirror policy add-rule -vserver svm1 -policy MirrorAndVault -snapmirror-label bi-monthly -keep 6 The following example adds a rule with the SnapMirror label bi-weekly to the custom my_snapvault policy: cluster_dst::> snapmirror policy add-rule -vserver svm1 -policy my_snapvault -snapmirror-label bi-weekly -keep 26 The following example adds a rule with the SnapMirror label app_consistent to
the custom Sync policy: cluster_dst::> snapmirror policy add-rule -vserver svm1 -policy Sync -snapmirror-label app_consistent -keep 1 You can then replicate Snapshot copies from the source cluster that match this SnapMirror label: cluster_src::> snapshot create -vserver vs1 -volume vol1 -snapshot snapshot1 -snapmirror-label app_consistent
Define a schedule for creating a local copy on the destinationFor SnapVault and unified replication relationships, you can protect against the possibility that an updated Snapshot
copy is corrupted by creating a copy of the last transferred Snapshot copy on the destination. This “local copy” is retained regardless of the retention rules on the source, so that even if the Snapshot originally transferred by SnapMirror is no longer available on the source, a copy of it will be available on the destination. About this task You specify the schedule for creating a local copy in the -schedule option of the snapmirror policy add-rule command. Step Define
a schedule for creating a local copy on the destination: snapmirror policy add-rule -vserver SVM -policy policy_for_rule -snapmirror-label snapmirror-label -schedule schedule
The following example adds a schedule for creating a local copy to the default MirrorAndVault policy: cluster_dst::> snapmirror policy add-rule -vserver svm1 -policy MirrorAndVault -snapmirror-label my_monthly -schedule my_monthly The following example adds a schedule for creating a local copy to the custom my_unified policy: cluster_dst::> snapmirror policy add-rule -vserver svm1 -policy my_unified -snapmirror-label my_monthly -schedule my_monthly
Create a replication relationshipThe relationship between the source volume in primary storage and the destination volume in secondary storage is called a data protection
relationship. You can use the snapmirror create command to create SnapMirror DR, SnapVault, or unified replication data protection relationships. What you’ll need About this task SnapMirror invoked in DP mode and SnapMirror invoked in XDP mode used different replication
engines, with different approaches to version-dependence: SnapMirror invoked in DP mode used a version-dependent replication engine in which the ONTAP version was required to be the same on primary and secondary storage: cluster_dst::> snapmirror create -type DP -source-path ... -destination-path ... SnapMirror invoked in XDP mode used a version-flexible replication engine that supported different ONTAP versions on primary and secondary storage: cluster_dst::> snapmirror create -type XDP -source-path ... -destination-path ...
With
improvements in performance, the significant benefits of version-flexible SnapMirror outweigh the slight advantage in replication throughput obtained with version-dependent mode. For this reason, beginning with ONTAP 9.7, XDP mode has been made the new default, and any invocations of DP mode on the command line or in new or existing scripts are automatically converted to XDP mode. Existing relationships are not affected. If a relationship is already of type DP, it will continue to be of
type DP. The table below shows the behavior you can expect.
If you specify… | The type is… | The default policy (if you do not specify a policy) is… |
|---|
DP
| XDP
| MirrorAllSnapshots (SnapMirror DR)
| Nothing
| XDP
| MirrorAllSnapshots (SnapMirror DR)
| XDP
| XDP
| XDPDefault (SnapVault)
|
See also the examples in the procedure below. The only exceptions to conversion are as follows: SVM data protection relationships continue to default to DP mode. Specify XDP explicitly to obtain XDP mode with the default MirrorAllSnapshots policy. Load-sharing data protection relationships continue to default to DP mode. SnapLock data protection relationships continue to default to DP mode. Explicit
invocations of DP continue to default to DP mode if you set the following cluster-wide option: options replication.create_data_protection_rels.enable on This option is ignored if you do not explicitly invoke DP.
In ONTAP 9.7 and later, a destination volume can contain up to 1019 Snapshot copies. Beginning with ONTAP 9.7, SnapMirror Synchronous relationships are supported. Step From the destination cluster, create a replication relationship: snapmirror create -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, … -type DP|XDP -schedule schedule -policy policy
For complete
command syntax, see the man page.
|
| The schedule parameter is not applicable when creating SnapMirror Synchronous relationships.
|
The following example creates a SnapMirror DR relationship using the default MirrorLatest policy: cluster_dst::> snapmirror create -source-path svm1:volA -destination-path svm_backup:volA_dst -type XDP -schedule my_daily -policy MirrorLatest The following example creates a SnapVault relationship using the default XDPDefault policy: cluster_dst::> snapmirror create -source-path svm1:volA -destination-path svm_backup:volA_dst -type XDP -schedule my_daily -policy XDPDefault The following example creates a unified replication relationship using the default MirrorAndVault policy: cluster_dst:> snapmirror create -source-path svm1:volA -destination-path svm_backup:volA_dst -type XDP -schedule my_daily -policy MirrorAndVault The following example creates a unified replication relationship using the custom my_unified policy: cluster_dst::> snapmirror create -source-path svm1:volA -destination-path svm_backup:volA_dst -type XDP -schedule my_daily -policy my_unified
The following example creates a SnapMirror Synchronous relationship using the default Sync policy: cluster_dst::> snapmirror create -source-path svm1:volA -destination-path svm_backup:volA_dst -type XDP -policy Sync The following example creates a SnapMirror Synchronous relationship using the default StrictSync policy: cluster_dst::> snapmirror create -source-path svm1:volA -destination-path svm_backup:volA_dst -type XDP -policy StrictSync The following example creates a SnapMirror DR relationship. With the DP type automatically converted to XDP and with no policy specified, the policy defaults to the MirrorAllSnapshots policy: cluster_dst::> snapmirror create -source-path svm1:volA -destination-path svm_backup:volA_dst -type DP -schedule my_daily The following example creates a
SnapMirror DR relationship. With no type or policy specified, the policy defaults to the MirrorAllSnapshots policy: cluster_dst::> snapmirror create -source-path svm1:volA -destination-path svm_backup:volA_dst -schedule my_daily The following example creates a SnapMirror DR relationship. With no policy specified, the policy defaults to the XDPDefault policy: cluster_dst::> snapmirror create -source-path svm1:volA -destination-path svm_backup:volA_dst -type XDP -schedule my_daily The following example creates a SnapMirror Synchronous relationship with the predefined policy SnapCenterSync: cluster_dst::> snapmirror create -source-path svm1:volA -destination-path svm_backup:volA_dst -type XDP -policy SnapCenterSync
|
| The predefined policy SnapCenterSync is of type Sync. This policy replicates any Snapshot copy that is created with the snapmirror-label of "app_consistent".
|
After you finish Use the snapmirror show command to verify that the SnapMirror relationship was created. For complete command syntax, see the man page. Initialize a replication relationshipFor all relationship types, initialization performs a baseline transfer: it makes a Snapshot copy of the source volume, then transfers that copy and all the
data blocks it references to the destination volume. Otherwise, the contents of the transfer depend on the policy. What you’ll need The source and destination clusters and SVMs must be peered. About this task Initialization can be time-consuming. You might want to run the baseline transfer in off-peak hours. Beginning with ONTAP 9.7, SnapMirror Synchronous relationships are supported. Step Initialize a replication
relationship: snapmirror initialize -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster.
|
The following example initializes the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup: cluster_dst::> snapmirror initialize -source-path svm1:volA -destination-path svm_backup:volA_dst
An example will show in concrete terms how you can configure replication relationships one step at a time. You can use the vault-vault cascade deployment
configured in the example to retain more than 251 Snapshot copies labeled “my-weekly”. What you’ll need About this task The example assumes the following: You have configured Snapshot copies on the source cluster with the SnapMirror
labels “my-daily”, “my-weekly”, and “my-monthly”. You have configured destination volumes named “volA” on the secondary and tertiary destination clusters. You have configured replication job schedules named “my_snapvault” on the secondary and tertiary destination clusters.
The example shows how to create replication relationships based on two custom policies: The “snapvault_secondary” policy retains 7 daily, 52 weekly, and
180 monthly Snapshot copies on the secondary destination cluster. The “snapvault_tertiary policy” retains 250 weekly Snapshot copies on the tertiary destination cluster.
Steps On the secondary destination cluster, create the “snapvault_secondary” policy: cluster_secondary::> snapmirror policy create -policy snapvault_secondary -type vault -comment “Policy on secondary for vault to vault cascade” -vserver svm_secondary
On the secondary destination cluster, define the “my-daily” rule for the policy: cluster_secondary::> snapmirror policy add-rule -policy snapvault_secondary -snapmirror-label my-daily -keep 7 -vserver svm_secondary
On the secondary destination cluster, define the
“my-weekly” rule for the policy: cluster_secondary::> snapmirror policy add-rule -policy snapvault_secondary -snapmirror-label my-weekly -keep 52 -vserver svm_secondary
On the secondary destination cluster, define the “my-monthly” rule for the policy: cluster_secondary::> snapmirror policy add-rule -policy snapvault_secondary -snapmirror-label my-monthly -keep 180 -vserver svm_secondary
On the secondary destination cluster, verify the policy: cluster_secondary::> snapmirror policy show snapvault_secondary -instance
Vserver: svm_secondary
SnapMirror Policy Name: snapvault_secondary
SnapMirror Policy Type: vault
Policy Owner: cluster-admin
Tries Limit: 8
Transfer Priority: normal
Ignore accesstime Enabled: false
Transfer Restartability: always
Network Compression Enabled: false
Create Snapshot: false
Comment: Policy on secondary for vault to vault cascade
Total Number of Rules: 3
Total Keep: 239
Rules: SnapMirror Label Keep Preserve Warn Schedule Prefix
---------------- ---- -------- ---- -------- ------
my-daily 7 false 0 - -
my-weekly 52 false 0 - -
my-monthly 180 false 0 - -On the secondary destination cluster, create the relationship with the source cluster: cluster_secondary::> snapmirror create -source-path svm_primary:volA -destination-path svm_secondary:volA -type XDP -schedule my_snapvault -policy snapvault_secondary
On the secondary destination cluster, initialize the relationship with the source cluster: cluster_secondary::> snapmirror initialize -source-path svm_primary:volA -destination-path svm_secondary:volA
On the tertiary destination cluster, create the “snapvault_tertiary” policy: cluster_tertiary::> snapmirror policy create -policy snapvault_tertiary -type vault -comment “Policy on tertiary for vault to vault cascade” -vserver svm_tertiary
On the tertiary destination cluster, define the “my-weekly” rule for the policy: cluster_tertiary::> snapmirror policy add-rule -policy snapvault_tertiary -snapmirror-label my-weekly -keep 250 -vserver svm_tertiary
On the tertiary destination cluster, verify the policy: cluster_tertiary::> snapmirror policy show snapvault_tertiary -instance
Vserver: svm_tertiary
SnapMirror Policy Name: snapvault_tertiary
SnapMirror Policy Type: vault
Policy Owner: cluster-admin
Tries Limit: 8
Transfer Priority: normal
Ignore accesstime Enabled: false
Transfer Restartability: always
Network Compression Enabled: false
Create Snapshot: false
Comment: Policy on tertiary for vault to vault cascade
Total Number of Rules: 1
Total Keep: 250
Rules: SnapMirror Label Keep Preserve Warn Schedule Prefix
---------------- ---- -------- ---- -------- ------
my-weekly 250 false 0 - -On the tertiary destination cluster, create the relationship with the secondary cluster: cluster_tertiary::> snapmirror create -source-path svm_secondary:volA -destination-path svm_tertiary:volA -type XDP -schedule my_snapvault -policy snapvault_tertiary
On the tertiary destination cluster,
initialize the relationship with the secondary cluster: cluster_tertiary::> snapmirror initialize -source-path svm_secondary:volA -destination-path svm_tertiary:volA
Convert an existing DP-type
relationship to XDPYou can easily convert an existing DP-type relationship to XDP to take advantage of version-flexible SnapMirror. About this task SnapMirror does not automatically convert existing DP-type relationships to XDP. To convert the relationship, you need to break and delete the existing relationship, create a new XDP relationship, and resync the relationship. For background information, see
XDP replaces DP as the SnapMirror default. When planning your conversion, you should be aware that background preparation and the data warehousing phase of an XDP SnapMirror relationship can take a long time. It is not uncommon to see the SnapMirror relationship reporting the status "preparing" for an extended time period.
|
| After you convert a SnapMirror relationship type from DP to XDP, space-related settings, such as autosize and space guarantee are no longer replicated to the destination.
|
Steps Quiesce the existing DP-type relationship: snapmirror quiesce -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster.
|
The following example quiesces the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup: cluster_dst::> snapmirror quiesce -source-path svm1:volA -destination-path svm_backup:volA_dst Break the existing DP-type relationship: snapmirror break -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster.
|
The following example breaks the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup: cluster_dst::> snapmirror break -source-path svm1:volA -destination-path svm_backup:volA_dst Disable automatic deletion of Snapshot copies on the destination volume: volume snapshot autodelete modify -vserver SVM -volume volume -enabled false
The following example disables Snapshot copy autodelete on the destination volume volA_dst: cluster_dst::> volume snapshot autodelete modify -vserver svm_backup -volume volA_dst -enabled false Delete the existing DP-type relationship: snapmirror delete -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete
command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster.
|
The following example deletes the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup: cluster_dst::> snapmirror delete -source-path svm1:volA -destination-path svm_backup:volA_dst Create the new XDP-type relationship: snapmirror create -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, … -type XDP -schedule schedule -policy policy
The new relationship must use the same source and destination volume. For complete command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster.
|
The following example creates a SnapMirror DR relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup using the default MirrorAllSnapshots policy: cluster_dst::> snapmirror create -source-path svm1:volA -destination-path svm_backup:volA_dst
-type XDP -schedule my_daily -policy MirrorAllSnapshots Resync the source and destination volumes: snapmirror resync -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster. Although resync does not require a baseline transfer, it can be time-consuming. You might want to run the resync in off-peak hours.
|
The following example resyncs the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup: cluster_dst::> snapmirror resync -source-path svm1:volA -destination-path svm_backup:volA_dst
After you finish Use the snapmirror show command to verify that the SnapMirror relationship was created. For complete command syntax, see the man page. Convert the type of a SnapMirror relationshipBeginning with ONTAP 9.7, SnapMirror Synchronous is supported. You can convert an asynchronous SnapMirror relationship to a SnapMirror
Synchronous relationship or vice versa without performing a baseline transfer. About this task You cannot convert an asynchronous SnapMirror relationship to a SnapMirror Synchronous relationship or vice versa by changing the SnapMirror policy Steps Convert the mode of a SnapMirror Synchronous relationshipBeginning with ONTAP 9.7, SnapMirror Synchronous relationships are supported. You can convert the mode of a
SnapMirror Synchronous relationship from StrictSync to Sync or vice versa. About this task You cannot modify the policy of a Snapmirror Synchronous relationship to convert its mode. Steps From the destination cluster, quiesce the existing SnapMirror Synchronous relationship: snapmirror quiesce -destination-path dest_SVM:dest_volume
cluster2::> snapmirror quiesce -destination-path vs1_dr:vol1 From the destination cluster, delete the existing SnapMirror Synchronous relationship: snapmirror delete -destination-path dest_SVM:dest_volume
cluster2::> snapmirror delete -destination-path vs1_dr:vol1 From the source cluster, release the SnapMirror relationship without deleting the common Snapshot copies: snapmirror release -relationship-info-only true -destination-path dest_SVM:dest_volume
cluster1::> snapmirror release -relationship-info-only true -destination-path vs1_dr:vol1 From the destination cluster, create a SnapMirror Synchronous relationship by specifying the mode to which you want to convert the SnapMirror Synchronous relationship: snapmirror create -source-path vs1:vol1 -destination-path dest_SVM:dest_volume -policy Sync|StrictSync
cluster2::> snapmirror create -source-path vs1:vol1 -destination-path vs1_dr:vol1 -policy Sync From the destination cluster, resynchronize the SnapMirror relationship: snapmirror resync -destination-path dest_SVM:dest_volume
cluster2::> snapmirror resync -destination-path vs1_dr:vol1
Make the destination volume writeableYou need to make the destination volume
writeable before you can serve data from the volume to clients. You can use the snapmirror quiesce command to stop scheduled transfers to the destination, the snapmirror abort command to stop ongoing transfers, and the snapmirror break command to make the destination writeable. About this task You must perform this task from the destination SVM or the destination cluster. Steps Stop scheduled transfers to the destination: snapmirror quiesce -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax,
see the man page. The following example stops scheduled transfers between the source volume volA on svm1 and the destination volume volA_dst on svm_backup: cluster_dst::> snapmirror quiesce -source-path svm1:volA -destination-path svm_backup:volA_dst Stop ongoing transfers to the destination: snapmirror abort -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page.
|
| This step is not required for SnapMirror Synchronous relationships (supported beginning with ONTAP 9.7).
|
The following example stops ongoing transfers between the source volume volA on svm1 and the destination volume volA_dst on svm_backup: cluster_dst::> snapmirror abort -source-path svm1:volA -destination-path svm_backup:volA_dst Break the SnapMirror DR relationship: snapmirror break -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page. The following example breaks the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup and the destination volume volA_dst on
svm_backup: cluster_dst::> snapmirror break -source-path svm1:volA -destination-path svm_backup:volA_dst
After making the destination volume writeable, you must configure the volume for data access. NAS clients, NVMe subsystem, andSAN hosts can access the data from the destination volume until the source volume is reactivated. NAS environment: Mount the NAS volume to the namespace using the same junction path that the source volume was mounted to in the source SVM. Apply the appropriate ACLs to the SMB shares at the destination volume. Assign
the NFS export policies to the destination volume. Apply the quota rules to the destination volume. Redirect clients to the destination volume. Remount the NFS and SMB shares on the clients.
SAN environment: Map the LUNs in the volume to the appropriate initiator group. For iSCSI, create iSCSI sessions from the SAN host initiators to the SAN LIFs. On the SAN client, perform a
storage re-scan to detect the connected LUNs.
Reactivate the original source volumeYou can reestablish the original
data protection relationship between the source and destination volumes when you no longer need to serve data from the destination. About this task The procedure below assumes that the baseline in the original source volume is intact. If the baseline is not intact, you must create and initialize the relationship between the volume you are serving data from and the original source volume before performing the procedure. Background preparation and the data
warehousing phase of an XDP SnapMirror relationship can take a long time. It is not uncommon to see the SnapMirror relationship reporting the status "preparing" for an extended time period.
Steps Delete the original data protection relationship: snapmirror delete -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page. You must run this command from the destination SVM or the destination cluster. The following example deletes the relationship between
the original source volume, volA on svm1, and the volume you are serving data from, volA_dst on svm_backup: cluster_dst::> snapmirror delete -source-path svm1:volA -destination-path svm_backup:volA_dst Reverse the original data protection relationship: snapmirror resync -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page. You must run this command from the destination SVM or the destination cluster. Although resync does not require a baseline transfer, it can be time-consuming. You might want to run the resync in off-peak hours. The
following example reverses the relationship between the original source volume, volA on svm1, and the volume you are serving data from, volA_dst on svm_backup: cluster_dst::> snapmirror resync -source-path svm_backup:volA_dst -destination-path svm1:volA Stop the source SVM for the reversed relationship: vserver stop -vserver SVM
For complete command syntax, see the man page. The following example stops the source SVM for the reversed relationship: cluster_src::> vserver stop svm_backup Update the reversed relationship: snapmirror update -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete
command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster.The command fails if a common Snapshot copy does not exist on the source and destination. Use snapmirror initialize to re-initialize the relationship.
|
The following example updates the relationship between the volume you are serving data from, volA_dst on svm_backup, and the original source volume, volA on svm1: cluster_dst::> snapmirror update -source-path svm_backup:volA_dst -destination-path svm1:volA Stop scheduled transfers for the reversed relationship: snapmirror quiesce -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster.
|
The following example stops scheduled transfers between the volume you are serving data from, volA_dst on svm_backup, and the original source volume, volA on svm1: cluster_dst::> snapmirror quiesce -source-path svm_backup:volA_dst -destination-path svm1:volA Stop ongoing transfers for the reversed relationship: snapmirror abort -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster.
|
The following example stops ongoing transfers between the volume you are serving data from, volA_dst on svm_backup, and the original source volume, volA on svm1: cluster_dst::> snapmirror abort -source-path svm_backup:volA_dst -destination-path svm1:volA Break the reversed relationship: snapmirror break -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster.
|
The following example breaks the relationship between the volume you are serving data from, volA_dst on svm_backup, and the original source volume, volA on svm1: cluster_dst::> snapmirror break -source-path svm_backup:volA_dst -destination-path svm1:volA Start the original source SVM: vserver start -vserver SVM
For complete command syntax, see the man page. The following example starts the original source SVM: cluster_dst::> vserver start svm1 Delete the reversed data protection relationship: snapmirror delete -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For
complete command syntax, see the man page. You must run this command from the source SVM or the source cluster for the reversed relationship. The following example deletes the reversed relationship between the original source volume, volA on svm1, and the volume you are serving data from, volA_dst on svm_backup: cluster_src::> snapmirror delete -source-path svm_backup:volA_dst -destination-path svm1:volA Reestablish the original data protection relationship: snapmirror resync -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page. The
following example reestablishes the relationship between the original source volume, volA on svm1, and the original destination volume, volA_dst on svm_backup: cluster_dst::> snapmirror resync -source-path svm1:volA -destination-path svm_backup:volA_dst
After you finish Use the snapmirror show command to verify that the SnapMirror relationship was created. For complete command syntax, see the man page. Restore a single file, LUN, or NVMe namespace from a SnapMirror destinationYou can restore a single file, LUN, a set of files or LUNs
from a Snapshot copy, or an NVMe namespace from a SnapMirror destination volume. Beginning with ONTAP 9.7, you can also restore NVMe namespaces from a SnapMirror Synchronous destination. You can restore files to the original source volume or to a different volume. What you’ll need To restore a file or LUN from a SnapMirror Synchronous destination (supported beginning with ONTAP 9.7), you must first delete and release the relationship. About this task The
volume to which you are restoring files or LUNs (the destination volume) must be a read-write volume: SnapMirror performs an incremental restore if the source and destination volumes have a common Snapshot copy (as is typically the case when you are restoring to the original source volume). Otherwise, SnapMirror performs a baseline restore, in which the specified Snapshot copy and all the data blocks it references are transferred to the
destination volume.
Steps List the Snapshot copies in the destination volume: volume snapshot show -vserver SVM -volume volume
For complete command syntax, see the man page. The following example shows the Snapshot copies on the vserverB:secondary1 destination: cluster_dst::> volume snapshot show -vserver vserverB -volume secondary1
Vserver Volume Snapshot State Size Total% Used%
------- ------ ---------- ----------- ------ ----- ------ -----
vserverB secondary1 hourly.2013-01-25_0005 valid 224KB 0% 0%
daily.2013-01-25_0010 valid 92KB 0% 0%
hourly.2013-01-25_0105 valid 228KB 0% 0%
hourly.2013-01-25_0205 valid 236KB 0% 0%
hourly.2013-01-25_0305 valid 244KB 0% 0%
hourly.2013-01-25_0405 valid 244KB 0% 0%
hourly.2013-01-25_0505 valid 244KB 0% 0%
7 entries were displayed.Restore a single file or LUN or a set of files or LUNs from a Snapshot copy in a SnapMirror destination volume: snapmirror restore -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, … -source-snapshot snapshot -file-list source_file_path,@destination_file_path
For complete command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster.
|
The following command restores the files file1 and file2 from the Snapshot copy daily.2013-01-25_0010 in the original destination volume secondary1, to the same location in the active file system of the original source volume primary1: cluster_dst::> snapmirror restore -source-path vserverB:secondary1 -destination-path vserverA:primary1 -source-snapshot daily.2013-01-25_0010 -file-list /dir1/file1,/dir2/file2
[Job 3479] Job is queued: snapmirror restore for the relationship with destination vserverA:primary1 The following command restores the files file1 and file2 from the Snapshot copy daily.2013-01-25_0010 in the original destination volume secondary1, to a different location in the active file system of the original source volume
primary1. The destination file path begins with the @ symbol followed by the path of the file from the root of the original source volume. In this example, file1 is restored to /dir1/file1.new and file2 is restored to /dir2.new/file2 on primary1: cluster_dst::> snapmirror restore -source-path vserverB:secondary1 -destination-path vserverA:primary1 -source-snapshot daily.2013-01-25_0010 -file-list /dir/file1,@/dir1/file1.new,/dir2/file2,@/dir2.new/file2
[Job 3479] Job is queued: snapmirror restore for the relationship with destination vserverA:primary1 The following command restores the files file1 and file3 from the Snapshot copy daily.2013-01-25_0010 in the original destination volume secondary1, to different locations in the active file system of the original source volume
primary1, and restores file2 from snap1 to the same location in the active file system of primary1. In this example, the file file1 is restored to /dir1/file1.new and file3 is restored to /dir3.new/file3: cluster_dst::> snapmirror restore -source-path vserverB:secondary1 -destination-path vserverA:primary1 -source-snapshot daily.2013-01-25_0010 -file-list /dir/file1,@/dir1/file1.new,/dir2/file2,/dir3/file3,@/dir3.new/file3
[Job 3479] Job is queued: snapmirror restore for the relationship with destination vserverA:primary1
Restore the contents of a volume from a SnapMirror destinationYou can restore the contents of an entire volume from a Snapshot copy in a SnapMirror destination volume. You can
restore the volume’s contents to the original source volume or to a different volume. About this task The destination volume for the restore operation must be one of the following: A read-write volume, in which case SnapMirror performs an incremental restore, provided that the source and destination volumes have a common Snapshot copy (as is typically the case when you are restoring to the original source volume).
|
| The command fails if there is not a common Snapshot copy. You cannot restore the contents of a volume to an empty read-write volume.
|
An empty data protection volume, in which case SnapMirror performs a baseline restore, in which the specified Snapshot copy and all the data blocks it references are transferred to the source volume.
Restoring the contents of a volume is a disruptive operation. SMB traffic must not be running on the SnapVault primary volume when a restore operation is running. If the destination volume for the restore operation has
compression enabled, and the source volume does not have compression enabled, disable compression on the destination volume. You need to re-enable compression after the restore operation is complete. Any quota rules defined for the destination volume are deactivated before the restore is performed. You can use the volume quota modify command to reactivate quota rules after the restore operation is complete. Steps List the Snapshot copies in the destination volume: volume snapshot show -vserver SVM -volume volume
For complete command syntax, see the man page. The following example shows the Snapshot copies on the vserverB:secondary1 destination: cluster_dst::> volume snapshot show -vserver vserverB -volume secondary1
Vserver Volume Snapshot State Size Total% Used%
------- ------ ---------- ----------- ------ ----- ------ -----
vserverB secondary1 hourly.2013-01-25_0005 valid 224KB 0% 0%
daily.2013-01-25_0010 valid 92KB 0% 0%
hourly.2013-01-25_0105 valid 228KB 0% 0%
hourly.2013-01-25_0205 valid 236KB 0% 0%
hourly.2013-01-25_0305 valid 244KB 0% 0%
hourly.2013-01-25_0405 valid 244KB 0% 0%
hourly.2013-01-25_0505 valid 244KB 0% 0%
7 entries were displayed.Restore the contents of a volume from a Snapshot copy in a SnapMirror destination volume: snapmirror restore -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, … -source-snapshot snapshot
For complete command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster.
|
The following command restores the contents of the original source volume primary1 from the Snapshot copy daily.2013-01-25_0010 in the original destination volume secondary1: cluster_dst::> snapmirror restore -source-path vserverB:secondary1 -destination-path vserverA:primary1 -source-snapshot daily.2013-01-25_0010
Warning: All data newer than Snapshot copy daily.2013-01-25_0010 on volume vserverA:primary1 will be deleted.
Do you want to continue? {y|n}: y
[Job 34] Job is queued: snapmirror restore from source vserverB:secondary1 for the snapshot daily.2013-01-25_0010.Remount the restored volume and restart all applications that use the volume.
Update a replication relationship manuallyYou might need to update a replication relationship manually if an update fails because the source volume has been moved. About this task
SnapMirror aborts any transfers from a moved source volume until you update the replication relationship manually. Beginning with ONTAP 9.7, SnapMirror Synchronous relationships are supported. Although the source and destination volumes are in sync at all times in these relationships, the view from the secondary cluster is synchronized with the primary only on an hourly basis. If you want to view the point-in-time data at the destination, you should perform a manual update by
running the snapmirror update command. Step Update a replication relationship manually: snapmirror update -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster. The command fails if a common Snapshot copy does not exist on the source and destination. Use snapmirror initialize to re-initialize the relationship.
|
The following example updates the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup: cluster_src::> snapmirror update -source-path svm1:volA -destination-path svm_backup:volA_dst
Resynchronize a replication relationshipYou need to resynchronize a replication relationship after you make a destination volume writeable, after an update fails because a common Snapshot copy does
not exist on the source and destination volumes, or if you want to change the replication policy for the relationship. About this task Although resync does not require a baseline transfer, it can be time-consuming. You might want to run the resync in off-peak hours. Volumes that are part of a fan-out or cascade configuration can take longer to resynchronize. It is not uncommon to see the SnapMirror relationship reporting the status "preparing" for an
extended time period.
Step Resync the source and destination volumes: snapmirror resync -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, … -type DP|XDP -schedule schedule -policy policy
For complete command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster.
|
The following example resyncs the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup: cluster_dst::> snapmirror resync -source-path svm1:volA -destination-path svm_backup:volA_dst
Delete a volume replication relationshipYou can use the snapmirror delete and snapmirror release commands to delete a volume replication relationship. You can then delete unneeded destination volumes manually.
About this task The snapmirror release command deletes any SnapMirror-created Snapshot copies from the source. You can use the -relationship-info-only option to preserve the Snapshot copies. Steps Quiesce the replication relationship: snapmirror quiesce -destination-path SVM:volume|cluster://SVM/volume
cluster_dst::> snapmirror quiesce -destination-path svm_backup:volA_dst Break the replication relationship: snapmirror break -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
cluster_dst::> snapmirror break -source-path svm1:volA -destination-path svm_backup:volA_dst Delete the replication relationship: snapmirror delete -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page.
|
| You must run this command from the destination cluster or destination SVM.
|
The following example deletes the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup: cluster_dst::> snapmirror delete -source-path svm1:volA -destination-path svm_backup:volA_dst Release replication relationship information from the source SVM: snapmirror release -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, …
For complete command syntax, see the man page.
|
| You must run this command from the source cluster or source SVM.
|
The following example releases information for the specified replication relationship from the source SVM svm1: cluster_src::> snapmirror release -source-path svm1:volA -destination-path svm_backup:volA_dst
Manage
storage efficiencySnapMirror preserves storage efficiency on the source and destination volumes, with one exception, when postprocess data compression is enabled on the destination. In that case, all storage efficiency is lost on the destination. To correct this issue, you need to disable postprocess compression on the destination, update the relationship manually, and re-enable storage efficiency. What you’ll need About this task You can use the volume efficiency show command to determine whether efficiency is enabled on a volume. For more information, see the man pages. You can check if SnapMirror is maintaining storage efficiency by viewing the SnapMirror audit logs and locating the transfer description. If the transfer description displays transfer_desc=Logical Transfer, SnapMirror is not
maintaining storage efficiency. If the transfer description displays transfer_desc=Logical Transfer with Storage Efficiency, SnapMirror is maintaining storage efficiency. For example: Fri May 22 02:13:02 CDT 2020 ScheduledUpdate[May 22 02:12:00]:cc0fbc29-b665-11e5-a626-00a09860c273 Operation-Uuid=39fbcf48-550a-4282-a906-df35632c73a1 Group=none Operation-Cookie=0 action=End source=<sourcepath> destination=<destpath> status=Success bytes_transferred=117080571 network_compression_ratio=1.0:1 transfer_desc=Logical Transfer - Optimized Directory Mode Logical Transfer with storage Beginning with ONTAP 9.7, manual update is no longer required to re-enable storage efficiency. If SnapMirror detects that postprocess compression has been disabled, it automatically re-enables storage efficiency at the next scheduled update. Beginning with ONTAP 9.7, ETERNUS AX series manage
storage efficiency settings differently from ETERNUS HX series after a destination volume is made writeable: After you make a destination volume writeable using the snapmirror break command, the caching policy on the volume is automatically set to “auto” (the default).
|
| This behavior is applicable to FlexVol volumes, only, and it does not apply to FlexGroup volumes.
|
On resync, the caching policy is automatically set to “none”, and deduplication and inline compression are automatically disabled, regardless of your original settings. You must modify the settings manually as needed.
|
| Manual updates with storage efficiency enabled can be time-consuming. You might want to run the operation in off-peak hours.
|
Step Update a replication relationship and re-enable storage efficiency: snapmirror update -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, … -enable-storage-efficiency true
For complete command syntax, see the man page.
|
| You must run this command from the destination SVM or the destination cluster. The command fails if a common Snapshot copy does not exist on the source and destination. Use snapmirror initialize to re-initialize the relationship.
|
The following example updates the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup, and re-enables storage efficiency: cluster_dst::> snapmirror update -source-path svm1:volA -destination-path svm_backup:volA_dst -enable-storage-efficiency true
Use SnapMirror global throttlingGlobal network throttling is available for all SnapMirror and SnapVault transfers at a per-node level. About this task SnapMirror global throttling restricts the
bandwidth used by incoming and/or outgoing SnapMirror and SnapVault transfers. The restriction is enforced cluster wide on all nodes in the cluster. For example, if the outgoing throttle is set to 100 Mbps, each node in the cluster will have the outgoing bandwidth set to 100 Mbps. If global throttling is disabled, it is disabled on all nodes.
|
| The throttle has no effect on volume move transfers or load-sharing mirror transfers. Although data transfer rates are often expressed in bits per second (bps), the throttle values must be entered in kilobytes per second (KBps).
|
Global throttling works with the per-relationship throttle feature for SnapMirror and SnapVault transfers. The per-relationship throttle is enforced until the combined bandwidth of per-relationship transfers exceeds the value of the global throttle, after which the global throttle is enforced. A throttle value 0 implies that global throttling is disabled.
|
| SnapMirror global throttling has no effect on SnapMirror Synchronous relationships when they are In-Sync. However, the throttle does effect SnapMirror Synchronous relationships when they perform an asynchronous transfer phase such as an initialization operation or after an Out Of Sync event. For this reason, enabling global throttling with SnapMirror Synchronous relationships is not recommended.
|
Steps Enable global throttling: options -option-name replication.throttle.enable on|off
The following example shows how to enable SnapMirror global throttling on cluster_dst: cluster_dst::> options -option-name replication.throttle.enable on Specify the maximum total bandwidth used by incoming transfers: options -option-name replication.throttle.incoming.max_kbs KBps
The recommended minimum throttle bandwidth is 4 KBps and the maximum is up to 2 TBps. The default value for this option is unlimited, which means there is no limit on total bandwidth used. The
following example shows how to set the maximum total bandwidth used by incoming transfers to 100 Mbps: cluster_dst::> options -option-name replication.throttle.incoming.max_kbs 12500 Specify the maximum total bandwidth used by outgoing transfers: options -option-name replication.throttle.outgoing.max_kbs KBps
KBps is the maximum transfer rate in kilobytes per second. Valid transfer rate values are 1 to 125000. The default value for this option is unlimited, which means there is no limit on total bandwidth used. The following example shows how to set the maximum total bandwidth
used by outgoing transfers to 100 Mbps: cluster_dst::> options -option-name replication.throttle.outgoing.max_kbs 12500
About SnapMirror SVM replicationYou can use SnapMirror to create a data
protection relationship between SVMs. In this type of data protection relationship, all or part of the SVM’s configuration, from NFS exports and SMB shares to RBAC, is replicated, as well as the data in the volumes that the SVM owns. Supported relationship typesOnly data-serving SVMs can be replicated. The following data protection relationship types are supported: SnapMirror DR, in which the destination typically contains only the
Snapshot copies currently on the source. Beginning with ONTAP 9.9.1, this behavior changes when you are using the mirror-vault policy. Beginning with ONTAP 9.9.1, you can create different Snapshot policies on the source and destination, and the Snapshot copies on the destination are not overwritten by Snapshot copies on the source: They are not overwritten from the source to the destination during normal scheduled operations, updates and resync They are
not deleted during break operations. They are not deleted during flip-resync operations.
When you configure an SVM DR relationship using the mirror-vault policy using ONTAP 9.9.1 and later, the policy behaves as follows: User-defined Snapshot copy policies at the source are not copied to the destination. System-defined Snapshot copy policies are not copied to the destination. Volume association with user and system defined
Snapshot policies are not copied to the destination. SVM.
Beginning with ONTAP 9.7, SnapMirror unified replication, in which the destination is configured for both DR and long-term retention.
The policy type of the replication policy determines the type of relationship it supports. The following table shows the available policy types.
Policy type | Relationship type |
|---|
async-mirror
| SnapMirror DR
| mirror-vault
| Unified replication
|
XDP replaces DP as the SVM replication default in ONTAP 9.7
Beginning with ONTAP 9.7, SVM data protection relationships default to XDP mode. Existing relationships are not affected by the new default. If a relationship is already of type DP, it will continue to be of type DP. The following table shows the behavior you can expect.
If you specify… | The type is… | The default policy (if you do not specify a policy) is… |
|---|
DP
| XDP
| MirrorAllSnapshots (SnapMirror DR)
| Nothing
| XDP
| MirrorAllSnapshots (SnapMirror DR)
| XDP
| XDP
| MirrorAndVault (Unified replication)
|
|
| Version-independence is not supported for SVM replication.
|
How SVM configurations are replicatedThe content of an SVM replication relationship is determined by the interaction of the
following fields: The -identity-preserve true option of the snapmirror create command replicates the entire SVM configuration. The -identity-preserve false option replicates only the volumes and authentication and authorization configurations of the SVM, and the protocol and name service settings listed in Configurations
replicated in SVM DR relationships. The -discard-configs network option of the snapmirror policy create command excludes LIFs and related network settings from SVM replication, for use in cases where the source and destination SVMs are in different subnets. The -vserver-dr-protection unprotected option of the volume modify command excludes the specified volume from SVM replication.
Otherwise, SVM replication is almost identical to volume replication. You can use virtually the same workflow for SVM
replication as you use for volume replication. Support detailsThe following table shows support details for SnapMirror SVM replication.
Resource or feature | Support details |
|---|
Relationship types
|
| Replication scope
| Intercluster only. You cannot replicate SVMs in the same cluster.
| Version-independence
| Not supported.
| Deployment types
| Single source to single destination Beginning with ONTAP 9.7, fan-out. You can fan-out to two destinations only. By default, only one -identity-preserve true relationship is allowed per source SVM.
| Volume encryption
| Encrypted volumes on the source are encrypted on the destination. Onboard Key Manager or KMIP servers must be configured on the destination. New encryption keys are generated at the destination. If the destination does not contain a node that supports volume .encryption, replication succeeds, but the destination volumes are not encrypted.
| FabricPool
| Beginning with ONTAP 9.7, SnapMirror SVM replication is supported with FabricPools.
| MetroCluster
| Beginning with ONTAP 9.11.1, both sides of a SVM DR relationship within a MetroCluster configuration can act as a source for additional SVM DR configurations. Beginning with ONTAP 9.7, SnapMirror SVM replication is supported on MetroCluster configurations. A MetroCluster configuration cannot be the destination of an SVM DR relationship. Only an active SVM within a MetroCluster configuration can be the source of an SVM DR relationship.
A source can be a sync-source SVM before switchover or a sync-destination SVM after switchover. When a MetroCluster configuration is in a steady state, the MetroCluster sync-destination SVM cannot be the source of an SVM DR relationship, since the volumes are not online. When the sync-source SVM is the source of an SVM DR relationship, the source SVM DR relationship information is replicated to the MetroCluster partner. During the switchover and
switchback processes, replication to the SVM DR destination might fail. However, after the switchover or switchback process completes, the next SVM DR scheduled updates will succeed.
| SnapMirror Synchronous
| Not supported with SVM DR.
|
Configurations replicated in SVM DR relationshipsThe following table shows the interaction of the snapmirror create -identity-preserve option and
the snapmirror policy create -discard-configs network option:
Configuration replicated | ‑identity‑preserve true
| ‑identity‑preserve false
|
|---|
| | Policy without -discard-configs network set | Policy with -discard-configs network set | |
|---|
Network
| NAS LIFs
| Yes
| No
| No
| LIF Kerberos configuration
| Yes
| No
| No
| SAN LIFs
| No
| No
| No
| Firewall policies
| Yes
| Yes
| No
| Routes
| Yes
| No
| No
| Broadcast domain
| No
| No
| No
| Subnet
| No
| No
| No
| IPspace
| No
| No
| No
| SMB
| SMB server
| Yes
| Yes
| No
| Local groups and local user
| Yes
| Yes
| Yes
| Privilege
| Yes
| Yes
| Yes
| Shadow copy
| Yes
| Yes
| Yes
| BranchCache
| Yes
| Yes
| Yes
| Server options
| Yes
| Yes
| Yes
| Server security
| Yes
| Yes
| No
| Home directory, share
| Yes
| Yes
| Yes
| Symlink
| Yes
| Yes
| Yes
| Fpolicy policy, Fsecurity policy, and Fsecurity NTFS
| Yes
| Yes
| Yes
| Name mapping and group mapping
| Yes
| Yes
| Yes
| Audit information
| Yes
| Yes
| Yes
| NFS
| Export policies
| Yes
| Yes
| No
| Export policy rules
| Yes
| Yes
| No
| NFS server
| Yes
| Yes
| No
| RBAC
| Security certificates
| Yes
| Yes
| No
| Login user, public key, role, and role configuration
| Yes
| Yes
| Yes
| SSL
| Yes
| Yes
| No
| Name services
| DNS and DNS hosts
| Yes
| Yes
| No
| UNIX user and UNIX group
| Yes
| Yes
| Yes
| Kerberos realm and Kerberos keyblocks
| Yes
| Yes
| No
| LDAP and LDAP client
| Yes
| Yes
| No
| Netgroup
| Yes
| Yes
| No
| NIS
| Yes
| Yes
| No
| Web and web access
| Yes
| Yes
| No
| Volume
| Object
| Yes
| Yes
| Yes
| Snapshot copies, Snapshot policy, and autodelete policy
| Yes
| Yes
| Yes
| Efficiency policy
| Yes
| Yes
| Yes
| Quota policy and quota policy rule
| Yes
| Yes
| Yes
| Recovery queue
| Yes
| Yes
| Yes
| Root volume
| Namespace
| Yes
| Yes
| Yes
| User data
| No
| No
| No
| Qtrees
| No
| No
| No
| Quotas
| No
| No
| No
| File-level QoS
| No
| No
| No
| Attributes: state of the root volume, space guarantee, size, autosize, and total number of files
| No
| No
| No
| Storage QoS
| QoS policy group
| Yes
| Yes
| Yes
| Fibre Channel (FC)
| No
| No
| No
| iSCSI
| No
| No
| No
| LUNs
| Object
| Yes
| Yes
| Yes
| igroups
| No
| No
| No
| portsets
| No
| No
| No
| Serial numbers
| No
| No
| No
| SNMP
| v3 users
| Yes
| Yes
| No
|
SVM DR storage limitsThe following table shows the recommended maximum number of volumes and SVM DR relationships supported per storage object. You should be aware that
limits are often platform dependent.
Storage object | Limit |
|---|
SVM
| 300 Flexible volumes
| HA pair
| 1,000 Flexible Volumes
| Cluster
| 128 SVM DR relationships
|
SnapMirror SVM replication workflowSnapMirror SVM replication involves creating the destination SVM, creating a
replication job schedule, and creating and initializing a SnapMirror relationship.
|
| This workflow assumes that you are already using a default policy or a custom replication policy.
|
Criteria for placing volumes on destination SVMsWhen replicating volumes from the source SVM to the destination SVM, it’s important to know the criteria for selecting aggregates.
Aggregates are selected based on the following criteria: Volumes are always placed on non-root aggregates. Non-root aggregates are selected based on the available free space and the number of volumes already hosted on the aggregate. Aggregates with more free space and fewer volumes are given priority. The aggregate with the highest priority is selected. Source volumes on FabricPool aggregates are placed on FabricPool aggregates on the
destination with the same tiering-policy. If a volume on the source SVM is located on a Flash Pool aggregate, then the volume is placed on a Flash Pool aggregate on the destination SVM, if such an aggregate exists and has enough free space. If the -space-guarantee option of the volume that is replicated is set to volume, only aggregates with free space greater than the volume size are considered. The volume size grows automatically on the destination SVM
during replication, based on the source volume size. If you want to pre-reserve the size on the destination SVM, you must resize the volume. The volume size does not shrink automatically on the destination SVM based on the source SVM.
If you want to move a volume from one aggregate to another, you can use the volume move command on the destination SVM. Replicate an entire SVM configurationYou can use the -identity-preserve true option of the snapmirror create command to replicate an entire SVM configuration. For complete command syntax, see the man page. About this task
This workflow assumes that you are already using a default policy or a custom replication policy. Beginning with ONTAP 9.9.1, when you use the mirror-vault policy, you can create different Snapshot policies on the source and destination SVM, and the Snapshot copies on the destination are not overwritten by Snapshot copies on the source. For more information, see
Understanding SnapMirror SVM replication. Steps Create a destination SVM: vserver create -vserver SVM_name -subtype dp-destination
The SVM name must be unique across the source and destination clusters. The following example creates a destination SVM named svm_backup: cluster_dst:> vserver create -vserver svm_backup -subtype dp-destination From the destination cluster, create an SVM peer relationship using
the vserver peer create command. Create a replication job schedule: job schedule cron create -name job_name -month month -dayofweek day_of_week -day day_of_month -hour hour -minute minute
For -month, -dayofweek, and -hour, you can specify all to run the job every month, day of the week, and hour, respectively. The following example creates a job schedule named my_weekly that runs on Saturdays at 3:00 a.m.: cluster_dst::> job schedule cron create -name my_weekly -dayofweek saturday -hour 3 -minute 0 From the destination SVM or the destination cluster, create a replication relationship: snapmirror create -source-path SVM_name: -destination-path SVM_name: -type DP|XDP -schedule schedule -policy policy -identity-preserve true
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options.
|
The following example creates a SnapMirror DR relationship using the default MirrorAllSnapshots policy: cluster_dst::> snapmirror create -source-path svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy MirrorAllSnapshots -identity-preserve true The following example creates a unified replication relationship using the default MirrorAndVault policy: cluster_dst:> snapmirror create -source-path svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy MirrorAndVault -identity-preserve true Assuming you have created a custom policy with the policy type async-mirror, the following example creates a SnapMirror DR relationship: cluster_dst::> snapmirror create -source-path svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy my_mirrored -identity-preserve true Assuming you have created a custom policy with the policy type mirror-vault,
the following example creates a unified replication relationship: cluster_dst::> snapmirror create -source-path svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy my_unified -identity-preserve true Stop the destination SVM: vserver stop
SVM name
The following example stops a destination SVM named dvs1: cluster_dst::> vserver stop -vserver dvs1 From the destination SVM or the destination cluster, initialize the SVM replication relationship: + snapmirror initialize -source-path SVM_name: -destination-path SVM_name:
The following example initializes the relationship between the source SVM, svm1, and the destination SVM, svm_backup:
cluster_dst::> snapmirror initialize -source-path svm1: -destination-path svm_backup:
If the source and destination SVMs are in different subnets, you can use the -discard-configs network option of the snapmirror policy create command to exclude LIFs and related network settings from SVM replication. What you’ll need The source and destination clusters and SVMs must be peered. About this task The -identity-preserve option of the snapmirror create command must be set to true when you create the SVM replication relationship.
For complete command syntax, see the man page. Steps Create a destination SVM: vserver create -vserver SVM -subtype dp-destination
The SVM name must be unique across the source and destination clusters. The following example creates a destination SVM named svm_backup: cluster_dst:> vserver create -vserver svm_backup -subtype dp-destination From the destination cluster, create an SVM peer relationship using the vserver peer create command. Create a job schedule: job schedule cron create -name job_name -month month -dayofweek day_of_week -day day_of_month -hour hour -minute minute
For -month, -dayofweek, and -hour, you can
specify all to run the job every month, day of the week, and hour, respectively. The following example creates a job schedule named my_weekly that runs on Saturdays at 3:00 a.m.: cluster_dst::> job schedule cron create -name my_weekly -dayofweek "Saturday" -hour 3 -minute 0 Create a custom replication policy: snapmirror policy create -vserver SVM -policy policy -type async-mirror|vault|mirror-vault -comment comment -tries transfer_tries -transfer-priority low|normal -is-network-compression-enabled true|false -discard-configs network
For complete command syntax, see the man page. The following example creates a custom replication policy for SnapMirror DR that excludes LIFs: cluster_dst::> snapmirror policy create -vserver svm1 -policy DR_exclude_LIFs -type async-mirror -discard-configs network The following example creates a custom
replication policy for unified replication that excludes LIFs: cluster_dst::> snapmirror policy create -vserver svm1 -policy unified_exclude_LIFs -type mirror-vault -discard-configs network From the destination SVM or the destination cluster, run the following command to create a replication relationship: snapmirror create -source-path SVM: -destination-path SVM: -type DP|XDP -schedule schedule -policy policy -identity-preserve true|false
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the examples below.
|
The following example creates a SnapMirror DR relationship that excludes LIFs: cluster_dst::> snapmirror create -source-path svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy DR_exclude_LIFs -identity-preserve true The following example creates a SnapMirror unified replication relationship that excludes LIFs: cluster_dst::> snapmirror create -source-path svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy unified_exclude_LIFs -identity-preserve true Stop the destination SVM: vserver stop
SVM name
The following example stops a destination SVM named dvs1: cluster_dst::> vserver stop -vserver dvs1 From the destination SVM or the destination cluster, initialize a replication
relationship: snapmirror initialize -source-path SVM: -destination-path SVM:
For complete command syntax, see the man page. The following example initializes the relationship between the source, svm1 and the destination, svm_backup: cluster_dst::> snapmirror initialize -source-path svm1: -destination-path svm_backup:
After you finish You must configure the network and protocols on the destination SVM for data access in the event a disaster occurs. Exclude network, name service, and other settings from SVM replicationYou can use the -identity-preserve false option of the snapmirror create command to replicate only
the volumes and security configurations of an SVM. Some protocol and name service settings are also preserved. What you’ll need The source and destination clusters and SVMs must be peered. For complete command syntax, see the man page. Steps Create a destination SVM: vserver create -vserver SVM -subtype dp-destination
The SVM name must be unique across the source and destination clusters. The following example creates a destination SVM named svm_backup: cluster_dst:> vserver create -vserver svm_backup -subtype dp-destination
From the destination cluster, create an SVM peer relationship using the vserver peer create command. Create a replication job schedule: job schedule cron create -name job_name -month month -dayofweek day_of_week -day day_of_month -hour hour -minute minute
For -month, -dayofweek, and -hour, you can specify all to run the job every month, day of the week, and hour, respectively. The following example creates a job schedule named my_weekly that runs on Saturdays at 3:00 a.m.: cluster_dst::> job schedule cron create -name my_weekly -dayofweek "Saturday" -hour 3 -minute 0 Create a replication relationship that excludes
network, name service, and other configuration settings: snapmirror create -source-path SVM: -destination-path SVM: -type DP|XDP -schedule schedule -policy policy -identity-preserve false
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the examples below. You must run this command from the destination SVM or the destination cluster.
|
The following example creates a SnapMirror DR relationship using the default MirrorAllSnapshots policy. The relationship excludes network, name service, and other configuration settings from SVM replication: cluster_dst::> snapmirror create -source-path svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy MirrorAllSnapshots -identity-preserve false The following example creates a unified replication relationship using the default MirrorAndVault policy. The relationship excludes network, name service, and other configuration settings: cluster_dst:> snapmirror create svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy MirrorAndVault -identity-preserve false Assuming you have created a custom policy
with the policy type async-mirror, the following example creates a SnapMirror DR relationship. The relationship excludes network, name service, and other configuration settings from SVM replication: cluster_dst::> snapmirror create -source-path svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy my_mirrored -identity-preserve false Assuming you have created a custom policy with the policy type mirror-vault, the following example creates a unified replication relationship. The relationship excludes network, name service, and other configuration settings from SVM replication: cluster_dst::> snapmirror create -source-path svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy my_unified -identity-preserve false Stop
the destination SVM: vserver stop
SVM name
The following example stops a destination SVM named dvs1: destination_cluster::> vserver stop -vserver dvs1 If you are using SMB, you must also configure an SMB server. From the destination SVM or the destination cluster, initialize the SVM replication relationship: snapmirror initialize -source-path SVM_name: -destination-path SVM_name:
After you finish You must configure the network and protocols on the destination SVM for data access in the event a disaster
occurs. Specify aggregates to use for SVM DR relationshipsAfter a disaster recovery SVM is
created, you can use the aggr-list option with vserver modify command to limit which aggregates are used to host SVM DR destination volumes. Step Create a destination SVM: vserver create -vserver SVM -subtype dp-destination
Modify the disaster recovery SVM’s aggr-list to limit the aggregates that are used to host the disaster recovery SVM’s volume: cluster_dest::> vserver modify -vserver SVM -aggr-list <comma-separated-list>
SMB only: Create a SMB serverIf the source SVM has an SMB configuration, and you chose to set identity-preserve to false, you must create a SMB server for the destination SVM. SMB server is required for some SMB configurations, such as shares
during initialization of the SnapMirror relationship. Steps Start the destination SVM by using the vserver start command. destination_cluster::> vserver start -vserver dvs1
[Job 30] Job succeeded: DONE Verify that the destination SVM is in the running state and subtype is dp-destination by using the vserver show command. destination_cluster::> vserver show
Admin Operational Root
Vserver Type Subtype State State Volume Aggregate
-------- ------- ---------- ---------- ----------- ---------- ----------
dvs1 data dp-destination running running - -Create a LIF by using the network interface create command. destination_cluster::>network interface create -vserver dvs1 -lif NAS1 -role data -data-protocol cifs -home-node destination_cluster-01 -home-port a0a-101 -address 192.0.2.128 -netmask 255.255.255.128 Create a route by using the network route create command. destination_cluster::>network route create -vserver dvs1 -destination 0.0.0.0/0
-gateway 192.0.2.1 Configure DNS by using
the vserver services dns create command. destination_cluster::>vserver services dns create -domains mydomain.example.com -vserver
dvs1 -name-servers 192.0.2.128 -state enabled Add the preferred domain controller by using the vserver cifs domain preferred-dc add command. destination_cluster::>vserver cifs domain preferred-dc add -vserver dvs1 -preferred-dc
192.0.2.128 -domain mydomain.example.com Create the SMB server by using the vserver cifs create command. destination_cluster::>vserver cifs create -vserver dvs1 -domain mydomain.example.com
-cifs-server CIFS1 Stop the destination SVM by using the vserver stop command. destination_cluster::> vserver stop -vserver dvs1
[Job 46] Job succeeded: DONE
Exclude volumes from SVM replicationBy default, all RW data volumes of the source SVM are replicated. If you do not want to protect all the volumes on the source SVM, you can use the -vserver-dr-protection unprotected option of the
volume modify command to exclude volumes from SVM replication. Steps Exclude a volume from SVM replication: volume modify -vserver SVM -volume volume -vserver-dr-protection unprotected
For complete command syntax, see the man page. The following example excludes the volume volA_src from SVM replication: cluster_src::> volume modify -vserver SVM1 -volume volA_src -vserver-dr-protection unprotected If you later want to include a volume in the SVM replication that you originally excluded, run the following command: volume modify -vserver SVM -volume volume -vserver-dr-protection protected
The following example includes the volume
volA_src in the SVM replication: cluster_src::> volume modify -vserver SVM1 -volume volA_src -vserver-dr-protection protected Create and initialize the SVM replication relationship as described in Replicating an entire SVM configuration.
SVM disaster recovery workflowTo recover from a disaster and serve data from the destination SVM, you must activate the destination SVM. Activating the destination SVM involves stopping scheduled SnapMirror transfers,
aborting ongoing SnapMirror transfers, breaking the replication relationship, stopping the source SVM, and starting the destination SVM. Make SVM destination volumes writeableYou need to make SVM destination volumes writeable before you can serve data to clients. The procedure is largely identical to the procedure for volume replication,
with one exception. If you set -identity-preserve true when you created the SVM replication relationship, you must stop the source SVM before activating the destination SVM. About this task For complete command syntax, see the man page.
|
| In a disaster recovery scenario, you cannot perform a SnapMirror update from the source SVM to the disaster recovery destination SVM because your source SVM and its data will be inaccessible, and because updates since the last resync might be bad or corrupt.
|
Steps From the destination SVM or the destination cluster, stop scheduled transfers to the destination: snapmirror quiesce -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example stops scheduled transfers between the source SVM svm1 and the destination SVM svm_backup: cluster_dst::> snapmirror quiesce -source-path svm1: -destination-path svm_backup: From the destination SVM or the destination cluster, stop ongoing transfers to the destination: snapmirror abort -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example stops ongoing transfers between the source SVM svm1 and the destination SVM svm_backup: cluster_dst::> snapmirror abort -source-path svm1: -destination-path svm_backup: From the destination SVM or the destination cluster, break the replication relationship: snapmirror break -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example breaks the relationship between the source SVM svm1 and the destination SVM svm_backup: cluster_dst::> snapmirror break -source-path svm1: -destination-path svm_backup: If you set -identity-preserve true when you created the SVM replication relationship, stop the source SVM: vserver stop -vserver SVM
The following example stops the source SVM svm1: cluster_src::> vserver stop svm1 Start the destination SVM: vserver start -vserver SVM
The following example starts the destination SVM svm_backup: cluster_dst::> vserver start svm_backup
Source SVM reactivation workflowIf the source SVM exists after a disaster, you can reactivate it and protect it by recreating the SVM
disaster recovery relationship. Reactivate the original source SVMYou can reestablish the original data protection relationship between the source and destination SVM when you no longer need to serve data from the destination. The procedure is
largely identical to the procedure for volume replication, with one exception. You must stop the destination SVM before reactivating the source SVM. What you’ll need If you have increased the size of destination volume while serving data from it, before you reactivate the source volume, you should manually increase max-autosize on the original source volume to ensure it can grow sufficiently. About this task Beginning with ONTAP 9.11.1, you can reduce
resynchronization time during a disaster recovery rehearsal by using the -quick-resync true option of the snapmirror resync command while performing a reverse resync of an SVM DR relationship. A quick resync can reduce the time it takes to return to production by bypassing the data warehouse rebuild and restore operations.
|
| Quick resync does not preserve the storage efficiency of the destination volumes. Enabling quick resync might increase the volume space used by the destination volumes.
|
This procedure assumes that the baseline in the original source volume is intact. If the baseline is not intact, you must create and initialize the relationship between the volume you are serving data from and the original source volume before performing the procedure. For complete command syntax on commands, see the man page. Steps From the original source SVM or the original source cluster, create a reverse SVM DR relationship using the
same configuration, policy, and identity-preserve setting as the original SVM DR relationship: snapmirror create -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example creates a relationship between the SVM from which you are serving data, svm_backup, and the original source SVM, svm1: cluster_src::> snapmirror create -source-path svm_backup: -destination-path svm1: From the original source SVM or the original source cluster, run the following command to reverse the data protection relationship: snapmirror resync -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
Although resync does not require a baseline transfer, it can be time-consuming. You might want to run the resync in off-peak hours.
|
| The command fails if a common Snapshot copy does not exist on the source and destination. Use snapmirror initialize to reinitialize the relationship.
|
The following example reverses the relationship between the original source SVM, svm1, and the SVM from which you are serving data, svm_backup: cluster_src::> snapmirror resync -source-path svm_backup: -destination-path svm1: Example using -quick-resync option: cluster_src::> snapmirror resync -source-path svm_backup: -destination-path svm1: -quick-resync true When you are ready to reestablish data access to the original source SVM, stop the original destination SVM to disconnect any clients currently connected to the original destination SVM. vserver stop -vserver SVM
The following example
stops the original destination SVM which is currently serving data: cluster_dst::> vserver stop svm_backup Verify that the original destination SVM is in the stopped state by using the vserver show command. cluster_dst::> vserver show
Admin Operational Root
Vserver Type Subtype State State Volume Aggregate
-------- ------- ---------- ---------- ----------- ---------- ----------
svm_backup data default stopped stopped rv aggr1From the original source SVM or the original source cluster, run the following command to perform the final update of the reversed relationship to transfer all changes from the original destination SVM to the original source SVM: snapmirror update -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example updates the relationship between the original destination SVM from which you are serving data,svm_backup, and the original source SVM, svm1: cluster_src::> snapmirror update -source-path svm_backup: -destination-path svm1: From the original source SVM or the original source cluster, run the following command to stop scheduled transfers for the reversed relationship: snapmirror quiesce -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example stops scheduled transfers between the SVM you are serving data from, svm_backup, and the original SVM, svm1: cluster_src::> snapmirror quiesce -source-path svm_backup: -destination-path svm1: When the final update is complete and the relationship indicates "Quiesced" for the relationship status, run the following command from the original source SVM or the original source cluster to break the reversed relationship: snapmirror break -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example breaks the relationship between the original destination SVM from which you were serving data, svm_backup, and the original source SVM, svm1: cluster_src::> snapmirror break -source-path svm_backup: -destination-path svm1: If the original source SVM was previously stopped, from the original source cluster, start the original source SVM: vserver start -vserver SVM
The following example starts the original source SVM: cluster_src::> vserver start svm1 From the original destination SVM or the original
destination cluster, reestablish the original data protection relationship: snapmirror resync -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example reestablishes the relationship between the original source SVM, svm1, and the original destination SVM, svm_backup: cluster_dst::> snapmirror resync -source-path svm1: -destination-path svm_backup: From the original source SVM or the original source cluster, run the following command to delete the reversed data protection relationship: snapmirror delete -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example deletes the reversed relationship between the original destination SVM, svm_backup, and the original source SVM, svm1: cluster_src::> snapmirror delete -source-path svm_backup: -destination-path svm1: From the original destination SVM or the original destination cluster, release the reversed data protection relationship: snapmirror release -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example releases the reversed relationship between the original destination SVM, svm_backup, and the original source SVM, svm1 cluster_dst::> snapmirror release -source-path svm_backup: -destination-path svm1:
After you finish Use the snapmirror show command to verify that the SnapMirror relationship was created. For complete command syntax, see the man page. Reactivate the original source SVM (FlexGroup volumes only)You can reestablish the original data protection relationship between the source and destination SVM when
you no longer need to serve data from the destination. To reactivate the original source SVM when you are using FlexGroup volumes, you need to perform some additional steps, including deleting the original SVM DR relationship and releasing the original relationship before you reverse the relationship. You also need to release the reversed relationship and recreate the original relationship before stopping scheduled transfers. Steps From the original destination SVM or
the original destination cluster, delete the original SVM DR relationship: snapmirror delete -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example deletes the original relationship between the original source SVM, svm1, and the original destination SVM, svm_backup: cluster_dst::> snapmirror delete -source-path svm1: -destination-path svm_backup: From the original source SVM or the original source cluster, release the original relationship while keeping the Snapshot copies intact: snapmirror release -source-path SVM: -destination-path SVM: -relationship-info-only true
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example releases the original relationship between the original source SVM, svm1, and the original destination SVM, svm_backup. cluster_src::> snapmirror release -source-path svm1: -destination-path svm_backup: -relationship-info-only true From the original source SVM or the original source cluster, create a reverse SVM DR relationship using the same configuration, policy, and identity-preserve setting as the original SVM DR relationship: snapmirror create -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example creates a relationship between the SVM from which you are serving data, svm_backup, and the original source SVM, svm1: cluster_src::> snapmirror create -source-path svm_backup: -destination-path svm1: From the original source SVM or the original source cluster, run the following command to reverse the data protection relationship: snapmirror resync -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
Although resync does not require a baseline transfer, it can be time-consuming. You might want to run the resync in off-peak hours.
|
| The command fails if a common Snapshot copy does not exist on the source and destination. Use snapmirror initialize to reinitialize the relationship.
|
The following example reverses the relationship between the original source SVM, svm1, and the SVM from which you are serving data, svm_backup: cluster_src::> snapmirror resync -source-path svm_backup: -destination-path svm1: When you are ready to reestablish data access to the original source SVM, stop the original destination SVM to disconnect any clients currently connected to the original destination SVM. vserver stop -vserver SVM
The following example stops the original destination SVM which is currently serving
data: cluster_dst::> vserver stop svm_backup Verify that the original destination SVM is in the stopped state by using the vserver show command. cluster_dst::> vserver show
Admin Operational Root
Vserver Type Subtype State State Volume Aggregate
-------- ------- ---------- ---------- ----------- ---------- ----------
svm_backup data default stopped stopped rv aggr1From the original source SVM or the original source cluster, run the following command to perform the final update of the reversed relationship to transfer all changes from the original destination SVM to the original source SVM: snapmirror update -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example updates the relationship between the original destination SVM from which you are serving data,svm_backup, and the original source SVM, svm1: cluster_src::> snapmirror update -source-path svm_backup: -destination-path svm1: From the original source SVM or the original source cluster, run the following command to stop scheduled transfers for the reversed relationship: snapmirror quiesce -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example stops scheduled transfers between the SVM you are serving data from, svm_backup, and the original SVM, svm1: cluster_src::> snapmirror quiesce -source-path svm_backup: -destination-path svm1: When the final update is complete and the relationship indicates "Quiesced" for the relationship status, run the following command from the original source SVM or the original source cluster to break the reversed relationship: snapmirror break -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example breaks the relationship between the original destination SVM from which you were serving data, svm_backup, and the original source SVM, svm1: cluster_src::> snapmirror break -source-path svm_backup: -destination-path svm1: If the original source SVM was previously stopped, from the original source cluster, start the original source SVM: vserver start -vserver SVM
The following example starts the original source SVM: cluster_src::> vserver start svm1 From the original source SVM or the original
source cluster, delete the reversed SVM DR relationship: snapmirror delete -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example deletes the reversed relationship between the original destination SVM, svm_backup, and the original source SVM, svm1: cluster_src::> snapmirror delete -source-path svm_backup: -destination-path svm1: From the original destination SVM or the original destination cluster, release the reversed relationship while keeping the Snapshot copies intact: snapmirror release -source-path SVM: -destination-path SVM: -relationship-info-only true
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example releases the reversed relationship between the original destination SVM, svm_backup, and the original source SVM, svm1: cluster_dst::> snapmirror release -source-path svm_backup: -destination-path svm1: -relationship-info-only true From the original destination SVM or the original destination cluster, recreate the original relationship. Use the same configuration, policy, and identity-preserve setting as the original SVM DR relationship: snapmirror create -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example creates a relationship between the original source SVM, svm1, and the original destination SVM, svm_backup: cluster_dst::> snapmirror create -source-path svm1: -destination-path svm_backup: From the original destination SVM or the original destination cluster, reestablish the original data protection relationship: snapmirror resync -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example reestablishes the relationship between the original source SVM, svm1, and the original destination SVM, svm_backup: cluster_dst::> snapmirror resync -source-path svm1: -destination-path svm_backup:
Convert volume replication relationships to an SVM replication relationshipYou can convert replication relationships between
volumes to a replication relationship between the storage virtual machines (SVMs) that own the volumes, provided that each volume on the source (except the root volume) is being replicated, and each volume on the source (including the root volume) has the same name as the volume on the destination. About this task Use the volume rename command when the SnapMirror relationship is idle to rename destination volumes if necessary. Steps From the destination
SVM or the destination cluster, run the following command to resync the source and destination volumes: snapmirror resync -source-path SVM:volume -destination-path SVM:volume -type DP|XDP -schedule schedule -policy policy
For complete command syntax, see the man page.
|
| Although resync does not require a baseline transfer, it can be time-consuming. You might want to run the resync in off-peak hours.
|
The following example resyncs the relationship between the source volume volA on svm1 and the destination volume volA on svm_backup: cluster_dst::> snapmirror resync -source-path svm1:volA -destination-path svm_backup:volA Create an SVM replication relationship between the source and destination SVMs, as described in Replicating SVM configurations. You must use the -identity-preserve true
option of the snapmirror create command when you create your replication relationship. Stop the destination SVM: vserver stop -vserver SVM
For complete command syntax, see the man page. The following example stops the destination SVM svm_backup: cluster_dst::> vserver stop svm_backup From the destination SVM or the destination cluster, run the following command to resync the source and destination SVMs: snapmirror resync -source-path SVM: -destination-path SVM: -type DP|XDP -schedule schedule -policy policy
For complete command syntax, see the man page.
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below. Although resync does not require a baseline transfer, it can be time-consuming. You might want to run the resync in off-peak hours.
|
The following example resyncs the relationship between the source SVM svm1 and the destination SVM svm_backup: cluster_dst::> snapmirror resync -source-path svm1: -destination-path svm_backup:
Delete an SVM replication relationshipYou can use the snapmirror delete and snapmirror release commands to delete an SVM replication relationship. You can then delete unneeded destination volumes manually. About
this task The snapmirror release command deletes any SnapMirror-created Snapshot copies from the source. You can use the -relationship-info-only option to preserve the Snapshot copies. For complete command syntax on commands, see the man page. Steps Run the following command from the destination SVM or the destination cluster to break the replication relationship: snapmirror break -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example breaks the relationship between the source SVM svm1 and the destination SVM svm_backup: cluster_dst::> snapmirror break -source-path svm1: -destination-path svm_backup: Run the following command from the destination SVM or the destination cluster to delete the replication relationship: snapmirror delete -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example deletes the relationship between the source SVM svm1 and the destination SVM svm_backup: cluster_dst::> snapmirror delete -source-path svm1: -destination-path svm_backup: Run the following command from the source cluster or source SVM to release the replication relationship information from the source SVM: snapmirror release -source-path SVM: -destination-path SVM:
|
| You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.
|
The following example releases information for the specified replication relationship from the source SVM svm1: cluster_src::> snapmirror release -source-path svm1: -destination-path svm_backup:
Manage SnapMirror root volume replication overviewEvery SVM in a NAS environment has a unique namespace. The SVM root volume, containing operating system and related
information, is the entry point to the namespace hierarchy. To ensure that data remains accessible to clients in the event of a node outage or failover, you should create a load-sharing mirror copy of the SVM root volume. The main purpose of load-sharing mirrors for SVM root volumes is no longer for load sharing; instead, their purpose is for disaster recovery. If the root volume is temporarily unavailable, the load-sharing mirror automatically provides read-only access
to root volume data. If the root volume is permanently unavailable, you can promote one of the load-sharing volumes to provide write access to root volume data.
Create and initializing load-sharing mirror relationshipsYou should create a load-sharing mirror (LSM) for each SVM root volume that serves NAS data in the cluster. You can create the LSM on any node other than the one
containing the root volume, such as the partner node in an HA pair, or preferably in a different HA pair. For a two-node cluster, you should create the LSM on the partner of the node with the SVM root volume. About this task If you create an LSM on the same node, and the node is unavailable, you have a single point of failure, and you do not have a second copy to ensure the data remains accessible to clients. But when you create the LSM on a node other than the one containing
the root volume, or on a different HA pair, your data is still accessible in the event of an outage. For example, in a four-node cluster with a root volume on three nodes: For the root volume on HA 1 node 1, create the LSM on HA 2 node 1 or HA 2 node 2. For the root volume on HA 1 node 2, create the LSM on HA 2 node 1 or HA 2 node 2. For the root volume on HA 2 node 1, create the LSM on HA 1 node 1 or HA 1 node 2.
Steps Create a destination volume for the LSM: volume create -vserver SVM -volume volume -aggregate aggregate -type DP -size size
The destination volume should be the same or greater in size than the root volume. It is a best practice to name the root and destination volume with suffixes, such as _root and _m1. For complete command syntax, see the man page. The following example creates a load-sharing mirror volume for the root volume svm1_root in cluster_src: cluster_src:> volume create -vserver svm1 -volume svm1_m1 -aggregate aggr_1 -size 1gb -state online -type DP Create a replication
job schedule, as described in Creating a replication job schedule. Create a load-sharing mirror relationship between the SVM root volume and the destination volume for the LSM: snapmirror create -source-path SVM:volume|cluster://SVM/volume -destination-path SVM:volume|cluster://SVM/volume -type LS -schedule schedule
For complete command syntax, see the man page. The following example creates a load-sharing mirror relationship between the root volume
svm1_root and the load-sharing mirror volume svm1_m1: cluster_src::> snapmirror create -source-path svm1:svm1_root -destination-path svm1:svm1_m1 -type LS -schedule hourly The type attribute of the load-sharing mirror changes from DP to LS. Initialize the load-sharing mirror: snapmirror initialize-ls-set -source-path SVM:volume|cluster://SVM/volume
Initialization can be time-consuming. You might want to run the baseline transfer in off-peak hours. For complete command syntax, see the man page. The following example initializes the load-sharing mirror for the root volume svm1_root:
cluster_src::> snapmirror initialize-ls-set -source-path svm1:svm1_root
Update a load-sharing mirror relationshipLoad-sharing mirror (LSM) relationships are updated
automatically for SVM root volumes after a volume in the SVM is mounted or unmounted, and during volume create operations that include the `junction-path`option. You can manually update a LSM relationship if you want it updated before the next scheduled update. Load-sharing mirror relationships update automatically in the following circumstances: It’s time for a scheduled update A mount or unmount operation is performed on a volume in the SVM root volume
A volume create command is issued that includes the juntion-path option
Step Update a load-sharing mirror relationship manually: snapmirror update-ls-set -source-path SVM:volume|cluster://SVM/volume
The following example updates the load-sharing mirror relationship for the root volume svm1_root: cluster_src::> snapmirror update-ls-set -source-path svm1:svm1_root
If a root volume is permanently unavailable, you can promote the load-sharing mirror (LSM) volume to provide write access to root volume data.
What you’ll need You must use advanced privilege level commands for this task. Steps Change to advanced privilege level: set -privilege advanced
Promote an LSM volume: snapmirror promote -destination-path SVM:volume|cluster://SVM/volume
For complete command syntax, see the man page. The following example promotes the volume svm1_m2 as the new SVM root volume: cluster_src::*> snapmirror promote -destination-path svm1:svm1_m2
Warning: Promote will delete the offline read-write volume
cluster_src://svm1/svm1_root and replace it with
cluster_src://svm1/svm1_m2. Because the volume is offline,
it is not possible to determine whether this promote will
affect other relationships associated with this source.
Do you want to continue? {y|n}: yEnter y. ONTAP makes the LSM volume a read/write volume, and deletes the original root volume if it is
accessible.
|
| The promoted root volume might not have all of the data that was in the original root volume if the last update did not occur recently.
|
Return to admin privilege level: set -privilege admin
Rename the promoted volume following the naming convention you used for the root volume: volume rename -vserver SVM -volume volume -newname new_name
The following example renames the promoted volume svm1_m2 with the name svm1_root: cluster_src::> volume rename -vserver svm11 -volume svm1_m2 -newname svm1_root Protect the renamed root volume, as described in step 3 through step 4 in
Creating and initializing load-sharing mirror relationships.
Use path name pattern matchingYou can use pattern matching to specify the source and destination paths in snapmirror commands. snapmirror commands use fully qualified path names in the following format: vserver:volume. You
can abbreviate the path name by not entering the SVM name. If you do this, the snapmirror command assumes the local SVM context of the user.
Assuming that the SVM is called “vserver1” and the volume is called “vol1”, the fully qualified path name is vserver1:vol1. You can use the asterisk (*) in paths as a wildcard to select matching, fully qualified path names. The following table provides examples of using the wildcard to select a range of volumes.
*
| Matches all paths.
| vs*
| Matches all SVMs and volumes with SVM names beginning with vs.
| :*src
| Matches all SVMs with volume names containing the src text.
| :vol
| Matches all SVMs with volume names beginning with vol.
|
vs1::> snapmirror show -destination-path *:*dest*
Progress
Source Destination Mirror Relationship Total Last
Path Type Path State Status Progress Healthy Updated
------------- ---- ------------ ------------- -------------- ---------- ------- --------
vs1:sm_src2
DP vs2:sm_dest1
Snapmirrored Idle - true -Use extended queries to act on many
SnapMirror relationshipsYou can use extended queries to perform SnapMirror operations on many SnapMirror relationships at one time. For example, you might have multiple uninitialized SnapMirror relationships that you want to initialize using one command. About this task You can apply extended queries to the following SnapMirror operations: Initializing uninitialized relationships Resuming quiesced relationships
Resynchronizing broken relationships Updating idle relationships Aborting relationship data transfers
Step Perform a SnapMirror operation on many relationships: snapmirror command {-state state } *
The following command initializes SnapMirror relationships that are in an Uninitialized state: vs1::> snapmirror initialize {-state Uninitialized} *
Ensure a common Snapshot copy in a mirror-vault deploymentYou can use the snapmirror snapshot-owner create command to preserve a labeled Snapshot copy on the secondary in a mirror-vault
deployment. Doing so ensures that a common Snapshot copy exists for the update of the vault relationship. About this task If you use a combination mirror-vault fan-out or cascade deployment, you should keep in mind that updates will fail if a common Snapshot copy does not exist on the source and destination volumes. This is never an issue for the mirror relationship in a mirror-vault fan-out or cascade deployment, since SnapMirror always creates a Snapshot copy of
the source volume before it performs the update. It might be an issue for the vault relationship, however, since SnapMirror does not create a Snapshot copy of the source volume when it updates a vault relationship. You need to use the snapmirror snapshot-owner create to ensure that there is at least one common Snapshot copy on both the source and destination of the vault relationship. Steps On the source volume, assign an owner to the labeled Snapshot copy you want to preserve: snapmirror snapshot-owner create -vserver SVM -volume volume -snapshot snapshot -owner owner
The following example assigns ApplicationA as the owner of the snap1 Snapshot copy: clust1::> snapmirror snapshot-owner create -vserver vs1 -volume vol1
-snapshot snap1 -owner ApplicationA Update the mirror relationship, as described in Updating a replication relationship manually. Alternatively, you can wait for the scheduled update of the mirror relationship. Transfer the labeled Snapshot copy
to the vault destination: snapmirror update -source-path SVM:volume|cluster://SVM/volume, … -destination-path SVM:volume|cluster://SVM/volume, … -source-snapshot snapshot
For complete command syntax, see the man page. The following example transfers the snap1 Snapshot copy clust1::> snapmirror update -vserver vs1 -volume vol1
-source-snapshot snap1 The labeled Snapshot copy will be preserved when the vault relationship is updated. On the source volume, remove the owner from the labeled Snapshot copy: snapmirror snapshot-owner delete -vserver SVM -volume volume -snapshot snapshot -owner owner
The following examples removes ApplicationA as the owner of the snap1 Snapshot copy: clust1::> snapmirror snapshot-owner delete -vserver vs1 -volume vol1
-snapshot snap1 -owner ApplicationA
Compatible ONTAP versions for SnapMirror relationshipsYou should verify that the source and
destination volumes are running compatible ONTAP versions before creating a SnapMirror data protection relationship.
|
| Version-independence is not supported for SVM replication.
|
SnapMirror DR relationshipsFor SnapMirror relationships of type “DP” and policy type “async-mirror”:
|
| DP-type mirrors cannot be initialized in ONTAP 9.11.1 and will be completely deprecated in a future release.
|
|
| In the following table, the column on the left indicates the ONTAP version on the source volume, and the top row indicates the ONTAP versions you can have on your destination volume.
|
Source | Destination |
|---|
|
| 9.7
| 9.8
| 9.9.1
| 9.10.1
| 9.11.1
| 9.7
| Yes
| Yes
| Yes
| No
| No
| 9.8
| No
| Yes
| Yes
| Yes
| No
| 9.9.1
| No
| No
| Yes
| Yes
| Yes
| 9.10.1
| No
| No
| No
| Yes
| Yes
| 9.11.1
| No
| No
| No
| No
| Yes
|
|
| Interoperability is not bidirectional.
|
Unified replication relationshipsFor SnapMirror relationships of type “XDP”, using on premises or Cloud Volumes ONTAP releases:
|
| The asterisk (*) after the release version indicates a Cloud Volumes ONTAP-only release.
|
|
| Locate the higher, more recent ONTAP version in the left column, and in the top row locate the lower ONTAP version to determine interoperability. Interoperability is bidirectional.
|
Table 2: Interoperability for ONTAP version 9.7 and later
ONTAP version… | Interoperates with previous ONTAP versions… |
|---|
|
| 9.7
| 9.8
| 9.9.0*
| 9.9.1
| 9.10.0*
| 9.10.1
| 9.11.0*
| 9.11.1
| 9.7
| Yes
| -
| -
| -
| -
| -
| -
| -
| 9.8
| Yes
| Yes
| -
| -
| -
| -
| -
| -
| 9.9.0*
| Yes
| Yes
| Yes
| -
| -
| -
| -
| -
| 9.9.1
| Yes
| Yes
| Yes
| Yes
| -
| -
| -
| -
| 9.10.0*
| Yes
| Yes
| No
| Yes
| Yes
| -
| -
| -
| 9.10.1
| Yes
| Yes
| No
| Yes
| Yes
| Yes
| -
| -
| 9.11.0*
| Yes
| Yes
| No
| Yes
| No
| Yes
| Yes
| -
| 9.11.1
| Yes
| Yes
| No
| Yes
| No
| Yes
| Yes
| Yes
|
SnapMirror limitationsYou should be aware of basic SnapMirror limitations before creating a data protection relationship. A
destination volume can have only one source volume.
|
| A source volume can have multiple destination volumes. The destination volume can be the source volume for any type of SnapMirror replication relationship.
|
You can fan out a maximum of eight destination volumes from a single source volume. You cannot restore files to the destination of a SnapMirror DR relationship. Source or destination SnapVault volumes cannot be 32-bit. The source volume for a SnapVault relationship should not be a FlexClone volume.
|
| The relationship will work, but the efficiency offered by FlexClone volumes will not be preserved.
|
Archive and compliance overviewYou can use Fujitsu SnapLock technology to retain files in unmodified form for regulatory and governance purposes. It shows you how to
commit files and Snapshot copies to “write once, read many” (WORM) storage, and how to set retention periods for WORM-protected data. You should use these procedures if you want to work with SnapLock in the following ways: You want to use the ONTAP command-line interface (CLI), not ONTAP System Manager or an automated scripting tool. A limited but important set of SnapLock technology is available in ONTAP System Manager. You can install SnapLock licenses, set the
Compliance Clock, create SnapLock aggregates and volumes, and configure SnapLock volumes. You want to create Compliance or Enterprise aggregates to host SnapLock audit log volumes on MetroCluster configurations, with the following limitation: SnapLock Enterprise is supported on mirrored and unmirrored aggregates. SnapLock Compliance is supported on unmirrored aggregates only. All MetroCluster configurations support mirrored aggregates.
You want to use SnapLock Enterprise aggregates with FabricPool. Beginning with ONTAP 9.8, SnapLock Enterprise aggregates are supported with Cluster Administration. You are not using SAN LUNs SAN LUNs are not supported on SnapLock volumes. Although it is possible to move SAN LUNs onto a SnapLock volume using legacy technology, this is not a
supported operation, nor is any other operation involving SAN LUNs on a SnapLock volume. You are not using SMTape. SMTape is not supported by SnapLock. You are not creating Compliance aggregates for array LUNs. SnapLock Compliance aggregates do not support array LUNs. You are not creating Compliance aggregates with the SyncMirror option. SnapLock Compliance aggregates do not support SyncMirror plexes.
|
| SSDs and Flash Pool aggregates are supported by SnapLock beginning with ONTAP 9.7.
|
What SnapLock isSnapLock is a high-performance compliance solution for organizations that use WORM storage to retain files in unmodified form for regulatory and governance
purposes. A single license entitles you to use SnapLock in strict Compliance mode, to satisfy external mandates like SEC Rule 17a-4, and a looser Enterprise mode, to meet internally mandated regulations for the protection of digital assets. Differences between Compliance and Enterprise modesSnapLock Compliance and Enterprise modes differ mainly in the level at which each mode protects WORM files: Compliance-mode
WORM files are protected at the disk level. You cannot reinitialize a disk that contains Compliance-mode aggregates. Enterprise-mode WORM files are protected at the file level.
A related difference involves how strictly each mode manages file deletes: Compliance-mode WORM files cannot be deleted during the retention period. Enterprise-mode WORM files can be deleted during the retention period by the compliance
administrator, using an audited privileged delete procedure.
After the retention period has elapsed, you are responsible for deleting any files you no longer need. Once a file has been committed to WORM, whether under Compliance or Enterprise mode, it cannot be modified, even after the retention period has expired. You cannot move a WORM file during or after the retention period. You can copy a WORM file, but the copy will not retain its WORM
characteristics. The following table shows the differences between SnapLock Compliance and Enterprise modes:
Capability | SnapLock Compliance | SnapLock Enterprise |
|---|
Privileged delete
| No
| Yes
| Reinitialize disk
| No
| Yes
| Destroy SnapLock aggregate and volume during retention period
| No
| Yes, with the exception of the SnapLock audit log volume
| Rename an aggregate or volume
| No
| Yes
| Non-Fujitsu disks
| No
| Yes (with FlexArray Virtualization)
| Use SnapLock volume for audit logging
| Yes
| Yes, beginning with ONTAP 9.7
|
Supported and unsupported features with SnapLockThe following table shows the features
that are supported with SnapLock Compliance mode, SnapLock Enterprise mode, or both:
Feature | Supported with SnapLock Compliance | Supported with SnapLock Enterprise |
|---|
Consistency Groups
| No
| No
| SAN
| No
| No
| SnapMirror Synchronous
| No
| No
| SnapMirror Business Continuity
| No
| No
| Single-file SnapRestore
| No
| Yes
| SnapRestore
| No
| Yes
| FlexClone
| You can clone SnapLock volumes, but you cannot clone files on a SnapLock volume.
| You can clone SnapLock volumes, but you cannot clone files on a SnapLock volume.
| LUNs
| No
| No
| SMTape
| No
| No
| MetroCluster configurations
| Yes, under the following conditions: SnapLock Compliance is supported on unmirrored MetroCluster aggregates. SnapLock Compliance is supported on mirrored aggregates, but only if the aggregate is used to host SnapLock audit log volumes. SVM-specific SnapLock configurations can be replicated to primary and secondary sites using MetroCluster.
| Yes, under the following conditions: SnapLock Enterprise aggregates are supported. SnapLock Enterprise aggregates with privileged delete are supported. SVM-specific SnapLock configurations can be replicated to both sites using MetroCluster.
| Support FabricPools on SnapLock aggregates
| No
| Yes, beginning with ONTAP 9.8. However, your account team needs to open a product variance request documenting that you understand that FabricPool data tiered to a public or private cloud is no longer protected by SnapLock because a cloud admin can delete that data.
|
| You should be aware that any data that FabricPool tiers to a public or private cloud is no longer protected by SnapLock because that data can be deleted by a cloud admin.
|
| FlexGroup volumes
| Yes, beginning with ONTAP 9.11.1; however, the following features are not supported: Legal-hold Event-based retention SnapLock for SnapVault
You should also be aware of the following behaviors: The volume compliance clock (VCC) of a FlexGroup volume is determined by the VCC of the root constituent. All non-root constituents will have their VCC closely synced to the root VCC. SnapLock
configuration properties are set only on the FlexGroup as a whole. Individual constituents cannot have different configuration properties, such as default retention time and autocommit period.
| Yes, beginning with ONTAP 9.11.1; however, the following features are not supported: Legal-hold Event-based retention SnapLock for SnapVault
You should also be aware of the following behaviors: The volume compliance clock (VCC) of a FlexGroup volume is determined by the VCC of the root constituent. All non-root constituents will have their VCC closely synced to the root VCC. SnapLock
configuration properties are set only on the FlexGroup as a whole. Individual constituents cannot have different configuration properties, such as default retention time and autocommit period.
|
MetroCluster configurations and compliance clocksMetroCluster configurations use two
compliance clock mechanisms, the Volume Compliance Clock (VCC) and the System Compliance Clock (SCC). The VCC and SCC are available to all SnapLock configurations. When you create a new volume on a node, its VCC is initialized with the current value of the SCC on that node. After the volume is created, the volume and file retention time is always tracked with the VCC. When a volume is replicated to another site, its VCC is also replicated. When a volume switchover occurs, from Site A to
Site B, for example, the VCC continues to be updated on Site B while the SCC on Site A halts when Site A goes offline. When Site A is brought back online and the volume switchback is performed, the Site A SCC clock restarts while the VCC of the volume continues to be updated. Because the VCC is continuously updated, regardless of switchover and switchback operations, the file retention times do not depend on SCC clocks and do not stretch. Committing files to WORMYou can use an application to commit files to WORM over NFS or CIFS, or use the SnapLock autocommit feature to commit files to WORM automatically. You can use a WORM appendable file to retain data that is
written incrementally, like log information. Data protectionSnapLock supports data protection methods that should satisfy most compliance requirements: Storage efficiencyBeginning
with ONTAP 9.9.1, SnapLock supports storage efficiency features, such as data compaction, cross-volume-deduplication, and adaptive compression for SnapLock volumes and aggregates. 7-Mode TransitionYou can
use the Copy-Based Transition (CBT) feature of the 7-Mode Transition Tool to migrate SnapLock volumes from 7-Mode to ONTAP. The SnapLock mode of the destination volume, Compliance or Enterprise, must match the SnapLock mode of the source volume. You cannot use Copy-Free Transition (CFT) to migrate SnapLock volumes. EncryptionONTAP offers both software- and hardware-based encryption technologies for ensuring that data at rest cannot be read if the storage medium is repurposed, returned, misplaced, or stolen. Disclaimer: Fujitsu cannot guarantee that
SnapLock-protected WORM files on self-encrypting drives or volumes will be retrievable if the authentication key is lost or if the number of failed authentication attempts exceeds the specified limit and results in the drive being permanently locked. You are responsible for ensuring against authentication failures.
|
| Beginning with ONTAP 9.7, encrypted volumes are supported on SnapLock aggregates.
|
SnapLock workflowYou specify which SnapLock mode you want to use, Compliance or Enterprise, when you create a SnapLock volume. You typically use a
file archiving application to move files from primary storage to the SnapLock volume. Install the licenseA SnapLock license entitles you to use both SnapLock Compliance mode and SnapLock Enterprise mode. SnapLock licenses are issued on a per-node basis. You must install a license for each node that hosts a SnapLock
aggregate.
What you’ll need You must be a cluster administrator to perform this task. About this task You should have received the SnapLock license keys from your sales representative. Steps Install the SnapLock license for a node: system license add -license-code license_key
The following command installs the license with the key AAAAAAAAAAAAAAAAAAAAAAAAAAAA. cluster1::> system license add -license-code AAAAAAAAAAAAAAAAAAAAAAAAAAAA Repeat the previous step for each node license.
Initialize the ComplianceClockThe SnapLock ComplianceClock ensures against tampering that might alter the retention period for WORM files. You must initialize the system
ComplianceClock on each node that hosts a SnapLock aggregate. Once you initialize the ComplianceClock on a node, you cannot initialize it again. What you’ll need About this task The time on the system ComplianceClock is inherited by the volume ComplianceClock, which controls the retention period for
WORM files on the volume. The volume ComplianceClock is initialized automatically when you create a new SnapLock volume.
|
| The initial setting of the ComplianceClock is based on the current system clock. For that reason, you should verify that the system time and time zone are correct before initializing the ComplianceClock. Once you initialize the ComplianceClock on a node, you cannot initialize it again.
|
Steps Initialize the system ComplianceClock: snaplock compliance-clock initialize -node node_name
The following command initializes the system ComplianceClock on node1: cluster1::> snaplock compliance-clock initialize -node node1 When prompted, confirm that the system clock is correct and that you want to initialize the ComplianceClock: Warning: You are about to initialize the secure ComplianceClock of
the node "node1" to the current value of the node's system clock.
This procedure can be performed only once on a given node, so you
should ensure that the system time is set correctly before proceeding.
The current node's system clock is: Mon Apr 25 06:04:10 GMT 2016
Do you want to continue? (y|n): y Repeat this procedure for each node that hosts a SnapLock aggregate.
Create a SnapLock aggregateYou use the volume -snaplock-type option to specify a Compliance or Enterprise SnapLock volume type. For releases earlier than ONTAP 9.10.1, you must create a
separate SnapLock aggregate. 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. What you’ll need You must be a cluster administrator to perform this task. The SnapLock license must be installed on the node. The ComplianceClock on the node must be initialized. If you have
partitioned the disks as “root”, “data1”, and “data2”, you must ensure that spare disks are available.
Upgrade considerations When upgrading to ONTAP 9.10.1, existing SnapLock and non-SnapLock aggregates are upgraded to support the existence of both SnapLock and non-SnapLock volumes; however, the existing SnapLock volume attributes are not automatically updated. For example, data-compaction, cross-volume-dedupe, and cross-volume-background-dedupe fields remain
unchanged. New SnapLock volumes created on existing aggregates have the same default values as non-SnapLock volumes, and the default values for new volumes and aggregates are platform dependent. Revert considerations If you need to revert to an ONTAP version earlier than 9.10.1, you must move all SnapLock Compliance, SnapLock Enterprise, and SnapLock volumes to their own SnapLock aggregates. About this task You cannot create Compliance
aggregates with the SyncMirror option. You can create mirrored Compliance aggregates in a MetroCluster configuration only if the aggregate is used to host SnapLock audit log volumes.
|
| In a MetroCluster configuration, SnapLock Enterprise is supported on mirrored and unmirrored aggregates. SnapLock Compliance is supported only on unmirrored aggregates.
|
Steps Create a SnapLock aggregate: storage aggregate create -aggregate aggregate_name -node node_name -diskcount number_of_disks -snaplock-type compliance|enterprise
The man page for the command contains a complete list of options. The following command creates a SnapLock Compliance aggregate named aggr1 with three disks on node1: cluster1::> storage aggregate create -aggregate aggr1 -node node1 -diskcount 3 -snaplock-type compliance
Create a SnapLock volumeYou must create a SnapLock volume for the files or Snapshot copies that you want to commit to the WORM state. Beginning with ONTAP 9.10.1, any volume you create, regardless of the aggregate type, is
created by default as a non-SnapLock volume. You must use the -snaplock-type option to explicitly create a SnapLock volume by specifying either Compliance or Enterprise as the SnapLock type. By default, the SnapLock type is set to non-snaplock. What you’ll need The SnapLock aggregate must be online. The SnapLock license must be installed on the node. The ComplianceClock on the node must be initialized.
About this task With
the proper SnapLock permissions, you can destroy or rename an Enterprise volume at any time. You cannot destroy a Compliance volume until the retention period has elapsed. You can never rename a Compliance volume. You can clone SnapLock volumes, but you cannot clone files on a SnapLock volume. The clone volume will be of the same SnapLock type as the parent 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.
|
Steps Create a SnapLock volume: volume create -vserver SVM_name -volume volume_name -aggregate aggregate_name -snaplock-type compliance|enterprise
For a complete list of options, see the man page for the command. The following options are not available for SnapLock volumes: -nvfail, -atime-update, -is-autobalance-eligible, -space-mgmt-try-first, and vmalign. The following command creates a SnapLock Compliance volume named vol1 on aggr1 on vs1: cluster1::> volume create -vserver vs1 -volume vol1 -aggregate aggr1 -snaplock-type compliance
Mount a SnapLock volumeYou can mount a SnapLock volume to a junction path in the SVM namespace for NAS client access. What you’ll need The SnapLock volume must be online. About this task Steps Mount a SnapLock volume: volume mount -vserver SVM_name -volume volume_name -junction-path path
For a complete list of options, see the man page for the command. The following command mounts a SnapLock volume named vol1 to the junction path /sales in the vs1 namespace: cluster1::> volume mount -vserver vs1 -volume vol1 -junction-path /sales
Set the retention time overviewYou can set the retention time for a file explicitly, or you can use the default retention period for the volume to derive the retention time. Unless you set the
retention time explicitly, SnapLock uses the default retention period to calculate the retention time. About retention period and retention time
The retention period for a WORM file specifies the length of time the file must be retained after it is committed to the WORM state. The retention time for a WORM file is the time after which the file no longer needs to be retained. A retention period of 20 years for a file committed to the WORM state on 10 November 2020 6:00 a.m., for example, would yield a retention time of 10 November 2040 6:00 a.m.
|
| Beginning with ONTAP 9.10.1, you can set a retention time up to October 26, 3058 and a retention period up to 100 years. When you extend retention dates, older policies are converted automatically. In ONTAP 9.9.1 and earlier releases, unless you set the default retention period to infinite, the maximum supported retention time is January 19 2071 (GMT).
|
Important revert considerationsONTAP prevents you from reverting a cluster from ONTAP 9.10.1 to an earlier ONTAP version when there are any
files with a retention period later than “January 19, 2071 8:44:07 AM”. Understanding the default retention periodsA SnapLock
Compliance or Enterprise volume has four retention periods: Minimum retention period (min), with a default of 0 Maximum retention period (max), with a default of 30 years Default retention period, with a default equal to min for both Compliance mode and Enterprise mode beginning with ONTAP 9.10.1. In ONTAP releases earlier than ONTAP 9.10.1, the default retention period depends on the mode: For Compliance mode,
the default is equal to max. For Enterprise mode, the default is equal to min.
Unspecified retention period. Beginning with ONTAP 9.8, you can set the retention period on files in a volume to unspecified, to enable the file to be retained until you set an absolute retention time. You can set a file with absolute retention time to unspecified retention and back to absolute retention as long as the new absolute retention time is later than
the absolute time you previously set.
So, if you do not set the retention time explicitly before committing a Compliance-mode file to the WORM state, and you do not modify the defaults, the file will be retained for 30 years. Similarly, if you do not set the retention time explicitly before committing an Enterprise-mode file to the WORM state, and you do not modify the defaults, the file will be retained for 0 years, or, effectively, not at all.
Set the retention time for a file explicitlyYou can set the retention time for a file explicitly by modifying its last access time.
You can use any suitable command or program over NFS or CIFS to modify the last access time. About this task After a file has been committed to WORM, you can extend but not shorten the retention time. The retention time is stored in the atime field for the file.
|
| You cannot explicitly set the retention time of a file to infinite. That value is only available when you use the default retention period to calculate the retention time.
|
Steps Use a suitable command or program to modify the last access time for the file whose retention time you want to set. In a UNIX shell, use the following command to set a retention time of 21 November 2020 6:00 a.m. on a file named document.txt: touch -a -t 202011210600 document.txt
|
| You can use any suitable command or program to modify the last access time in Windows.
|
Set the default retention periodYou can use the volume snaplock modify command to set the default retention period for files on
a SnapLock volume. What you’ll need The SnapLock volume must be online. About this task The following table shows the possible values for the default retention period option:
|
| The default retention period must be greater than or equal to (>=) the minimum retention period and less than or equal to (<=) the maximum retention period.
|
| Value | Unit | Notes |
|---|
0 - 65535
| seconds
|
| 0 - 24
| hours
|
| 0 - 365
| days
|
| 0 - 12
| months
|
| 0 - 70
| years
|
| max
| -
| Use the maximum retention period.
| min
| -
| Use the minimum retention period.
| infinite
| -
| Retain the files forever.
| unspecified
| -
| Retain the files until an absolute retention period is set.
|
The values and ranges for the maximum and minimum retention periods are identical, except for max and min, which are not applicable. For more information about this task, see Set the retention time overview. You can use the volume snaplock show command to view the retention period settings for the volume. For more information, see the
man page for the command.
|
| After a file has been committed to the WORM state, you can extend but not shorten the retention period.
|
Steps Set the default retention period for files on a SnapLock volume: volume snaplock modify -vserver SVM_name -volume volume_name -default-retention-period default_retention_period -minimum-retention-period min_retention_period -maximum-retention-period max_retention_period
For a complete list of options, see the man page for the command.
|
| The following examples assume that the minimum and maximum retention periods have not been modified previously.
|
The following command sets the default retention period for a Compliance or Enterprise volume to 20 days: cluster1::> volume snaplock modify -vserver vs1 -volume vol1 -default-retention-period 20days The following command sets the default retention period for a Compliance volume to 70 years: cluster1::> volume snaplock modify -vserver vs1 -volume vol1 -maximum-retention-period 70years The following command sets the default retention period for an Enterprise volume to 10 years: cluster1::> volume snaplock modify -vserver vs1 -volume vol1 -default-retention-period max -maximum-retention-period 10years The following commands set the default retention period for an Enterprise volume to 10 days: cluster1::> volume snaplock modify -vserver vs1 -volume vol1 -minimum-retention-period 10days
cluster1::> volume snaplock modify -vserver vs1 -volume vol1 -default-retention-period min
The following command sets the default retention period for a Compliance volume to infinite: cluster1::> volume snaplock modify -vserver vs1 -volume vol1 -default-retention-period infinite -maximum-retention-period infinite
Verify SnapLock settingsYou can use
the volume file fingerprint start and volume file fingerprint dump commands to view key information about files and volumes, including the file type (regular, WORM, or WORM appendable), the volume expiration date, and so forth. Steps Generate a file fingerprint: volume file fingerprint start -vserver SVM_name -file file_path
svm1::> volume file fingerprint start -vserver svm1 -file /vol/sle/vol/f1
File fingerprint operation is queued. Run "volume file fingerprint show -session-id 16842791" to view the fingerprint session status. The command generates a session ID that you can use as input to the volume file fingerprint dump command.
|
| You can use the volume file fingerprint show command with the session ID to monitor the progress of the fingerprint operation. Make sure that the operation has completed before attempting to display the fingerprint.
|
Display the fingerprint for the file: volume file fingerprint dump -session-id session_ID
svm1::> volume file fingerprint dump -session-id 33619976
Vserver:svm1
Session-ID:33619976
Volume:slc_vol
Path:/vol/slc_vol/f1
Data Fingerprint:MOFJVevxNSJm3C/4Bn5oEEYH51CrudOzZYK4r5Cfy1g=Metadata
Fingerprint:8iMjqJXiNcqgXT5XuRhLiEwIrJEihDmwS0hrexnjgmc=Fingerprint Algorithm:SHA256
Fingerprint Scope:data-and-metadata
Fingerprint Start Time:1460612586
Formatted Fingerprint Start Time:Thu Apr 14 05:43:06 GMT 2016
Fingerprint Version:3
**SnapLock License:available**
Vserver UUID:acf7ae64-00d6-11e6-a027-0050569c55ae
Volume MSID:2152884007
Volume DSID:1028
Hostname:my_host
Filer ID:5f18eda2-00b0-11e6-914e-6fb45e537b8d
Volume Containing Aggregate:slc_aggr1
Aggregate ID:c84634aa-c757-4b98-8f07-eefe32565f67
**SnapLock System ComplianceClock:1460610635
Formatted SnapLock System ComplianceClock:Thu Apr 14 05:10:35 GMT 2016
Volume SnapLock Type:compliance
Volume ComplianceClock:1460610635
Formatted Volume ComplianceClock:Thu Apr 14 05:10:35 GMT 2016
Volume Expiry Date:1465880998**
Is Volume Expiry Date Wraparound:false
Formatted Volume Expiry Date:Tue Jun 14 05:09:58 GMT 2016
Filesystem ID:1028
File ID:96
File Type:worm
File Size:1048576
Creation Time:1460612515
Formatted Creation Time:Thu Apr 14 05:41:55 GMT 2016
Modification Time:1460612515
Formatted Modification Time:Thu Apr 14 05:41:55 GMT 2016
Changed Time:1460610598
Is Changed Time Wraparound:false
Formatted Changed Time:Thu Apr 14 05:09:58 GMT 2016
Retention Time:1465880998
Is Retention Time Wraparound:false
Formatted Retention Time:Tue Jun 14 05:09:58 GMT 2016
Access Time:-
Formatted Access Time:-
Owner ID:0
Group ID:0
Owner SID:-
Fingerprint End Time:1460612586
Formatted Fingerprint End Time:Thu Apr 14 05:43:06 GMT 2016
When the SnapLock secure clock daemon detects a skew beyond the threshold, the system time is used to reset both the
system and volume ComplianceClocks. What you’ll need This feature is available only at the advanced privilege level. You must be a cluster administrator to perform this task. The SnapLock license must be installed on the node. This feature is available only for VSIM platforms.
About this task When the SnapLock secure clock daemon detects a skew beyond the threshold, the system time is used to
reset both the system and volume ComplianceClocks. A period of 24 hours is set as the skew threshold. This means that the system ComplianceClock is synchronized to the system clock only if the skew is more than a day old. The SnapLock secure clock daemon detects a skew and changes the ComplianceClock to the system time. Any attempt at modifying the system time to force the ComplianceClock to synchronize to the system time fails, since the ComplianceClock synchronizes to the system
time only if the system time is synchronized with the NTP time. Steps Enable the SnapLock ComplianceClock time synchronization feature when an NTP server is configured: snaplock compliance-clock ntp
The following command enables the system ComplianceClock time synchronization feature: cluster1::*> snaplock compliance-clock ntp modify -is-sync-enabled true When prompted, confirm that the configured NTP servers are trusted and that the communications channel is secure to enable the feature: Check that the
feature is enabled: snaplock compliance-clock ntp show
The following command checks that the system ComplianceClock time synchronization feature is enabled: cluster1::*> snaplock compliance-clock ntp show
Enable clock sync to NTP system time: true
Commit files to WORM manuallyYou commit a file to WORM manually by making the file read-only. You can use any suitable command or program over NFS or CIFS to change the read-write attribute of a file to read-only.
What you’ll need About this task The volume ComplianceClock time is written to the ctime field of the file when the command or program is executed. The ComplianceClock time determines when the retention time for the file has been reached. Steps Use a suitable command or program to change the read-write
attribute of a file to read-only. In a UNIX shell, use the following command to make a file named document.txt read-only: In a Windows shell, use the following command to make a file named document.txt read-only:
Autocommit files to WORMThe SnapLock autocommit feature enables you to commit files to WORM automatically. What you’ll need The files you want to autocommit must reside on a SnapLock volume. The
SnapLock volume must be online. The SnapLock volume must be a read-write volume.
|
| The SnapLock autocommit feature scans through all of the files in the volume and commits a file if it meets the autocommit requirement. There might be a time interval between when the file is ready for autocommit and when it is actually committed by the SnapLock autocommit scanner. However, the file is still protected from modifications and deletion by the file system as soon as it is eligible for autocommit.
|
About this task The autocommit period specifies the amount of time that files must remain unchanged before they are autocommitted. Changing a file before the autocommit period has elapsed restarts the autocommit period for the file. The following table shows the possible values for the autocommit period:
| Value | Unit | Notes |
|---|
none
| -
| The default.
| 5 - 5256000
| minutes
| -
| 1 - 87600
| hours
| -
| 1 - 3650
| days
| -
| 1 - 120
| months
| -
| 1 - 10
| years
| -
|
|
| The minimum value is 5 minutes and the maximum value is 10 years.
|
Steps Autocommit files on a SnapLock volume to WORM: volume snaplock modify -vserver SVM_name -volume volume_name -autocommit-period autocommit_period
For a complete list of options, see the man page for the command. The following command autocommits the files on volume vol1 of SVM vs1, as long as the files remain unchanged for 5 hours: cluster1::>volume snaplock modify -vserver vs1 -volume vol1 -autocommit-period 5hours
Use a command or program to create a WORM appendable fileYou can use any suitable command or program over NFS or CIFS to create a WORM appendable file. A WORM
appendable file retains data written incrementally, like log entries. Data is appended to the file in 256 KB chunks. As each chunk is written, the previous chunk becomes WORM-protected. You cannot delete the file until the retention period has elapsed. What you’ll need The WORM appendable file must reside on a SnapLock volume. About this task Data does not have to be written sequentially to the active 256 KB chunk. When data is written to byte n×256KB+1 of
the file, the previous 256 KB segment becomes WORM-protected. Steps Use a suitable command or program to create a zero-length file with the desired retention time. In a UNIX shell, use the following command to set a retention time of 21 November 2020 6:00 a.m. on a zero-length file named document.txt: touch -a -t 202011210600 document.txt Use a suitable command or program to change the read-write attribute of the file to read-only. In a UNIX shell, use the
following command to make a file named document.txt read-only: Use a suitable command or program to change the read-write attribute of the file back to writable.
|
| This step is not deemed a compliance risk because there is no data in the file.
|
In a UNIX shell, use the following command to make a file named document.txt writable: Use a suitable command or program to start writing data to the file. In a UNIX shell, use the following command to write data to document.txt: echo test data >> document.txt
|
| Change the file permissions back to read-only when you no longer need to append data to the file.
|
Use volume append mode to create WORM appendable files
Beginning with ONTAP 9.7, you can use the SnapLock volume append mode (VAM) feature to create WORM appendable files by default. A WORM appendable file retains data written incrementally, like log entries. Data is appended to the file in 256 KB chunks. As each chunk is written, the previous chunk becomes WORM-protected. You cannot delete the file until the retention period has elapsed. What you’ll need About this task Data does not have to be written sequentially to the active 256 KB chunk. When data is written to byte n×256KB+1 of the file, the previous 256 KB segment becomes WORM-protected. If you specify an autocommit period for the volume, WORM appendable files that are not modified for a period greater than the autocommit period are
committed to WORM.
|
| VAM is not supported on SnapLock audit log volumes.
|
Steps Enable VAM: volume snaplock modify -vserver SVM_name -volume volume_name -is-volume-append-mode-enabled true|false
For a complete list of options, see the man page for the command. The following command enables VAM on volume vol1 of SVMvs1: cluster1::>volume snaplock modify -vserver vs1 -volume vol1 -is-volume-append-mode-enabled true Use a suitable command or program to create files with write permissions. The files are WORM-appendable by default.
Commit Snapshot copies to WORMYou can use SnapLock for SnapVault to WORM-protect Snapshot copies on secondary storage. You perform all of the basic SnapLock tasks on the SnapVault 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. What you’ll need 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. 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.
|
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 SnapVault relationship: Steps Identify the destination cluster. On the destination
cluster, install the SnapLock license, initialize the ComplianceClock, and create a SnapLock aggregate, as described in Configure SnapLock. 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 -type DP -size size
|
| 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 -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.
|
<<data-protection_create-replication-relationship-task,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 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
Mirror WORM filesYou can use SnapMirror to replicate WORM files to another geographic location for disaster
recovery and other purposes. Both the source volume and destination volume must be configured for SnapLock, and both volumes must have the same SnapLock mode, Compliance or Enterprise. All key SnapLock properties of the volume and files are replicated. Prerequisites The source and destination volumes must be created in peered clusters with peered SVMs. For more information, see
Cluster and SVM peering. About this task Beginning with ONTAP 9.7, you can replicate WORM files with the XDP (extended data protection) type SnapMirror relationship rather than the DP (data protection) type relationship. XDP mode is ONTAP version-independent, and is able to differentiate files stored in the same block, making it much easier to resync
replicated Compliance-mode volumes. For information on how to convert an existing DP-type relationship to an XDP-type relationship, see Data Protection. A resync operation on a DP type SnapMirror relationship fails for a Compliance-mode volume if SnapLock determines that it will result in a loss of data. If a resync operation fails, you can use the volume clone create
command to make a clone of the destination volume. You can then resync the source volume with the clone. A SnapMirror relationship of type XDP between SnapLock compliant volumes supports a resync after a break even if data on the destination has diverged from the source post the break. On a resync, when data divergence is detected between the source the destination beyond the common snapshot, a new snapshot is cut on the destination to capture this divergence. The new
snapshot and the common snapshot are both locked with a retention time as follows: The volume expiry time of the destination If the volume expiry time is in the past or has not been set, then the snapshot is locked for a period of 30 days If the destination has legal-holds, the actual volume expiry period is masked and shows up as ‘indefinite’, however the snapshot is locked for the duration of the actual volume expiry period.
If the destination volume has an expiry period that is later than the source, the destination expiry period is retained and will not be overwritten by the expiry period of the source volume post the resync. If the destination has legal-holds placed on it that differ from the source, a resync is not allowed. The source and destination must have identical legal-holds or all legal-holds on the destination must be released before a resync is attempted. A locked
snapshot on the destination volume created to capture the divergent data can be copied to the source by running the snapmirror update -s snapshot command. The snapshot once copied will continue to be locked at the source as well. The following illustration shows the procedure for initializing a SnapMirror relationship: Steps Identify the destination cluster. On the destination cluster, install the SnapLock license, initialize the ComplianceClock, and
create a SnapLock aggregate. On the destination cluster, create a SnapLock destination volume of type DP that is either the same size as or greater in size than the source volume: volume create -vserver SVM_name -volume volume_name -aggregate aggregate_name -type DP -size size
|
| 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 -type DP -size 2GB On the destination SVM, create a SnapMirror policy: snapmirror policy create -vserver SVM_name -policy policy_name
The following command creates the SVM-wide policy SVM1-mirror: SVM2::> snapmirror policy create -vserver SVM2 -policy SVM1-mirror On the destination SVM, create a SnapMirror schedule: job schedule cron create -name schedule_name -dayofweek day_of_week -hour hour -minute minute
The following command creates a SnapMirror schedule named weekendcron: SVM2::> job schedule cron create -name weekendcron -dayofweek "Saturday, Sunday" -hour 3 -minute 0
On the destination SVM, create a SnapMirror relationship: snapmirror create -source-path source_path -destination-path destination_path -type XDP|DP -policy policy_name -schedule schedule_name
The following command creates a SnapMirror relationship between the source volume srcvolA on SVM1 and the destination volume dstvolB on SVM2, and assigns the policy SVM1-mirror and the schedule weekendcron: SVM2::> snapmirror create -source-path SVM1:srcvolA -destination-path SVM2:dstvolB -type XDP -policy SVM1-mirror -schedule weekendcron
|
| The XDP type is available in ONTAP 9.7 and later.
|
On the destination SVM, initialize the SnapMirror relationship: snapmirror initialize -destination-path destination_path
The initialization process performs a baseline transfer to the destination volume. SnapMirror makes a Snapshot copy of the source volume, then transfers the copy and all the data blocks that it references to the destination volume. It also transfers any other Snapshot copies on the source volume to the destination volume. The following command initializes the
relationship between the source volume srcvolA on SVM1 and the destination volume dstvolB on SVM2: SVM2::> snapmirror initialize -destination-path SVM2:dstvolB
Create an audit logYou must create a
SnapLock-protected audit log before performing a privileged delete or SnapLock volume move. The audit log records the creation and deletion of SnapLock administrator accounts, modifications to the log volume, whether privileged delete is enabled, privileged delete operations, and SnapLock volume move operations. What you’ll need You must be a cluster administrator to create a SnapLock aggregate. About this task You cannot delete an audit log until the log
file retention period has elapsed. You cannot modify an audit log even after the retention period has elapsed.
|
| In ONTAP 9.7, you cannot use a SnapLock Enterprise volume for audit logging. You must use a SnapLock Compliance volume. In ONTAP 9.7 and later, you can use either a SnapLock Enterprise volume or a SnapLock Compliance volume for audit logging. In all cases, the audit log volume must be mounted at the junction path /snaplock_audit_log. No other volume can use this junction path.
|
You can find the SnapLock audit logs in the /snaplock_log directory under the root of the audit log volume, in subdirectories named privdel_log (privileged delete operations) and system_log (everything else). Audit log file names contain the timestamp of the first logged operation, making it easy to search for records by the approximate time that operations were executed. You can use the snaplock log file show command to view the log files on the audit log volume. You can use the snaplock log file archive command to archive the current log file and create a new one, which is useful in cases where you need to record audit log information in a separate file.
For more information, see the man pages for the commands.
|
| A data protection volume cannot be used as a SnapLock audit log volume.
|
Steps Create a SnapLock aggregate. On the SVM that you want to configure for audit logging, create a SnapLock volume. Configure the SVM for audit logging: snaplock log create -vserver SVM_name -volume snaplock_volume_name -max-file-size size -retention-period default_retention_period
|
| The minimum default retention period for audit log files is six months. If the retention period of an affected file is longer than the retention period of the audit log, the retention period of the log inherits the retention period of the file. So, if the retention period for a file deleted using privileged delete is 10 months, and the retention period of the audit log is 8 months, the retention period of the log is extended to 10 months.
|
The following command configures SVM1 for audit logging using the SnapLock volume logVol. The audit log has a maximum size of 20 GB and is retained for eight months. SVM1::> snaplock log create -vserver SVM1 -volume logVol -max-file-size 20GB -retention-period 8months On the SVM that you configured for audit logging, mount the SnapLock volume at the junction path /snaplock_audit_log.
Create a SnapLock administrator accountYou must have SnapLock administrator privileges to perform a privileged delete. These privileges are defined in the vsadmin-snaplock role. If you have not
already been assigned that role, you can ask your cluster administrator to create an SVM administrator account with the SnapLock administrator role. What you’ll need You must be a cluster administrator to perform this task. You must have logged in on a secure connection (SSH, console, or ZAPI).
Steps Create an SVM administrator account with the SnapLock administrator role: security login create -vserver SVM_name -user-or-group-name user_or_group_name -application application -authmethod authentication_method -role role -comment comment
The following command
enables the SVM administrator account SnapLockAdmin with the predefined vsadmin-snaplock role to access SVM1 using a password: cluster1::> security login create -vserver SVM1 -user-or-group-name SnapLockAdmin -application ssh -authmethod password -role vsadmin-snaplock
Enable the privileged delete featureYou must explicitly enable the privileged delete feature on the Enterprise volume that contains the WORM files you want to delete. About this task The
value of the -privileged-delete option determines whether privileged delete is enabled. Possible values are enabled, disabled, and permanently-disabled.
|
| permanently-disabled is the terminal state. You cannot enable privileged delete on the volume after you set the state to permanently-disabled.
|
Steps Enable privileged delete for a SnapLock Enterprise volume: volume snaplock modify -vserver SVM_name -volume volume_name -privileged-delete disabled|enabled|permanently-disabled
The following command enables the privileged delete feature for the Enterprise volume dataVol on SVM1: SVM1::> volume snaplock modify -vserver SVM1 -volume dataVol -privileged-delete enabled
Delete WORM files using privileged deleteYou can use the privileged delete feature to delete Enterprise-mode WORM files during the retention period. What you’ll need About this task You cannot use a privileged delete operation to delete an expired WORM file. You can use the volume file retention show command to view the retention time of the WORM file that you want to delete. For more information, see the man page for the command. Step -
Delete a WORM file on an Enterprise volume: volume file privileged-delete -vserver SVM_name -file file_path
The following command deletes the file /vol/dataVol/f1 on the SVMSVM1: SVM1::> volume file privileged-delete -file /vol/dataVol/f1
Use the Legal
Hold featureBeginning with ONTAP 9.7, you can use the Legal Hold feature to retain Compliance-mode WORM files for the duration of a litigation. What you’ll need You must be a SnapLock administrator to perform this task. You must have logged in on a secure connection (SSH, console, or ZAPI).
About this task A file under a Legal Hold behaves like a WORM file with an indefinite retention period. It is
your responsibility to specify when the Legal Hold period ends. The number of files you can place under a Legal Hold depends on the space available on the volume. Steps Start a Legal Hold: snaplock legal-hold begin -litigation-name litigation_name -volume volume_name -path path_name
The following command starts a Legal Hold for all the files in vol1: cluster1::>snaplock legal-hold begin -litigation-name litigation1 -volume vol1 -path / End a Legal Hold: snaplock legal-hold end -litigation-name litigation_name -volume volume_name -path path_name
The following command ends a Legal Hold for all the files in vol1: cluster1::>snaplock legal-hold end -litigation-name litigation1 -volume vol1 -path /
Use the Event Based Retention (EBR) featureBeginning with ONTAP 9.7, you can use the SnapLock Event Based Retention
(EBR) feature to define how long a file is retained after the occurrence of an event. What you’ll need You must be a SnapLock administrator to perform this task. You must have logged in on a secure connection (SSH, console, or ZAPI).
About this task The event retention policy defines the retention period for the file after the event occurs. The policy can be applied to a single file or all the files in a
directory. If a file is not a WORM file, it will be committed to the WORM state for the retention period defined in the policy. If a file is a WORM file or a WORM appendable file, its retention period will be extended by the retention period defined in the policy.
You can use a Compliance-mode or Enterprise-mode volume.
|
| EBR policies cannot be applied to files under a Legal Hold.
|
Using EBR to extend the retention period of already existing WORM files |
|---|
EBR is convenient when you want to extend the retention period of already existing WORM files. For example, it might be your firm’s policy to retain employee W-4 records in unmodified form for three years after the employee changes a withholding election. Another company policy might require that W-4 records be retained
for five years after the employee is terminated. In this situation, you could create an EBR policy with a five-year retention period. After the employee is terminated (the “event”), you would apply the EBR policy to the employee’s W-4 record, causing its retention period to be extended. That will usually be easier than extending the retention period manually, particularly when a large number of files is involved.
|
Steps Create an EBR policy: snaplock event-retention policy create -vserver SVM_name -name policy_name -retention-period retention_period
The following command creates the EBR policy employee_exit on vs1 with a retention period of ten years: cluster1::>snaplock event-retention policy create -vserver vs1 -name employee_exit -retention-period 10years Apply an EBR policy: snaplock event-retention apply -vserver SVM_name -name policy_name -volume volume_name -path path_name
The following command applies the EBR policy employee_exit on vs1 to all the files in the directory d1: cluster1::>snaplock event-retention apply -vserver vs1 -name employee_exit -volume vol1 -path /d1
Create a SnapLock security administrator accountYou must have SnapLock security administrator privileges to perform a SnapLock volume move. This privilege is granted to you with the
snaplock role, introduced in ONTAP 9.8. If you have not already been assigned that role, you can ask your cluster administrator to create a SnapLock security user with this SnapLock security role. What you’ll need You must be a cluster administrator to perform this task. You must have logged in on a secure connection (SSH, console, or ZAPI).
About this task The snaplock role is associated with the admin SVM, unlike
the vsadmin-snaplock role, which is associated with the data SVM. Step Create an SVM administrator account with the SnapLock administrator role: security login create -vserver SVM_name -user-or-group-name user_or_group_name -application application -authmethod authentication_method -role role -comment comment
The following command enables the SVM administrator account SnapLockAdmin with the predefined snaplock role to access admin SVM cluster1 using a password: cluster1::> security login create -vserver cluster1 -user-or-group-name SnapLockAdmin -application ssh -authmethod password -role snaplock
Move a SnapLock volumeYou can use the volume move command to move a SnapLock volume to a destination aggregate. What you’ll need You must have created a SnapLock-protected audit log before performing SnapLock
volume move. If you are using a version of ONTAP earlier than ONTAP 9.10.1, the destination aggregate must be the same SnapLock type as the SnapLock volume you want to move; either Compliance to Compliance or Enterprise to Enterprise. Beginning with ONTAP 9.10.1, this restriction is removed and an aggregate can include both Compliance and Enterprise SnapLock volumes, as well as non-SnapLock volumes. You must be a user with the SnapLock security role.
Steps Using a secure connection, log in to the ONTAP cluster management LIF: ssh snaplock_user@node_mgmt_ip
Move a SnapLock volume: volume move start -vserver SVM_name -volume SnapLock_volume_name -destination-aggregate destination_aggregate_name
Check the status of the volume move operation: volume move show -volume SnapLock_volume_name -vserver SVM_name -fields volume,phase,vserver
SnapLock APIsYou can use Zephyr APIs to integrate with SnapLock functionality in scripts or workflow automation. The APIs use XML messaging over HTTP, HTTPS, and Windows DCE/RPC. Consistency groups overviewA consistency group is a collection of volumes that provides a write-order consistency guarantee for an application workload spanning multiple volumes. Consistency groups facilitate application
workload management, providing easy management of local and remote protection policies and providing simultaneous crash-consistent or application-consistent Snapshot copies of a collection of volumes at a point in time. Snapshots in consistency groups enable an entire application workload to be restored. Consistency groups support any FlexVol volume regardless of protocol (NAS, SAN, or NVMe) and can be managed through the ONTAP REST APIs or in ONTAP System Manager under the Storage
> Consistency Groups menu item. Consistency groups can exist on their own or in a hierarchical relationship. An individual consistency group is a collection of volumes. Volumes can have their own volume-granular snapshot policy. In addition, the consistency group the volume is associated with can have its own snapshot policy. The consistency group can only have one SM-BC relationship and shared SM-BC policy, which can be used to recover the entire consistency group.
Larger application workloads might require multiple consistency groups. In these situations, multiple consistency groups can be placed together in a hierarchical relationship. In this configuration, single consistency groups become the child components of a parent consistency group. The
parent consistency group can include up to five child consistency groups. Like in individual consistency groups, a remote SM-BC protection policy can be applied to the entire configuration of consistency groups (parent and children) to recover the application workload.
ProtectionConsistency groups offer remote protection through SnapMirror Business Continuity (SM-BC) and local protection through Snapshot policies. In order to utilize remote protection, you must meet the requirements for
SnapMirror Business Continuity deployments. By default, consistency groups do not have a protection policy set and will not protect your data unless a policy is selected. See “Protect a consistency group” for more information.
|
| SM-BC relationships cannot be established on volumes mounted for NAS access.
|
Consistency groups in MetroCluster configurationsBeginning with ONTAP 9.11.1, you can
provision consistency groups with new volumes on a cluster within a MetroCluster configuration. These volumes are provisioned on mirrored aggregates. After they are provisioned, you can move volumes associated with consistency groups between mirrored and unmirrored aggregates. Therefore, they can be located on mirrored aggregates, unmirrored aggregates, or both. You can modify mirrored aggregates containing volumes associated with consistency groups to become unmirrored. Similarly, you can
modify unmirrored aggregates containing volumes associated with consistency groups to enable mirroring. Volumes associated with consistency groups placed on mirrored aggregates and their Snapshots, including any consistency group Snapshots, are replicated to the remote site (site B). The contents of the volumes on site B are consistency group semantics-compliant. You can access replicated consistency group Snapshots using consistency group Snapshot REST APIs and ONTAP System Manager on
clusters running ONTAP 9.11.1 or later. If some or all of the volumes associated with a consistency group are located on unmirrored aggregates that are not currently accessible, GET or DELETE operations on the consistency group behave as if the local volumes or hosting aggregates are offline. Consistency group configuration replicationIf site B is running ONTAP 9.10.1 or earlier, only the volumes associated with the consistency groups located on mirrored aggregates are replicated to site
B. The consistency group configurations are only replicated to site B, if both sites are running ONTAP 9.11.1 or later.After site B is upgraded to ONTAP 9.11.1, data for consistency groups on site A that have all their associated volumes placed on mirrored aggregates are replicated to site B. Upgrade considerationsConsistency groups created with SM-BC in ONTAP 9.8 and 9.9.1 will automatically be upgraded and become manageable under Storage > Consistency Groups in ONTAP System Manager or the ONTAP REST API when
upgrading to ONTAP 9.10.1. For more information about upgrading, see SM-BC upgrade and revert considerations. Consistency group snapshots created with the ONTAP REST API can be managed through ONTAP System Manager’s Consistency Group interface and through consistency group API endpoints. Snapshots created with the ONTAPI commands cg-start
and cg-commit will not be recognized as consistency group Snapshots and thus cannot be managed through ONTAP System Manager’s Consistency Group interface or the consistency group endpoints in the ONTAP API. Consistency group object limits
Consistency Groups | Scope | Minimum | Maximum |
|---|
Number of consistency groups
| Cluster
| 0
| Same as maximum volume count in cluster
| Number of parent consistency groups
| Cluster
| 0
| Same as maximum volume count in cluster
| Number of individual and parent consistency groups
| Cluster
| 0
| Same as maximum volume count in cluster
| Consistency group
| Same as maximum volume count in cluster
| 1
| 80
| Number of volumes in the child of a parent consistency group
| Parent consistency group
| 1
| 80
| Number of volumes in a child consistency group
| Child consistency group
| 1
| 80
| Number of child consistency groups in a parent consistency group
| Parent consistency group
| 1
| 5
|
Consistency groups can be created with existing volumes or with new volumes. Once a
volume is added to a consistency group, it cannot be added to another consistency group. A volume can be removed from a consistency group by deleting the volume or deleting the consistency group. Create a consistency group with new volumesSteps Select Storage > Consistency groups. Select +Add. then Using New
LUNs. Name the consistency group. Designate the number of LUNs and capacity per LUN. Select the host operating system and LUN format. Enter the host initiator information. To configure protection policies, add a child consistency group, or show more options about host initiators, select More options Select Save. Confirm your consistency group has been created by returning to the
main consistency group menu where it will appear once the ONTAP job completes. If you set a protection policy, look under the appropriate policy, remote or local, which should display a green shield with a checkmark.
Create a consistency group with existing volumesSteps Select Storage > Consistency groups. Select +Add. then
Using existing volumes. Name the consistency group and select the storage VM. Select the existing volumes to include. Only volumes that are not already part of a consistency group will be available for selection. If creating a consistency group with new volumes, the consistency group supports FlexVol volumes. Volumes with Asynchronous or Synchronous SnapMirror relationships can be added to consistency groups, but they are not consistency
group-aware. Consistency groups do not support S3 buckets, MCC, or SVMs with SVMDR relationships. Select Save. Confirm your consistency group has been created by returning to the main consistency group menu where it will appear once the ONTAP job completes. If you have chosen a protection policy, confirm it was properly set by selecting your consistency group from the menu. If you set a protection policy, look under the appropriate policy, remote or
local, which should display a green shield with a checkmark.
If your application workload consists of more than one subset of volumes, where each subset is consistent across its own associated volumes, ONTAP allows you to create a hierarchical consistency group. Hierarchical consistency groups have a parent that can include up to five individual consistency groups. Hierarchical consistency groups can support different local Snapshot policies across consistency groups or individual volumes. If you use a remote SM-BC policy, that will apply for the
entire consistency group. Create a hierarchical consistency group with new volumesSteps
Select Storage > Consistency groups. Select +Add. then Using New LUNs. Name the consistency group. Designate the number of LUNs and capacity per LUN. Select the host operating system and LUN format. Enter the host initiator information. To configure protection policies, add a child consistency group, or show more options about host initiators, select More
options. To add a child consistency group, select +Add child consistency group. Select the performance level, the number of LUNs, and capacity per LUN. Designate the host operating system, LUN format, and select a new or existing host initiator group. Optional: select a local snapshot policy. Repeat for up to five child consistency groups. Select Save. Confirm your consistency group has been created by returning to the main consistency group menu where it will appear once the ONTAP job completes. If you set a protection policy, look under the appropriate policy, remote or local, which should display a green shield with a checkmark in it.
Create a hierarchical consistency group with existing volumesSteps Select Storage > Consistency groups. Select
+Add. then Using existing volumes. Select the storage VM. Select the existing volumes to include. Only volumes that are not already part of a consistency group will be available for selection. To add a child consistency group, select +Add Child Consistency Group. Create the necessary consistency groups, which will be named automatically. Assign existing volumes to each consistency
group. Optional: select a local Snapshot policy. Repeat for up to five child consistency groups. Select Save. Confirm your consistency group has been created by returning to the main consistency group menu where it will appear once the ONTAP job completes. If you have chosen a protection policy, confirm it was properly set by selecting your consistency group from the menu. If you set a protection
policy, look under the appropriate policy, remote or local, which should display a green shield with a checkmark in it.
Protect a consistency
group
Consistency groups offer easily managed local and remote protection for SAN, NAS, and NVMe applications that span multiple volumes. Creating a consistency group does not automatically enable protection. Local and/or remote protection policies can be set at the time of creation or after creating your consistency group. Protection policies can include local Snapshot copies or remote SnapMirror protection with SnapMirror Business Continuity (SM-BC). If you are utilizing nested
consistency groups, you can set different protection policies for individual volumes. Beginning in ONTAP 9.11.1, consistency groups offer two-phase consistency group Snapshot creation. If you are utilizing remote SM-BC protection, to ensure Snapshot copies of consistency groups created on your consistency group are copied to the destination, the policy labels in the source and
destination cluster must match. SM-BC will not replicate Snapshot copies by default unless a rule with a SnapMirror label is added to the predefined AutomatedFailOver policy and the Snapshot copies are created with that label. To learn more about this process, refer to Configure protection for business continuity. Recovery can occur
for an entire consistency group, a single consistency group in a hierarchical configuration, or for individual volumes within the consistency group. Recovery can be achieved by selecting the consistency group you want to recover from, selecting the Snapshot copy type, and then identifying the particular Snapshot copy to base the restoration on. For more information about this process, see
Restore a volume from an earlier Snapshot copy. Beginning with ONTAP 9.10.1, ONTAP System Manager visualizes LUN maps under the Protection > Relationships menu. When you select a source relationship, ONTAP System Manager displays a visualization of the source relationships. By selecting a volume, you can delve deeper into these relationships
to see a list of the contained LUNs and the initiator group relationships. This information can be downloaded as an Excel workbook from the individual volume view. The task will run in the background. Set a local Snapshot protection policySteps Select the consistency group you have created from the Consistency group menu. At the top right of the overview page for the
consistency group, select Edit. Check the box next to Schedule Snapshot copies (local). Select a Snapshot policy. To configure a new, custom policy, refer to Create a custom data protection policy. Select Save. Return to the consistency
group overview menu. In the left column under Snapshot Copies (Local), the status should say protected next to .
Set a remote SM-BC policySteps Ensure you have met the prerequisites for using SM-BC. See
SM-BC prerequisites
|
| SM-BC relationships cannot be established on volumes mounted for NAS access.
|
Select the consistency group you have created from the Consistency group menu. At the top right of the overview page, select More then Protect. The source-side information should be autofilled on the left-hand side of the page. Select the appropriate cluster and storage VM for the destination. Select a protection policy. Ensure that Initialize relationship is
checked. Click Save. The consistency group will have to initialize and synchronize. When this is complete, under SnapMirror (Remote) the status should say “Protected” next to .
Two-phase CG Snapshot creationBeginning in ONTAP 9.11.1, consistency groups support two-phase commits for consistency group (CG) Snapshot creation. This feature is only available with the ONTAP REST API. Two-phase CG Snapshot creation is only available for Snapshot
creation, not provisioning consistency groups or restoring consistency groups. A two-phase CG Snapshot creation breaks the Snapshot creation process invoked with a POST request to the /application/consistency-groups/{consistency_group_uuid}/snapshots endpoint into a sequence of two phases. In the first phase initiated with a POST request, the API executes prechecks, triggers Snapshot creation, and starts a timer for designated interval. If the POST request in phase one completes with a 201 status code, you can invoke the second phase within the
designated interval from the first phase, committing the Snapshot to the appropriate endpoint. To use two-phase CG Snapshot creation, all nodes in the cluster must be running ONTAP 9.11.1. The two-phase CG Snapshot creation can be invoked with the action=start parameter. You can additionally use the action_timeout parameter that specifies the maximum number of seconds that the Snapshot creation process can take. The action_timeout parameter can be set equal to an integer between 5 and 120. The default
value of action_timeout is 7. Only one active invocation of a consistency group Snapshot creation operation is supported on a consistency group instance at a time, whether it be a one-phase or two-phase. Attempting to invoke a Snapshot creation while another one is in progress will result in a failure. For more information about the ONTAP REST API, refer to the API
reference or visit the ONTAP REST API page at the NetApp Developer Network for a complete list of API endpoints. Create a two-phase commit Invoke the Snapshot creation with a POST request to the consistency group endpoint using the action=start parameter. curl -k -X POST 'https://<IP_address>/application/consistency-groups/<cg-uuid>/snapshots?action=start&action_timeout=7' -H "accept: application/hal+json" -H "content-type: application/json" -d '
{
"name": "name_of_this_snapshot",
"consistency_type": "crash",
"comment": "<comment>",
"snapmirror_label": "<snap_mirror label>"
}'
If the POST request succeeds, your output will include a snapshot uuid. Using that information, submit
a PATCH request to commit the Snapshot. curl -k -X PATCH 'https://<IP_address>/application/consistency-groups/<cg_uuid>/snapshots/<snapshot_id>?action=commit' -H "accept: application/hal+json" -H "content-type: application/json"
Delete a consistency groupIf you decide that you no longer need a consistency
group, it can be deleted. Deleting a consistency group deletes the instance of the consistency group and does not impact the constituent volumes or LUNs. Deleting a consistency group does not result in deletion of the Snapshots present on each volume, but they will no longer be accessible as consistency group Snapshots. They can, however, continue to be managed as ordinary volume granular snapshots. Consistency groups will also be deleted if all of the volumes in a
consistency group are deleted. Volumes can only be removed from a consistency group if the volume itself is deleted, in which case the volume is automatically removed from the consistency group. Steps In the consistency group menu under Storage > Consistency groups, select the consistency group you would like to delete. Next to the name of the consistency group, select
and then Delete.
OverviewBeginning with ONTAP 9.8, you
can use SnapMirror Business Continuity (SM-BC) to protect applications with LUNs, enabling applications to fail over transparently, ensuring business continuity in case of a disaster. SM-BC is supported on ETERNUS AX clusters or All SAN Array (ASA) clusters, where the primary and secondary clusters can be either ETERNUS AX or ASA. SM-BC protects applications with iSCSI or FCP LUNs. BenefitsSnapMirror Business Continuity provides the following benefits: Provides continuous availability for business-critical applications Ability to host critical applications alternately from primary and secondary site -
Simplified application management using consistency groups for dependent write-order consistency The ability to test failover for each application Instantaneous creation of mirror clones without impacting application availability Beginning in ONTAP 9.11.1, SM-BC supports single-file SnapRestore.
Typical use casesApplication deployment for zero RTO or Transparent Application FailoverTransparent Application Failover is based on host multipath I/O (MPIO)
software-based path failover to achieve non-disruptive access to the storage. Both LUN copies, for example, primary(L1P) and mirror copy(L1S), have the same identity (serial number) and are reported as read-writable to the host. However, reads and writes are serviced only by the primary volume. I/Os issued to the mirror copy are proxied to the primary copy. The host’s preferred path to L1 is VS1:N1 based on Asymmetric Logical Unit Access (ALUA) access state Active Optimized (A/O). Mediator is
recommended as part of the deployment, primarily to perform failover in case of a storage outage on the primary. Disaster scenarioThe site hosting the primary cluster experiences a disaster. Host
multipathing software marks all paths through the cluster as down and uses paths from the secondary cluster. The result is a non-disruptive failover to the mirror copy for LUN L1. L1S is converted from a mirror copy to an active copy of LUN L1. The failover happens automatically when an external Mediator is configured. The host’s preferred path to L1 becomes VS2:N1. ArchitectureThe following figure illustrates the operation of the SnapMirror Business Continuity feature at a high level.
Key conceptsAs you begin to explore the
ONTAP SnapMirror Business Continuity and plan a deployment, it is helpful to become familiar with the key terminology and concepts. SM-BC Acronym for the SnapMirror Business Continuity (SM-BC) solution available with ONTAP 9.8 and later. Consistency group Beginning with ONTAP 9.10.1, consistency groups have become a first order management unit. To learn more about consistency groups, refer to
Consistency groups overview. A consistency group (CG) is a collection of FlexVol volumes that provide a write order consistency guarantee for the application workload which needs to be protected for business continuity. The purpose of a consistency group is to take simultaneous crash-consistent Snapshot copies of a collection of volumes at a point in time.
In regular deployment, the group of volumes picked to be part of a CG are mapped to an application instance. SnapMirror relationships, also known as a CG relationship, is established between a source CG and a destination CG. The source and destination CGs must contain the same number and type of volumes. Constituent The individual FlexVol volumes that are part of a consistency group. Mediator ONTAP Mediator provides an alternate health path to the peer
cluster, with the intercluster LIFs providing the other health path. With the Mediator’s health information, clusters can differentiate between intercluster LIF failure and site failure. When the site goes down, Mediator passes on the health information to the peer cluster on demand, facilitating the peer cluster to fail over. With the Mediator-provided information and the intercluster LIF health check information, ONTAP determines whether to perform an auto failover, if it is failover
incapable, continue or stop. Mediator is one of three parties in the SM-BC quorum, working with the primary cluster and the secondary cluster to reach a consensus. A consensus requires at least two parties in the quorum to agree to an operation. Out of Sync (OOS) The application I/O is not replicating to the secondary storage system. The destination volume is not in sync with the source volume because SnapMirror replication is not occuring. If the mirror state is
Snapmirrored, this indicates a transfer failure or failure due to an unsupported operation. Zero RPO Zero recovery point objective. This is the acceptable amount of data loss from downtime. Zero RTO Zero recovery time objective or Transparent Application Failover is achieved by using host multipath I/O (MPIO) software-based path failover to provide non-disruptive access to the storage. Planned failover A manual operation to
change the roles of copies in a SM-BC relationship. The primary becomes the secondary and the secondary becomes the primary. ALUA reporting also changes. Automatic unplanned failover (AUFO) An automatic operation to perform a failover to the mirror copy. The operation requires assistance from Mediator to detect that the primary copy is unavailable. PrerequisitesThere are several prerequisites that you should consider as part of planning a SnapMirror Business Continuity solution deployment. HardwareSoftware
Mediator version | Supported Linux versions |
|---|
1.3
| Red Hat Enterprise Linux: 7.6, 7.7, 7.8, 7.9, 8.0, 8.1, 8.2, 8.3 CentOS: 7.6, 7.7, 7.8, 7.9
| 1.2
| Red Hat Enterprise Linux: 7.6, 7.7, 7.8, 8.0, 8.1 CentOS: 7.6, 7.7, 7.8
|
LicensingSupported protocolsOnly SAN protocols are supported (not NFS/CIFS) Only Fibre Channel and iSCSI protocols are supported The default IPspace is required by SM-BC for cluster
peer relationships. Custom IPspace is not supported.
ONTAP Mediator
Read-write destination volumesSM-BC relationships are not supported on read-write destination volumes. Before you can use a read-write volume, you must convert it
to a DP volume by creating a volume-level SnapMirror relationship and then deleting the relationship. For details, see Converting existing relationships to SM-BC relationships
Large LUNs and large volumes
|
| You must ensure that both the primary and secondary cluster are All SAN Arrays, and that they both have ONTAP 9.8 installed. If the secondary cluster is running a version earlier than ONTAP 9.8 or if it is not an All SAN Array, the synchronous relationship can go out of sync if the primary volume grows larger than 100 TB.
|
Additional restrictions and limitationsThere are several additional restrictions and
limitations when using the SnapMirror Business Continuity solution. Consistency groups in a clusterConsistency group limits for a cluster with SM-BC are calculated based
on relationships and depend on the version of ONTAP used. Limits are platform-independent.
| ONTAP version | Maximum number of relationships |
|---|
ONTAP 9.8-9.9.1
| 5
| ONTAP 9.10.1
| 20
| ONTAP 9.11.1
| 50
|
Volumes per consistency groupFrom ONTAP 9.8 to 9.9.1, the maximum number of volumes supported per SM-BC consistency group relationship is twelve, a
limit which is platform-independent. Beginning with ONTAP 9.10.1, the maximum number of volumes supported per SM-BC relationship is sixteen. VolumesLimits in SM-BC are calculated based on the number of endpoints, not the number of
relationships. A consistency group with 12 volumes contributes 12 endpoints on both the source and destination. Both SM-BC and SnapMirror Synchronous relationships contribute to the total number of endpoints. The maximum endpoints per platform are included in the following table.
| S. No | Platform | Endpoints per HA for SM-BC | Overall sync and SM-BC endpoints per HA |
|---|
|
|
| ONTAP 9.8-9.9.1
| ONTAP 9.10.1
| ONTAP 9.11.1
| ONTAP 9.8-9.9.1
| ONTAP 9.10.1
| ONTAP 9.11.1
| 1
| ETERNUS AX
| 60
| 200
| 400
| 80
| 200
| 400
| 2
| ASA
| 60
| 200
| 400
| 80
| 200
| 400
|
SAN object limitsThe following SAN object limits are included in the following table and apply regardless of the platform.
| Limits of objects in an SM-BC relationship | Count |
|---|
LUNs per volume
| 256
| LUN maps per node
| 2048
| LUN maps per cluster
| 4096
| LIFs per VServer (with at least one volume in an SM-BC relationship)
| 256
| Inter-cluster LIFs per node
| 4
| Inter-cluster LIFs per cluster
| 8
|
AIXBeginning with ONTAP 9.11.1, AIX is supported with SM-BC. With an AIX configuration, the primary cluster is the "active" cluster. In an AIX configuration, failovers are disruptive. With each failover, you will
need to perform a re-scan on the host for I/O operations to resume. Solaris Host setting
recommendation for SM-BC configurationBeginning with ONTAP 9.10.1, SM-BC supports Solaris 11.4. To ensure the Solaris client applications are nondisruptive when an unplanned site failover switchover occurs in an SM-BC environment, the following setting must be configured on Solaris 11.4 Host. This setting overrides failover module – f_tpgs to prevent the code path that detects the contradiction from being executed. Follow these steps to configure the override parameter:
Create configuration file /etc/driver/drv/scsi_vhci.conf with an entry similar to the following for the Fujitsu storage type connected to the host: scsi-vhci-failover-override =
"FUJITSU LUN","f_tpgs" Use devprop and mdb commands to verify the override has been successfully applied: root@host-A:~# devprop -v -n /scsi_vhci scsi-vhci-failover-override scsi-vhci-failover-override=FUJITSU LUN + f_tpgs
root@host-A:~# echo "*scsi_vhci_dip::print -x struct dev_info devi_child | ::list struct dev_info devi_sibling| ::print struct dev_info devi_mdi_client| ::print mdi_client_t ct_vprivate| ::print struct scsi_vhci_lun svl_lun_wwn svl_fops_name"| mdb -k` svl_lun_wwn = 0xa002a1c8960 "600a098038313477543f524539787938"
svl_fops_name = 0xa00298d69e0 "conf f_tpgs"
|
| conf will be added to the svl_fops_name when a scsi-vhci-failover-override has been applied.
|
HP-UX Known issues and limitations for SM-BC configurationBeginning
in ONTAP 9.10.1, SM-BC for HP-UX is supported. If an automatic unplanned failover (AUFO) event occurs on the isolated master cluster in the SM-BC configuration, it might take more than 120 seconds for I/O to resume on the HP-UX host. Depending on the applications that are running, this might not lead to any I/O disruption or error messages. If an AUFO event on the isolated master cluster occurs, you must restart applications on the HP-UX host that have a disruption tolerance of less than 120
seconds. An AUFO event on the isolated master cluster might cause dual event failure when the connection between the primary and the secondary cluster is lost and the connection between the primary cluster and the mediator is also lost. This is considered a rare event, unlike other AUFO events. ONTAP access optionsYou have several access options available when configuring the ONTAP nodes participating in an SM- BC deployment. You should select the option that best matches your specific environment and deployment goals.
|
| In all cases, you must sign in using the administrator account with a valid password.
|
Command line interface The text-based command line interface is available through the ONTAP management shell. You can access the CLI using secure shell (SSH). ONTAP System ManagerYou can connect to the ONTAP System Manager using a modern web browser. The web GUI provides an intuitive and easy-to-use interface when accessing the SnapMirror Business Continuity functionality. For more information about using ONTAP System
Manager, see ONTAP System Manager documentation. REST APIThe ONTAP REST API exposed to external clients provides another option when connecting to the ONTAP. You can access the API using any mainstream programming language or tool that supports REST web services. Popular choices include: Using a programming or scripting language provides an opportunity to automate the deployment and management of a SnapMirror Business Continuity deployment. For more information, see the ONTAP online documentation page at your ONTAP storage system. Prepare to use the ONTAP CLIYou should be familiar with the following commands when deploying the SnapMirror Business Continuity solution using the ONTAP command line interface.
|
| SM-BC does not support the snapmirror quiesce and snapmirror resume commands for relationships with active
sync policy.
|
| Command | Description |
|---|
lun igroup create
| Create an igroup on a cluster
| lun map
| Map a LUN to an igroup
| lun show
| Display a list of LUNs
| snapmirror create
| Create a new SnapMirror relationship
| snapmirror initialize
| Initialize an SM-BC consistency group
| snapmirror update
| Initiates a common snapshot creation operation
| snapmirror show
| Display a list of SnapMirror relationships
| snapmirror failover
| Start a planned failover operation
| snapmirror resync
| Start a resynchronization operation
| snapmirror delete
| Delete a SnapMirror relationship
| snapmirror release
| Remove source information for a SnapMirror relationship
|
The ONTAP Mediator establishes a quorum for the ONTAP clusters in an SM-BC relationship. It coordinates
automated failover when a failure is detected and helps to avoid split-brain scenarios when each cluster simultaneously tries to establish control as the primary cluster. Network configurationBy
default, the ONTAP Mediator provides service through TCP port 31784. You should make sure that port 31784 is open and available between the ONTAP clusters and the mediator. Summary of deployment best practicesThere are several best practices that you should consider as part of planning an SnapMirror Business Continuity deployment. SANThe SnapMirror Business Continuity solution supports only SAN workloads. You should follow the SAN best practices in all cases. In addition: Replicated LUNs in the secondary cluster must be mapped to the host and the I/O paths to the LUNs from both
the primary and secondary cluster must be discovered at the time of host configuration. After an out of sync (OOS) event exceeds 80 seconds, or after an automatic unplanned failover, it is important to rescan the host LUN I/O path to ensure that there is no I/O path loss. For more information, see the respective host OS vendor’s documentation on rescan of LUN I/O paths.
MediatorTo be fully functional and to enable automatic unplanned failover, the external ONTAP mediator should be provisioned and configured with ONTAP clusters. When installing the mediator, you should replace the self-signed certificate with a valid certificate
signed by a mainstream reliable CA. SnapMirrorYou should terminate an SnapMirror relationship in the following order: Perform snapmirror delete at the destination cluster Perform snapmirror release at the source
cluster
Use ONTAP System Manager to configure the Mediator server to be used for automated failover. You can also replace the self-signed SSL and CA with the third party validated SSL Certificate and CA if you have not already done so. Steps Navigate to Protection > Overview > Mediator > Configure. Click Add, and enter the following Mediator server information:
IPv4 address Username Password Certificate
Configuring protection for business continuity involves selecting LUNs on the ONTAP source cluster and adding them to a consistency
group. Open ONTAP System Manager from a browser on the source cluster to begin configuring protection for business continuity. This workflow is designed for ONTAP 9.8 and 9.9. Beginning with ONTAP 9.10.1, it is recommended that you begin by creating a consistency group and then use SM-BC as a remote protection. About this taskLUNs must reside on the same storage VM. LUNs can reside on different volumes. The source and destination cluster cannot be the same. The default IPspace is required by SM-BC for
cluster peer relationships. Custom IPspace is not supported.
Steps Choose the LUNs you want to protect and add them to a protection group: Protection > Overview > Protect for Business Continuity > Protect LUNs. Select one or more LUNs to protect on the source cluster. Select the destination cluster and SVM. Initialize relationship is selected by default. Click
Save to begin protection. Go to Dashboard > Performance to verify IOPS activity for the LUNs. On the destination cluster, use ONTAP System Manager to verify that the protection for business continuity relationship is in sync: Protection > Relationships.
Reestablish the original protection relationship after an unplanned failoverONTAP uses the ONTAP Mediator to detect when a
failure occurs on the primary storage system and executes automatic unplanned failover to the secondary storage system. You can use ONTAP System Manager to reverse the relationship and reestablish the original protection relationship when original source cluster is back online. Steps Navigate to Protection > Relationships and wait for the relationship state to show “InSync.” To resume operations on the original source cluster, click
and select Failover.
You should make sure that your source and destination clusters are configured properly. About this task Proceed through
each of the following steps. For each step, you should confirm that the specific configuration has been performed. Use the link included after each step to get more information as needed. Steps Install the ONTAP Mediator service before you ensure that your source and destination clusters are configured properly. Confirm that a cluster peering relationship exists between the clusters.
|
| The default IPspace is required by SM-BC for cluster peer relationships. Custom IPspace is not supported.
|
Confirm that the Storage VMs are created on each cluster. Confirm that a peer relationship exists between the Storage VMs on each cluster. Confirm that the volumes exist for your LUNs. Confirm that at least one SAN LIF is created on each node in the cluster. Confirm that the necessary LUNs are created and mapped to igroup, which is used to map LUNs to the initiator on the application host. Rescan the application host to discover any new LUNs.
You must initialize Mediator on one of your cluster peers before SM-BC can perform planned and automatic unplanned failover operations. About this task You can initialize Mediator from either cluster. When you issue the mediator add command on one cluster, Mediator is automatically added on the other cluster. Steps Initialize Mediator on one of the
clusters: snapmirror mediator add -mediator-address IP_Address -peer-cluster cluster_name -username user_name
Example cluster1::> snapmirror mediator add -mediator-address 192.168.10.1 -peer-cluster cluster2 -username mediatoradmin
Notice: Enter the mediator password.
Enter the password: ******
Enter the password again: ****** Check the status of the Mediator configuration: snapmirror mediator show
Mediator Address Peer Cluster Connection Status Quorum Status
---------------- ---------------- ----------------- -------------
192.168.10.1 cluster-2 connected true -quorum-status indicates whether the SnapMirror consistency group relationships are synchronized with Mediator.
Create a consistency group relationshipYou must create a SM-BC consistency group which also establishes the synchronous consistency group relationship.
|
| This workflow applies to users in ONTAP 9.8 and 9.9.1. If using these ONTAP CLI commands beginning with ONTAP 9.10.1, they will still work to create a consistency group, however, it is recommended that you manage consistency groups with ONTAP System Manager or the ONTAP REST API.
|
Before you begin The following prerequisites and restrictions apply: You must be a cluster or storage VM administrator You must have a SnapMirror Synchronous license The destination volumes must be type DP The primary and the secondary storage VM must be in a peered relationship All constituent volumes in a consistency group must be in a single Storage VM You
cannot establish SM-BC consistency group relationships across ASA clusters and non-ASA clusters The name of the consistency group must be unique
About this task You must create the consistency group relationship from the destination cluster. You can map up to 12 constituents using the cg-item-mappings parameter on the snapmirror create command. Steps Create a consistency group and constituent relationship. This example creates two
consistency groups: cg_src with constituent volumes vol1 and vol2, and cg_dist with constituent volumes vol1_dr and vol2_dr. destination::> snapmirror create -source-path vs1_src:/cg/cg_src -destination-path vs1_dst:/cg/cg_dst -cg-item-mappings vol_src1:@vol_dst1,vol_src2:@vol_dst2 -policy AutomatedFailOver
Initialize a consistency groupAfter creating a consistency group, you must initialize it.
|
| This workflow applies to users in ONTAP 9.8 and 9.9.1. If using these ONTAP CLI commands beginning with ONTAP 9.10.1, they will still work to initialize a consistency group, however, is recommended that you manage consistency groups with ONTAP System Manager or the ONTAP REST API.
|
Before you begin You must be a cluster or storage VM administrator. About this task You initialize the consistency group from the destination cluster. Steps Sign in to the ONTAP CLI at the destination cluster and initialize the consistency group: destination::>snapmirror initialize -destination-path vs1_dst:/cg/cg_dst
Confirm that the initialization operation completed successfully. The status should be InSync. snapmirror show
Mapping LUNs to the application hostsYou must create an igroup on each cluster so you can map LUNs to the initiator on the application
host. About this task You should perform this configuration on both the source and destination clusters. Steps Create an igroup on each cluster: lun igroup create -igroup name -protocol fcp|iscsi -ostype os -initiator initiator_name
Example lun igroup create -igroup ig1 -protocol iscsi -ostype linux -initiator -initiator iqn.2001-04.com.example:abc123 Map LUNs to the igroup: lun map -path path_name -igroup igroup_name
Example: lun map -path /vol/src1/11 -group ig1 Verify the LUNs are mapped: lun show
On the application host, discover the new LUNs.
Create a common Snapshot copyIn addition to the regularly scheduled Snapshot copy operations, you can manually create a common Snapshot copy between the
volumes in the primary SnapMirror consistency group and the volumes in the secondary SnapMirror consistency group. In ONTAP 9.8, the scheduled snapshot creation interval is one hour. Beginning with ONTAP 9.9.1, that interval is 12 hours. Before you begin The SnapMirror group relationship must be in sync. Steps Create a common Snapshot copy: destination::>snapmirror update -destination-path vs1_dst:/cg/cg_dst
Monitor the progress of the update: destination::>snapmirror show -fields -newest-snapshot
You can perform a planned failover to test your disaster recovery configuration or to perform maintenance on the primary cluster. Before
you begin The relationship must be in sync Nondisruptive operations must not be running The ONTAP Mediator must be configured, connected, and in quorum
About this task A planned failover is initiated by the administrator of the secondary cluster. The operation requires switching the primary and secondary roles so that the secondary cluster takes over from the primary. The new primary cluster can then begin processing
input and output requests locally without disrupting client operations. Steps Start the failover operation: destination::>snapmirror failover start -destination-path vs1_dst:/cg/cg_dst
Monitor the progress of the failover: destination::>snapmirror failover show
When the failover operation is complete, you can monitor the Synchronous SnapMirror protection relationship status from the destination: destination::>snapmirror show
Automatic unplanned failover operationsAn automatic unplanned failover (AUFO) operation occurs when the primary cluster is down or isolated. When this occurs, the secondary cluster is converted to the
primary and begins serving clients. This operation is performed only with assistance from the ONTAP Mediator.
|
| After the automatic unplanned failover, it is important to rescan the host LUN I/O paths so that there is no loss of I/O paths.
|
You can monitor the status of the automatic unplanned failover by using the snapmirror failover show command. Basic monitoringThere are several SM-BC components and operations you can monitor. ONTAP mediatorDuring normal operation, the Mediator state should be connected. If it is in any other state, this might indicate an error condition. You can review the Event Management System (EMS) messages to determine the
error and appropriate corrective actions.
| EMS Name | Description |
|---|
sm.mediator.added
| Mediator is added successfully
| sm.mediator.removed
| Mediator is removed successfully
| sm.mediator.unusable
| Mediator is unusable due to a corrupted Mediator server
| sm.mediator.misconfigured
| Mediator is repurposed or the Mediator package is no longer installed on the Mediator server
| sm.mediator.unreachable
| Mediator is unreachable
| sm.mediator.removed.force
| Mediator is removed from the cluster using the "force" option
| sm.mediator.cacert.expiring
| Mediator certificate authority (CA) certificate is due to expire in 30 days or less
| sm.mediator.serverc.expiring
| Mediator server certificate is due to expire in 30 days or less
| sm.mediator.clientc.expiring
| Mediator client certificate is due to expire in 30 days or less
| sm.mediator.cacert.expired
| Mediator certificate authority (CA) certificate has expired
| sm.mediator.serverc.expired
| Mediator server certificate has expired
| sm.mediator.clientc.expired
| Mediator client certificate has expired
| sm.mediator.in.quorum
| All the SM-BC records are resynchronized with Mediator
|
Planned failover operationsYou can monitor status and progress of a planned failover operation using the snapmirror failover show command. For example: ClusterB::> snapmirror failover start -destination-path vs1:/cg/dcg1
Once the failover operation is complete, you can monitor the Synchronous SnapMirror protection status from the new destination cluster. For example: ClusterA::> snapmirror show You can also review the following messages to determine if there is an error and take the appropriate corrective actions.
| EMS Name | Description |
|---|
smbc.pfo.failed
| SMBC planned failover operation failed. Destination path:
| smbc.pfo.start. Destination path:
| SMBC planned failover operation started
|
Automatic unplanned failover operationsDuring an unplanned automatic failover, you can monitor the status of
the operation using the snapmirror failover show command. For example: ClusterB::> snapmirror failover show -instance
Start Time: 9/23/2020 22:03:29
Source Path: vs1:/cg/scg3
Destination Path: vs3:/cg/dcg3
Failover Status: completed
Error Reason:
End Time: 9/23/2020 22:03:30
Primary Data Cluster: cluster-2
Last Progress Update: -
Failover Type: unplanned
Error Reason codes: -You can also review the following messages to determine if there is an error and take the appropriate corrective actions.
| EMS Name | Description |
|---|
smbc.aufo.failed
| SnapMirror automatic planned failover operation failed. Destination path:
| smbc.aufo.start
| SMBC planned failover operation started. Destination path:
| smbc.aufo.completed:
| SnapMirror automatic planned failover operation completed. Destination path:
| smbc.aufo.failover.incapable
| block.giveback.during.aufo
|
SM-BC availabilityYou can check the availability of the SM-BC relationship using a series of commands, either on the primary cluster, the secondary cluster, or both. Commands
you use include the snapmirror mediator show command on both the primary and secondary cluster to check the connection and quorum status, the snapmirror show command, and the volume show command. For example: SMBC_A::*> snapmirror mediator show
Mediator Address Peer Cluster Connection Status Quorum Status
---------------- ---------------- ----------------- -------------
10.236.172.86 SMBC_B connected true
SMBC_B::*> snapmirror mediator show
Mediator Address Peer Cluster Connection Status Quorum Status
---------------- ---------------- ----------------- -------------
10.236.172.86 SMBC_A connected true
SMBC_B::*> snapmirror show -expand
Progress
Source Destination Mirror Relationship Total Last
Path Type Path State Status Progress Healthy Updated
----------- ---- ------------ ------- -------------- --------- ------- --------
vs0:/cg/cg1 XDP vs1:/cg/cg1_dp Snapmirrored InSync - true -
vs0:vol1 XDP vs1:vol1_dp Snapmirrored InSync - true -
2 entries were displayed.
SMBC_A::*> volume show -fields is-smbc-master,smbc-consensus,is-smbc-failover-capable -volume vol1
vserver volume is-smbc-master is-smbc-failover-capable smbc-consensus
------- ------ -------------- ------------------------ --------------
vs0 vol1 true false Consensus
SMBC_B::*> volume show -fields is-smbc-master,smbc-consensus,is-smbc-failover-capable -volume vol1_dp
vserver volume is-smbc-master is-smbc-failover-capable smbc-consensus
------- ------- -------------- ------------------------ --------------
vs1 vol1_dp false true No-consensusAdd and remove volumes in a consistency groupIf you want to change the composition of the consistency group by adding or removing a volume, you must first delete the original relationship
and then create the consistency group again with the new composition.
|
| This workflow applies to ONTAP 9.8 and 9.9.1. Beginning with ONTAP 9.10.1, it is recommended that you manage consistency groups through ONTAP System Manager or with the ONTAP REST API.
|
About this task
|
| The new volume you add to expand the consistency group must have a pair of common Snapshot copies between the source and destination volumes.
|
Steps This procedure assumes that there are two volume mappings: vol_src1 ←→ vol_dst1 and vol_src2 ←→ vol_dst2, in a consistency group relationship between the end points vs1_src:/cg/cg_src and vs1_dst:/cg/cg_dst. Verify that a common Snapshot copy exists between the source and destination volumes on both the source and destination cluster: source::>snapshot show -vserver vs1_src -volume vol_src3 -snapshot snapmirror*
destination::>snapshot show -vserver vs1_dst -volume vol_dst3 -snapshot snapmirror*
If no common Snapshot copy exists, create and
initialize a FlexVol SnapMirror relationship: destination::>snapmirror initialize -source-path vs1_src:vol_src3 -destination-path vs1_dst:vol_dst3
Delete the zero RTO consistency group relationship: destination::>snapmirror delete -destination-path vs1_dst:vol_dst3
Release the source SnapMirror relationship and retain the common Snapshot copies: source::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol_dst3
Unmap the LUNs and delete the existing consistency group relationship: destination::>lun mapping delete -vserver vs1_dst -path <lun_path> -igroup <igroup_name>
|
| The destination LUNs are unmapped, while the LUNs on the primary copy continue to serve the host I/O.
|
destination::>snapmirror delete -destination-path vs1_dst:/cg/cg_dst
source::>snapmirror release -destination-path vs1_dst:/cg/cg_dst -relationship-info-only true
Create the new consistency group with the new composition: destination::>snapmirror create -source-path vs1_src:/cg/cg_src -destination-path vs1_dst:/cg/cg_dst -cg-item-mappings vol_src1:@vol_dst1, vol_src2:@vol_dst2, vol_src3:@vol_dst3
Resynchronize the zero RTO consistency group relationship to ensure it is in sync: destination::>snapmirror resync -destination-path vs1_dst:/cg/cg_dst
Remap the LUNs that you unmapped in Step 5: destination::> lun map -vserver vs1_dst -path <lun_path> -igroup <igroup_name>
Rescan host LUN I/O paths to restore all paths to the LUNs.
Resume protection in a fan-out configuration with SM-BCSM-BC supports
fan-out configurations. Using the MirrorAllSnapshots policy, your source volume can be mirrored to an SM-BC destination endpoint and to one or more asynchronous SnapMirror relationships. If you experience a failover on the SM-BC destination, the asynchronous SnapMirror destination will become unhealthy, and you must manually restore protection by deleting and
recreating the relationship with the asynchronous SnapMirror endpoint. Resume protection in a fan-out configuration Verify the failover has completed successfully:
snapmirror failover show On the asynchronous Snapmirror endpoint, delete the fan-out endpoint:
snapmirror delete -destination-path destination_path On the third site, create an asynchronous SnapMirror relationships between the new SM-BC primary volume and the async fan-out destination volume:
snapmirror create -source-path source_path -destination-path destination_path -policy MirrorAllSnapshots -schedule schedule Resynchronize
the relationship:
SnapMirror resync -destination-path destination_path Verify the relationship status and heath:
snapmirror show
Convert existing relationships to SM-BC relationshipsYou can convert an existing zero recovery point protection (zero RPO) Synchronous SnapMirror relationship to an SM-BC zero
RTO Synchronous SnapMirror consistency group relationship. Before you begin A zero RPO Synchronous SnapMirror relationship exists between the primary and secondary. All LUNs on the destination volume are unmapped before the zero RTO SnapMirror relationship is created. SM-BC only supports SAN protocols (not NFS/CIFS). Ensure no constituent of the consistency group is mounted for NAS access.
About this task
You must be a cluster and SVM administrator on the source and destination. You cannot convert zero RPO to zero RTO sync by changing the SnapMirror policy. If existing LUNs on the secondary volume are mapped, snapmirror create with AutomatedFailover policy triggers an error.
You must ensure the LUNs are unmapped before issuing the snapmirror create command. Steps Perform a SnapMirror update operation on the existing relationship:
destination::>snapmirror update -destination-path vs1_dst:vol1
Verify that the SnapMirror update completed successfully: destination::>snapmirror show
Quiesce each of the zero RPO synchronous relationships: destination::>snapmirror quiesce -destination-path vs1_dst:vol1
destination::>snapmirror quiesce -destination-path vs1_dst:vol2
Delete each of the zero RPO synchronous relationships: destination::>snapmirror delete -destination-path vs1_dst:vol1
destination::>snapmirror delete -destination-path vs1_dst:vol2
Release the source SnapMirror relationship but retain the common Snapshot copies: source::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol1
source::>snapmirror release -relationship-info-only true -destination-path vs1_dst:vol2
Create a group zero RTO Synchronous Snapmirror
relationship: destination::> snapmirror create -source-path vs1_src:/cg/cg_src -destination-path vs1_dst:/cg/cg_dst -cg-item-mappings vol1:@vol1,vol2:@vol2 -policy AutomatedFailover
Resynchronize the zero RTO consistency group: destination::> snapmirror resync -destination-path vs1_dst:/cg/cg_dst
Rescan host LUN I/O paths to restore all paths to the LUNs.
SM-BC upgrade and revert considerationsYou should be aware of the requirements for upgrading and reverting an SM-BC configuration. UpgradeBefore you can configure and use SM-BC, you must upgrade all nodes on the source and destination clusters to ONTAP 9.8 or later.
Upgating software on ONTAP clusters
|
| SM-BC is not supported with mixed ONTAP 9.7 and ONTAP 9.8 clusters.
|
Upgrading clusters from 9.8 or 9.9.1 to 9.10.1 creates new consistency groups on both source and destination for SM-BC relationships. Reverting to ONTAP 9.9.1 from ONTAP 9.10.1To revert relationships from 9.10.1 to 9.9.1, SM-BC relationships must be deleted, followed by the 9.10.1 consistency group instance. Consistency groups cannot
be deleted with an active SMBC relationship. Any FlexVol volumes that were upgraded to 9.10.1 previously associated with another Smart Container or Enterprise App in 9.9.1 or earlier will no longer be associated on revert. Deleting consistency groups does not delete the constituent volumes or volume granular snapshots. Refer to Delete a consistency group for more
information on this task. Reverting to ONTAP 9.7 from ONTAP 9.8When you revert from ONTAP 9.8 to ONTAP 9.7, you must be aware of the following:
If the cluster is hosting an SM-BC destination, reverting to ONTAP 9.7 is not allowed until the relationship is broken and deleted. If the cluster is hosting an SM-BC source, reverting to ONTAP 9.7 is not allowed until the relationship is released. All user-created custom SM-BC SnapMirror policies must be deleted before reverting to ONTAP 9.7.
Steps Perform a revert check from one of the clusters in the SM-BC
relationship: cluster::*> system node revert-to -version 9.7 -check-only
Example: cluster::*> system node revert-to -version 9.7 -check-only
Error: command failed: The revert check phase failed. The following issues must be resolved before revert can be completed. Bring the data LIFs down on running vservers. Command to list the running vservers: vserver show -admin-state running Command to list the data LIFs that are up: network interface show -role data -status-admin up Command to bring all data LIFs down: network interface modify {-role data} -status-admin down
Disable snapshot policies.
Command to list snapshot policies: "snapshot policy show".
Command to disable snapshot policies: "snapshot policy modify -vserver
* -enabled false"
Break off the initialized online data-protection (DP) volumes and delete
Uninitialized online data-protection (DP) volumes present on the local
node.
Command to list all online data-protection volumes on the local node:
volume show -type DP -state online -node <local-node-name>
Before breaking off the initialized online data-protection volumes,
quiesce and abort transfers on associated SnapMirror relationships and
wait for the Relationship Status to be Quiesced.
Command to quiesce a SnapMirror relationship: snapmirror quiesce
Command to abort transfers on a SnapMirror relationship: snapmirror
abort
Command to see if the Relationship Status of a SnapMirror relationship
is Quiesced: snapmirror show
Command to break off a data-protection volume: snapmirror break
Command to break off a data-protection volume which is the destination
of a SnapMirror relationship with a policy of type "vault": snapmirror
break -delete-snapshots
Uninitialized data-protection volumes are reported by the "snapmirror
break" command when applied on a DP volume.
Command to delete volume: volume delete
Delete current version snapshots in advanced privilege level.
Command to list snapshots: "snapshot show -fs-version 9.8"
Command to delete snapshots: "snapshot prepare-for-revert -node
<nodename>"
Delete all user-created policies of the type active-strict-sync-mirror
and active-sync-mirror.
The command to see all active-strict-sync-mirror and active-sync-mirror
type policies is:
snapmirror policy show -type
active-strict-sync-mirror,active-sync-mirror
The command to delete a policy is :
snapmirror policy delete -vserver <vserver-name> -policy <policy-name>
Remove an SM-BC configurationYou can
remove zero RTO Synchronous SnapMirror protection and delete the SM-BC relationship configuration. About this task Before you delete the SM-BC relationship, all LUNs in the destination cluster must be unmapped.
After the LUNs are unmapped and the host is rescanned, the SCSI target notifies the hosts that the LUN inventory has changed. The existing LUNs on the zero RTO secondary volumes change to reflect a new identity after the zero RTO relationship is deleted. Hosts
discover the secondary volume LUNs as new LUNs that have no relationship to the source volume LUNs.
The secondary volumes remain DP volumes after the relationship is deleted. You can issue the snapmirror break command to convert them to read/write.
Deleting the relationship is not allowed in the failed-over state when the relationship is not reversed. Steps Delete the SM-BC consistency group relationship between the source endpoint and destination
endpoint: Destination::>snapmirror delete -destination-path vs1_dst:/cg/cg_dst
From the source cluster, release the consistency group relationship and the Snapshot copies created for the relationship: Source::>snapmirror release -destination-path vs1_dst:/cg/cg_dst
Perform a host rescan to update the LUN inventory. Beginning with ONTAP 9.10.1, deleting the SnapMirror relationship does not delete the consistency group. If you want to delete the consistency group, you must use ONTAP System Manager or the ONTAP REST API. See
Delete a consistency group for more information.
If you want to remove an existing ONTAP Mediator configuration from your ONTAP clusters, you can do so by using the snapmirror mediator remove command. Steps Remove ONTAP Mediator: snapmirror mediator remove -mediator-address 12.345.678.90 -peer-cluster cluster_xyz
TroubleshootingSnapMirror delete operation fails in takover stateIssue: When ONTAP 9.9.1 is installed on a cluster, executing the snapmirror delete command fails when an SM-BC consistency group
relationship is in takeover state. Example: C2_cluster::> snapmirror delete vs1:/cg/dd
Error: command failed: RPC: Couldn't make connection Solution When the nodes in an SM-BC relationship are in takeover state, perform the SnapMirror delete and release operation with the "-force" option set to true. Example: C2_cluster::> snapmirror delete vs1:/cg/dd -force true
Warning: The relationship between source "vs0:/cg/ss" and destination
"vs1:/cg/dd" will be deleted, however the items of the destination
Consistency Group might not be made writable, deletable, or modifiable
after the operation. Manual recovery might be required.
Do you want to continue? {y|n}: y
Operation succeeded: snapmirror delete for the relationship with destination "vs1:/cg/dd".Planned failover unsuccessfulIssue: After executing the snapmirror failover start command, the output for the snapmirror failover show command displays a message indicates that a nondisruptive operation is in progress. Example:
Cluster1::> snapmirror failover show
Source Destination Error
Path Path Type Status start-time end-time Reason
-------- ----------- -------- --------- ---------- ---------- ----------
vs1:/cg/cg vs0:/cg/cg planned failed 10/1/2020 10/1/2020 SnapMirror Failover cannot start because a volume move is running. Retry the command once volume move has finished.
08:35:04 08:35:04Cause: Planned failover cannot begin when a nondisruptive operation is in progress, including volume move, aggregate relocation, and storage failover. Solution: Wait for the nondisruptive operation to complete and try the failover operation again. Issue: After executing the snapmirror failover start command, the output for the snapmirror failover show command displays a message
indicating that Mediator is not configured. Example: Cluster1::> snapmirror failover show
Source Destination Error
Path Path Type Status start-time end-time Reason
-------- ----------- -------- --------- ---------- ---------- ----------
vs0:/cg/cg vs1:/cg/cg planned failed 10/1/2020 10/1/2020 SnapMirror failover cannot start because the source-side precheck failed. reason: Mediator not configured.
05:50:42 05:50:43 Cause: Mediator is not configured or there are network connectivity issues. Solution: If Mediator is not configured, you must configure Mediator before you can establish an SM-BC relationship. Fix any network connectivity issues. Make sure Mediator is connected and quorum status is true on both the source and destination site using the snapmirror mediator show
command. Example: cluster::> snapmirror mediator show
Mediator Address Peer Cluster Connection Status Quorum Status
---------------- ---------------- ----------------- -------------
10.234.10.143 cluster2 connected true Automatic unplanned failover not triggered on Site
BIssue: A failure on Site A does not trigger an unplanned failover on Site B. Possible cause #1: Mediator is not configured. To determine if this is the cause, issue the snapmirror mediator show command on the Site B cluster. Example: Cluster2::*> snapmirror mediator show
This table is currently empty. This example indicates that Mediator is not configured on Site B. Solution: Ensure that Mediator is configured on both clusters, that the status is connected, and quorum
is set to True. Possible cause #2: SnapMirror consistency group is out of sync. To determine if this is the cause, view the event log to view if the consistency group was in sync during the time at which the Site A failure occurred. Example: cluster::*> event log show -event *out.of.sync*
Time Node Severity Event
------------------- ---------------- ------------- ---------------------------
10/1/2020 23:26:12 sti42-vsim-ucs511w ERROR sms.status.out.of.sync: Source volume "vs0:zrto_cg_556844_511u_RW1" and destination volume "vs1:zrto_cg_556881_511w_DP1" with relationship UUID "55ab7942-03e5-11eb-ba5a-005056a7dc14" is in "out-of-sync" status due to the following reason: "Transfer failed." Solution: Complete the following steps to perform a forced failover on Site B. Unmap all LUNs belonging to the consistency group from Site B. Delete the SnapMirror consistency group relationship using the force option. Enter the snapmirror break command on the consistency group constituent volumes to convert volumes from DP to R/W, to enable I/O from Site B. Boot up the Site A nodes to create a zero RTO relationship from Site B to Site A. Release the consistency group with relationship-info-only on Site A to retain common Snapshot copy and unmap the LUNs belonging to the consistency group. -
Convert volumes on Site A from R/W to DP by setting up a volume level relationship using either the Sync policy or Async policy. Issue the snapmirror resync to synchronize the relationships. Delete the SnapMirror relationships with the Sync policy on Site A. Release the SnapMirror relationships with Sync policy using relationship-info-only true on Site B. Create a consistency group relationship from Site B to Site A. Perform a consistency group
resync from Site A, and then verify that the consistency group is in sync. Rescan host LUN I/O paths to restore all paths to the LUNs.
To check on the connection of the Mediator, use the snapmirror mediator show command. If the connection status is unreachable and Site B is
unable to reach Site B, you will have an output similar to the one below. Follow the steps in the solution to restore connection Example: cluster::*> snapmirror mediator show
Mediator Address Peer Cluster Connection Status Quorum Status
---------------- ---------------- ----------------- -------------
10.237.86.17 C1_cluster unreachable true
SnapMirror consistency group relationship status is out of sync.
C2_cluster::*> snapmirror show -expand
Source Destination Mirror Relationship Total Last
Path Type Path State Status Progress Healthy Updated
----------- ---- ------------ ------- -------------- --------- ------- --------
vs0:/cg/src_cg_1 XDP vs1:/cg/dst_cg_1 Snapmirrored OutOfSync - false -
vs0:zrto_cg_655724_188a_RW1 XDP vs1:zrto_cg_655755_188c_DP1 Snapmirrored OutOfSync - false -
vs0:zrto_cg_655733_188a_RW2 XDP vs1:zrto_cg_655762_188c_DP2 Snapmirrored OutOfSync - false -
vs0:zrto_cg_655739_188b_RW1 XDP vs1:zrto_cg_655768_188d_DP1 Snapmirrored OutOfSync - false -
vs0:zrto_cg_655748_188b_RW2 XDP vs1:zrto_cg_655776_188d_DP2 Snapmirrored OutOfSync - false -
5 entries were displayed.
Site B cluster is unable to reach Site A.
C2_cluster::*> cluster peer show
Peer Cluster Name Cluster Serial Number Availability Authentication
------------------------- --------------------- -------------- --------------
C1_cluster 1-80-000011 Unavailable ok Solution Force a failover to enable I/O from Site B and then establish a zero RTO relationship from Site B to Site A. Complete the following steps to perform a forced failover on Site B. Unmap all LUNs belonging to the consistency group from Site B. Delete the
SnapMirror consistency group relationship using the force option. Enter the snapmirror break command on the consistency group constituent volumes to convert volumes from DP to RW, to enable I/O from Site B. Boot up the Site A nodes to create a zero RTO relationship from Site B to Site A. Release the consistency group with relationship-info-only on Site A to retain common Snapshot copy and unmap the LUNs belonging to the consistency group. -
Convert volumes on Site A from RW to DP by setting up a volume level relationship using either Sync policy or Async policy. Issue the snapmirror resync to synchronize the relationships. Delete the SnapMirror relationships with Sync policy on Site A. Release the SnapMirror relationships with Sync policy using relationship-info-only true on Site B. Create a consistency group relationship from Site B to Site A. Perform a
consistency group resync from Site A, and then verify that the consistency group is in sync. Rescan host LUN I/O paths to restore all paths to the LUNs.
When using SM-BC, you may lose connectivity between the mediator or your peered clusters. You can diagnose the issue by
checking the connection, availability, and consensus status of the different parts of the SM-BC relationship and then forcefully resuming connection. Determining the cause: Check the status of Mediator from Site A with the snapmirror mediator show command. Example: C1_cluster::*> snapmirror mediator show
Mediator Address Peer Cluster Connection Status Quorum Status
---------------- ---------------- ----------------- -------------
10.237.86.17 C2_cluster unreachable true
C1_cluster::*> snapmirror list-destinations
Progress
Source Destination Transfer Last Relationship
Path Type Path Status Progress Updated Id
----------- ----- ------------ ------- --------- ------------ ---------------
vs0:/cg/src_cg_1 XDP vs1:/cg/dst_cg_1 OutOfSync - - bba7d354-06f6-11eb-9138-005056acec19Check Site B connectivity with the cluster peer show command: C1_sti78-vsim-ucs188a_cluster::*> cluster peer show
Peer Cluster Name Cluster Serial Number Availability Authentication
------------------------- --------------------- -------------- --------------
C2_cluster 1-80-000011 Unavailable ok Check the consensus status on the SM-BC volume with the command volume show volume_name -fields smbc-consensus: C1_cluster::*> volume show zrto_cg_894191_188b_RW1 -fields smbc-consensus
vserver volume smbc-consensus
------- ----------------------- ------------------
vs0 zrto_cg_894191_188b_RW1 Awaiting-consensus Solution:
Complete the following steps to override SM-BC consensus and forcefully resume I/O on Site A: Unmap the LUNs on Site A. Issue the snapmirror release command using the -force and override-smbc-consensus option on Site A. Remap the LUNs. First, bring up Mediator, and then bring up the Site B nodes. Resync the consistency group relationship using snapmirror resync. After Site B is up, verify that the consistency group
relationship is up and is in sync. Perform a LUN rescan on the host to restore all paths to the LUNs.
Volume move operation stuck when primary is downIssue: A volume move operation is stuck indefinitely in cutover deferred state when the primary site is down in an SM-BC
relationship.
When the primary site is down, the secondary site performs an automatic unplanned failover (AUFO). When a volume move operation is in progress when the AUFO is triggered the volume move becomes stuck. Solution: Abort the volume move instance that is stuck and restart the volume move operation. SnapMirror release fails when unable to delete Snapshot copyIssue: The SnapMirror release operation fails when the Snapshot copy cannot be deleted.
Solution: The Snapshot copy contains a transient tag. Use the snapshot delete command with the -ignore-owners option to remove the transient Snapshot copy.
snapshot delete -volume <volume_name> -snapshot <snapshot_name> -ignore-owners true -force true Retry the snapmirror release command. Volume move reference Snapshot copy shows as the newestIssue: After performing a volume move operation on a consistency group volume, the volume move reference
Snapshot copy might display as the newest for the SnapMirror relationship. You can view the newest Snapshot copy with the following command: snapmirror show -fields newest-snapshot status -expand
Solution: Manually perform a snapmirror resync or wait for the next automatic resync operation after the volume move operation completes. To install the ONTAP Mediator service, you must ensure all prerequisites are met, get the installation package and run the installer on the host. This
procedure is used for an installation or an upgrade of an existing installation. About this task Beginning with ONTAP 9.7, you can use any version of ONTAP Mediator to monitor a MetroCluster IP configuration. Beginning with ONTAP 9.8, you can use any version of ONTAP Mediator to monitor an SM-BC relationship.
Before you begin You must meet the following prerequisites.
|
| The kernel version must match the operating system version.
|
The following table provides the upgrade guidelines if you are upgrading from RHEL/CentOS 7.6 to a later RHEL/CentOS
release in addition upgrading the Mediator version.
Target Linux version | Target Mediator version | Upgrade notes |
|---|
|
| 1.2
|
| Red Hat Enterprise Linux: 7.6, 7.7, 7.8, 7.9, 8.1, 8.2, 8.3 CentOS: 7.6, 7.7, 7.8, 7.9
| 1.3
| Upgrade the operating system from RHEL/CentOS version. Reboot the host to apply the kernel module changes. Upgrade the Mediator from the immediately prior version to the current version.
| Red Hat Enterprise Linux: 7.6, 7.7, 7.8, 7.9, 8.1, 8.2, 8.3, 8.4, 8.5 CentOS: 7.6, 7.7, 7.8, 7.9
| 1.4
| Upgrade the operating system from RHEL/CentOS version. Reboot the host to apply the kernel module changes. Upgrade the Mediator from the immediately prior version to the current version.
|
The best practices for installing Red Hat Enterprise Linux or CentOS and the associated repositories on your system are listed below. Systems installed or configured differently might require additional steps. You must install Red Hat Enterprise Linux or CentOS according to Red Hat best practices. Due to end-of-life support for CentOS 8.x versions, compatible versions of CentOS 8.x are not recommended. While installing the ONTAP
Mediator service on Red Hat Enterprise Linux or CentOS, the system must have access to the appropriate repository so that the installation program can access and install all the required software dependencies. For the yum installer to find dependent software in the Red Hat Enterprise Linux repositories, you must have registered the system during the Red Hat Enterprise Linux installation or afterwards by using a valid Red Hat subscription. See the Red Hat documentation for
information about the Red Hat Subscription Manager. The following ports must be unused and available for the Mediator: If using a third-party firewall: refer to Firewall requirements for ONTAP Mediator If the
Linux host is in a location without access to the internet, you must ensure that the required packages are available in a local repository. If you are using Link Aggregation Control Protocol (LACP) in a Linux environment, you must correctly configure the kernel and make sure the sysctl net.ipv4.conf.all.arp_ignore is set to "2". The following packages are required by the ONTAP Mediator service:
All RHEL/CentOS versions | Additional packages for RHEL/CentOS 7.x | Additional packages for RHEL 8.x |
|---|
openssl openssl-devel kernel-devel gcc libselinux-utils make redhat-lsb-core patch bzip2 python36 python36-devel perl-Data-Dumper perl-ExtUtils-MakeMaker python3-pip
| policycoreutils-python python36-pip
|
|
The Mediator installation package is a self-extracting compressed tar file that includes: A valid SSL certification is recommended, as documented in this procedure. Enable access to the repositories
If your operating system is… | You must provide access to these repositories… |
|---|
RHEL 7.x
| rhel-7-server-optional-rpms
| CentOS 7.x
| C7.6.1810 - Base repository
| RHEL 8.x
|
|
Enable access to the repositories listed above so Mediator can access the required packages during the installation process. Use the procedure below for your operating system. Procedure for RHEL 7.x operating system. Procedure for
RHEL 8.x operating system. Procedure for CentOS 7.x operating system.
Procedure for RHEL 7.x operating systemIf your operating system is RHEL 7.x: Steps Subscribe to the required repository: subscription-manager repos --enable rhel-7-server-optional-rpms
The following example shows the execution of this command: [root@localhost ~]# subscription-manager repos --enable rhel-7-server-optional-rpms
Repository 'rhel-7-server-optional-rpms' is enabled for this system. -
Run the yum repolist command. The following example shows the execution of this command. The "rhel-7-server-optional-rpms" repository should appear in the list. [root@localhost ~]# yum repolist
Loaded plugins: product-id, search-disabled-repos, subscription-manager
rhel-7-server-optional-rpms | 3.2 kB 00:00:00
rhel-7-server-rpms | 3.5 kB 00:00:00
(1/3): rhel-7-server-optional-rpms/7Server/x86_64/group | 26 kB 00:00:00
(2/3): rhel-7-server-optional-rpms/7Server/x86_64/updateinfo | 2.5 MB 00:00:00
(3/3): rhel-7-server-optional-rpms/7Server/x86_64/primary_db | 8.3 MB 00:00:01
repo id repo name status
rhel-7-server-optional-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server - Optional (RPMs) 19,447
rhel-7-server-rpms/7Server/x86_64 Red Hat Enterprise Linux 7 Server (RPMs) 26,758
repolist: 46,205
[root@localhost ~]#
Procedure for RHEL 8.x operating systemIf
your operating system is RHEL 8.x: Steps Subscribe to the required repository: subscription-manager repos --enable rhel-8-for-x86_64-baseos-rpms
subscription-manager repos --enable rhel-8-for-x86_64-appstream-rpms
The following example shows the execution of this command: [root@localhost ~]# subscription-manager repos --enable rhel-8-for-x86_64-baseos-rpms
[root@localhost ~]# subscription-manager repos --enable rhel-8-for-x86_64-appstream-rpms
Repository 'rhel-8-for-x86_64-baseos-rpms' is enabled for this system.
Repository 'rhel-8-for-x86_64-appstream-rpms' is enabled for this system. Run the yum repolist command. The newly subscribed repositories should appear in the list.
Procedure for CentOS 7.x operating systemIf your operating system is CentOS 7.x:
|
| The following examples are showing a repository for CentOS 7.6 and may not work for other CentOS versions. Use the base repository for your version of CentOS.
|
Steps Add the C7.6.1810 - Base repository. The C7.6.1810 - Base vault repository contains the kernel-devel package needed for ONTAP Mediator. Add the following lines to /etc/yum.repos.d/CentOS-Vault.repo. [C7.6.1810-base]
name=CentOS-7.6.1810 - Base
baseurl=http://vault.centos.org/7.6.1810/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
enabled=1 Run the yum repolist command. The following example shows the execution of this command. The CentOS-7.6.1810 - Base repository should appear in the list. Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: distro.ibiblio.org
* extras: distro.ibiblio.org
* updates: ewr.edge.kernel.org
C7.6.1810-base | 3.6 kB 00:00:00
(1/2): C7.6.1810-base/x86_64/group_gz | 166 kB 00:00:00
(2/2): C7.6.1810-base/x86_64/primary_db | 6.0 MB 00:00:04
repo id repo name status
C7.6.1810-base/x86_64 CentOS-7.6.1810 - Base 10,019
base/7/x86_64 CentOS-7 - Base 10,097
extras/7/x86_64 CentOS-7 - Extras 307
updates/7/x86_64 CentOS-7 - Updates 1,010
repolist: 21,433
[root@localhost ~]#
Steps Download the Mediator installation package from the ONTAP Mediator
page. Confirm that the Mediator installation package is in the target directory: ls
[root@mediator-host ~]#ls
ontap-mediator If you are at a location without access to the internet, you must ensure that the installer has access to the required packages. If necessary, move the Mediator installation package from the download directory to the installation directory on the Linux Mediator host.
About this task Step Install the Mediator installation package and respond to the prompts as required: ./ontap-mediator
The installation process proceeds to create the required accounts and install required packages. If you have a previous version of Mediator installed on the host, you will be prompted to confirm that you want to upgrade.
Example of ONTAP Mediator 1.4 installation (console output)
[root@scs000065018 ~]# ./ontap-mediator
ONTAP Mediator: Self Extracting Installer
ONTAP Mediator requires two user accounts. One for the service (netapp), and one for use by ONTAP to the mediator API (mediatoradmin).
Would you like to use the default account names: netapp + mediatoradmin? (Y(es)/n(o)): y
Enter ONTAP Mediator user account (mediatoradmin) password:
Re-Enter ONTAP Mediator user account (mediatoradmin) password:
Checking if SELinux is in enforcing mode
Checking for default Linux firewall
Linux firewall is running. Open ports 31784 and 3260? y(es)/n(o): y
success
success
Preparing for installation of ONTAP Mediator packages.
Do you wish to continue? Y(es)/n(o): y
+ Installing required packages.
Last metadata expiration check: 1:56:17 ago on Thu 07 Apr 2022 11:35:42 AM EDT.
Package openssl-1:1.1.1k-6.el8_5.x86_64 is already installed.
Package openssl-devel-1:1.1.1k-6.el8_5.x86_64 is already installed.
.
.
.
.
Dependencies resolved.
Nothing to do.
Complete!
OS package installations finished
+ Installing ONTAP Mediator. (Log: /tmp/ontap_mediator.5gmxnI/ontap-mediator/install_20220407133105.log)
This step will take several minutes. Use the log file to view progress.
Sudo include verified
ONTAP Mediator logging enabled
+ Install successful. (Moving log to /opt/netapp/lib/ontap_mediator/log/install_20220407133105.log)
+ WARNING: This system supports UEFI
Secure Boot (SB) is currently enabled on this system.
The following action need be taken:
Using the keys in /opt/netapp/lib/ontap_mediator/ontap_mediator/SCST_mod_keys follow
instructions in /opt/netapp/lib/ontap_mediator/ontap_mediator/SCST_mod_keys/README.module-signing
to sign the SCST kernel module. Note that reboot will be needed.
SCST will not start automatically when Secure Boot is enabled and not configured properly.
+ Note: ONTAP Mediator uses a kernel module compiled specifically for the current
system OS. Using 'yum update' to upgrade the kernel may cause a service
interruption.
For more information, see /opt/netapp/lib/ontap_mediator/README
[root@scs000065018 ~]#Verify the installationSteps Run the following commands to view the status of the ONTAP Mediator services: Run:
systemctl status ontap_mediator [root@scspr1915530002 ~]# systemctl status ontap_mediator
ontap_mediator.service - ONTAP Mediator
Loaded: loaded (/etc/systemd/system/ontap_mediator.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2022-04-18 10:41:49 EDT; 1 weeks 0 days ago
Process: 286710 ExecStop=/bin/kill -s INT $MAINPID (code=exited, status=0/SUCCESS)
Main PID: 286712 (uwsgi)
Status: "uWSGI is ready"
Tasks: 3 (limit: 49473)
Memory: 139.2M
CGroup: /system.slice/ontap_mediator.service
├─286712 /opt/netapp/lib/ontap_mediator/pyenv/bin/uwsgi --ini /opt/netapp/lib/ontap_mediator/uwsgi/ontap_mediator.ini
├─286716 /opt/netapp/lib/ontap_mediator/pyenv/bin/uwsgi --ini /opt/netapp/lib/ontap_mediator/uwsgi/ontap_mediator.ini
└─286717 /opt/netapp/lib/ontap_mediator/pyenv/bin/uwsgi --ini /opt/netapp/lib/ontap_mediator/uwsgi/ontap_mediator.ini
[root@scspr1915530002 ~]#Run: systemctl status mediator-scst [root@scspr1915530002 ~]# systemctl status mediator-scst
Loaded: loaded (/etc/systemd/system/mediator-scst.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2022-04-18 10:41:47 EDT; 1 weeks 0 days ago
Process: 286595 ExecStart=/etc/init.d/scst start (code=exited, status=0/SUCCESS)
Main PID: 286662 (iscsi-scstd)
Tasks: 1 (limit: 49473)
Memory: 1.2M
CGroup: /system.slice/mediator-scst.service
└─286662 /usr/local/sbin/iscsi-scstd
[root@scspr1915530002 ~]#
Confirm the ports the ONTAP Mediator service is using: netstat [root@scspr1905507001 ~]# netstat -anlt | grep -E '3260|31784'
tcp 0 0 0.0.0.0:31784 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3260 0.0.0.0:* LISTEN
tcp6 0 0 :::3260 :::* LISTEN
After you have installed ONTAP Mediator service, you may change the user name or password. You may also uninstall the ONTAP Mediator Service. Change the user nameAbout these tasks These task is performed on the Linux host on which the ONTAP Mediator service is installed. If you are unable to reach this command, you might need to run the command using the full
path as shown in the following example: /usr/local/bin/mediator_username
Procedure Change the username by choosing one of the following options: Run the command mediator_change_user and respond to the prompts as shown in the following example: [root@mediator-host ~]# mediator_change_user
Modify the Mediator API username by entering the following values:
Mediator API User Name: mediatoradmin
Password:
New Mediator API User Name: mediator
The account username has been modified successfully.
[root@mediator-host ~]#Run the following command: MEDIATOR_USERNAME=mediator MEDIATOR_PASSWORD=mediator2 MEDIATOR_NEW_USERNAME=mediatoradmin mediator_change_user
[root@mediator-host ~]# MEDIATOR_USERNAME= mediator MEDIATOR_PASSWORD='mediator2' MEDIATOR_NEW_USERNAME= mediatoradmin mediator_change_user
The account username has been modified successfully.
[root@mediator-host ~]#
Change the passwordAbout this task This task is performed on the Linux host on which the ONTAP Mediator service is installed. If you are unable to reach this command, you might need to run the command using the full path as
shown in the following example: /usr/local/bin/mediator_change_password
Procedure Change the password by choosing one of the following options: Run the mediator_change_password command and respond to the prompts as shown in the following example: [root@mediator-host ~]# mediator_change_password
Change the Mediator API password by entering the following values:
Mediator API User Name: mediatoradmin
Old Password:
New Password:
Confirm Password:
The password has been updated successfully.
[root@mediator-host ~]#Run the following command: MEDIATOR_USERNAME= mediatoradmin MEDIATOR_PASSWORD=mediator1 MEDIATOR_NEW_PASSWORD=mediator2 mediator_change_password
The example shows the password is changed from "mediator1" to "mediator2". [root@mediator-host ~]# MEDIATOR_USERNAME=mediatoradmin MEDIATOR_PASSWORD=mediator1 MEDIATOR_NEW_PASSWORD=mediator2 mediator_change_password
The password has been updated successfully.
[root@mediator-host ~]#
Before you begin If necessary, you can remove the ONTAP Mediator service. The Mediator must be disconnected from ONTAP before you remove the Mediator service.
About this task This task is performed on the Linux host on which the ONTAP Mediator service is installed. If you are unable to reach this command, you might need to run the command using the full path as shown in the following example: /usr/local/bin/uninstall_ontap_mediator
Step Uninstall the ONTAP Mediator service: uninstall_ontap_mediator
[root@mediator-host ~]# uninstall_ontap_mediator
ONTAP Mediator: Self Extracting Uninstaller
+ Removing ONTAP Mediator. (Log: /tmp/ontap_mediator.GmRGdA/uninstall_ontap_mediator/remove.log)
+ Remove successful.
[root@mediator-host ~]#
MetroCluster site management overview with ONTAP System ManagerBeginning with ONTAP 9.8, you can use ONTAP System Manager as a simplified interface for
managing a configuration of a MetroCluster setup. A MetroCluster configuration allows two clusters to mirror data to each other so if one cluster goes down, the data isn’t lost. Typically, an organization sets up the clusters in two separate geographical locations. An administrator at each location sets up a cluster and configures it. Then one of the administrators can set up the peering between the clusters so that they can share data. The organization can also install an
ONTAP Mediator in a third location. The ONTAP Mediator service monitors the status of each cluster. When one of the clusters detects that it cannot communicate with the partner cluster, it queries the monitor to determine if the error is a problem with the cluster system or with the network connection. If the problem is with the network connection, the system administrator performs troubleshooting methods to correct the error and reconnect. If the partner cluster is down, the other cluster
initiates a switchover process to control the data I/O for both clusters. You can also perform a switchover to bring down one of the cluster systems for planned maintenance. The partner cluster handles all data I/O operations for both clusters until you bring up the cluster on which you performed maintenance and perform a switchback operation. You can manage the following operations: Set up an IP MetroCluster site Set up IP MetroCluster peering Configure an IP MetroCluster
site Perform IP MetroCluster switchover and switchback Troubleshoot problems with IP MetroCluster configurations Upgrade ONTAP on MetroCluster clusters
Set up an IP MetroCluster
siteBeginning with ONTAP 9.8, you can use ONTAP System Manager to set up an IP configuration of a MetroCluster site. A MetroCluster site consists of two clusters. Typically, the clusters are located in different geographical locations. Before you start Your system should already be installed and cabled according to the
Installation and Setup Instructions that came with the system. Cluster network interfaces should be configured on each node of each cluster for intra-cluster communication.
Assign a node-management IP addressWindows SystemYou should connect your Windows computer to the same subnet as the controllers. This will automatically assign a node-management IP address to your system. Steps From the Windows system, open the
Network drive to discover the nodes. Double-click the node to launch the cluster setup wizard.
Other systemsYou should configure the node-management IP address for one of
the nodes in your cluster. You can use this node-management IP address to launch the cluster set up wizard.
You initialize the cluster by setting an administrative password for the cluster and setting up the cluster management and node management networks. You can also configure services like a DNS server to resolve host names and an NTP server to synchronize time. Steps On a web browser, enter the node-management IP address that you have configured: "https://node-management-IP" ONTAP System Manager automatically discovers the remaining nodes in the cluster. In the Initialize Storage System window, perform the following: Enter cluster management network configuration data. Enter Node management IP addresses for all the nodes. Provide domain name servers (DNS) details. In the Other section, select the check box labeled Use time service (NTP) to add the time servers.
When you click
Submit, wait for the cluster to be created and configured. Then, a validation process occurs. What’s Next? After both clusters have been set up, initialized, and configured, perform the following procedure: Set up IP MetroCluster peeringBeginning with ONTAP 9.8, you can manage an IP configuration of a MetroCluster operation with ONTAP System Manager. After setting up two clusters, you set up peering
between them. Before you start You should have completed the following procedure to set up two clusters: Certain steps of this process are performed by different system administrators located at the geographical sites of each cluster. For the purposes of explaining this
process, the clusters are called "Site A cluster" and "Site B cluster". This process is
performed by a system administrator at Site A. Steps Log in to Site A cluster. In ONTAP System Manager, select Dashboard from the left navigation column to display the cluster overview. The dashboard shows the details for this cluster (Site A). In the MetroCluster section, Site A cluster is shown on the left. Click Attach Partner Cluster. Enter the details of the network
interfaces that allow the nodes in Site A cluster to communicate with the nodes in Site B cluster. Click Save and Continue. On the Attach Partner Cluster window, select I do not have a passphrase, which lets you generate a passphrase. Copy the generated passphrase and share it with the system administrator at Site B. Select Close.
This process is performed by a system administrator at Site B. Steps Log in to
Site B cluster. In ONTAP System Manager, select Dashboard to display the cluster overview. The dashboard shows the details for this cluster (Site B). In the MetroCluster section, Site B cluster is shown on the left. Click Attach Partner Cluster to start the peering process. Enter the details of the network interfaces that allow the nodes in Site B cluster to communicate with the nodes in Site A cluster. Click Save and Continue. On the Attach Partner Cluster window, select I have a passphrase, which lets you enter the passphrase that you received from the system administrator at Site A. Select Peer to complete the peering process.
Beginning with ONTAP 9.8, you can manage an IP configuration of a MetroCluster operation with ONTAP System Manager. After setting up two clusters and peering them, you configure each cluster.
Before you start You should have completed the following procedures: Steps Log in to ONTAP System Manager on one of the sites, and select
Dashboard. In the MetroCluster section, the graphic shows the two clusters that you set up and peered for the MetroCluster sites. The cluster you are working from (local cluster) is shown on the left. Click Configure MetroCluster. From this window, you can perform the following tasks: The nodes for each cluster in the MetroCluster configuration are shown. Use the drop-down lists to select which
nodes in the local cluster will be disaster recovery partners with which nodes in the remote cluster. Click the check box if you want to configure an ONTAP Mediator service. See Configure the ONTAP Mediator service. If both clusters have a license to enable encryption, the Encryption section is displayed.
To enable encryption, enter a passphrase. Click the check box if you want to configure MetroCluster with shared layer 3 network.
|
| The HA partner nodes and network switches connecting to the nodes must have a matching configuration.
|
Click Save to configure the MetroCluster sites. On the Dashboard, in the MetroCluster section, the graphic shows a check mark on the link between the two clusters, indicating a healthy connection.
The ONTAP Mediator service is typically installed at a geographic location separate from either location of the clusters. The clusters communicate regularly with the service to
indicate that they are up and running. If one of the clusters in the MetroCluster configuration detects that the communication with its partner cluster is down, it checks with the ONTAP Mediator to determine if the partner cluster itself is down. Before you start Both clusters at the MetroCluster sites should be up and peered. Steps In ONTAP System Manager in ONTAP 9.8, select Cluster > Settings. In the
Mediator section, click . On the Configure Mediator window, click Add+. Enter the configuration details for the ONTAP Mediator.
You can switch over control from one IP MetroCluster site to the other to perform maintenance or recover from an issue.
|
| Switchover and switchback procedures are supported only for IP MetroCluster configurations.
|
Overview of switchover and switchbackA switchover can occur in two instances: A planned
switchover This switchover is initiated by a system administrator using ONTAP System Manager. The planned switchover allows a system administrator of a local cluster to switch control so that the data services of the remote cluster are handled by the local cluster. Then, a system administrator at the remote cluster location can perform maintenance on the remote cluster. An unplanned switchover In some cases, when a MetroCluster cluster goes
down or the connections between the clusters are down, ONTAP will automatically initiate a switchover procedure so that the cluster that is still running handles the data handling responsibilities of the down cluster. At other times, when ONTAP cannot determine the status of one of the clusters, the system administrator of the site that is working initiates the switchover procedure to take control of the data handling responsibilities of the other site.
For any type
of switchover procedure, the data servicing capability is returned to the cluster by using a switchback process. You perform different switchover and switchback processes for ONTAP 9.7 and 9.8: Use ONTAP System Manager in ONTAP 9.7 for
switchover and switchbackSteps Log in to ONTAP System Manager in ONTAP 9.7. Click (Return to classic version). Click Configuration > MetroCluster. ONTAP System Manager verifies whether a negotiated switchover is possible. Perform one of the following substeps when the validation process has completed: If validation fails, but Site B is up, then an
error has occurred. For example, there might be a problem with a subsystem, or NVRAM mirroring might not be synchronized. Fix the issue that is causing the error, click Close, and then start again at Step 2. Halt the Site B nodes, click Close, and then perform the steps in Performing an unplanned
switchover.
If validation fails, and Site B is down, then most likely there is a connection problem. Verify that Site B is really down, then perform the steps in Performing an unplanned switchover.
Click Switchover from Site B to Site A to initiate the switchover process. Click
Switch to the new experience.
Use ONTAP System Manager in ONTAP 9.8 for switchover and switchbackPerform a planned switchover (ONTAP 9.8)Steps Log in to ONTAP System Manager in ONTAP 9.8. Select Dashboard. In the MetroCluster section, the
two clusters are shown with a connection. In the local cluster (shown on the left), click , and select Take control of remote site. After the switchover request is validated, control is transferred from the remote site to the local site, which performs data service requests for both clusters. The remote cluster reboots, but the
storage components are not active, and the cluster does not service data requests. It is now available for planned maintenance.
|
| The remote cluster should not be used for data servicing until you perform a switchback.
|
Perform an unplanned switchover (ONTAP 9.8)An unplanned switchover might be initiated automatically by ONTAP. If
ONTAP cannot determine if a switchback is needed, the system administrator of the MetroCluster site that is still running initiates the switchover with the following steps: Steps Log in to ONTAP System Manager in ONTAP 9.8. Select Dashboard. In the MetroCluster section, the connection between the two clusters is shown with an "X" on it, meaning a connection cannot be detected. Either the connections or the cluster is
down. In the local cluster (shown on the left), click , and select Take control of remote site. After the switchover request is validated, control is transferred from the remote site to the local site, which performs data service requests for both clusters. The cluster must be repaired before it is brought online again.
|
| After the remote cluster is brought online again, it should not be used for data servicing until you perform a switchback.
|
Perform a switchback (ONTAP 9.8)Before you start Whether the remote cluster was down due to planned maintenance or due to a disaster,
it should now be up and running and waiting for the switchback. Steps On the local cluster, log in to ONTAP System Manager in ONTAP 9.8. Select Dashboard. In the MetroCluster section, the two clusters are shown. In the local cluster (shown on the left), click , and select
Take back control. The data is healed first, to ensure data is synchronized and mirrored between both clusters. When the data healing is complete, click , and select Initiate switchback. When the switchback is complete, both clusters are active and servicing data requests. Also, the data is being mirrored
and synchronized between the clusters.
Modify address, netmask, and
gateway in a MetroCluster IPBeginning with ONTAP 9.10.1, you can change the following properties of a MetroCluster IP interface: IP address and mask, and gateway. You can use any combination of parameters to update. You might need to update these properties, for example, if a duplicate IP address is detected or if a gateway needs to change in the case of a layer 3 network due to router configuration changes. You can only change one interface at a time. There will be
traffic disruption on that interface until the other interfaces are updated and connections are reestablished.
|
| You must make the changes on each port. Similarly, network switches also need to update their configuration. For example, if the gateway is updated, ideally it is changed on both nodes of an HA pair, since they are same. Plus the switch connected to those nodes also needs to update its gateway.
|
Step Update the IP address, netmask, and gateway for a each node and interface. Troubleshoot problems with IP MetroCluster
configurationsBeginning with ONTAP 9.8, ONTAP System Manager monitors the health of IP MetroCluster configurations and helps you identify and correct problems that might occur. Overview of the MetroCluster Health CheckONTAP System Manager periodically checks the health of your IP MetroCluster configuration. When you view the MetroCluster section in the Dashboard, usually the
message is "MetroCluster systems are healthy." However, when a problem occurs, the message will show the number of events. You can click on that message and view the results of the health check for the following components: The Status column identifies
which components have problems, and the Details column suggests how to correct the problem. MetroCluster troubleshootingSteps In ONTAP
System Manager, select Dashboard. In the MetroCluster section, notice the message. If the message indicates that your MetroCluster configuration is healthy, and the connections between the clusters and the ONTAP Mediator are healthy (shown with check marks), then you have no problems to correct. If the message lists the number of events, or the connections have gone down (shown with an "X"), then continue
to the next step.
Click the message that shows the number of events. The MetroCluster Health Report displays. Troubleshoot the problems that appear in the report using the suggestions in the Details column. When all the problems have been corrected, click Check MetroCluster Health.
|
| The MetroCluster Health Check uses an intensive amount of resources, so it is recommended that you perform all your troubleshooting tasks before running the check.
|
The MetroCluster Health Check runs in the background. You can work on other tasks while you wait for it to finish.
Tape backup of FlexVol volumes overview
ONTAP supports tape backup and restore through Network Data Management Protocol (NDMP). NDMP allows you to back up data in storage systems directly to tape, resulting in efficient use of network bandwidth. ONTAP supports both dump and SMTape engines for tape backup. You can perform a dump or SMTape backup or restore by using NDMP-compliant backup applications. Only NDMP version 4 is supported. Tape backup using dumpDump is a Snapshot copy based backup in which your file system data is backed up to tape. The ONTAP dump engine backs up files, directories, and the applicable access control list (ACL) information to tape. You can back
up an entire volume, an entire qtree, or a subtree that is not an entire volume or an entire qtree. Dump supports baseline, differential, and incremental backups. Tape backup using SMTape
SMTape is a Snapshot copy based disaster recovery solution from ONTAP that backs up blocks of data to tape. You can use SMTape to perform volume backups to tapes. However, you cannot perform a backup at the qtree or subtree level. SMTape supports baseline, differential, and incremental backups. Tape backup and restore workflowYou can perform tape backup and restore operations by using an NDMP-enabled backup application. About this task The tape backup and restore workflow provides an
overview of the tasks that are involved in performing tape backup and restore operations. For detailed information about performing a backup and restore operation, see the backup application documentation. Steps Set up a tape library configuration by choosing an NDMP-supported tape topology. Enable NDMP services on your storage system. You can enable the NDMP services either at the node level or at the storage virtual machine (SVM) level. This
depends on the NDMP mode in which you choose to perform the tape backup and restore operation. Use NDMP options to manage NDMP on your storage system. You can use NDMP options either at the node level or at the SVM level. This depends on the NDMP mode in which you choose to perform the tape backup and restore operation. You can modify the NDMP options at the node level by using the system services ndmp modify command and at the SVM level by using the vserver services ndmp modify command. For more
information about these commands, see the man pages. Perform a tape backup or restore operation by using an NDMP-enabled backup application. ONTAP supports both dump and SMTape engines for tape backup and restore. For more information about using the backup application (also called Data Management Applications or DMAs) to perform backup or restore operations, see your backup application documentation.
Use cases for choosing a tape backup engineONTAP supports two backup engines: SMTape and dump. You should be aware of the use cases for the
SMTape and dump backup engines to help you choose the backup engine to perform tape backup and restore operations. Dump can be used in the following cases: Direct Access Recovery (DAR) of files and directories Backup of a subset of subdirectories or files in a specific path Excluding specific files and directories during backups Preserving backup for long durations
SMTape can be used in the following
cases: Manage tape drives overviewYou can verify tape library connections and view tape drive information before performing a tape backup or restore operation. You can use a nonqualified tape drive by emulating this to a qualified
tape drive. You can also assign and remove tape aliases in addition to viewing existing aliases. When you back up data to tape, the data is stored in tape files. File marks separate the tape files, and the files have no names. You specify a tape file by its position on the tape. You write a tape file by using a tape device. When you read the tape file, you must specify a device that has the same compression type that you used to write that tape file. There are
commands for viewing information about tape drives and media changers in a cluster, bringing a tape drive online and taking it offline, modifying the tape drive cartridge position, setting and clearing tape drive alias name, and resetting a tape drive. You can also view and reset tape drive statistics.
| If you want to… | Use this command… |
|---|
Bring a tape drive online
| storage tape online
| Clear an alias name for tape drive or media changer
| storage tape alias clear
| Enable or disable a tape trace operation for a tape drive
| storage tape trace
| Modify the tape drive cartridge position
| storage tape position
| Reset a tape drive
| storage tape reset
|
| This command is available only at the advanced privilege level.
|
| Set an alias name for tape drive or media changer
| storage tape alias set
| Take a tape drive offline
| storage tape offline
| View information about all tape drives and media changers
| storage tape show
| View information about tape drives attached to the cluster
|
| View information about media changers attached to the cluster
| storage tape show-media-changer
| View error information about tape drives attached to the cluster
| storage tape show-errors
| View all ONTAP qualified and supported tape drives attached to each node in the cluster
| storage tape show-supported-status
| View aliases of all tape drives and media changers attached to each node in the cluster
| storage tape alias show
| Reset the statistics reading of a tape drive to zero
| storage stats tape zero tape_name
You must use this command at the nodeshell.
| View tape drives supported by ONTAP
| storage show tape supported [-v]
You must use this command at the nodeshell. You can use the -v option to view more details about each tape drive.
| View tape device statistics to understand tape performance and check usage pattern
| storage stats tape tape_name
You must use this command at the nodeshell.
|
For more information about these commands, see the man pages. Use a nonqualified tape driveYou can use a nonqualified tape drive on a
storage system if it can emulate a qualified tape drive. It is then treated like a qualified tape drive. To use a nonqualified tape drive, you must first determine whether it emulates any of the qualified tape drives. About this task A nonqualified tape drive is one that is attached to the storage system, but not supported or recognized by ONTAP. Steps View the nonqualified tape drives attached to a storage system by using the storage tape show-supported-status command.
The following command displays tape drives attached to the storage system and the support and qualification status of each tape drive. The nonqualified tape drives are also listed. “`tape_drive_vendor_name`” is a nonqualified tape drive attached to the storage system, but not supported by ONTAP. cluster1::> storage tape show-supported-status -node Node1
Node: Node1
Is
Tape Drive Supported Support Status
-------------------- --------- --------------
"tape_drive_vendor_name" false Nonqualified tape drive
Hewlett-Packard C1533A true Qualified
Hewlett-Packard C1553A true Qualified
Hewlett-Packard Ultrium 1 true Qualified
Sony SDX-300C true Qualified
Sony SDX-500C true Qualified
StorageTek T9840C true Dynamically Qualified
StorageTek T9840D true Dynamically Qualified
Tandberg LTO-2 HH true Dynamically QualifiedEmulate the qualified tape drive.
Assign tape aliasesFor easy device identification, you can assign tape aliases to a tape drive or medium changer. Aliases provide a correspondence between the logical names of backup devices and a name permanently assigned to the tape
drive or medium changer. Steps Assign an alias to a tape drive or medium changer by using the storage tape alias set command. For more information about this command, see the man pages. You can view the serial number (SN) information about the tape drives by using the system node hardware tape drive show command and about tape libraries by using the system node hardware tape library show commands. The following command sets an alias name to a tape drive with serial number SN[123456]L4 attached to the node, cluster1-01:
cluster-01::> storage tape alias set -node cluster-01 -name st3 -mapping SN[123456]L4 The following command sets an alias name to a media changer with serial number SN[65432] attached to the node, cluster1-01: cluster-01::> storage tape alias set -node cluster-01 -name mc1 -mapping SN[65432]
Remove tape
aliasesYou can remove aliases by using the storage tape alias clear command when persistent aliases are no longer required for a tape drive or medium changer. Steps Remove an alias from a tape drive or medium changer by using the storage tape alias clear command. For more information about this command, see the man pages. The following command removes the aliases of all tape drives by specifying the scope of the alias clear operation to tape: cluster-01::>storage tape alias clear -node cluster-01 -clear-scope tape
After you finish If you are performing a tape backup or restore operation using NDMP, then after you remove an alias from a tape drive or medium changer, you must assign a new alias name to the tape drive or medium changer to continue access to the tape device. Enabling or disabling tape reservationsYou can control how ONTAP manages tape device reservations by using the tape.reservations option. By default, tape reservation is turned off. About this task
Enabling the tape reservations option can cause problems if tape drives, medium changers, bridges, or libraries do not work properly. If tape commands report that the device is reserved when no other storage systems are using the device, this option should be disabled. Steps To use either the SCSI Reserve/Release mechanism or SCSI Persistent Reservationsor to disable tape reservations, enter the following commandat the clustershell: options -option-name tape.reservations -option-value {scsi | persistent | off}
scsi
selects the SCSI Reserve/Release mechanism.
persistent selects SCSI Persistent Reservations.
off disables tape reservations.
Commands for verifying tape library connectionsYou can view information about the connection path between a storage system and a tape library configuration attached to the storage
system. You can use this information to verify the connection path to the tape library configuration or for troubleshooting issues related to the connection paths. You can view the following tape library details to verify the tape library connections after adding or creating a new tape library, or after restoring a failed path in a single-path or multipath access to a tape library. You can also use this information while troubleshooting path-related errors or if access to a tape library
fails. Node to which the tape library is attached Device ID NDMP path Tape library name Target port and initiator port IDs Single-path or multipath access to a tape library for every target or FC initiator port Path-related data integrity details, such as “Path Errors” and “Path Qual” LUN groups and LUN counts
| If you want to… | Use this command… |
|---|
View information about a tape library in a cluster
| system node hardware tape library show
| View path information for a tape library
| storage tape library path show
| View path information for a tape library for every initiator port
| storage tape library path show-by-initiator
| View connectivity information between a storage tape library and cluster
| storage tape library config show
|
For more information about these commands, see the man pages. Qualified tape drives overviewYou must use a qualified tape drive that
has been tested and found to work properly on a storage system. You can follow tape aliasing and also enable tape reservations to ensure that only one storage system accesses a tape drive at any particular time. A qualified tape drive is a tape drive that has been tested and found to work properly on storage systems. You can qualify tape drives for existing ONTAP releases by using the tape configuration file. The tape configuration file format consists of fields such as vendor ID, product ID, and details of compression types for a tape drive. This file also consists of
optional fields for enabling the autoload feature of a tape drive and changing the command timeout values of a tape drive. The following table displays the format of the tape configuration file:
| Item | Size | Description |
|---|
vendor_id (string)
| up to 8 bytes
| The vendor ID as reported by the SCSI Inquiry command.
| product_id(string)
| up to 16 bytes
| The product ID as reported by the SCSI Inquiry command.
| id_match_size(number)
|
| The number of bytes of the product ID to be used for matching to detect the tape drive to be identified, beginning with the first character of the product ID in the Inquiry data.
| vendor_pretty (string)
| up to 16 bytes
| If this parameter is present, it is specified by the string displayed by the command, storage tape show -device-names; otherwise, INQ_VENDOR_ID is displayed.
| product_pretty(string)
| up to 16 bytes
| If this parameter is present, it is specified by the string displayed by the command, storage tape show -device-names; otherwise, INQ_PRODUCT_ID is displayed.
|
|
| The vendor_pretty and product_pretty fields are optional, but if one of these fields has a value, the other must also have a value.
|
The following table explains the description, density code, and compression algorithm for the various compression types, such as l, m, h, and a:
| Item | Size | Description |
|---|
{l | m | h | a}_description=(string)
| up to 24 bytes
| The string to print for the nodeshell command, sysconfig -t, that describes characteristics of the particular density setting.
| {l | m | h | a}_density=(hex codes)
|
| The density code to be set in the SCSI mode page block descriptor corresponding to the desired density code for l, m, h, or a.
| {l | m | h | a}_algorithm=(hex codes)
|
| The compression algorithm to be set in the SCSI Compression Mode Page corresponding to the density code and the desired density characteristic.
|
The following table describes the optional fields available in the tape configuration file:
| Field | Description |
|---|
autoload=(Boolean yes/no)
| This field is set to yes if the tape drive has an automatic loading feature; that is, after tape cartridge is inserted, the tape drive becomes ready without the need to execute a SCSI load (start/stop unit) command. The default for this field is no.
| cmd_timeout_0x
| Individual timeout value. You must use this field only if you want to specify a different timeout value from the one being used as a default by the tape driver. The sample file lists the default SCSI command timeout values used by the tape drive. The timeout value can be expressed in minutes (m), seconds (s), or milliseconds (ms).
|
| You should change this field only with guidance from Fujitsu Support.
|
|
You can download and view the tape configuration file from the Fujitsu Support Site. Example of a tape configuration file format The tape configuration file format for the HP LTO5 ULTRIUM tape drive is as follows: vendor_id="HP"
product_id="Ultrium 5-SCSI"
id_match_size=9
vendor_pretty="Hewlett-Packard"
product_pretty="LTO-5"
l_description="LTO-3(ro)/4 4/800GB"
l_density=0x00
l_algorithm=0x00
m_description="LTO-3(ro)/4
8/1600GB cmp"
m_density=0x00
m_algorithm=0x01
h_description="LTO-5 1600GB"
h_density=0x58
h_algorithm=0x00
a_description="LTO-5 3200GB cmp"
a_density=0x58
a_algorithm=0x01
autoload="yes"
How the storage system qualifies a new tape drive dynamicallyThe storage system qualifies a tape drive dynamically by matching its vendor ID and product ID
with the information contained in the tape qualification table. When you connect a tape drive to the storage system, it looks for a vendor ID and product ID match between the information obtained during tape discovery and the information in the internal tape qualification table. If the storage system discovers a match, it marks the tape drive as qualified and can access the tape drive. If the storage system cannot find a match, the tape drive remains in the unqualified state and is not
accessed. Tape devices overviewA tape device is a representation of a tape drive. It is a specific combination of rewind type and compression capability of a tape drive. A tape
device is created for each combination of rewind type and compression capability. Therefore, a tape drive or tape library can have several tape devices associated with it. You must specify a tape device to move, write, or read tapes. When you install a tape drive or tape library on a storage system, ONTAP creates tape devices associated with the tape drive or tape library. ONTAP detects tape drives and tape libraries and assigns logical numbers and tape devices to them. ONTAP detects
the Fibre Channel, SAS, and parallel SCSI tape drives and libraries when they are connected to the interface ports. ONTAP detects these drives when their interfaces are enabled. Each tape device has an associated name that appears in a defined format. The format includes information about the type of device, rewind type, alias, and compression type. The format of a tape device name is as follows: rewind_type st alias_number compression_type
rewind_type is the rewind type.
The following list describes the various rewind type values: r ONTAP rewinds the tape after it finishes writing the tape
file. nr ONTAP does not rewind the tape after it finishes writing the tape file. You must use this rewind type when you want to write multiple tape files on the same tape. ur This is the unload/reload rewind type. When you use this rewind type, the tape library unloads the tape when it reaches the end of a tape file, and then loads the next tape, if there is one. You must use this rewind type only under the
following circumstances: The tape drive associated with this device is in a tape library or is in a medium changer that is in the library mode. The tape drive associated with this device is attached to a storage system. Sufficient tapes for the operation that you are performing are available in the library tape sequence defined for this tape drive.
|
| If you record a tape using a no-rewind device, you must rewind the tape before you read it.
|
st is the standard designation for a tape drive.
alias_number is the alias that ONTAP assigns to the tape drive. When ONTAP detects a new tape drive, ONTAP assigns an alias to the tape drive.
compression_type is a drive-specific code for the density of data on the tape and the type of compression.
The following list describes the various values for compression_type: a Highest compression h
High compression m Medium compression l Low compression
Examples nrst0a specifies a no-rewind device on tape drive 0 using the highest compression.
Example of a listing of tape devices The following example shows the tape devices associated with HP Ultrium 2-SCSI: Tape drive (fc202_6:2.126L1) HP Ultrium 2-SCSI
rst0l - rewind device, format is: HP (200GB)
nrst0l - no rewind device, format is: HP (200GB)
urst0l - unload/reload device, format is: HP (200GB)
rst0m - rewind device, format is: HP (200GB)
nrst0m - no rewind device, format is: HP (200GB)
urst0m - unload/reload device, format is: HP (200GB)
rst0h - rewind device, format is: HP (200GB)
nrst0h - no rewind device, format is: HP (200GB)
urst0h - unload/reload device, format is: HP (200GB)
rst0a - rewind device, format is: HP (400GB w/comp)
nrst0a - no rewind device, format is: HP (400GB w/comp)
urst0a - unload/reload device, format is: HP (400GB w/comp)The following list describes the abbreviations in the preceding
example: Supported number of simultaneous tape devicesONTAP supports a maximum of 64 simultaneous tape drive connections, 16 medium changers, and 16 bridge or router devices for each storage system
(per node) in any mix of Fibre Channel, SCSI, or SAS attachments. Tape drives or medium changers can be devices in physical or virtual tape libraries or stand-alone devices.
|
| Although a storage system can detect 64 tape drive connections, the maximum number of backup and restore sessions that can be performed simultaneously depends upon the scalability limits of the backup engine.
|
Tape aliasing overviewAliasing simplifies the process of device identification. Aliasing binds a physical path name (PPN) or a serial number (SN)
of a tape or a medium changer to a persistent, but modifiable alias name. The following table describes how tape aliasing enables you to ensure that a tape drive (or tape library or medium changer) is always associated with a single alias name:
| Scenario | Reassigning of the alias |
|---|
When the system reboots
| The tape drive is automatically reassigned its previous alias.
| When a tape device moves to another port
| The alias can be adjusted to point to the new address.
| When more than one system uses a particular tape device
| The user can set the alias to be the same for all the systems.
|
Assigning tape aliases provides a correspondence between the logical names of backup devices (for example, st0 or mc1) and a name permanently assigned to a port, a tape drive, or a medium changer.
|
| st0 and st00 are different logical names.
|
|
| Logical names and serial numbers are used only to access a device. After the device is accessed, it returns all error messages by using the physical path name.
|
There are two types of names available for aliasing: physical path name and serial number. What physical path names arePhysical path
names (PPNs) are the numerical address sequences that ONTAP assigns to tape drives and tape libraries based on the SCSI-2/3 adapter or switch (specific location) they are connected to the storage system. PPNs are also known as electrical names. PPNs of direct-attached devices use the following format: host_adapter. device_id_lun
|
| The LUN value is displayed only for tape and medium changer devices whose LUN values are not zero; that is, if the LUN value is zero the lun part of the PPN is not displayed.
|
For example, the PPN 8.6 indicates that the host adapter number is 8, the device ID is 6, and the logical unit number (LUN) is 0. SAS tape devices are also direct-attached devices. For example, the PPN 5c.4 indicates that in a storage system, the SAS HBA is connected in slot 5, SAS tape is connected to port C of the SAS HBA, and the device ID is 4. PPNs of Fibre Channel switch-attached devices use the following format: switch:port_id. device_id_lun For example,
the PPN MY_SWITCH:5.3L2 indicates that the tape drive connected to port 5 of a switch called MY_SWITCH is set with device ID 3 and has the LUN 2. The LUN (logical unit number) is determined by the drive. Fibre Channel, SCSI tape drives and libraries, and disks have PPNs. PPNs of tape drives and libraries do not change unless the name of the switch changes, the tape drive or library moves, or the tape drive or library is reconfigured. PPNs remain unchanged after reboot. For example,
if a tape drive named MY_SWITCH:5.3L2 is removed and a new tape drive with the same device ID and LUN is connected to port 5 of the switch MY_SWITCH, the new tape drive would be accessible by using MY_SWITCH:5.3L2. What serial numbers areA serial number (SN) is a unique identifier for a tape drive or a medium changer. ONTAP generates aliases based on SN instead of the WWN. Since the SN is a unique identifier for a tape drive or a medium
changer, the alias remains the same regardless of the multiple connection paths to the tape drive or medium changer. This helps storage systems to track the same tape drive or medium changer in a tape library configuration. The SN of a tape drive or a medium changer does not change even if you rename the Fibre Channel switch to which the tape drive or medium changer is connected. However, in a tape library if you replace an existing tape drive with a new one, then ONTAP generates new
aliases because the SN of the tape drive changes. Also, if you move an existing tape drive to a new slot in a tape library or remap the tape drive’s LUN, ONTAP generates a new alias for that tape drive.
|
| You must update the backup applications with the newly generated aliases.
|
The SN of a tape device uses the following format: SN[xxxxxxxxxx]L[X] x is an alphanumeric character and LX is the LUN of the tape device. If the LUN is 0, the LX part of the string is not displayed.
Each SN consists of up to 32 characters; the format for the SN is not case-sensitive. Considerations when configuring multipath tape accessYou can configure two paths from the storage system to access the tape drives in a tape library. If one path fails, the
storage system can use the other paths to access the tape drives without having to immediately repair the failed path. This ensures that tape operations can be restarted. You must consider the following when configuring multipath tape access from your storage system: In tape libraries that support LUN mapping, for multipath access to a LUN group, LUN mapping must be symmetrical on each path. Tape drives and media changers are assigned to LUN groups (set of LUNs
that share the same initiator path set) in a tape library. All tape drives of a LUN group must be available for backup and restore operations on all multiple paths. A maximum of two paths can be configured from the storage system to access the tape drives in a tape library. Multipath tape access supports load balancing. Load balancing is disabled by default.
In the following example, the storage system accesses LUN group 0 through two initiator
paths: 0b and 0d. In both these paths, the LUN group has the same LUN number, 0, and LUN count, 5. The storage system accesses LUN group 1 through only one initiator path, 3d. STSW-3070-2_cluster::> storage tape library config show
Node LUN Group LUN Count Library Name Library Target Port Initiator
----------------------- ----------- ---------- ------------- -------------------- -----
STSW-3070-2_cluster-01 0 5 IBM 3573-TL_1 510a09800000412d 0b
0d
1 2 IBM 3573-TL_2 50050763124b4d6f 3d
3 entries were displayedFor more information, see the man pages. How you add tape drives and libraries to storage systemsYou can add tape drives and libraries to storage system dynamically (without taking the storage system
offline). When you add a new medium changer, the storage system detects its presence and adds it to the configuration. If the medium changer is already referenced in the alias information, no new logical names are created. If the library is not referenced, the storage system creates a new alias for the medium changer. In a tape library configuration, you must configure a tape drive or medium changer on LUN 0 of a target port for ONTAP to discover all medium changers and tape drives
on that target port. What tape reservations areMultiple storage systems can share access to tape drives, medium changers, bridges, or tape libraries. Tape reservations ensure
that only one storage system accesses a device at any particular time by enabling either the SCSI Reserve/Release mechanism or SCSI Persistent Reservations for all tape drives, medium changers, bridges, and tape libraries.
|
| All the systems that share devices in a library, whether switches are involved or not, must use the same reservation method.
|
The SCSI Reserve/Release mechanism for reserving devices works well under normal conditions. However, during interface error recovery procedures, reservations can be lost. If this occurs, initiators other than the reserved owner can access the device. Reservations made with SCSI Persistent Reservations are not affected by error recovery mechanisms, such as loop reset or target reset; however, not all devices implement SCSI Persistent Reservations correctly.
Transfer data using ndmpcopy overviewThe ndmpcopy nodeshell command transfers data between storage systems that support NDMP v4. You can
perform both full and incremental data transfers. You can transfer full or partial volumes, qtrees, directories, or individual files. About this task Beginning with ONTAP 9.7 and later releases, incremental transfers are limited to a maximum of nine levels (one full and up to nine incremental backups). You can run ndmpcopy at the nodeshell command line of the source and destination storage systems, or a storage system that is neither the source nor the destination of
the data transfer. You can also run ndmpcopy on a single storage system that is both the source and the destination of the data transfer. You can use IPv4 or IPv6 addresses of the source and destination storage systems in the ndmpcopy command. The path format is /vserver_name/volume_name \[path\]. Steps Enable NDMP service on the source and destination storage systems:
If you are performing data transfer at the source or destination in… | Use the following command… |
|---|
SVM-scoped NDMP mode
| vserver services ndmp on
|
| For NDMP authentication in the admin SVM, the user account is admin and the user role is admin or backup. In the data SVM, the user account is vsadmin and the user role is vsadmin or vsadmin-backup role.
|
| Node-scoped NDMP mode
| system services ndmp on
|
Transfer data within a storage system or between storage systems using the ndmpcopy command at the nodeshell: ::> system node run -node <node_name> < ndmpcopy [options] source_IP:source_path destination_IP:destination_path [-mcs {inet|inet6}] [-mcd {inet|inet6}] [-md {inet|inet6}]
|
| DNS names are not supported in ndmpcopy. You must provide the IP address of the source and the destination. The loopback address (127.0.0.1) is not supported for the source IP address or the destination IP address.
|
The ndmpcopy command determines the address mode for control connections as follows: If the source or the destination is the ONTAP system, then depending on the NDMP mode (node-scoped or SVM-scoped), use an IP address that allows access to
the target volume. source_path and destination_path are the absolute path names till the granular level of volume, qtree, directory or file.
-mcs specifies the preferred addressing mode for the control connection to the source storage system.
inet indicates an IPv4 address mode and inet6 indicates an IPv6 address mode.
-mcd specifies the preferred addressing mode for the control connection to the destination storage system.
inet
indicates an IPv4 address mode and inet6 indicates an IPv6 address mode.
-md specifies the preferred addressing mode for data transfers between the source and the destination storage systems.
inet indicates an IPv4 address mode and inet6 indicates an IPv6 address mode.
If you do not use the -md option in the ndmpcopy command, the addressing mode for the data connection is determined as follows: If either of the addresses specified
for the control connections is an IPv6 address, the address mode for the data connection is IPv6. If both the addresses specified for the control connections are IPv4 addresses, the ndmpcopy command first attempts an IPv6 address mode for the data connection. If that fails, the command uses an IPv4 address mode.
|
| An IPv6 address, if specified, must be enclosed within square brackets.
|
This sample command migrates data from a source path (source_path) to a destination path (destination_path). > ndmpcopy -sa admin:<ndmp_password> -da admin:<ndmp_password>
-st md5 -dt md5 192.0.2.129:/<src_svm>/<src_vol> 192.0.2.131:/<dst_svm>/<dst_vol> This sample command explicitly sets the control connections and the data connection to use IPv6 address mode: > ndmpcopy -sa admin:<ndmp_password> -da admin:<ndmp_password> -st md5 -dt md5 -mcs inet6 -mcd inet6 -md
inet6 [2001:0db8:1:1:209:6bff:feae:6d67]:/<src_svm>/<src_vol> [2001:0ec9:1:1:200:7cgg:gfdf:7e78]:/<dst_svm>/<dst_vol>
Options for the ndmpcopy commandYou should understand the options available for the ndmpcopy nodeshell command to successfully transfer data. The following table lists the available options. For more
information, see the ndmpcopy man pages available through the nodeshell.
| Option | Description |
|---|
-sa username:[password]
| This option sets the source authentication user name and password for connecting to the source storage system. This is a mandatory option. For a user without admin privilege, you must specify the user’s system-generated NDMP-specific password. The system-generated password is mandatory for both admin and non-admin users.
| -da username:[password]
| This option sets the destination authentication user name and password for connecting to the destination storage system. This is a mandatory option.
| -st {md5|text}
| This option sets the source authentication type to be used when connecting to the source storage system.This is a mandatory option and therefore the user should provide either the text or md5 option.
| -dt {md5|text}
| This option sets the destination authentication type to be used when connecting to the destination storage system.
| -l
| This option sets the dump level used for the transfer to the specified value of level.Valid values are 0, 1, to 9, where 0 indicates a full transfer and 1 to 9 specifies an incremental transfer. The default is 0.
| -d
| This option enables generation of ndmpcopy debug log messages. The ndmpcopy debug log files are located in the /mroot/etc/log root volume. The ndmpcopy debug log file names are in the ndmpcopy.yyyymmdd format.
| -f
| This option enables the forced mode. This mode enables system files to be overwritten in the /etc directory on the root of the 7-Mode volume.
| -h
| This option prints the help message.
| -p
| This option prompts you to enter the password for source and destination authorization. This password overrides the password specified for -sa and -da options.
|
| You can use this option only when the command is running in an interactive console.
|
| -exclude
| This option excludes specified files or directories from the path specified for data transfer. The value can be a comma-separated list of directory or file names such as .pst or .txt.
|
About NDMP for FlexVol volumesThe Network Data Management Protocol (NDMP) is a standardized protocol for controlling backup,
recovery, and other types of data transfer between primary and secondary storage devices, such as storage systems and tape libraries. By enabling NDMP support on a storage system, you enable that storage system to communicate with NDMP-enabled network-attached backup applications (also called Data Management Applications or DMAs), data servers, and tape servers participating in backup or recovery operations. All network communications occur over TCPIP or TCP/IPv6 network.
NDMP also provides low-level control of tape drives and medium changers. You can perform tape backup and restore operations in either node-scoped NDMP mode or storage virtual machine (SVM) scoped NDMP mode. You must be aware of the considerations that you have to take into account while using NDMP, list of environment variables, and supported NDMP tape backup topologies. You can also enable or disable the enhanced DAR functionality. The two authentication methods supported by ONTAP
for authenticating NDMP access to a storage system are: plaintext and challenge. About NDMP modes of operationYou can choose to perform tape backup and restore
operations either at the node level as you have been doing until now or at the storage virtual machine (SVM) level. To perform these operations successfully at the SVM level, NDMP service must be enabled on the SVM. NDMP is in the SVM-scoped NDMP mode by default. To perform tape backup and restore operations in the node-scoped NDMP mode, you must explicitly enable the node-scoped NDMP mode. What node-scoped NDMP mode isIn the node-scoped NDMP mode, you can perform tape backup and restore operations at the node level. In the node-scoped NDMP mode, you can perform tape backup and restore operations on a
node that owns the volume. To perform these operations, you must establish NDMP control connections on a LIF hosted on the node that owns the volume or tape devices.
|
| This mode is deprecated and will be removed in a future major release.
|
What SVM-scoped NDMP mode isYou can perform tape backup and restore operations at the storage virtual machine (SVM) level successfully if the
NDMP service is enabled on the SVM. You can back up and restore all volumes hosted across different nodes in the SVM of a cluster if the backup application supports the CAB extension. An NDMP control connection can be established on different LIF types. In the SVM-scoped NDMP mode, these LIFs belong to either the data SVM or admin SVM. The connection can be established on a LIF only if the NDMP service is enabled on the SVM that owns this LIF. A data LIF belongs to the data SVM and
the intercluster LIF, node-management LIF, and cluster-management LIF belong to the admin SVM. In the SVM-scoped NDMP mode, the availability of volumes and tape devices for backup and restore operations depends on the LIF type on which the NDMP control connection is established and the status of the CAB extension. If your backup application supports the CAB extension and a volume and the tape device share the same affinity, then the backup application can perform a local backup or restore
operation, instead of a three-way backup or restore operation. Considerations when using NDMPYou must take into account a number of considerations when
starting the NDMP service on your storage system. Each node supports a maximum of 16 concurrent backups, restores, or combination of the two using connected tape drives. NDMP services can generate file history data at the request of NDMP backup applications. File history is used by backup applications to enable optimized recovery of selected subsets of data from a backup image. File history generation and processing might be time-consuming and
CPU-intensive for both the storage system and the backup application.
|
| SMTape does not support file history.
|
If your data protection is configured for disaster recovery—where the entire backup image will be recovered—you can disable file history generation to reduce backup time. See your backup application documentation to determine whether it is possible to disable NDMP file history generation. Firewall policy for NDMP is enabled by default on all LIF types. In node-scoped NDMP mode, backing up a FlexVol volume requires that you use the backup
application to initiate a backup on a node that owns the volume. However, you cannot back up a node root volume. You can perform NDMP backup from any LIF as permitted by the firewall policies. If you use a data LIF, you must select a LIF that is not configured for failover. If a data LIF fails over during an NDMP operation, the NDMP operation fails and must be run again. In node-scoped NDMP mode and storage virtual machine (SVM) scoped NDMP mode with no
CAB extension support, the NDMP data connection uses the same LIF as the NDMP control connection. During LIF migration, ongoing backup and restore operations are disrupted. You must initiate the backup and restore operations after the LIF migration. The NDMP backup path is of the format /vserver_name/volume_name/path_name. path_name is optional, and specifies the path of the directory, file, or Snapshot copy.
When a SnapMirror destination is backed up to tape by
using the dump engine, only the data in the volume is backed up. However, if a SnapMirror destination is backed up to tape using SMTape, then the metadata is also backed up. The SnapMirror relationships and the associated metadata are not backed up to tape. Therefore, during restore, only the data on that volume is restored, but the associated SnapMirror relationships are not restored.
Environment variables overviewEnvironment variables are used to communicate information about a backup or restore operation between an NDMP-enabled backup application and a storage system. For example, if a user
specifies that a backup application should back up /vserver1/vol1/dir1, the backup application sets the FILESYSTEM environment variable to /vserver1/vol1/dir1. Similarly, if a user specifies that a backup should be a level 1 backup, the backup application sets the LEVEL environment variable to 1 (one).
|
| The setting and examining of environment variables are typically transparent to backup administrators; that is, the backup application sets them automatically.
|
A backup administrator rarely specifies environment variables; however, you might want to change the value of an environment variable from that set by the backup application to characterize or work around a functional or performance problem. For example, an administrator might want to temporarily disable file history generation to determine if the backup application’s processing of file history information is contributing to performance issues or functional problems.
Many backup applications provide a means to override or modify environment variables or to specify additional environment variables. For information, see your backup application documentation. Environment variables supported by ONTAPEnvironment variables are used to communicate information about a backup or restore operation between an NDMP-enabled backup application and a storage system. ONTAP
supports environment variables, which have an associated default value. However, you can manually modify these default values. If you manually modify the values set by the backup application, the application might behave unpredictably. This is because the backup or restore operations might not be doing what the backup application expected them to do. But in some cases, judicious modification might help in identifying or working around problems. The following tables list the
environment variables whose behavior is common to dump and SMTape and those variables that are supported only for dump and SMTape. These tables also contain descriptions of how the environment variables that are supported by ONTAP work if they are used:
|
| In most cases, variables that have the value, Y also accept T and N also accept F.
|
Environment variables supported for dump and SMTape
| Environment variable | Valid values | Default | Description |
|---|
DEBUG
| Y or N
| N
| Specifies that debugging information is printed.
| FILESYSTEM
| string
| none
| Specifies the path name of the root of the data that is being backed up.
| NDMP_VERSION
| return_only
| none
| You should not modify the NDMP_VERSION variable. Created by the backup operation, the NDMP_VERSION variable returns the NDMP version. ONTAP sets the NDMP_VERSION variable during a backup for internal use and to pass to a backup application for informational purposes. The NDMP version of an NDMP session is not set with this variable.
| PATHNAME_SEPARATOR
| return_value
| none
| Specifies the path name separator character. This character depends on the file system being backed up. For ONTAP, the character “/” is assigned to this variable. The NDMP server sets this variable before starting a tape backup operation.
| TYPE
| dump or smtape
| dump
| Specifies the type of backup supported to perform tape backup and restore operations.
| VERBOSE
| Y or N
| N
| Increases the log messages while performing a tape backup or restore operation.
|
Environment variables supported for dump
| Environment variable | Valid values | Default | Description |
|---|
ACL_START
| return_only
| none
| Created by the backup operation, the ACL_START variable is an offset value used by a direct access restore or restartable NDMP backup operation. The offset value is the byte offset in the dump file where the ACL data (Pass V) begins and is returned at the end of a backup. For a direct access restore operation to correctly restore backed-up data, the ACL_START value must be passed to the restore operation when it begins. An NDMP restartable backup operation uses the
ACL_START value to communicate to the backup application where the nonrestartable portion of the backup stream begins.
| BASE_DATE
| 0, -1, or DUMP_DATE value
| -1
| Specifies the start date for incremental backups. When set to -1, the BASE_DATE incremental specifier is disabled. When set to 0 on a level 0 backup, incremental backups are enabled. After the initial backup, the value of the DUMP_DATE variable from the previous incremental backup is assigned to the BASE_DATE variable. These variables are an alternative to the LEVEL/UPDATE based incremental backups.
| DIRECT
| Y or N
| N
| Specifies that a restore should fast-forward directly to the location on the tape where the file data resides instead of scanning the entire tape. For direct access recovery to work, the backup application must provide positioning information. If this variable is set to Y, the backup application specifies the file or directory names and the positioning information.
| DMP_NAME
| string
| none
| Specifies the name for a multiple subtree backup. This variable is mandatory for multiple subtree backups.
| DUMP_DATE
| return_value
| none
| You do not change this variable directly. It is created by the backup if the BASE_DATE variable is set to a value other than -1. The DUMP_DATE variable is derived by prepending the 32-bit level value to a 32-bit time value computed by the dump software. The level is incremented from the last level value passed into the BASE_DATE variable. The resulting value is used as the BASE_DATE value on a subsequent incremental backup.
| ENHANCED_DAR_ENABLED
| Y or N
| N
| Specifies whether enhanced DAR functionality is enabled. Enhanced DAR functionality supports directory DAR and DAR of files with NT Streams. It provides performance improvements. Enhanced DAR during restore is possible only if the following conditions are met: ONTAP supports enhanced DAR. File history is enabled (HIST=Y) during the backup. The ndmpd.offset_map.enable option is set to on. ENHANCED_DAR_ENABLED variable
is set to Y during restore.
| EXCLUDE
| pattern_string
| none
| Specifies files or directories that are excluded when backing up data. The exclude list is a comma-separated list of file or directory names. If the name of a file or directory matches one of the names in the list, it is excluded from the backup. The following rules apply while specifying names in the exclude list: The exact name of the file or directory must be used. The asterisk (*), a wildcard character, must be either the first
or the last character of the string. Each string can have up to two asterisks. A comma in a file or directory name must be preceded with a backslash. The exclude list can contain up to 32 names.
|
| Files or directories specified to be excluded for backup are not excluded if you set NON_QUOTA_TREE to Y simultaneously.
|
| EXTRACT
| Y, N, or E
| N
| Specifies that subtrees of a backed-up data set are to be restored. The backup application specifies the names of the subtrees to be extracted. If a file specified matches a directory whose contents were backed up, the directory is recursively extracted. To rename a file, directory, or qtree during restore without using DAR, you must set the EXTRACT environment variable to E.
| EXTRACT_ACL
| Y or N
| Y
| Specifies that ACLs from the backed up file are restored on a restore operation. The default is to restore ACLs when restoring data, except for DARs (DIRECT=Y).
| FORCE
| Y or N
| N
| Determines if the restore operation must check for volume space and inode availability on the destination volume. Setting this variable to Y causes the restore operation to skip checks for volume space and inode availability on the destination path. If enough volume space or inodes are not available on the destination volume, the restore operation recovers as much data allowed by the destination volume space and inode availability. The restore operation stops
when volume space or inodes are not available.
| HIST
| Y or N
| N
| Specifies that file history information is sent to the backup application. Most commercial backup applications set the HIST variable to Y. If you want to increase the speed of a backup operation, or you want to troubleshoot a problem with the file history collection, you can set this variable to N.
|
| You should not set the HIST variable to Y if the backup application does not support file history.
|
| IGNORE_CTIME
| Y or N
| N
| Specifies that a file is not incrementally backed up if only its ctime value has changed since the previous incremental backup. Some applications, such as virus scanning software, change the ctime value of a file within the inode, even though the file or its attributes have not changed. As a result, an incremental backup might back up files that have not changed. The IGNORE_CTIME variable should be specified only if incremental backups are taking an unacceptable amount of time
or space because the ctime value was modified.
|
| The NDMP dump command sets IGNORE_CTIME to false by default. Setting it to true can result in the following data loss: If IGNORE_CTIME is set to true with a volume level incremental ndmpcopy, it results in the deleting of files, which are moved across qtrees on source. If IGNORE_CTIME is set to true during a volume level incremental dump, it results in the deleting of files, which are moved across qtrees on source during incremental restore.
To avoid this problem, IGNORE_CTIME must be set to false during volume level NDMP dumps or ndmpcopy.
|
| IGNORE_QTREES
| Y or N
| N
| Specifies that the restore operation does not restore qtree information from backed-up qtrees.
| LEVEL
| 0-31
| 0
| Specifies the backup level. Level 0 copies the entire data set. Incremental backup levels, specified by values above 0, copy all files (new or modified) since the last incremental backup. For example, a level 1 backs up new or modified files since the level 0 backup, a level 2 backs up new or modified files since the level 1 backup, and so on.
| LIST
| Y or N
| N
| Lists the backed-up file names and inode numbers without actually restoring the data.
| LIST_QTREES
| Y or N
| N
| Lists the backed-up qtrees without actually restoring the data.
| MULTI_SUBTREE_ NAMES
| string
| none
| Specifies that the backup is a multiple subtree backup. Multiple subtrees are specified in the string, which is a newline-separated, null-terminated list of subtree names. Subtrees are specified by path names relative to their common root directory, which must be specified as the last element of the list. If you use this variable, you must also use the DMP_NAME variable.
| NDMP_UNICODE_ FH
| Y or N
| N
| Specifies that a Unicode name is included in addition to the NFS name of the file in the file history information. This option is not used by most backup applications and should not be set unless the backup application is designed to receive these additional file names. The HIST variable must also be set.
| NO_ACLS
| Y or N
| N
| Specifies that ACLs must not be copied when backing up data.
| NON_QUOTA_TREE
| Y or N
| N
| Specifies that files and directories in qtrees must be ignored when backing up data. When set to Y, items in qtrees in the data set specified by the FILESYSTEM variable are not backed up. This variable has an effect only if the FILESYSTEM variable specifies an entire volume. The NON_QUOTA_TREE variable only works on a level 0 backup and does not work if the MULTI_SUBTREE_NAMES variable is specified.
|
| Files or directories specified to be excluded for backup are not excluded if you set NON_QUOTA_TREE to Y simultaneously.
|
| NOWRITE
| Y or N
| N
| Specifies that the restore operation must not write data to the disk. This variable is used for debugging.
| RECURSIVE
| Y or N
| Y
| Specifies that directory entries during a DAR restore be expanded. The DIRECT and ENHANCED_DAR_ENABLED environment variables must be enabled (set to Y) as well. If the RECURSIVE variable is disabled (set to N), only the permissions and ACLs for all the directories in the original source path are restored from tape, not the contents of the directories. If the RECURSIVE variable is set to N or the RECOVER_FULL_PATHS variable is set to Y, the
recovery path must end with the original path.
|
| If the RECURSIVE variable is disabled and if there is more than one recovery path, all of the recovery paths must be contained within the longest of the recovery paths. Otherwise, an error message is displayed.
|
For example, the following are valid recovery paths because all of the recovery paths are within foo/dir1/deepdir/myfile: /foo
/foo/dir
/foo/dir1/deepdir
/foo/dir1/deepdir/myfile
The following are invalid recovery paths: /foo
/foo/dir
/foo/dir1/myfile
/foo/dir2
/foo/dir2/myfile
| RECOVER_FULL_PATHS
| Y or N
| N
| Specifies that the full recovery path will have their permissions and ACLs restored after the DAR. DIRECT and ENHANCED_DAR_ENABLED must be enabled (set to Y) as well. If RECOVER_FULL_PATHS is set to Y, the recovery path must end with the original path. If directories already exist on the destination volume, their permissions and ACLs will not be restored from tape.
| UPDATE
| Y or N
| Y
| Updates the metadata information to enable LEVEL based incremental backup.
|
Environment variables supported for SMTape
| Environment variable | Valid values | Default | Description |
|---|
BASE_DATE
| DUMP_DATE
| -1
| Specifies the start date for incremental backups. BASE_DATE is a string representation of the reference Snapshot identifiers. Using the BASE_DATE string, SMTape locates the reference Snapshot copy.
BASE_DATE is not required for baseline backups. For an incremental backup, the value of the DUMP_DATE variable from the previous baseline or incremental backup is assigned to the BASE_DATE variable.
The backup application assigns the DUMP_DATE value from a previous SMTape
baseline or incremental backup.
| DUMP_DATE
| return_value
| none
| At the end of an SMTape backup, DUMP_DATE contains a string identifier that identifies the Snapshot copy used for that backup. This Snapshot copy could be used as the reference Snapshot copy for a subsequent incremental backup. The resulting value of DUMP_DATE is used as the BASE_DATE value for subsequent incremental backups.
| SMTAPE_BACKUP_SET_ID
| string
| none
| Identifies the sequence of incremental backups associated with the baseline backup. Backup set ID is a 128-bit unique ID that is generated during a baseline backup. The backup application assigns this ID as the input to the SMTAPE_BACKUP_SET_ID variable during an incremental backup.
| SMTAPE_SNAPSHOT_NAME
| Any valid Snapshot copy that is available in the volume
| Invalid
| When the SMTAPE_SNAPSHOT_NAME variable is set to a Snapshot copy, that Snapshot copy and its older Snapshot copies are backed up to tape. For incremental backup, this variable specifies incremental Snapshot copy. The BASE_DATE variable provides the baseline Snapshot copy.
| SMTAPE_DELETE_SNAPSHOT
| Y or N
| N
| For a Snapshot copy created automatically by SMTape, when the SMTAPE_DELETE_SNAPSHOT variable is set to Y, then after the backup operation is complete, SMTape deletes this Snapshot copy. However, a Snapshot copy created by the backup application will not be deleted.
| SMTAPE_BREAK_MIRROR
| Y or N
| N
| When the SMTAPE_BREAK_MIRROR variable is set to Y, the volume of type DP is changed to a RW volume after a successful restore.
|
Common NDMP tape backup topologiesNDMP supports a number of topologies and configurations between backup applications and
storage systems or other NDMP servers providing data (file systems) and tape services. Storage system-to-local-tapeIn the simplest configuration, a backup application backs up
data from a storage system to a tape subsystem attached to the storage system. The NDMP control connection exists across the network boundary. The NDMP data connection that exists within the storage system between the data and tape services is called an NDMP local configuration. Storage system-to-tape attached to another storage systemA backup application can also back up data from a storage system to a tape library (a medium changer with one or
more tape drives) attached to another storage system. In this case, the NDMP data connection between the data and tape services is provided by a TCP or TCP/IPv6 network connection. This is called an NDMP three-way storage system-to-storage system configuration. Storage system-to-network-attached tape libraryNDMP-enabled tape libraries provide a variation of the three-way configuration. In this case, the tape library attaches directly to the TCP/IP
network and communicates with the backup application and the storage system through an internal NDMP server. Storage system-to-data server-to-tape or data server-to-storage system-to-tapeNDMP also supports storage system-to-data-server
and data-server-to-storage system three-way configurations, although these variants are less widely deployed. Storage system-to-server allows storage system data to be backed up to a tape library attached to the backup application host or to another data server system. The server-to-storage system configuration allows server data to be backed up to a storage system-attached tape library. Supported NDMP authentication methodsYou can specify an authentication method to allow NDMP connection requests. ONTAP supports two methods for authenticating NDMP access to a storage system: plaintext and
challenge. In node-scoped NDMP mode, both challenge and plaintext are enabled by default. However, you cannot disable challenge. You can enable and disable plaintext. In the plaintext authentication method, the login password is transmitted as clear text. In the storage virtual machine (SVM)-scoped NDMP mode, by default the authentication method is challenge. Unlike the node-scoped NDMP mode, in this mode you can enable and disable both plaintext and challenge authentication
methods. NDMP extensions supported by ONTAPNDMP v4 provides a mechanism for creating NDMP v4 protocol extensions without modifying the core NDMP
v4 protocol. You should be aware of the NDMP v4 extensions that are supported by ONTAP. The following NDMP v4 extensions are supported by ONTAP: Cluster Aware Backup (CAB)
|
| This extension is supported only in the SVM-scoped NDMP mode.
|
Connection Address Extension (CAE) for IPv6 support Extension class 0x2050 This extension supports restartable backup operations and Snapshot Management Extensions.
|
| The NDMP_SNAP_RECOVER message, which is part of the Snapshot Management Extensions, is used to initiate a recovery operation and to transfer the recovered data from a local Snapshot copy to a local file system location. In ONTAP, this message allows the recovery of volumes and regular files only. The NDMP_SNAP_DIR_LIST message enables you to browse through the Snapshot copies of a volume. If a nondisruptive operation takes place while a browsing operation is in progress, the backup application
must reinitiate the browsing operation.
|
What enhanced DAR functionality isYou can use the enhanced direct access recovery (DAR) functionality for
directory DAR and DAR of files and NT streams. By default, enhanced DAR functionality is enabled. Enabling enhanced DAR functionality might impact the backup performance because an offset map has to be created and written onto tape. You can enable or disable enhanced DAR in both the node-scoped and storage virtual machine (SVM)-scoped NDMP modes. Scalability limits for NDMP sessionsYou must be aware of the maximum number of NDMP sessions that can be established simultaneously on storage systems of different system memory capacities. This
maximum number depends on the system memory of a storage system. The limits mentioned in the following table are for the NDMP server. The limits mentioned in the section “Scalability limits for dump backup and restore sessions” are for the dump and restore session.
| System memory of a storage system | Maximum number of NDMP sessions |
|---|
Less than 16 GB
| 8
| Greater than or equal to 16 GB but less than 24 GB
| 20
| Greater than or equal to 24 GB
| 36
|
You can obtain the system memory of your storage system by using the sysconfig -a command (available through the nodeshell). For more information about using this command, see the man pages. About NDMP for FlexGroup volumesBeginning with ONTAP 9.7, NDMP is supported on FlexGroup volumes. Beginning with ONTAP 9.7, the ndmpcopy command is supported for data transfer between FlexVol and FlexGroup
volumes. Beginning with ONTAP 9.8, the following NDMP features are supported on FlexGroup volumes: The NDMP_SNAP_RECOVER message in the extension class 0x2050 can be used for recovering individual files in a FlexGroup volume. NDMP restartable backup extension (RBE) is supported for FlexGroup volumes. Environment variables EXCLUDE and MULTI_SUBTREE_NAMES are supported for FlexGroup volumes.
About NDMP with SnapLock volumesCreating multiple copies of regulated data provides you with redundant recovery scenarios, and by using NDMP dump and restore, it’s possible
to preserve the write once, read many (WORM) characteristics of source files on a SnapLock volume. WORM attributes on the files in a SnapLock volume are preserved when backing up, restoring and copying data; however, WORM attributes are enforced only when restoring to a SnapLock volume. If a backup from a SnapLock volume is restored to a volume other than a SnapLock volume, the WORM attributes are preserved but are ignored and are not enforced by ONTAP. Manage node-scoped NDMP mode for FlexVol volumes overviewYou can manage NDMP at the node level by using NDMP options and commands. You can modify the NDMP options by
using the options command. You must use NDMP-specific credentials to access a storage system to perform tape backup and restore operations. For more information about the options command, see the man pages. Commands for managing node-scoped NDMP modeYou can use the system services ndmp commands to manage NDMP at a node level. Some of these commands are deprecated and will be removed in a future major release.
You can use the following NDMP commands only at the advanced privilege level: system services ndmp service terminate
system services ndmp service start
system services ndmp service stop
system services ndmp log start
system services ndmp log stop
| If you want to… | Use this command… |
|---|
Enable NDMP service
| system services ndmp on*
| Disable NDMP service
| system services ndmp off*
| Display NDMP configuration
| system services ndmp show*
| Modify NDMP configuration
| system services ndmp modify*
| Display the default NDMP version
| system services ndmp version*
| Display NDMP service configuration
| system services ndmp service show
| Modify NDMP service configuration
| system services ndmp service modify
| Display all NDMP sessions
| system services ndmp status
| Display detailed information about all NDMP sessions
| system services ndmp probe
| Terminate the specified NDMP session
| system services ndmp kill
| Terminate all NDMP sessions
| system services ndmp kill-all
| Change the NDMP password
| system services ndmp password*
| Enable node-scoped NDMP mode
| system services ndmp node-scope-mode on*
| Disable node-scoped NDMP mode
| system services ndmp node-scope-mode off*
| Display the node-scoped NDMP mode status
| system services ndmp node-scope-mode status*
| Forcefully terminate all NDMP sessions
| system services ndmp service terminate
| Start the NDMP service daemon
| system services ndmp service start
| Stop the NDMP service daemon
| system services ndmp service stop
| Start logging for the specified NDMP session
| system services ndmp log start*
| Stop logging for the specified NDMP session
| system services ndmp log stop*
|
For more information about these commands, see the man pages for the system services ndmp commands. User authentication in a node-scoped NDMP modeIn the node-scoped NDMP mode, you must use NDMP specific credentials to access a storage system in order to perform tape backup and
restore operations. The default user ID is “root”. Before using NDMP on a node, you must ensure that you change the default NDMP password associated with the NDMP user. You can also change the default NDMP user ID. Manage SVM-scoped NDMP mode for FlexVol volumes overviewYou can manage NDMP on a per SVM basis by using the NDMP options and commands. You can modify the NDMP options by using the vserver services ndmp modify command. In the
SVM-scoped NDMP mode, user authentication is integrated with the role-based access control mechanism. You can add NDMP in the allowed or disallowed protocols list by using the vserver modify command. By default, NDMP is in the allowed protocols list. If NDMP is added to the disallowed protocols list, NDMP sessions cannot be established. You can control the LIF type on which an NDMP data connection is established by using the -preferred-interface-role option. During an NDMP data connection establishment,
NDMP chooses an IP address that belongs to the LIF type as specified by this option. If the IP addresses do not belong to any of these LIF types, then the NDMP data connection cannot be established. For more information about the -preferred-interface-role option, see the man pages. For more information about the vserver services ndmp modify command, see the man pages. Commands for managing SVM-scoped NDMP modeYou can use the vserver services ndmp commands to manage NDMP on each storage virtual machine (SVM, formerly known as Vserver).
| If you want to… | Use this command… |
|---|
Enable NDMP service
| vserver services ndmp on
|
| NDMP service must always be enabled on all nodes in a cluster. You can enable NDMP service on a node by using the system services ndmp on command. By default, NDMP service is always enabled on a node.
|
| Disable NDMP service
| vserver services ndmp off
| Display NDMP configuration
| vserver services ndmp show
| Modify NDMP configuration
| vserver services ndmp modify
| Display default NDMP version
| vserver services ndmp version
| Display all NDMP sessions
| vserver services ndmp status
| Display detailed information about all NDMP sessions
| vserver services ndmp probe
| Terminate a specified NDMP session
| vserver services ndmp kill
| Terminate all NDMP sessions
| vserver services ndmp kill-all
| Generate the NDMP password
| vserver services ndmp generate-password
| Display NDMP extension status
| vserver services ndmp extensions show
This command is available at the advanced privilege level.
| Modify (enable or disable) NDMP extension status
| vserver services ndmp extensions modify
This command is available at the advanced privilege level.
| Start logging for the specified NDMP session
| vserver services ndmp log start
This command is available at the advanced privilege level.
| Stop logging for the specified NDMP session
| vserver services ndmp log stop
This command is available at the advanced privilege level.
|
For more information about these commands, see the man pages for the vserver services ndmp commands. What Cluster Aware Backup extension
doesCAB (Cluster Aware Backup) is an NDMP v4 protocol extension. This extension enables the NDMP server to establish a data connection on a node that owns a volume. This also enables the backup application to determine if volumes and tape devices are located on the same node in a cluster. To enable the NDMP server to identify the node that owns a volume and to establish a data connection on such a node, the backup application must support the CAB extension. CAB extension
requires the backup application to inform the NDMP server about the volume to be backed up or restored prior to establishing the data connection. This allows the NDMP server to determine the node that hosts the volume and appropriately establish the data connection. With the CAB extension supported by the backup application, the NDMP server provides affinity information about volumes and tape devices. Using this affinity information, the backup application can perform a local backup
instead of a three-way backup if a volume and tape device are located on the same node in a cluster. Availability of volumes and tape devices for backup and restore on different LIF typesYou can configure a
backup application to establish an NDMP control connection on any of the LIF types in a cluster. In the storage virtual machine (SVM)-scoped NDMP mode, you can determine the availability of volumes and tape devices for backup and restore operations depending upon these LIF types and the status of the CAB extension. The following tables show the availability of volumes and tape devices for NDMP control connection LIF types and the status of the CAB extension: Availability of volumes and tape devices when CAB extension is not supported by the backup
application
| NDMP control connection LIF type | Volumes available for backup or restore | Tape devices available for backup or restore |
|---|
Node-management LIF
| All volumes hosted by a node
| Tape devices connected to the node hosting the node-management LIF
| Data LIF
| Only volumes that belong to the SVM hosted by a node that hosts the data LIF
| None
| Cluster-management LIF
| All volumes hosted by a node that hosts the cluster-management LIF
| None
| Intercluster LIF
| All volumes hosted by a node that hosts the intercluster LIF
| Tape devices connected to the node hosting the intercluster LIF
|
Availability of volumes and tape devices when CAB extension is supported by the backup
application
| NDMP control connection LIF type | Volumes available for backup or restore | Tape devices available for backup or restore |
|---|
Node-management LIF
| All volumes hosted by a node
| Tape devices connected to the node hosting the node-management LIF
| Data LIF
| All volumes that belong to the SVM that hosts the data LIF
| None
| Cluster-management LIF
| All volumes in the cluster
| All tape devices in the cluster
| Intercluster LIF
| All volumes in the cluster
| All tape devices in the cluster
|
With the backup application being CAB aware, the NDMP server provides unique location information about
volumes and tape devices. Using this affinity information, the backup application can perform a local backup instead of a three-way backup if a volume and a tape device share the same affinity. If the NDMP control connection is established on a node management LIF, cluster management LIF, or an intercluster LIF, the backup application can use the affinity information to determine if a volume and tape device are located on the same node and then perform either a local or a three-way backup
or restore operation. If the NDMP control connection is established on a data LIF, then the backup application always performs a three-way backup. Local NDMP backup and Three-way NDMP backupUsing the affinity information about volumes and tape devices, the DMA (backup application) performs a local NDMP backup on the volume and tape device located on Node 1 in the cluster. If the volume moves from Node 1 to Node 2, affinity information about the volume and tape device changes. Hence, for a subsequent backup the DMA performs a three-way NDMP backup operation. This ensures continuity of the backup policy for the volume irrespective of the node to which
the volume is moved to. NDMP server supports secure control
connections in SVM-scoped modeA secure control connection can be established between the Data Management Application (DMA) and NDMP server by using secure sockets (SSL/TLS) as the communication mechanism. This SSL communication is based on the server certificates. The NDMP server listens on port 30000 (assigned by IANA for “ndmps” service). After establishing the connection from the client on this port, the standard SSL handshake ensues where the server presents the
certificate to the client. When the client accepts the certificate, the SSL handshake is complete. After this process is complete, all of the communication between the client and the server is encrypted. The NDMP protocol workflow remains exactly as before. The secure NDMP connection requires server- side certificate authentication only. A DMA can choose to establish a connection either by connecting to the secure NDMP service or the standard NDMP service. By default, secure NDMP service
is disabled for a storage virtual machine (SVM). You can enable or disable the secure NDMP service on a given SVM by using the vserver services ndmp modify -vserver vserver -is-secure-control-connection-enabled [true|false] command. NDMP data connection types
In the storage virtual machine (SVM)-scoped NDMP mode, the supported NDMP data connection types depend on the NDMP control connection LIF type and the status of the CAB extension. This NDMP data connection type indicates whether you can perform a local or a three-way NDMP backup or restore operation. You can perform a three-way NDMP backup or restore operation over a TCP or TCP/IPv6 network. The following tables show the NDMP data connection types based on the NDMP control connection
LIF type and the status of the CAB extension. User authentication in the SVM-scoped NDMP modeIn the
storage virtual machine (SVM)-scoped NDMP mode, NDMP user authentication is integrated with role-based access control. In the SVM context, the NDMP user must have either the “vsadmin” or “vsadmin-backup” role. In a cluster context, the NDMP user must have either the “admin” or “backup” role. Apart from these pre-defined roles, a user account associated with a custom role can also be used for NDMP authentication provided that the custom role has the “vserver services ndmp” folder in its
command directory and the access level of the folder is not “none”. In this mode, you must generate an NDMP password for a given user account, which is created through role-based access control. Cluster users in an admin or backup role can access a node-management LIF, a cluster-management LIF, or an intercluster LIF. Users in a vsadmin-backup or vsadmin role can access only the data LIF for that SVM. Therefore, depending on the role of a user, the availability of volumes and tape devices for
backup and restore operations vary. This mode also supports user authentication for NIS and LDAP users. Therefore, NIS and LDAP users can access multiple SVMs with a common user ID and password. However, NDMP authentication does not support Active Directory users. In this mode, a user account must be associated with the SSH application and the “User password” authentication method. Generate an NDMP-specific password for NDMP usersIn the storage virtual machine (SVM)-scoped NDMP mode, you must generate a password for a specific user ID. The generated password is
based on the actual login password for the NDMP user. If the actual login password changes, you must generate the NDMP-specific password again. Steps Use the vserver services ndmp generate-password command to generate an NDMP-specific password. You can use this password in any current or future NDMP operation that requires password input.
|
| From the storage virtual machine (SVM, formerly known as Vserver) context, you can generate NDMP passwords for users belonging only to that SVM.
|
The following example shows how to generate an NDMP-specific password for a user ID user1: cluster1::vserver services ndmp> generate-password -vserver vs1 -user user1
Vserver: vs1
User: user1
Password: jWZiNt57huPOoD8d If you change the password to your regular storage system account, repeat this procedure to obtain your new NDMP-specific password.
How tape backup and restore operations are affected during disaster recovery in
MetroCluster configurationYou can perform tape backup and restore operations simultaneously during disaster recovery in a MetroCluster configuration. You must understand how these operations are affected during disaster recovery. If tape backup and restore operations are performed on a volume of anSVM in a disaster recovery relationship, then you can continue performing incremental tape backup and restore operations after a switchover and switchback.
About dump engine for FlexVol volumesDump is a Snapshot copy based backup and recovery solution from ONTAP that helps you to back up files and directories from a Snapshot copy to a tape device and
restore the backed up data to a storage system. You can back up your file system data, such as directories, files, and their associated security settings, to a tape device by using the dump backup. You can back up an entire volume, an entire qtree, or a subtree that is neither an entire volume nor an entire qtree. You can perform a dump backup or restore by using NDMP-compliant backup applications. When you perform a dump backup, you can specify the Snapshot copy to be used for
a backup. If you do not specify a Snapshot copy for the backup, the dump engine creates a Snapshot copy for the backup. After the backup operation is completed, the dump engine deletes this Snapshot copy. You can perform level-0, incremental, or differential backups to tape by using the dump engine. How a dump backup worksA dump backup writes file system data from disk to tape using a predefined process. You can back up a volume, a qtree, or a subtree that is neither an entire volume nor an entire qtree. The following table
describes the process that ONTAP uses to back up the object indicated by the dump path:
| Stage | Action |
|---|
1
| For less than full volume or full qtree backups, ONTAP traverses directories to identify the files to be backed up. If you are backing up an entire volume or qtree, ONTAP combines this stage with Stage 2.
| 2
| For a full volume or full qtree backup, ONTAP identifies the directories in the volumes or qtrees to be backed up.
| 3
| ONTAP writes the directories to tape.
| 4
| ONTAP writes the files to tape.
| 5
| ONTAP writes the ACL information (if applicable) to tape.
|
The dump backup uses a Snapshot copy of your data for the backup. Therefore, you do not have to take the volume offline before initiating the backup. The dump backup names each Snapshot copy it creates as snapshot_for_backup.n, where n is an integer starting at 0. Each time the dump backup creates a Snapshot copy, it increments the integer by 1. The integer is reset to 0 after the storage system is rebooted. After the backup operation is completed, the dump engine
deletes this Snapshot copy. When ONTAP performs multiple dump backups simultaneously, the dump engine creates multiple Snapshot copies. For example, if ONTAP is running two dump backups simultaneously, you find the following Snapshot copies in the volumes from which data is being backed up: snapshot_for_backup.0 and snapshot_for_backup.1.
|
| When you are backing up from a Snapshot copy, the dump engine does not create an additional Snapshot copy.
|
Types of data that the dump engine backs upThe dump engine enables you to back up data to tape
to guard against disasters or controller disruptions. In addition to backing up data objects such as a files, directories, qtrees, or entire volumes, the dump engine can back up many types of information about each file. Knowing the types of data that the dump engine can back up and the restrictions to take into consideration can help you plan your approach to disaster recovery. In addition to backing up data in files, the dump engine can back up the following information about each file,
as applicable: UNIX GID, owner UID, and file permissions UNIX access, creation, and modification time File type File size DOS name, DOS attributes, and creation time Access control lists (ACLs) with 1,024 access control entries (ACEs) Qtree information Junction paths
Junction paths are backed up as symbolic links.
|
| When a snapshot-backed LUN clone is transitioned from Data ONTAP operating in 7-Mode to ONTAP, it becomes an inconsistent LUN. The dump engine does not back up inconsistent LUNs.
|
When you restore data to a volume, client I/O is restricted on the LUNs being restored. The LUN restriction is removed only when the dump restore operation is complete. Similarly, during a SnapMirror single file or LUN restore operation, client I/O is restricted on both files and LUNs being restored. This restriction is removed only when the single file or LUN restore operation is complete. If a dump backup is performed on a volume on which a dump restore or SnapMirror
single file or LUN restore operation is being performed, then the files or LUNs that have client I/O restriction are not included in the backup. These files or LUNs are included in a subsequent backup operation if the client I/O restriction is removed.
|
| A LUN running on Data ONTAP 9.7 that is backed up to tape can be restored only to 9.7 and later releases and not to an earlier release.
|
When you back up a SnapVault secondary volume or a volume SnapMirror destination to tape, only the data on the volume is backed up. The associated metadata is not backed up. Therefore, when you try to restore the volume, only the data on that volume is restored. Information about the volume SnapMirror relationships is not available in the backup and therefore is not restored. If you dump a file that has only Windows NT permissions and restore it to a UNIX-style
qtree or volume, the file gets the default UNIX permissions for that qtree or volume. If you dump a file that has only UNIX permissions and restore it to an NTFS-style qtree or volume, the file gets the default Windows permissions for that qtree or volume. Other dumps and restores preserve permissions. You can back up VM-aligned files and the vm-align-sector option. For more information about VM-aligned files, see
Volume Administration. What increment chains areAn
increment chain is a series of incremental backups of the same path. Because you can specify any level of backup at any time, you must understand increment chains to be able to perform backups and restores effectively. You can perform 31 levels of incremental backup operations. There are two types of increment chains: A consecutive increment chain, which is a sequence of incremental backups that starts with level 0 and is raised by 1 at each subsequent backup. A nonconsecutive increment chain, where incremental backups skip levels or have levels that are out of sequence, such as 0, 2, 3, 1, 4, or more commonly 0, 1, 1, 1 or 0, 1, 2, 1, 2.
Incremental backups are based on the most recent lower-level backup. For example, the sequence of backup levels 0, 2, 3, 1, 4 provides two increment chains: 0, 2, 3 and 0, 1, 4. The following table explains the bases of the incremental backups:
| Backup order | Increment level | Increment chain | Base | Files backed up |
|---|
1
| 0
| Both
| Files on the storage system
| All files in the backup path
| 2
| 2
| 0, 2, 3
| Level-0 backup
| Files in the backup path created since the level-0 backup
| 3
| 3
| 0, 2, 3
| Level-2 backup
| Files in the backup path created since the level-2 backup
| 4
| 1
| 0, 1, 4
| Level-0 backup, because this is the most recent level that is lower than the level-1 backup
| Files in the backup path created since the level-0 backup, including files that are in the level-2 and level-3 backups
| 5
| 4
| 0, 1, 4
| The level-1 backup, because it is a lower level and is more recent than the level-0, level-2, or level-3 backups
| Files created since the level-1 backup
|
What the blocking factor isA tape block is 1,024 bytes of data. During a tape backup or restore, you can specify the number of tape blocks
that are transferred in each read/write operation. This number is called the blocking factor. You can use a blocking factor from 4 to 256. If you plan to restore a backup to a system other than the system that did the backup, the restore system must support the blocking factor that you used for the backup. For example, if you use a blocking factor of 128, the system on which you restore that backup must support a blocking factor of 128. During an NDMP backup, the
MOVER_RECORD_SIZE determines the blocking factor. ONTAP allows a maximum value of 256 KB for MOVER_RECORD_SIZE. When to restart a dump backupA dump backup
sometimes does not finish because of internal or external errors, such as tape write errors, power outages, accidental user interruptions, or internal inconsistency on the storage system. If your backup fails for one of these reasons, you can restart it. You can choose to interrupt and restart a backup to avoid periods of heavy traffic on the storage system or to avoid competition for other limited resources on the storage system, such as a tape drive. You can interrupt a long backup and
restart it later if a more urgent restore (or backup) requires the same tape drive. Restartable backups persist across reboots. You can restart an aborted backup to tape only if the following conditions are true: The aborted backup is in phase IV. All of the associated Snapshot copies that were locked by the dump command are available. The file history must be enabled.
When such a dump operation is aborted and left in a
restartable state, the associated Snapshot copies are locked. These Snapshot copies are released after the backup context is deleted. You can view the list of backup contexts by using the vserver services ndmp restartable backup show command. cluster::> vserver services ndmpd restartable-backup show
Vserver Context Identifier Is Cleanup Pending?
----------- ------------------------------------ -------------------
vserver1 330e6739-0179-11e6-a299-005056bb4bc9 false
vserver1 481025c1-0179-11e6-a299-005056bb4bc9 false
vserver2 5cf10132-0179-11e6-a299-005056bb4bc9 false
3 entries were displayed.
cluster::> vserver services ndmpd restartable-backup show -vserver vserver1 -context-id 330e6739-0179-11e6-a299-005056bb4bc9
Vserver: vserver1
Context Identifier: 330e6739-0179-11e6-a299-005056bb4bc9
Volume Name: /vserver1/vol1
Is Cleanup Pending?: false
Backup Engine Type: dump
Is Snapshot Copy Auto-created?: true
Dump Path: /vol/vol1
Incremental Backup Level ID: 0
Dump Name: /vserver1/vol1
Context Last Updated Time: 1460624875
Has Offset Map?: true
Offset Verify: true
Is Context Restartable?: true
Is Context Busy?: false
Restart Pass: 4
Status of Backup: 2
Snapshot Copy Name: snapshot_for_backup.1
State of the Context: 7
cluster::>"How a dump restore worksA dump restore writes file system data from tape to disk using a predefined process. The process in the following table shows how the dump restore works:
| Stage | Action |
|---|
1
| ONTAP catalogs the files that need to be extracted from the tape.
| 2
| ONTAP creates directories and empty files.
| 3
| ONTAP reads a file from tape, writes it to disk, and sets the permissions (including ACLs) on it.
| 4
| ONTAP repeats stages 2 and 3 until all the specified files are copied from the tape.
|
Types of data that the dump engine restoresWhen a disaster or controller disruption occurs,
the dump engine provides multiple methods for you to recover all of the data that you backed up, from single files, to file attributes, to entire directories. Knowing the types of data that dump engine can restore and when to use which method of recovery can help minimize downtime. You can restore data to an online mapped LUN. However, host applications cannot access this LUN until the restore operation is complete. After the restore operation is complete, the host cache of the LUN data
should be flushed to provide coherency with the restored data. The dump engine can recover the following data: Contents of files and directories UNIX file permissions ACLs If you restore a file that has only UNIX file permissions to an NTFS qtree or volume, the file has no Windows NT ACLs. The storage system uses only the UNIX file permissions on this file until you create a Windows NT ACL on it. Qtree information Qtree
information is used only if a qtree is restored to the root of a volume. Qtree information is not used if a qtree is restored to a lower directory, such as /vs1/vol1/subdir/lowerdir, and it ceases to be a qtree. All other file and directory attributes Windows NT streams LUNs A LUN must be restored to a volume level or a qtree level for it to remain as a LUN. If it is restored to a directory, it is restored as a file because it does not contain
any valid metadata. A 7-Mode LUN is restored as a LUN on an ONTAP volume.
A 7-Mode volume can be restored to an ONTAP volume. VM-aligned files restored to a destination volume inherit the VM-align properties of the destination volume. The destination volume for a restore operation might have files with mandatory or advisory locks. While performing restore operation to such a destination volume, the dump engine
ignores these locks.
Considerations before restoring dataYou can restore backed-up data to its original path or to a
different destination. If you are restoring backed-up data to a different destination, you must prepare the destination for the restore operation. Before restoring data either to its original path or to a different destination, you must have the following information and meet the following requirements: The level of the restore The path to which you are restoring the data The blocking factor used during the backup If you are
doing an incremental restore, all tapes must be in the backup chain A tape drive that is available and compatible with the tape to be restored from
Before restoring data to a different destination, you must perform the following operations: If you are restoring a volume, you must create a new volume. If you are restoring a qtree or a directory, you must rename or move files that are likely to have the same names as files you
are restoring.
|
| In ONTAP 9.7, qtree names support the Unicode format.
|
|
| If a restored file has the same name as an existing file, the existing file is overwritten by the restored file. However, the directories are not overwritten.
|
To rename a file, directory, or qtree during restore without using DAR, you must set the EXTRACT environment variable to E. Required space on the destination storage systemYou require about 100 MB more space on the destination storage system than the amount of data to be restored.
|
| The restore operation checks for volume space and inode availability on the destination volume when the restore operation starts. Setting the FORCE environment variable to Y causes the restore operation to skip the checks for volume space and inode availability on the destination path. If there is not enough volume space or inodes available on the destination volume, the restore operation recovers as much data allowed by the destination volume space and inode availability. The
restore operation stops when there is no more volume space or inodes left.
|
Scalability limits for dump backup and restore sessionsYou
must be aware of the maximum number of dump backup and restore sessions that can be performed simultaneously on storage systems of different system memory capacities. This maximum number depends on the system memory of a storage system. The limits mentioned in the following table are for the dump or restore engine. The limits mentioned in the scalability limits for NDMP sessions are for the NDMP server, which are higher than the engine limits.
| System memory of a storage system | Total number of dump backup and restore sessions |
|---|
Less than 16 GB
| 4
| Greater than or equal to 16 GB but less than 24 GB
| 16
| Greater than or equal to 24 GB
| 32
|
|
| If you use ndmpcopy command to copy data within storage systems, two NDMP sessions are established, one for dump backup and the other for dump restore.
|
You can obtain the system memory of your storage system by using the sysconfig -a command (available through the nodeshell). For more information about using this command, see the man pages. Tape backup and restore support between Data ONTAP operating in 7-Mode and ONTAPYou can restore data backed up from a
storage system operating in 7-Mode or running ONTAP to a storage system either operating in 7-Mode or running ONTAP. The following tape backup and restore operations are supported between Data ONTAP operating in 7-Mode and ONTAP: Backing up a 7-Mode volume to a tape drive connected to a storage system running ONTAP Backing up an ONTAP volume to a tape drive connected to a 7-Mode system Restoring backed-up data of a 7-Mode volume from a tape
drive connected to a storage system running ONTAP Restoring backed-up data of an ONTAP volume from a tape drive connected to a 7-Mode system Restoring a 7-Mode volume to an ONTAP volume
|
| - A 7-Mode LUN is restored as a LUN on an ONTAP volume.
- You should retain the ONTAP LUN identifiers when restoring a 7-Mode LUN to an existing ONTAP LUN.
|
Restoring an ONTAP volume to a 7-Mode volume
|
| An ONTAP LUN is restored as a regular file on a 7-Mode volume.
|
Delete restartable contextsIf you want to start a backup instead of restarting a context, you can delete the context.
About this task You can delete a restartable context using the vserver services ndmp restartable-backup delete command by providing the SVM name and the context ID. Steps Delete a restartable context: vserver services ndmp restartable-backup delete -vserver vserver-name -context-id context_identifier.
cluster::> vserver services ndmpd restartable-backup show
Vserver Context Identifier Is Cleanup Pending?
----------- ------------------------------------ -------------------
vserver1 330e6739-0179-11e6-a299-005056bb4bc9 false
vserver1 481025c1-0179-11e6-a299-005056bb4bc9 false
vserver2 5cf10132-0179-11e6-a299-005056bb4bc9 false
3 entries were displayed.
cluster::>
cluster::> vserver services ndmp restartable-backup delete -vserver vserver1 -context-id 481025c1-0179-11e6-a299-005056bb4bc9
cluster::> vserver services ndmpd restartable-backup show
Vserver Context Identifier Is Cleanup Pending?
----------- ------------------------------------ -------------------
vserver1 330e6739-0179-11e6-a299-005056bb4bc9 false
vserver2 5cf10132-0179-11e6-a299-005056bb4bc9 false
3 entries were displayed.
cluster::>"
How dump works on a SnapVault secondary volumeYou can perform tape backup operations on data that is mirrored on the SnapVault secondary volume. You can back up only the data that is mirrored on the SnapVault secondary volume to tape, and not the SnapVault relationship metadata. When you break the data protection mirror relationship (snapmirror break) or
when a SnapMirror resynchronization occurs, you must always perform a baseline backup. How dump
works with storage failover and ARL operationsBefore you perform dump backup or restore operations, you should understand how these operations work with storage failover (takeover and giveback) or aggregate relocation (ARL) operations. The -override-vetoes option determines the behavior of dump engine during a storage failover or ARL operation. When a dump backup or restore operation is running and the -override-vetoes option is set to false, a user-initiated storage failover or ARL
operation is stopped. However, if the –override-vetoes option is set to true, then the storage failover or ARL operation is continued and the dump backup or restore operation is aborted. When a storage failover or ARL operation is automatically initiated by the storage system, an active dump backup or restore operation is always aborted. You cannot restart dump backup and restore operations even after storage failover or ARL operations complete. Dump operations when CAB extension is supportedIf the backup application supports CAB extension, you can continue performing
incremental dump backup and restore operations without reconfiguring backup policies after a storage failover or ARL operation. Dump operations when CAB extension is not supportedIf the backup application does not support CAB extension, you can continue performing incremental dump backup and restore operations
if you migrate the LIF configured in the backup policy to the node that hosts the destination aggregate. Otherwise, after the storage failover and ARL operation, you must perform a baseline backup prior to performing the incremental backup operation.
|
| For storage failover operations, the LIF configured in the backup policy must be migrated to the partner node.
|
How dump works with volume moveTape backup and restore operations and volume move can run in parallel until the final cutover
phase is attempted by the storage system. After this phase, new tape backup and restore operations are not allowed on the volume that is being moved. However, the current operations continue to run until completion. The following table describes the behavior of tape backup and restore operations after the volume move operation:
| If you are performing tape backup and restore operations in the… | Then… |
|---|
storage virtual machine (SVM) scoped NDMP mode when CAB extension is supported by the backup application
| You can continue performing incremental tape backup and restore operations on read/write and read-only volumes without reconfiguring backup policies.
| SVM-scoped NDMP mode when CAB extension is not supported by the backup application
| You can continue performing incremental tape backup and restore operations on read/write and read-only volumes if you migrate the LIF configured in the backup policy to the node that hosts the destination aggregate. Otherwise, after the volume move, you must perform a baseline backup before performing the incremental backup operation.
|
|
| When a volume move occurs, if the volume belonging to a different SVM on the destination node has the same name as that of the moved volume, then you cannot perform incremental backup operations of the moved volume.
|
How dump works when a FlexVol volume is fullBefore performing an incremental dump backup
operation, you must ensure that there is sufficient free space in the FlexVol volume. If the operation fails, you must increase the free space in the Flex Vol volume either by increasing its size or by deleting the Snapshot copies. Then perform the incremental backup operation again. How dump works when volume access type changesWhen a SnapMirror destination volume or a SnapVault secondary volume changes state from read/write to read-only or from read-only to
read/write, you must perform a baseline tape backup or restore operation. SnapMirror destination and SnapVault secondary volumes are read-only volumes. If you perform tape backup and restore operations on such volumes, you must perform a baseline backup or restore operation whenever the volume changes state from read-only to read/write or from read/write to read-only. How dump works with SnapMirror single file or LUN restoreBefore you perform dump backup or restore operations on a volume to which a single file or LUN is restored by
using SnapMirror technology, you must understand how dump operations work with a single file or LUN restore operation. During a SnapMirror single file or LUN restore operation, client I/O is restricted on the file or LUN being restored. When the single file or LUN restore operation finishes, the I/O restriction on the file or LUN is removed. If a dump backup is performed on a volume to which a single file or LUN is restored, then the file or LUN that has client I/O restriction is not
included in the dump backup. In a subsequent backup operation, this file or LUN is backed up to tape after the I/O restriction is removed. You cannot perform a dump restore and a SnapMirror single file or LUN restore operation simultaneously on the same volume. How dump backup and restore operations are affected in MetroCluster configurationsBefore you perform dump backup and
restore operations in a MetroCluster configuration, you must understand how dump operations are affected when a switchover or switchback operation occurs. Dump backup or restore operation followed by switchoverConsider two clusters: cluster 1 and cluster 2. During a dump backup or restore operation on cluster 1, if a switchover
is initiated from cluster 1 to cluster 2, then the following occurs: If the value of the override-vetoes option is false, then the switchover is aborted and the backup or restore operation continues. If the value of the option is true, then the dump backup or restore operation is aborted and the switchover continues.
Dump backup or restore operation followed by switchbackA switchover is performed from cluster 1 to cluster 2 and a dump backup or restore operation is initiated on cluster 2.
The dump operation backs up or restores a volume that is located on cluster 2. At this point, if a switchback is initiated from cluster 2 to cluster 1, then the following occurs: If the value of the override-vetoes option is false, then the switchback is cancelled and the backup or restore operation continues. If the value of the option is true, then the backup or restore operation is aborted and the switchback continues.
Dump backup or restore operation initiated during a
switchover or switchbackDuring a switchover from cluster 1 to cluster 2, if a dump backup or restore operation is initiated on cluster 1, then the backup or restore operation fails and the switchover continues. During a switchback from cluster 2 to cluster 1, if a dump backup or restore operation is initiated from cluster 2, then the backup or restore operation fails and the switchback continues. About SMTape engine for FlexVol volumesSMTape is a disaster recovery solution from ONTAP that backs up blocks of data to tape. You can use SMTape to perform volume backups to tapes. However, you cannot
perform a backup at the qtree or subtree level. SMTape supports baseline, differential, and incremental backups. SMTape does not require a license. You can perform an SMTape backup and restore operation by using an NDMP-compliant backup application. You can choose SMTape to perform backup and restore operations only in the storage virtual machine (SVM) scoped NDMP mode.
|
| Reversion process is not supported when an SMTape backup or restore session is in progress. You must wait until the session finishes or you must abort the NDMP session.
|
Using SMTape, you can back up 255 Snapshot copies. For subsequent baseline, incremental, or differential backups, you must delete older backed-up Snapshot copies. Before performing a baseline restore, the volume to which data is being restored must be of type DP and this volume must be in the restricted state. After a successful restore, this volume is automatically online. You can perform subsequent incremental or differential restores on this volume in
the order in which the backups were performed. Use Snapshot copies during SMTape backupYou should understand how Snapshot
copies are used during an SMTape baseline backup and an incremental backup. There are also considerations to keep in mind while performing a backup using SMTape. Baseline backupWhile performing a baseline backup, you
can specify the name of the Snapshot copy to be backed up to tape. If no Snapshot copy is specified, then depending on the access type of the volume (read/write or read-only), either a Snapshot copy is created automatically or existing Snapshot copies are used. When you specify a Snapshot copy for the backup, all the Snapshot copies older than the specified Snapshot copy are also backed up to tape. If you do not specify a Snapshot copy for the backup, the following occurs: -
For a read/write volume, a Snapshot copy is created automatically. The newly created Snapshot copy and all the older Snapshot copies are backed up to tape. For a read-only volume, all the Snapshot copies, including the latest Snapshot copy, are backed up to tape. Any new Snapshot copies created after the backup is started are not backed up.
Incremental backupFor SMTape incremental or differential backup operations, the NDMP-compliant backup applications create and manage the Snapshot copies. You must always specify a Snapshot copy while performing an incremental backup operation.
For a successful incremental backup operation, the Snapshot copy backed up during the previous backup operation (baseline or incremental) must be on the volume from which the backup is performed. To ensure that you use this backed-up Snapshot copy, you must consider the Snapshot policy assigned on this volume while configuring the backup policy. Considerations on SMTape backups on SnapMirror destinationsA data protection mirror relationship creates temporary Snapshot copies on the destination
volume for replication. You should not use these Snapshot copies for SMTape backup. If a SnapMirror update occurs on a destination volume in a data protection mirror relationship during an SMTape backup operation on the same volume, then the Snapshot copy that is backed up by SMTape must not be deleted on the source volume. During the backup operation, SMTape locks the Snapshot copy on the destination volume and if the corresponding Snapshot copy is deleted on the
source volume, then the subsequent SnapMirror update operation fails. You should not use these Snapshot copies during incremental backup.
SMTape capabilities
SMTape capabilities such as backup of Snapshot copies, incremental and differential backups, preservation of deduplication and compression features on restored volumes, and tape seeding help you optimize your tape backup and restore operations. SMTape provides the following capabilities: Provides a disaster recovery solution Enables incremental and differential backups Backs up Snapshot copies Enables backup and
restore of deduplicated volumes and preserves deduplication on the restored volumes Backs up compressed volumes and preserves compression on the restored volumes Enables tape seeding
SMTape supports the blocking factor in multiples of 4 KB, in the range of 4 KB through 256 KB.
|
| You can restore data to volumes created across up to two major consecutive ONTAP releases only.
|
Scalability limits for SMTape backup and restore sessions
While performing SMTape backup and restore operations through NDMP or CLI (tape seeding), you must be aware of the maximum number of SMTape backup and restore sessions that can be performed simultaneously on storage systems with different system memory capacities. This maximum number depends on the system memory of a storage system.
|
| SMTape backup and restore sessions scalability limits are different from NDMP session limits and dump session limits.
|
| System memory of the storage system | Total number of SMTape backup and restore sessions |
|---|
Less than 16 GB
| 6
| Greater than or equal to 16 GB but less than 24 GB
| 16
| Greater than or equal to 24 GB
| 32
|
You can obtain the system memory of your storage system by using the sysconfig -a command (available through the nodeshell). For more information about using this command, see the man pages. What tape seeding isTape seeding is an SMTape functionality that helps you initialize a destination FlexVol volume in a data protection mirror relationship. Tape seeding enables you to establish a data protection mirror relationship
between a source system and a destination system over a low-bandwidth connection. Incremental mirroring of Snapshot copies from the source to the destination is feasible over a low bandwidth connection. However, an initial mirroring of the base Snapshot copy takes a long time over a low-bandwidth connection. In such cases, you can perform an SMTape backup of the source volume to a tape and use the tape to transfer the initial base Snapshot copy to the destination. You can then set up
incremental SnapMirror updates to the destination system using the low-bandwidth connection. How SMTape works with storage failover and ARL operationsBefore you perform SMTape backup or restore operations, you should understand how these operations work with
storage failover (takeover and giveback) or aggregate relocation (ARL) operation. The -override-vetoes option determines the behavior of SMTape engine during a storage failover or ARL operation. When an SMTape backup or restore operation is running and the -override-vetoes option is set to false, a user-initiated storage failover or ARL operation is stopped and the backup or restore operation complete. If the backup application supports CAB extension, then you can continue performing incremental SMTape
backup and restore operations without reconfiguring backup policies. However, if the –override-vetoes option is set to true, then the storage failover or ARL operation is continued and the SMTape backup or restore operation is aborted. How SMTape works with volume moveSMTape backup operations and volume move operations can run in parallel until the storage system attempts the final cutover phase. After this phase, new SMTape backup operations
cannot run on the volume that is being moved. However, the current operations continue to run until completion. Before the cutover phase for a volume is started, the volume move operation checks for active SMTape backup operations on the same volume. If there are active SMTape backup operations, then the volume move operation moves into a cutover deferred state and allows the SMTape backup operations to complete. After these backup operations are completed, you must manually restart the
volume move operation. If the backup application supports CAB extension, you can continue performing incremental tape backup and restore operations on read/write and read-only volumes without reconfiguring backup policies. Baseline restore and volume move operations cannot be performed simultaneously; however, incremental restore can run in parallel with volume move operations, with the behavior similar to that of SMTape backup operations during volume move operations.
How SMTape works with volume rehost operationsSMTape operations cannot commence when a volume rehost operation is in
progress on a volume. When a volume is involved in a volume rehost operation, SMTape sessions should not be started on that volume. If any volume rehost operation is in progress, then SMTape backup or restore fails. If an SMTape backup or restore is in progress, then volume rehost operations fail with an appropriate error message. This condition applies to both NDMP-based and CLI-based backup or restore operations. How NDMP backup policy are affected during ADBWhen the automatic data balancer (ADB) is enabled, the balancer analyzes the usage
statistics of aggregates to identify the aggregate that has exceeded the configured high-threshold usage percentage. After identifying the aggregate that has exceeded the threshold, the balancer identifies a volume that can be moved to aggregates residing in another node in the cluster and attempts to move that volume. This situation affects the backup policy configured for this volume because if the data management application (DMA) is not CAB aware, then the user has to reconfigure the
backup policy and run the baseline backup operation.
|
| If the DMA is CAB aware and the backup policy has been configured using specific interface, then the ADB is not affected.
|
How SMTape backup and restore operations are affected in MetroCluster configurationsBefore you perform SMTape
backup and restore operations in a MetroCluster configuration, you must understand how SMTape operations are affected when a switchover or switchback operation occurs. SMTape backup or restore operation followed by switchoverConsider two clusters: cluster 1 and cluster 2. During an SMTape backup or restore operation on cluster 1, if a
switchover is initiated from cluster 1 to cluster 2, then the following occurs: If the value of the –override-vetoes option is false, then the switchover process is aborted and the backup or restore operation continues. If the value of the option is true, then the SMTape backup or restore operation is aborted and the switchover process continues.
SMTape backup or restore operation followed by switchbackA switchover is performed from cluster 1 to cluster 2 and an SMTape backup or restore operation is initiated on cluster 2. The
SMTape operation backs up or restores a volume that is located on cluster 2. At this point, if a switchback is initiated from cluster 2 to cluster 1, then the following occurs: If the value of the –override-vetoes option is false, then the switchback process is aborted and the backup or restore operation continues. If the value of the option is true, then the backup or restore operation is aborted and the switchback process continues.
SMTape backup or restore operation initiated
during a switchover or switchbackDuring a switchover process from cluster 1 to cluster 2, if an SMTape backup or restore operation is initiated on cluster 1, then the backup or restore operation fails and the switchover continues. During a switchback process from cluster 2 to cluster 1, if an SMTape backup or restore operation is initiated from cluster 2, then the backup or restore operation fails and the switchback continues. Monitor tape backup and restore operations for FlexVol volumes
overviewYou can view the event log files to monitor the tape backup and restore operations. ONTAP automatically logs significant backup and restore events and the time at which they occur in a log file named backup in the controller’s /etc/log/ directory. By default, event logging is set to on. You might want to view event log files for the following reasons: Checking whether a nightly backup was successful Gathering statistics on
backup operations For using the information in past event log files to help diagnose problems with backup and restore operations
Once every week, the event log files are rotated. The /etc/log/backup file is renamed to /etc/log/backup.0, the /etc/log/backup.0 file is renamed to /etc/log/backup.1, and so on. The system saves the log files for up to six weeks; therefore, you can have up to seven message files (/etc/log/backup.[0-5] and the current /etc/log/backup file). Access the event log filesYou can access the event log files for tape backup and restore operations in the /etc/log/ directory by using the rdfile command at the nodeshell. You can view these
event log files to monitor tape backup and restore operations. About this task With additional configurations, such as an access-control role with access to the spi web service or a user account set up with the http access method, you can also use a web browser to access these log files. Steps To access the nodeshell, enter the following command: node run -node node_name
node_name is the name of the node.
To access the event log
files for tape backup and restore operations, enter the following command: rdfile /etc/log/backup
For each dump and restore event, a message is written to the backup log file. The format of the dump and restore event log message is as follows: type timestamp identifier event (event_info)
The following list describes the fields in the event log message format: Each log message begins with one of the type indicators described in the following table:
| Type | Description |
|---|
log
| Logging event
| dmp
| Dump event
| rst
| Restore event
|
timestamp shows the date and time of the event.
The identifier field for a dump event includes the dump path and the unique ID for the dump. The identifier field for a restore event uses only the restore destination path name as a unique identifier. Logging-related event messages do not include an identifier field.
What logging events areThe event field of a message that begins with a log specifies the beginning of a logging or the end of a logging. It contains one of the events shown in the following table:
| Event | Description |
|---|
Start_Logging
| Indicates the beginning of logging or that logging has been turned back on after being disabled.
| Stop_Logging
| Indicates that logging has been turned off.
|
What dump events areThe event field for a dump event contains an event type followed by event-specific information within parentheses. The following table
describes the events, their descriptions, and the related event information that might be recorded for a dump operation:
| Event | Description | Event information |
|---|
Start
| NDMP dump is started
| Dump level and the type of dump
| End
| Dumps completed successfully
| Amount of data processed
| Abort
| The operation is cancelled
| Amount of data processed
| Options
| Specified options are listed
| All options and their associated values, including NDMP options
| Tape_open
| The tape is open for read/write
| The new tape device name
| Tape_close
| The tape is closed for read/write
| The tape device name
| Phase-change
| A dump is entering a new processing phase
| The new phase name
| Error
| A dump has encountered an unexpected event
| Error message
| Snapshot
| A Snapshot copy is created or located
| The name and time of the Snapshot copy
| Base_dump
| A base dump entry in the internal metafile has been located
| The level and time of the base dump (for incremental dumps only)
|
What restore events areThe event field for a restore event contains an event type followed by event-specific information in parentheses. The
following table provides information about the events, their descriptions, and the related event information that can be recorded for a restore operation:
| Event | Description | Event information |
|---|
Start
| NDMP restore is started
| Restore level and the type of restore
| End
| Restores completed successfully
| Number of files and amount of data processed
| Abort
| The operation is cancelled
| Number of files and amount of data processed
| Options
| Specified options are listed
| All options and their associated values, including NDMP options
| Tape_open
| The tape is open for read/write
| The new tape device name
| Tape_close
| The tape is closed for read/write
| The tape device name
| Phase-change
| Restore is entering a new processing phase
| The new phase name
| Error
| Restore encounters an unexpected event
| Error message
|
Enabling or disabling event loggingYou can turn the event logging on or off. Steps To enable
or disable event logging, enter the following command at the clustershell: options -option_name backup.log.enable -option-value {on | off}
on turns event logging on.
off turns event logging off.
|
| Event logging is turned on by default.
|
Resource limitation: no available threadMessage Resource limitation: no available thread
Cause The maximum number of active local tape I/O threads is currently in use. You can have a maximum of 16 active local tape drives. Corrective action Wait for some tape jobs to finish before starting a new backup or restore job.
Tape reservation preemptedMessage Tape reservation preempted
Cause The tape drive is in use by another operation or the tape has been closed prematurely. Corrective
action Ensure that the tape drive is not in use by another operation and that the DMA application has not aborted the job and then retry.
Message Media error on tape write
Cause The tape used for the backup is corrupted. Corrective action Replace the tape and retry the backup job.
Tape write failedMessage Tape write failed - new tape encountered media error
Cause The tape used for the backup is corrupted. Corrective action Replace the tape and retry the backup.
Message Tape write failed - new tape is already at the end of media
Cause There is not enough space on the tape to complete the backup. Corrective action
Replace the tape and retry the backup.
Tape write errorMessage Tape write error - The previous tape had less than the required minimum capacity, size MB, for this tape operation, The operation should be restarted from the beginning
Cause The tape capacity is insufficient to
contain the backup data. Corrective action Use tapes with larger capacity and retry the backup job.
Message Media error on tape read
Cause The tape from which data is being restored is corrupted and might not contain the complete backup data. Corrective action If you are sure that the tape has the complete backup, retry the restore
operation. If the tape does not contain the complete backup, you cannot perform the restore operation.
Tape read errorMessage Tape read error
Cause
The tape drive is damaged or the tape does not contain the complete backup. Corrective action If the tape drive is damaged, use another tape drive. If the tape does not contain the complete backup, you cannot restore the data.
Already at the end of tapeMessage Already at the end of tape
Cause The tape does not contain any data or must be rewound. Corrective action
If the tape does not contain data, use the tape that contains the backup and retry the restore job. Otherwise, rewind the tape and retry the restore job.
Tape record size is too small. Try a larger size.Message Tape record size is too small. Try a larger size.
Cause The blocking factor specified for the restore
operation is smaller than the blocking factor that was used during the backup. Corrective action Use the same blocking factor that was specified during the backup.
Tape record size must be in the range between 4KB and 256KBMessage Tape record size must be in the range between 4KB and 256KB
Cause The
blocking factor specified for the backup or restore operation is not within the permitted range. Corrective action Specify a blocking factor in the range of 4 KB to 256 KB.
Network communication errorMessage Network communication error
Cause Communication to a remote tape in an NDMP three-way connection has failed. Corrective
action Check the network connection to the remote mover.
Message from Read Socket: error_stringMessage
Message from Read Socket: error_string
Cause Restore communication from the remote tape in NDMP 3-way connection has errors. Corrective action Check the network connection to the remote mover.
Message from Write Dirnet: error_stringMessage Message from Write Dirnet: error_string
Cause Backup communication to a remote tape in an NDMP three-way connection has
an error. Corrective action Check the network connection to the remote mover.
Read Socket received EOFMessage
Read Socket received EOF
Cause Attempt to communicate with a remote tape in an NDMP three-way connection has reached the End Of File mark. You might be attempting a three-way restore from a backup image with a larger block size. Corrective action Specify the correct block size and retry the restore operation.
ndmpd session session_ID not activeMessage ndmpd session session_ID not active
Cause The NDMP session might not exist. Corrective
action
Use the ndmpd status command to view the active NDMP sessions.
Could not obtain vol ref for Volume
volume_nameMessage Could not obtain vol ref for Volume vol_name
Cause The volume reference could not be obtained because the volume might be in use by other operations. Corrective action Retry the operation later.
DATA LISTEN: CAB data connection prepare precondition errorMessage DATA LISTEN: CAB data connection prepare precondition error
Cause NDMP data
listen fails when the backup application has negotiated the CAB extension with the NDMP server and there is a mismatch in the specified NDMP data connection address type between the NDMP_CAB_DATA_CONN_PREPARE and the NDMP_DATA_LISTEN messages. Corrective action Contact your backup application vendor.
DATA CONNECT: CAB data connection prepare precondition errorMessage DATA CONNECT: CAB data connection prepare precondition error
Cause NDMP data
connect fails when the backup application has negotiated the CAB extension with the NDMP server and there is a mismatch in the specified NDMP data connection address type between the NDMP_CAB_DATA_CONN_PREPARE and the NDMP_DATA_CONNECT messages. Corrective action Contact your backup application vendor.
Error:show failed: Cannot get password for user '<username>'Message Error: show failed: Cannot get password for user '<username>'
Cause Incomplete
user account configuration for NDMP Corrective action Ensure that the user account is associated with the SSH access method and the authentication method is user password.
Destination volume is read-onlyMessage Destination volume is read-only
Cause The path to which the restore operation is attempted to is read-only. Corrective
action Try restoring the data to a different location.
Destination qtree is read-onlyMessage Destination qtree is read-only
Cause The qtree to which the restore is attempted to is read-only. Corrective action Try restoring the data to a different location.
Dumps temporarily disabled on volume, try againMessage Dumps temporarily disabled on volume, try again
Cause NDMP dump backup is attempted on a SnapMirror
destination volume that is part of either a snapmirror break or a snapmirror resync operation. Corrective action Wait for the snapmirror break or snapmirror resync operation to finish and then perform the dump operation.
|
| Whenever the state of a SnapMirror destination volume changes from read/write to read-only or from read-only to read/write, you must perform a baseline backup.
|
NFS labels not recognizedMessage Error: Aborting: dump encountered NFS security labels in the file system
Cause NFS security labels are
supported Beginning with ONTAP 9.9.1 when NFSv4.2 is enabled. However, NFS security labels are not currently recognized by the dump engine. If it encounters any NFS security labels on the files, directories, or any special files in any format of dump, the dump fails. Corrective action Verify that no files or directories have NFS security labels.
No files were createdRestore of the file <file name> failed-
Message Restore of the file file name failed
Cause When a DAR (Direct Access Recovery) of a file whose file name is the same as that of a LUN on the destination volume is performed, then the DAR fails. Corrective action Retry DAR of the file.
Truncation failed for src inode <inode number>…Message Truncation failed for src inode <inode number>. Error <error number>. Skipping inode.
Cause Inode of a file is deleted when the file is
being restored. Corrective action Wait for the restore operation on a volume to complete before using that volume.
Unable to lock a snapshot needed by dumpMessage Unable to lock a snapshot needed by dump
Cause The Snapshot copy specified for the backup is not available.
Corrective action Retry the backup with a different Snapshot copy. Use the snap list command to see the list of available Snapshot copies.
Unable to locate bitmap filesMessage Unable to locate bitmap files
Cause The bitmap files required for the backup operation might have been deleted. In this case, the backup
cannot be restarted. Corrective action Perform the backup again.
Volume is
temporarily in a transitional stateMessage Volume is temporarily in a transitional state
Cause The volume being backed up is temporarily in an unmounted state. Corrective action Wait for some time and perform the backup again.
Chunks out of orderMessage Chunk format not supported
Cause
The backup image is not of SMTape. Corrective action If the backup image is not of SMTape, retry the operation with a tape that has the SMTape backup.
Failed to allocate memoryMessage Failed to allocate memory
Cause The system has run out of memory. Corrective action Retry the job later
when the system is not too busy.
Failed to get data bufferMessage Failed to get data buffer
Cause The storage
system ran out of buffers. Corrective action Wait for some storage system operations to finish and then retry the job.
Failed to find
snapshot
Message Failed to find snapshot
Cause The Snapshot copy specified for the backup is unavailable. Corrective action Check if the specified Snapshot copy is available. If not, retry with the correct Snapshot copy.
Failed to create snapshotMessage Failed to create snapshot
Cause The volume already contains the maximum number of Snapshot copies. Corrective
action Delete some Snapshot copies and then retry the backup operation.
Failed to lock snapshotMessage Failed to lock snapshot
Cause The Snapshot copy is either in use or has been deleted. Corrective action If the Snapshot copy is in use by another operation, wait for that operation to finish and then retry the backup. If the Snapshot copy has been deleted, you cannot perform the backup.
Failed to delete snapshotMessage Failed to delete snapshot
Cause The auto Snapshot copy could not be deleted because it is in use by other operations. Corrective
action Use the snap command to determine the status of the Snapshot copy. If the Snapshot copy is not required, delete it manually.
Failed to get
latest snapshotMessage Failed to get latest snapshot
Cause The latest Snapshot copy might not exist because the volume is being initialized by SnapMirror. Corrective action Retry after initialization is complete.
Failed to load new tapeFailed to initialize tapeFailed to initialize restore streamFailed to read backup imageMessage Image header missing or corrupted
Cause The tape does not contain a valid SMTape backup. Corrective action Retry with a tape containing a valid backup.
Internal assertionInvalid backup image magic numberMessage Invalid backup image magic number
Cause
The backup image is not of SMTape. Corrective action If the backup image is not of SMTape, retry the operation with a tape that has the SMTape backup.
Invalid backup image checksumInvalid volume pathMismatch in backup set IDMessage Mismatch in backup set ID
Cause
The tape loaded during a tape change is not a part of the backup set. Corrective action Load the correct tape and retry the job.
Mismatch in backup time stampMessage Mismatch in backup time stamp
Cause The tape loaded during a tape change is not a part of the backup set. Corrective
action Use the smtape restore -h command to verify the header information of a tape.
Job aborted due to shutdownMessage
Job aborted due to shutdown
Cause The storage system is being rebooted. Corrective action Retry the job after the storage system reboots.
Job aborted due to Snapshot autodeleteMessage Job aborted due to Snapshot autodelete
Cause The volume does not have enough space and has triggered the automatic
deletion of Snapshot copies. Corrective action Free up space in the volume and retry the job.
Tape is currently in use by other operationsMessage Tape is currently in use by other operations
Cause The tape drive is in use by another job. Corrective
action Retry the backup after the currently active job is finished.
Tapes out of orderTransfer failed (Aborted due to MetroCluster operation)Message Transfer failed (Aborted due to MetroCluster operation)
Cause The SMTape operation is
aborted because of a switchover or switchback operation. Corrective action Perform the SMTape operation after the switchover or switchback operation finishes.
Transfer failed (ARL initiated abort)Message Transfer failed (ARL initiated abort)
Cause While an SMTape operation is in progress if an aggregate relocation is initiated,
then the SMTape operation is aborted. Corrective action Perform the SMTape operation after the aggregate relocation operation finishes.
Transfer failed (CFO initiated abort)Message Transfer failed (CFO initiated abort)
Cause The SMTape operation is aborted because of a storage failover (takeover and
giveback) operation of a CFO aggregate. Corrective action Perform the SMTape operation after the storage failover of the CFO aggregate finishes.
Transfer failed (SFO initiated abort)Message Transfer failed (SFO initiated abort)
Cause The SMTape operation is aborted because of a storage failover (takeover and
giveback) operation. Corrective action Perform the SMTape operation after the storage failover (takeover and giveback) operation finishes.
Underlying aggregate under migrationMessage Underlying aggregate under migration
Cause If an SMTape operation is initiated on an aggregate that is under migration
(storage failover or aggregate relocation), then the SMTape operation fails. Corrective action Perform the SMTape operation after the aggregate migration finishes.
Volume is currently under migrationMessage Volume is currently under migration
Cause Volume migration and SMTape backup cannot run simultaneously. Corrective
action Retry the backup job after the volume migration is complete.
Volume offlineVolume not restrictedNDMP configuration overviewYou can quickly configure an ONTAP 9 cluster to use the Network Data Management Protocol (NDMP) to back up data directly to tape using a third-party backup application. Configure NDMP in the following circumstances:
The cluster is running ONTAP 9.7. You have a third-party backup application (also called a Data Management Application or DMA). You are a cluster administrator. You want to perform backup operations either at the cluster level (using the admin storage virtual machine (SVM)) or node level. Tape devices and an optional media server are installed. Tape devices are connected to the cluster through a Fibre Channel (FC)
switch and not directly attached. At least one tape device has a logical unit number (LUN) of 0. NDMP configuration workflowSetting up
tape backup over NDMP involves preparing for NDMP configuration, verifying the tape device connections, enabling tape reservations, configuring NDMP at the SVM or node level, enabling NDMP on the cluster, configuring a backup user, configuring LIFs, and configuring the backup application. Prepare for NDMP configurationBefore you configure tape backup access over Network Data Management Protocol (NDMP), you must verify that the planned configuration is supported, verify that your tape drives are listed as
qualified drives on each node, verify that all nodes have intercluster LIFs, and identify whether the backup application supports the Cluster Aware Backup (CAB) extension. Steps Verify that the planned configuration is supported by contacting Fujitsu support personnel. You should verify that the following components are compatible: The version of ONTAP 9 that is running on the cluster. The backup application vendor and application
version: for example, Symantec NetBackup 7.6 or CommVault Simpana 10 SP8. The tape devices details, such as the manufacturer, model, and interface of the tape drives: for example, IBM Ultrium-TD4 FC or HP Ultrium-5 SAS. The platforms of the nodes in the cluster.
Verify that your tape drives are listed as qualified drives in each node’s built-in tape configuration file: On the command line-interface, view the
built-in tape configuration file by using the storage tape show-supported-status command. cluster1::> storage tape show-supported-status
Node: cluster1-1
Is
Tape Drives Supported Support Status
------------------------------ --------- -------------------------------
Certance Ultrium 2 true Dynamically Qualified
Certance Ultrium 3 true Dynamically Qualified
Digital DLT2000 true Qualified
....Compare your tape drives to the list of qualified drives in the output.
|
| The names of the tape devices in the output might vary slightly from the names on the device label. For example, Digital DLT2000 can also be known as DLT2k. You can ignore these minor naming differences.
|
If a device is not listed as qualified in the output even though the device is qualified according to the support personnel, download and install an updated configuration file for the device using the instructions on the DVD included in the Product.
A qualified device might not be listed in the built-in tape configuration file if the tape device was qualified after the node was shipped. Verify that every node in the cluster
has an intercluster LIF: View the intercluster LIFs on the nodes by using the network interface show -role intercluster command. cluster1::> network interface show -role intercluster
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cluster1 IC1 up/up 192.0.2.65/24 cluster1-1 e0a trueIf an intercluster LIF does not exist on any node, create an intercluster LIF by using the network interface create command. cluster1::> network interface create -vserver cluster1 -lif IC2 -role intercluster
-home-node cluster1-2 -home-port e0b -address 192.0.2.68 -netmask 255.255.255.0
-status-admin up -failover-policy local-only -firewall-policy intercluster
cluster1::> network interface show -role intercluster
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cluster1 IC1 up/up 192.0.2.65/24 cluster1-1 e0a true
cluster1 IC2 up/up 192.0.2.68/24 cluster1-2 e0b true
Identify whether the backup application supports Cluster Aware Backup (CAB) by using the documentation provided with the backup application. CAB support is a key factor in
determining the type of backup you can perform.
Verify tape device connectionsYou must ensure that all drives and media changers are visible
in ONTAP as devices. Steps View information about all drives and media changers by using the storage tape show command. cluster1::> storage tape show
Node: cluster1-01
Device ID Device Type Description Status
---------------------- -------------- ------------------------------ --------
sw4:10.11 tape drive HP LTO-3 normal
0b.125L1 media changer HP MSL G3 Series normal
0d.4 tape drive IBM LTO 5 ULT3580 normal
0d.4L1 media changer IBM 3573-TL normal
... If a tape drive is not displayed, troubleshoot the problem. If a media changer is not displayed, view information about media changers by using the storage tape show-media-changer command, and then troubleshoot the problem. cluster1::> storage tape show-media-changer
Media Changer: sw4:10.11L1
Description: PX70-TL
WWNN: 2:00a:000e11:10b919
WWPN: 2:00b:000e11:10b919
Serial Number: 00FRU7800000_LL1
Errors: -
Paths:
Node Initiator Alias Device State Status
------------------------ --------- ------- ------------------------ --------
cluster1-01 2b mc0 in-use normal
...
Enable tape reservationsYou must ensure that tape drives are reserved for use by backup applications for NDMP backup operations. About this task The reservation settings vary in different backup applications, and
these settings must match the backup application and the nodes or servers using the same drives. See the vendor documentation of the backup application for the correct reservation settings. Steps Enable reservations by using the options -option-name tape.reservations -option-value persistent command. The following command enables reservations with the persistent value: cluster1::> options -option-name tape.reservations -option-value persistent
2 entries were modified. Verify that reservations are enabled on all nodes by using the options tape.reservations command, and then review the output.
cluster1::> options tape.reservations
cluster1-1
tape.reservations persistent
cluster1-2
tape.reservations persistent
2 entries were displayed.
If the backup application supports Cluster Aware Backup (CAB), you can configure NDMP as SVM-scoped at the cluster (admin SVM) level, which enables you to back up all volumes hosted across different nodes of the cluster. Otherwise, you can configure node-scoped NDMP, which enables you to back up all the volumes hosted on that node. If the DMA supports the Cluster Aware Backup (CAB) extension, you can back up all the volumes hosted across different nodes in a cluster by enabling SVM-scoped NDMP, configuring
a backup user account, and configuring LIFs for data and control connection. What you’ll need The CAB extension must be supported by the DMA. Enable SVM-scoped NDMP on the clusterYou can configure SVM-scoped NDMP on the cluster by enabling SVM-scoped NDMP mode and NDMP service on the cluster (admin SVM). About this task Turning
off node-scoped NDMP mode enables SVM-scoped NDMP mode on the cluster. Steps Enable SVM-scoped NDMP mode by using the system services ndmp command with the node-scope-mode parameter. cluster1::> system services ndmp node-scope-mode off
NDMP node-scope-mode is disabled. Enable NDMP service on the admin SVM by using the vserver services ndmp on command. cluster1::> vserver services ndmp on -vserver cluster1 The authentication type is set to challenge by default and plaintext authentication is disabled.
|
| For secure communication, you should keep plaintext authentication disabled.
|
Verify that NDMP service is enabled by using the vserver services ndmp show command. cluster1::> vserver services ndmp show
Vserver Enabled Authentication type
------------- --------- -------------------
cluster1 true challenge
vs1 false challenge
To authenticate NDMP from the backup application, you must create a local backup user, or an NIS or LDAP user for the cluster with the admin or backup role, and generate an NDMP password for the backup user. What you’ll need If you are using an NIS or LDAP user, the user must be created on the respective server. You cannot use an Active Directory user. Steps Create a backup user with the admin or
backup role by using the security login create command. You can specify a local backup user name or an NIS or LDAP user name for the -user-or-group-name parameter. The following command creates the backup user backup_admin1 with the backup role: cluster1::> security login create -user-or-group-name backup_admin1 -application ssh
-authmethod password -role backup
Please enter a password for user 'backup_admin1':
Please enter it again: Generate a password for the admin SVM by using the vserver services ndmp generate password command. The generated password must be used to authenticate the NDMP connection by the backup application. cluster1::> vserver services ndmp generate-password -vserver cluster1 -user backup_admin1
Vserver: cluster1
User: backup_admin1
Password: qG5CqQHYxw7tE57g
You must identify the LIFs that will be used for establishing a data connection between the data and tape resources, and for control connection between the admin SVM and the backup application. After
identifying the LIFs, you must verify that firewall and failover policies are set for the LIFs, and specify the preferred interface role. Steps Identify the intercluster, cluster-management, and node-management LIFs by using the network interface show command with the -role parameter. The following command displays the intercluster LIFs: cluster1::> network interface show -role intercluster
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cluster1 IC1 up/up 192.0.2.65/24 cluster1-1 e0a true
cluster1 IC2 up/up 192.0.2.68/24 cluster1-2 e0b trueThe following command displays the cluster-management LIF: cluster1::> network interface show -role cluster-mgmt
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cluster1 cluster_mgmt up/up 192.0.2.60/24 cluster1-2 e0M trueThe following command displays
the node-management LIFs: cluster1::> network interface show -role node-mgmt
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------ ------ ------
cluster1 cluster1-1_mgmt1 up/up 192.0.2.69/24 cluster1-1 e0M true
cluster1-2_mgmt1 up/up 192.0.2.70/24 cluster1-2 e0M trueEnsure that the firewall policy is enabled for NDMP on the intercluster, cluster-management (cluster-mgmt), and node-management (node-mgmt) LIFs: Verify that the firewall policy is enabled for NDMP by using the system services firewall policy show command. The following command displays the firewall policy for the cluster-management LIF: cluster1::> system services firewall policy show -policy cluster
Vserver Policy Service Allowed
------- ------------ ---------- -----------------
cluster cluster dns 0.0.0.0/0
http 0.0.0.0/0
https 0.0.0.0/0
** ndmp 0.0.0.0/0**
ndmps 0.0.0.0/0
ntp 0.0.0.0/0
rsh 0.0.0.0/0
snmp 0.0.0.0/0
ssh 0.0.0.0/0
telnet 0.0.0.0/0
10 entries were displayed.The following command displays the firewall policy for the intercluster
LIF: cluster1::> system services firewall policy show -policy intercluster
Vserver Policy Service Allowed
------- ------------ ---------- -------------------
cluster1 intercluster dns -
http -
https -
**ndmp 0.0.0.0/0, ::/0**
ndmps -
ntp -
rsh -
ssh -
telnet -
9 entries were displayed.The following command displays the firewall policy for the node-management LIF: cluster1::> system services firewall policy show -policy mgmt
Vserver Policy Service Allowed
------- ------------ ---------- -------------------
cluster1-1 mgmt dns 0.0.0.0/0, ::/0
http 0.0.0.0/0, ::/0
https 0.0.0.0/0, ::/0
**ndmp 0.0.0.0/0, ::/0**
ndmps 0.0.0.0/0, ::/0
ntp 0.0.0.0/0, ::/0
rsh -
snmp 0.0.0.0/0, ::/0
ssh 0.0.0.0/0, ::/0
telnet -
10 entries were displayed.If the firewall policy is not enabled, enable the firewall policy by using the system services firewall policy modify command with the -service parameter. The following command enables firewall policy for the intercluster LIF: cluster1::> system services firewall policy modify -vserver cluster1 -policy intercluster -service ndmp 0.0.0.0/0
Ensure that the failover policy is set appropriately for all the LIFs: Verify
that the failover policy for the cluster-management LIF is set to broadcast-domain-wide, and the policy for the intercluster and node-management LIFs is set to local-only by using the network interface show -failover command. The following command displays the failover policy for the cluster-management, intercluster, and node-management LIFs: cluster1::> network interface show -failover
Logical Home Failover Failover
Vserver Interface Node:Port Policy Group
---------- ----------------- ----------------- -------------------- --------
cluster cluster1_clus1 cluster1-1:e0a local-only cluster
Failover Targets:
.......
**cluster1 cluster_mgmt cluster1-1:e0m broadcast-domain-wide Default**
Failover Targets:
.......
**IC1 cluster1-1:e0a local-only Default**
Failover Targets:
**IC2 cluster1-1:e0b local-only Default**
Failover Targets:
.......
**cluster1-1 cluster1-1_mgmt1 cluster1-1:e0m local-only Default**
Failover Targets:
......
**cluster1-2 cluster1-2_mgmt1 cluster1-2:e0m local-only Default**
Failover Targets:
......If the failover policies are not set appropriately, modify the failover policy by using the network interface modify command with the -failover-policy parameter. cluster1::> network interface modify -vserver cluster1 -lif IC1 -failover-policy local-only
Specify the LIFs that are required for data connection by using the vserver services ndmp modify command with the preferred-interface-role parameter. cluster1::> vserver services ndmp modify -vserver cluster1 -preferred-interface-role intercluster,cluster-mgmt,node-mgmt Verify that the preferred interface role is set for the cluster by using the vserver services ndmp show command. cluster1::> vserver services ndmp show -vserver cluster1
Vserver: cluster1
NDMP Version: 4
.......
.......
Preferred Interface Role: intercluster, cluster-mgmt, node-mgmt
Enable node-scoped NDMP on the clusterYou can back up volumes hosted on a node by enabling node-scoped NDMP, setting up the password for the root user, and configuring a LIF for data and control
connection. You can configure node-scoped NDMP by enabling node-scoped NDMP on the cluster and NDMP service on all nodes of the cluster. You must also configure the root user for NDMP when enabling the NDMP service. Steps Enable node-scoped NDMP mode by using the system services ndmp command with the node-scope-mode parameter. cluster1::> system services ndmp node-scope-mode on
NDMP node-scope-mode is enabled. Enable NDMP service on all nodes in the cluster by using the system services ndmp on command. Using the wildcard “*” enables NDMP
service on all nodes at the same time. You must specify a password for authentication of the NDMP connection by the backup application. cluster1::> system services ndmp on -node *
Please enter password:
Confirm password:
2 entries were modified. Disable the -clear-text option for secure communication of the NDMP password by using the system services ndmp modify command. Using the wildcard “*” disables the -clear-text option on all nodes at the same time. cluster1::> system services ndmp modify -node * -clear-text false
2 entries were modified. Verify that NDMP service is enabled and the -clear-text option is disabled by using the system services ndmp show
command. cluster1::> system services ndmp show
Node Enabled Clear text User Id
--------------------- --------- ----------- ---------
cluster1-1 true false root
cluster1-2 true false root
2 entries were displayed.
You must identify a LIF that will be used for establishing a data connection and control connection between the node and the backup
application. After identifying the LIF, you must verify that firewall and failover policies are set for the LIF. Steps Identify the intercluster LIF hosted on the nodes by using the network interface show command with the -role parameter. cluster1::> network interface show -role intercluster
Logical Status Network Current Current Is
Vserver Interface Admin/Oper Address/Mask Node Port Home
----------- ---------- ---------- ------------------ ------------- ------- ----
cluster1 IC1 up/up 192.0.2.65/24 cluster1-1 e0a true
cluster1 IC2 up/up 192.0.2.68/24 cluster1-2 e0b trueEnsure that the firewall policy is enabled for NDMP on the intercluster LIFs: Verify that the firewall policy is enabled for NDMP by using the system services firewall policy show command. The following
command displays the firewall policy for the intercluster LIF: cluster1::> system services firewall policy show -policy intercluster
Vserver Policy Service Allowed
------- ------------ ---------- -------------------
cluster1 intercluster dns -
http -
https -
**ndmp 0.0.0.0/0, ::/0**
ndmps -
ntp -
rsh -
ssh -
telnet -
9 entries were displayed.If the firewall policy is not enabled, enable the firewall policy by using the system services firewall policy modify command with the -service parameter. The following command enables firewall policy for the intercluster LIF: cluster1::> system services firewall policy modify -vserver cluster1 -policy intercluster -service ndmp 0.0.0.0/0
Ensure that the failover policy is set appropriately for the intercluster LIFs: Verify that the failover policy for the
intercluster LIFs is set to local-only by using the network interface show -failover command. cluster1::> network interface show -failover
Logical Home Failover Failover
Vserver Interface Node:Port Policy Group
-------- --------------- ----------------- ------------ --------
cluster1 **IC1 cluster1-1:e0a local-only Default**
Failover Targets:
.......
**IC2 cluster1-2:e0b local-only Default**
Failover Targets:
.......
cluster1-1 cluster1-1_mgmt1 cluster1-1:e0m local-only Default
Failover Targets:
.......If the failover policy is not set appropriately, modify the failover policy by using the network interface modify command with the -failover-policy parameter. cluster1::> network interface modify -vserver cluster1 -lif IC1 -failover-policy local-only
After the cluster is configured for NDMP access, you must gather information from the cluster configuration and then configure the rest of the backup process in the backup
application. Steps Gather the following information that you configured earlier in ONTAP: In ONTAP, display the aliases that ONTAP assigned to each device by using the storage tape alias show command. The aliases are
often useful in configuring the backup application. cluster1::> storage tape show -alias
Device ID: 2a.0
Device Type: tape drive
Description: Hewlett-Packard LTO-5
Node Alias Mapping
--------------------------- --------- ------------------------------
stsw-3220-4a-4b-02 st2 SN[HU19497WVR]
... In the backup application, configure the rest of the backup process by using the backup application’s documentation.
After you finish If a data mobility event occurs, such as a volume move or LIF migration, you must be prepared to reinitialize any interrupted backup operations. Replication between Fujitsu Element software and ONTAP overviewYou can ensure business continuity on an Element system by using SnapMirror to replicate Snapshot copies of an Element volume to an ONTAP destination. In the event of a
disaster at the Element site, you can serve data to clients from the ONTAP system, and then reactivate the Element system when service is restored. Beginning with ONTAP 9.7, you can replicate Snapshot copies of a LUN created on an ONTAP node back to an Element system. You might have created a LUN during an outage at the Element site, or you might be using a LUN to migrate data from ONTAP to Element software. You should work with Element to ONTAP backup if the following apply:
You want to use best practices, not explore every available option. You want to use the ONTAP command-line interface (CLI), not ONTAP System Manager or an automated scripting tool. You are using iSCSI to serve data to clients.
If you require additional configuration or conceptual information, see the following documentation: About replication between Element and ONTAPBeginning with ONTAP 9.7, you can use SnapMirror to replicate Snapshot copies of an
Element volume to an ONTAP destination. In the event of a disaster at the Element site, you can serve data to clients from the ONTAP system, then reactivate the Element source volume when service is restored. Beginning with ONTAP 9.7, you can replicate Snapshot copies of a LUN created on an ONTAP node back to an Element system. You might have created a LUN during an outage at the Element site, or you might be using a LUN to migrate data from ONTAP to Element software. Types of data protection relationshipSnapMirror offers two types of data protection relationship. For each type, SnapMirror creates a Snapshot copy of the Element
source volume before initializing or updating the relationship: In a disaster recovery (DR) data protection relationship, the destination volume contains only the Snapshot copy created by SnapMirror, from which you can continue to serve data in the event of a catastrophe at the primary site. In a long-term retention data protection relationship, the destination volume contains point-in-time Snapshot copies created by Element software, as well
as the Snapshot copy created by SnapMirror. You might want to retain monthly Snapshot copies created over a 20-year span, for example.
Default policiesThe first time you invoke SnapMirror, it
performs a baseline transfer from the source volume to the destination volume. The SnapMirror policy defines the contents of the baseline and any updates. You can use a default or custom policy when you create a data protection relationship. The policy type determines which Snapshot copies to include and how many copies to retain. The table below shows the default policies. Use the MirrorLatest policy to create a traditional DR relationship. Use the MirrorAndVault or
Unified7year policy to create a unified replication relationship, in which DR and long-term retention are configured on the same destination volume.
Policy | Policy Type | Update behavior |
|---|
MirrorLatest
| async-mirror
| Transfer the Snapshot copy created by SnapMirror.
| MirrorAndVault
| mirror-vault
| Transfer the Snapshot copy created by SnapMirror and any less recent Snapshot copies made since the last update, provided they have SnapMirror labels “daily” or “weekly”.
| Unified7year
| mirror-vault
| Transfer the Snapshot copy created by SnapMirror and any less recent Snapshot copies made since the last update, provided they have SnapMirror labels “daily”, “weekly”, or “monthly”.
|
|
| For complete background information on SnapMirror policies, including guidance on which policy to use, see Data Protection.
|
Understanding SnapMirror labelsEvery policy with the “mirror-vault” policy type must have a rule that specifies which Snapshot copies to
replicate. The rule “daily”, for example, indicates that only Snapshot copies assigned the SnapMirror label “daily” should be replicated. You assign the SnapMirror label when you configure Element Snapshot copies. Replication from an Element source cluster to an ONTAP destination clusterYou can use SnapMirror to replicate Snapshot copies of an
Element volume to an ONTAP destination system. In the event of a disaster at the Element site, you can serve data to clients from the ONTAP system, then reactivate the Element source volume when service is restored. An Element volume is roughly equivalent to an ONTAP LUN. SnapMirror creates a LUN with the name of the Element volume when a data protection relationship between Element software and ONTAP is initialized. SnapMirror replicates data to an existing LUN if the LUN meets the
requirements for Element to ONTAP replication. Replication rules are as follows: Replication from an ONTAP source cluster to an Element destination clusterBeginning with ONTAP 9.7, you can replicate Snapshot copies of
a LUN created on an ONTAP system back to an Element volume: If a SnapMirror relationship already exists between an Element source and an ONTAP destination, a LUN created while you are serving data from the destination is automatically replicated when the source is reactivated. Otherwise, you must create and initialize a SnapMirror relationship between the ONTAP source cluster and the Element destination cluster.
Replication rules are as
follows: The replication relationship must have a policy of type “async-mirror”. Policies of type “mirror-vault” are not supported. Only iSCSI LUNs are supported. You cannot replicate more than one LUN from an ONTAP volume to an Element volume. You cannot replicate a LUN from an ONTAP volume to multiple Element volumes.
PrerequisitesYou must have completed the following tasks before configuring a data protection relationship between Element and ONTAP: The Element cluster must be running Fujitsu Element software version 10.1 or later. -
The ONTAP cluster must be running ONTAP 9.7 or later. SnapMirror must have been licensed on the ONTAP cluster. You must have configured volumes on the Element and ONTAP clusters that are large enough to handle anticipated data transfers. If you are using the “mirror-vault” policy type, a SnapMirror label must have been configured for the Element Snapshot copies to be replicated. You must have ensured that port 5010 is available.
If you foresee that you might need to move a destination volume, you must have ensured that full-mesh connectivity exists between the source and destination. Every node on the Element source cluster must be able to communicate with every node on the ONTAP destination cluster.
Support detailsThe following table shows support details for Element to ONTAP backup.
Resource or feature | Support details |
|---|
SnapMirror
| The SnapMirror restore feature is not supported. The MirrorAllSnapshots and XDPDefault policies are not supported. The “vault” policy type is not supported. The system-defined rule “all_source_snapshots” is not supported. The “mirror-vault” policy type is supported only for replication from Element software to ONTAP. Use “async-mirror” for replication from ONTAP to Element software. The -schedule and -prefix
options for snapmirror policy add-rule are not supported. The -preserve and -quick-resync options for snapmirror resync are not supported. Storage efficiency is not preserved. Fan-out and cascade data protection deployments are not supported.
| ONTAP
|
| Element
| Volume size limit is 8 TiB. Volume block size must be 512 bytes. A 4K byte block size is not supported. Volume size must be a multiple of 1 MiB. Volume attributes are not preserved. Maximum number of Snapshot copies to be replicated is 30.
| Network
| A single TCP connection is allowed per transfer. The Element node must be specified as an IP address. DNS hostname lookup is not supported. IPspaces are not supported.
| SnapLock
| SnapLock volumes are not supported.
| FlexGroup
| FlexGroup volumes are not supported.
| SVM DR
| ONTAP volumes in an SVM DR configuration are not supported.
| MetroCluster
| ONTAP volumes in a MetroCluster configuration are not supported.
|
Workflow for replication between Element and ONTAPWhether you
are replicating data from Element to ONTAP or from ONTAP to Element, you need to configure a job schedule, specify a policy, and create and initialize the relationship. You can use a default or custom policy. The workflow assumes that you have completed the prerequisite tasks listed in Prerequisites. For complete background information on SnapMirror policies, including
guidance on which policy to use, see Data protection. Enable SnapMirror on the Element clusterYou must enable SnapMirror on the Element cluster before you can create a replication relationship. You can perform this task in the Element software web UI
only. Before you begin About this task The Element system comes with SnapMirror disabled by default. SnapMirror is not automatically enabled as part of a new installation or upgrade.
|
| Once enabled, SnapMirror cannot be disabled. You can only disable the SnapMirror feature and restore the default settings by returning the cluster to the factory image.
|
Steps Click Clusters > Settings. Find the cluster-specific settings for SnapMirror. Click Enable SnapMirror.
Enable SnapMirror on the Element source volumeYou must enable SnapMirror on the Element source volume before you can create a replication relationship. You can perform this task in the
Element software web UI only. Before you begin You must have enabled SnapMirror on the Element cluster. The volume block size must be 512 bytes. The volume must not be participating in Element remote replication. The volume access type must not be “Replication Target”.
About this task The procedure below assumes the volume already exists. You can also enable SnapMirror when you create or clone
a volume. Steps Click Management > Volumes. Click the button for the volume. In the drop-down menu, select Edit. In the Edit Volume dialog, select Enable SnapMirror. Click Save Changes.
Create a SnapMirror endpointYou must create a SnapMirror endpoint before you can create a replication relationship. You can perform this task in the
Element software web UI only. Before you begin You must have enabled SnapMirror on the Element cluster. Steps Click Data Protection > SnapMirror Endpoints. Click Create Endpoint. In the Create a New Endpoint dialog, enter the ONTAP cluster management IP address. Enter the user ID and password of the ONTAP cluster administrator.
Click Create Endpoint.
Create a replication job
scheduleWhether you are replicating data from Element to ONTAP or from ONTAP to Element, you need to configure a job schedule, specify a policy, and create and initialize the relationship. You can use a default or custom policy. You can use the job schedule cron create command to create a replication job schedule. The job schedule determines when SnapMirror automatically updates the data protection relationship to which the schedule is assigned. About this task You assign
a job schedule when you create a data protection relationship. If you do not assign a job schedule, you must update the relationship manually. Step Create a job schedule: job schedule cron create -name job_name -month month -dayofweek day_of_week -day day_of_month -hour hour -minute minute
For -month, -dayofweek, and -hour, you can specify all to run the job every month, day of the week, and hour, respectively. Beginning with ONTAP 9.10.1, you can include the Vserver for your job schedule: job schedule cron create -name job_name -vserver Vserver_name -month month -dayofweek day_of_week -day day_of_month -hour hour -minute minute
The following example creates a job
schedule named my_weekly that runs on Saturdays at 3:00 a.m.: cluster_dst::> job schedule cron create -name my_weekly -dayofweek "Saturday" -hour 3 -minute 0
Create a custom replication policyYou can use a default or custom policy when you create a replication relationship. For a custom unified replication policy, you
must define one or more rules that determine which Snapshot copies are transferred during initialization and update. You can create a custom replication policy if the default policy for a relationship is not suitable. You might want to compress data in a network transfer, for example, or modify the number of attempts SnapMirror makes to transfer Snapshot copies. About this task The policy type of the replication policy determines the type of relationship
it supports. The table below shows the available policy types.
Policy type | Relationship type |
|---|
async-mirror
| SnapMirror DR
| mirror-vault
| Unified replication
|
Step Create a custom replication policy: snapmirror policy create -vserver SVM -policy policy -type async-mirror|mirror-vault -comment comment -tries transfer_tries -transfer-priority low|normal -is-network-compression-enabled true|false
For complete command syntax, see the man page. Beginning with ONTAP 9.7, you can specify the schedule for creating a common Snapshot copy schedule for SnapMirror Synchronous relationships by using the -common-snapshot-schedule parameter. By default, the common Snapshot copy schedule for SnapMirror Synchronous relationships is one hour. You can specify a value from 30 minutes to two hours for the
Snapshot copy schedule for SnapMirror Synchronous relationships. The following example creates a custom replication policy for SnapMirror DR that enables network compression for data transfers: cluster_dst::> snapmirror policy create -vserver svm1 -policy DR_compressed -type async-mirror -comment “DR with network compression enabled” -is-network-compression-enabled true The following example creates a custom replication policy for unified replication: cluster_dst::> snapmirror policy create -vserver svm1 -policy my_unified -type mirror-vault
After you finish For “mirror-vault” policy types, you must define rules that determine which Snapshot copies are transferred during
initialization and update. Use the snapmirror policy show command to verify that the SnapMirror policy was created. For complete command syntax, see the man page. Define a rule for a
policyFor custom policies with the “mirror-vault” policy type, you must define at least one rule that determines which Snapshot copies are transferred during initialization and update. You can also define rules for default policies with the “mirror-vault” policy type. About this task Every policy with the “mirror-vault” policy type must have a rule that specifies which Snapshot copies to replicate. The rule “bi-monthly”, for example, indicates that only Snapshot
copies assigned the SnapMirror label “bi-monthly” should be replicated. You assign the SnapMirror label when you configure Element Snapshot copies. Each policy type is associated with one or more system-defined rules. These rules are automatically assigned to a policy when you specify its policy type. The table below shows the system-defined rules.
System-defined rule | Used in policy types | Result |
|---|
sm_created
| async-mirror, mirror-vault
| A Snapshot copy created by SnapMirror is transferred on initialization and update.
| daily
| mirror-vault
| New Snapshot copies on the source with the SnapMirror label “daily” are transferred on initialization and update.
| weekly
| mirror-vault
| New Snapshot copies on the source with the SnapMirror label “weekly” are transferred on initialization and update.
| monthly
| mirror-vault
| New Snapshot copies on the source with the SnapMirror label “monthly” are transferred on initialization and update.
|
You can specify additional rules as needed, for default or custom policies. For example: For the default MirrorAndVault policy, you might create a rule called “bi-monthly” to match Snapshot copies on the source with the “bi-monthly” SnapMirror label. For a custom policy with the “mirror-vault” policy type, you might create a rule called “bi-weekly” to match Snapshot copies on the source with the “bi-weekly” SnapMirror label.
Step Define a rule for a policy: snapmirror policy add-rule -vserver SVM -policy policy_for_rule -snapmirror-label snapmirror-label -keep retention_count
For complete command syntax, see the man page. The following example adds a rule with the SnapMirror label bi-monthly to the default MirrorAndVault policy: cluster_dst::> snapmirror policy add-rule -vserver svm1 -policy MirrorAndVault -snapmirror-label bi-monthly -keep 6 The following example adds a rule with the SnapMirror label bi-weekly to the custom my_snapvault policy: cluster_dst::> snapmirror policy add-rule -vserver svm1 -policy my_snapvault -snapmirror-label bi-weekly -keep 26 The following example adds a rule with the SnapMirror label app_consistent to the custom Sync policy: cluster_dst::> snapmirror policy add-rule -vserver svm1 -policy Sync -snapmirror-label app_consistent -keep 1
You can then replicate Snapshot copies from the source cluster that match this SnapMirror label: cluster_src::> snapshot create -vserver vs1 -volume vol1 -snapshot snapshot1 -snapmirror-label app_consistent
Create a relationship from an Element source to an ONTAP destinationThe relationship between the source volume in primary storage and the destination volume in secondary
storage is called a data protection relationship. You can use the snapmirror create command to create a data protection relationship from an Element source to an ONTAP destination, or from an ONTAP source to an Element destination. You can use SnapMirror to replicate Snapshot copies of an Element volume to an ONTAP destination system. In the event of a disaster at the Element site, you can serve data to clients from the ONTAP system, then reactivate the Element source volume when service
is restored. Before you begin The Element node containing the volume to be replicated must have been made accessible to ONTAP. The Element volume must have been enabled for SnapMirror replication. If you are using the “mirror-vault” policy type, a SnapMirror label must have been configured for the Element Snapshot copies to be replicated.
About this task You must specify the Element source path in the form
hostip:/lun/name, where “lun” is the actual string “lun” and name is the name of the Element volume. An Element volume is roughly equivalent to an ONTAP LUN. SnapMirror creates a LUN with the name of the Element volume when a data protection relationship between Element software and ONTAP is initialized. SnapMirror replicates data to an existing LUN if the LUN meets the requirements for replicating from Element software to ONTAP. Replication
rules are as follows: In ONTAP 9.7, a destination volume can contain up to 251 Snapshot copies. In ONTAP 9.7 and later, a destination volume can contain up to 1019 Snapshot copies. Step From the destination cluster, create a replication relationship from an Element source to an
ONTAP destination: snapmirror create -source-path hostip:/lun/name -destination-path SVM:volume|cluster://SVM/volume -type XDP -schedule schedule -policy policy
For complete command syntax, see the man page. The following example creates a SnapMirror DR relationship using the default MirrorLatest policy: cluster_dst::> snapmirror create -source-path 10.0.0.11:/lun/0005 -destination-path svm_backup:volA_dst -type XDP -schedule my_daily -policy MirrorLatest The following example creates a unified replication relationship using the default MirrorAndVault policy: cluster_dst:> snapmirror create -source-path 10.0.0.11:/lun/0005 -destination-path svm_backup:volA_dst -type XDP -schedule my_daily -policy MirrorAndVault The following example creates a unified replication relationship using the Unified7year policy: cluster_dst::> snapmirror create -source-path 10.0.0.11:/lun/0005 -destination-path svm_backup:volA_dst -type XDP -schedule my_daily -policy Unified7year The following example creates a unified
replication relationship using the custom my_unified policy: cluster_dst::> snapmirror create -source-path 10.0.0.11:/lun/0005 -destination-path svm_backup:volA_dst -type XDP -schedule my_daily -policy my_unified
After you finish Use the snapmirror show command to verify that the SnapMirror relationship was created. For complete command syntax, see the man page. Create a relationship from an ONTAP source to an Element destinationBeginning with ONTAP 9.7, you can use SnapMirror to replicate Snapshot
copies of a LUN created on an ONTAP source back to an Element destination. You might be using the LUN to migrate data from ONTAP to Element software. Before you begin About this task You must specify the Element destination path in the form hostip:/lun/name, where “lun” is the actual string
“lun” and name is the name of the Element volume. Replication rules are as follows: The replication relationship must have a policy of type “async-mirror”. You can use a default or custom policy. Only iSCSI LUNs are supported. You cannot replicate more than one LUN from an ONTAP volume to an Element volume. You cannot replicate a LUN from an ONTAP volume to multiple Element volumes.
Step
Create a replication relationship from an ONTAP source to an Element destination: snapmirror create -source-path SVM:volume|cluster://SVM/volume -destination-path hostip:/lun/name -type XDP -schedule schedule -policy policy
For complete command syntax, see the man page. The following example creates a SnapMirror DR relationship using the default MirrorLatest policy: cluster_dst::> snapmirror create -source-path svm_1:volA_dst -destination-path 10.0.0.11:/lun/0005 -type XDP -schedule my_daily -policy MirrorLatest The following example creates a SnapMirror DR relationship using the custom my_mirror policy: cluster_dst::> snapmirror create -source-path svm_1:volA_dst -destination-path 10.0.0.11:/lun/0005 -type XDP -schedule my_daily -policy my_mirror
After you finish Use the snapmirror show command to verify that the
SnapMirror relationship was created. For complete command syntax, see the man page. Initialize a replication relationshipFor
all relationship types, initialization performs a baseline transfer: it makes a Snapshot copy of the source volume, then transfers that copy and all the data blocks it references to the destination volume. Before you begin The Element node containing the volume to be replicated must have been made accessible to ONTAP. The Element volume must have been enabled for SnapMirror replication. If you are using the “mirror-vault” policy
type, a SnapMirror label must have been configured for the Element Snapshot copies to be replicated.
About this task You must specify the Element source path in the form hostip:/lun/name, where “lun” is the actual string “lun” and name is the name of the Element volume. Initialization can be time-consuming. You might want to run the baseline transfer in off-peak hours.
|
| If initialization of a relationship from an ONTAP source to an Element destination fails for any reason, it will continue to fail even after you have corrected the problem (an invalid LUN name, for example). The workaround is as follows: Delete the relationship. Delete the Element destination volume. Create a new Element destination volume. Create and initialize a new relationship from the ONTAP source to the Element
destination volume.
|
Step Initialize a replication relationship: snapmirror initialize -source-path hostip:/lun/name -destination-path SVM:volume|cluster://SVM/volume
For complete command syntax, see the man page. The following example initializes the relationship between the source volume 0005 at IP address 10.0.0.11 and the destination volume volA_dst on svm_backup: cluster_dst::> snapmirror initialize -source-path 10.0.0.11:/lun/0005 -destination-path svm_backup:volA_dst
Make the destination volume writeableWhen disaster disables the primary site for a SnapMirror DR relationship, you can serve data from the destination volume with minimal disruption. You can reactivate the
source volume when service is restored at the primary site. You need to make the destination volume writeable before you can serve data from the volume to clients. You can use the snapmirror quiesce command to stop scheduled transfers to the destination, the snapmirror abort command to stop ongoing transfers, and the snapmirror break command to make the destination writeable. About this task You must specify the Element source path in the form hostip:/lun/name, where “lun” is the actual string “lun” and
name is the name of the Element volume. Steps Stop scheduled transfers to the destination: snapmirror quiesce -source-path hostip:/lun/name -destination-path SVM:volume|cluster://SVM/volume
For complete command syntax, see the man page. The following example stops scheduled transfers between the source volume 0005 at IP address 10.0.0.11 and the destination volume volA_dst on svm_backup: cluster_dst::> snapmirror quiesce -source-path 10.0.0.11:/lun/0005 -destination-path svm_backup:volA_dst Stop ongoing transfers to the destination: snapmirror abort -source-path hostip:/lun/name -destination-path SVM:volume|cluster://SVM/volume
For complete command syntax, see the
man page. The following example stops ongoing transfers between the source volume 0005 at IP address 10.0.0.11 and the destination volume volA_dst on svm_backup: cluster_dst::> snapmirror abort -source-path 10.0.0.11:/lun/0005 -destination-path svm_backup:volA_dst Break the SnapMirror DR relationship: snapmirror break -source-path hostip:/lun/name -destination-path SVM:volume|cluster://SVM/volume
For complete command syntax, see the man page. The following example breaks the relationship between the source volume 0005 at IP address 10.0.0.11 and the destination volume volA_dst on svm_backup and the destination volume
volA_dst on svm_backup: cluster_dst::> snapmirror break -source-path 10.0.0.11:/lun/0005 -destination-path svm_backup:volA_dst
After making the destination volume writeable, you must configure the volume for data access. SAN
hosts can access the data from the destination volume until the source volume is reactivated. Map the Element LUN to the appropriate initiator group. Create iSCSI sessions from the SAN host initiators to the SAN LIFs. On the SAN client, perform a storage re-scan to detect the connected LUN.
Reactivate the original source volumeYou can reestablish the original data protection relationship between the source and destination volumes when you no longer need to serve data from the
destination.
About this task The procedure below assumes that the baseline in the original source volume is intact. If the baseline is not intact, you must create and initialize the relationship between the volume you are serving data from and the original source volume before performing the procedure. You must specify the Element source path in the form hostip:/lun/name, where “lun” is the actual string “lun” and name is the name of the Element volume. Beginning with ONTAP 9.7,
Snapshot copies of a LUN created while you are serving data from the ONTAP destination are automatically replicated when the Element source is reactivated. Replication rules are as follows: Only iSCSI LUNs are supported. You cannot replicate more than one LUN from an ONTAP volume to an Element volume. You cannot replicate a LUN from an ONTAP volume to multiple Element volumes.
Steps Delete the
original data protection relationship: snapmirror delete -source-path SVM:volume|cluster://SVM/volume -destination-path hostip:/lun/name -policy policy
For complete command syntax, see the man page. The following example deletes the relationship between the original source volume, 0005 at IP address 10.0.0.11, and the volume you are serving data from, volA_dst on svm_backup: cluster_dst::> snapmirror delete -source-path 10.0.0.11:/lun/0005 -policy MirrorLatest -destination-path svm_backup:volA_dst Reverse the original data protection relationship: snapmirror resync -source-path SVM:volume|cluster://SVM/volume -destination-path hostip:/lun/name -policy policy
For complete command syntax, see the man page. Although resync does not require a baseline
transfer, it can be time-consuming. You might want to run the resync in off-peak hours. The following example reverses the relationship between the original source volume, 0005 at IP address 10.0.0.11, and the volume you are serving data from, volA_dst on svm_backup: cluster_dst::> snapmirror resync -source-path svm_backup:volA_dst -destination-path 10.0.0.11:/lun/0005 -policy MirrorLatest Update the reversed relationship: snapmirror update -source-path SVM:volume|cluster://SVM/volume -destination-path hostip:/lun/name
For complete command syntax, see the man page.
|
| The command fails if a common Snapshot copy does not exist on the source and destination. Use snapmirror initialize to re-initialize the relationship.
|
The following example updates the relationship between the volume you are serving data from, volA_dst on svm_backup, and the original source volume, 0005 at IP address 10.0.0.11: cluster_dst::> snapmirror update -source-path svm_backup:volA_dst -destination-path 10.0.0.11:/lun/0005 Stop scheduled transfers for the reversed relationship: snapmirror quiesce -source-path SVM:volume|cluster://SVM/volume -destination-path hostip:/lun/name
For complete command syntax, see the man page. The following example stops scheduled transfers between the volume you are serving data from, volA_dst on svm_backup, and the
original source volume, 0005 at IP address 10.0.0.11: cluster_dst::> snapmirror quiesce -source-path svm_backup:volA_dst -destination-path 10.0.0.11:/lun/0005 Stop ongoing transfers for the reversed relationship: snapmirror abort -source-path SVM:volume|cluster://SVM/volume -destination-path hostip:/lun/name
For complete command syntax, see the man page. The following example stops ongoing transfers between the volume you are serving data from, volA_dst on svm_backup, and the original source volume, 0005 at IP address 10.0.0.11: cluster_dst::> snapmirror abort -source-path svm_backup:volA_dst -destination-path 10.0.0.11:/lun/0005 Break the reversed relationship: snapmirror break -source-path SVM:volume|cluster://SVM/volume -destination-path hostip:/lun/name
For complete
command syntax, see the man page. The following example breaks the relationship between the volume you are serving data from, volA_dst on svm_backup, and the original source volume, 0005 at IP address 10.0.0.11: cluster_dst::> snapmirror break -source-path svm_backup:volA_dst -destination-path 10.0.0.11:/lun/0005 Delete the reversed data protection relationship: snapmirror delete -source-path SVM:volume|cluster://SVM/volume -destination-path hostip:/lun/name -policy policy
For complete command syntax, see the man page. The following example deletes the reversed relationship between the original source volume, 0005 at IP address
10.0.0.11, and the volume you are serving data from, volA_dst on svm_backup: cluster_src::> snapmirror delete -source-path svm_backup:volA_dst -destination-path 10.0.0.11:/lun/0005 -policy MirrorLatest Reestablish the original data protection relationship: snapmirror resync -source-path hostip:/lun/name -destination-path SVM:volume|cluster://SVM/volume
For complete command syntax, see the man page. The following example reestablishes the relationship between the original source volume, 0005 at IP address 10.0.0.11, and the original destination volume, volA_dst on svm_backup: cluster_dst::> snapmirror resync -source-path 10.0.0.11:/lun/0005 -destination-path svm_backup:volA_dst
After you finish Use the
snapmirror show command to verify that the SnapMirror relationship was created. For complete command syntax, see the man page. Update a replication relationship manuallyYou might need to update a replication relationship manually if an update fails because of a network error. About this task You must
specify the Element source path in the form hostip:/lun/name, where “lun” is the actual string “lun” and name is the name of the Element volume. Steps Update a replication relationship manually: snapmirror update -source-path hostip:/lun/name -destination-path SVM:volume|cluster://SVM/volume
For complete command syntax, see the man page.
|
| The command fails if a common Snapshot copy does not exist on the source and destination. Use snapmirror initialize to re-initialize the relationship.
|
The following example updates the relationship between the source volume 0005 at IP address 10.0.0.11 and the destination volume volA_dst on svm_backup: cluster_src::> snapmirror update -source-path 10.0.0.11:/lun/0005 -destination-path svm_backup:volA_dst
Resynchronize a replication relationshipYou need to resynchronize a replication relationship after you make a destination volume writeable, after an update fails because a common Snapshot copy
does not exist on the source and destination volumes, or if you want to change the replication policy for the relationship. About this task Although resync does not require a baseline transfer, it can be time-consuming. You might want to run the resync in off-peak hours. You must specify the Element source path in the form hostip:/lun/name, where “lun” is the actual string “lun” and name is the name of the Element volume. Step Resync the source
and destination volumes: snapmirror resync -source-path hostip:/lun/name -destination-path SVM:volume|cluster://SVM/volume -type XDP -schedule schedule -policy policy
For complete command syntax, see the man page. The following example resyncs the relationship between the source volume 0005 at IP address 10.0.0.11 and the destination volume volA_dst on svm_backup: cluster_dst::> snapmirror resync -source-path 10.0.0.11:/lun/0005 -policy MirrorLatest -destination-path svm_backup:volA_dst
Which ONTAP data protection feature provides a point in time volume level copy?
SnapMirror Synchronous technology is a per-node, licensed feature that provides synchronous data replication at the volume level.
Which netapp ONTAP data protection feature provides volume level data replication that is used for disaster recovery?
Storage virtual machine disaster recovery (SVM-DR)
SVM-DR is an ONTAP feature that allows you to replicate not just data volumes to a remote site, but also the SVM configuration details, such as CIFS shares, NFS exports, data LIFs, and even the NFS file handles to avoid remounts when failing over to the DR site.
Which netapp management products create data protection relationships?
OnCommand Unified Manager enables you to create protection relationships, to monitor and troubleshoot SnapMirror and SnapVault relationships on managed clusters, and to restore data when it is overwritten or lost.
What is snap mirror in netapp?
SnapMirror is a feature of Data ONTAP that enables you to replicate data. SnapMirror enables you to replicate data from specified source volumes or qtrees to specified destination volumes or qtrees, respectively.
|
