Skip to main content

Protect consistency groups

Contributors netapp-ahibbard netapp-lenida

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. Protection policies can be set at the time of creation or after creating your consistency group. You can protect consistency groups using:

  • Local Snapshot copies

  • SnapMirror Business Continuity (SM-BC)

  • MetroCluster (beginning 9.11.1)

  • Asynchronous SnapMirror (beginning 9.13.1)

  • Asynchronous SVM disaster recovery (beginning 9.14.1)

If you are utilizing nested consistency groups, you can set different protection policies for the parent and child consistency groups.

Beginning with ONTAP 9.11.1, consistency groups offer two-phase consistency group Snapshot creation. The two-phase Snapshot operation executes a pre-check, ensuring the Snapshot copy is captured successfully.

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 Snapshot copy to base the restoration on. For more information about this process, see Restore a volume from an earlier Snapshot copy.

Configure a local Snapshot policy

Setting a local snapshot protection policy allows you to create a policy spanning all volumes in a consistency group.

About this task

The minimum supported Snapshot copy schedule for consistency groups is 30 minutes.This is based on testing for FlexGroups, which share the same Snapshot infrastructure as consistency groups.

System Manager
Steps
  1. Select Storage > Consistency groups.

  2. Select the consistency group you have created from the Consistency group menu.

  3. At the top right of the overview page for the consistency group, select Edit.

  4. Check the box next to Schedule Snapshot copies (local).

  5. Select a Snapshot policy. To configure a new, custom policy, refer to Create a custom data protection policy.

  6. Select Save.

  7. Return to the consistency group overview menu. In the left column under Snapshot Copies (Local), the status will say protected next to green shield icon.

CLI

Beginning with ONTAP 9.14.1, you can modify the protection policy of a consistency group using the CLI.

Step
  1. Issue the following command to set or modify the protection policy:

    If you are modifying the protection policy of a child consistency, you must identify the parent consistency group using the -parent-consistency-group parent_consistency_group_name parameter.

    consistency-group modify -vserver svm_name -consistency-group consistency_group_name -snapshot-policy policy_name

Create an on-demand Snapshot copy

If you need to create a Snapshot copy of your consistency group outside of a normally scheduled policy, you can create one on-demand.

System Manager
Steps
  1. Navigate to Storage > Consistency groups.

  2. Select the consistency group for which you want to create an on-demand Snapshot copy.

  3. Switch to the Snapshot copies tab then select +Add.

  4. Provide a Name and a SnapMirror Label. In the dropdown menu for Consistency, select Application consistent or Crash consistent.

  5. Select Save.

CLI

Beginning with ONTAP 9.14.1, you can create an on-demand Snapshot copy of a consistency group using the CLI.

Step
  1. Create the Snapshot copy:

    By default, the Snapshot type is crash-consistent. You can modify the Snapshot type with the optional -type parameter.

    consistency-group snapshot create -vserver svm_name -consistency-group consistency_group_name -snapshot snapshot_name

Create two-phase consistency group Snapshots

Beginning with ONTAP 9.11.1, consistency groups support two-phase commits for consistency group (CG) Snapshot creation, which execute a precheck before committing the Snapshot copy. 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 breaks the Snapshot creation process into two phases:

  1. In the first phase, the API executes prechecks and triggers Snapshot creation. The first phase includes includes a timeout parameter, designating the amount of time for the Snapshot copy to commit successfully.

  2. If the request in phase one completes successfully, you can invoke the second phase within the designated interval from the first phase, committing the Snapshot copy to the appropriate endpoint.

Before you begin
  • To use two-phase CG Snapshot creation, all nodes in the cluster must be running ONTAP 9.11.1 or later.

  • Only one active invocation of a consistency group Snapshot 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 operation while another one is in progress results in a failure.

  • When you invoke the Snapshot creation, you can set an optional timeout value of between 5 and 120 seconds. If no timeout value is provided, the operation times out at the default of 7 seconds. In the API, set the timeout value with the action_timeout parameter. In the CLI, use the -timeout flag.

Steps

You can complete a two-phase Snapshot with the REST API or, beginning with ONTAP 9.14.1, the ONTAP CLI. This operation is not supported in System Manager.

Note If you invoke the Snapshot creation with the API, you must commit the Snapshot copy with the API. If you invoke the Snapshot creation with the CLI, you must commit the Snapshot copy with the CLI. Mixing methods is not supported.
CLI

Beginning with ONTAP 9.14.1, you can create a two-phase Snapshot copy using the CLI.

Steps
  1. Initiate the Snapshot:

    consistency-group snapshot start -vserver svm_name -consistency-group consistency_group_name -snapshot snapshot_name [-timeout time_in_seconds -write-fence {true|false}]

  2. Verify the Snapshot was taken:

    consistency-group snapshot show

  3. Commit the Snapshot:

    consistency-group snapshot commit svm_name -consistency-group consistency_group_name -snapshot snapshot_name

API
  1. Invoke the Snapshot creation. Send 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": "<snapshot_name>",
      "consistency_type": "crash",
      "comment": "<comment>",
      "snapmirror_label": "<SnapMirror_label>"
    }'
  2. If the POST request succeeds, the output includes a Snapshot uuid. Using that uuid, submit a PATCH request to commit the Snapshot copy.

    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"
    
    For more information about the ONTAP REST API, see link:https://docs.netapp.com/us-en/ontap-automation/reference/api_reference.html[API reference^] or the link:https://devnet.netapp.com/restapi.php[ONTAP REST API page^] at the NetApp Developer Network for a complete list of API endpoints.

Set remote protection for a consistency group

Consistency groups offer remote protection through SM-BC and, Beginning with ONTAP 9.13.1, asynchronous SnapMirror.

Configure protection with SM-BC

You can utilize SM-BC to ensure Snapshot copies of consistency groups created on your consistency group are copied to the destination. To learn more about SM-BC or how to configure SM-BC using the CLI, see Configure protection for business continuity.

Before you begin
  • SM-BC relationships cannot be established on volumes mounted for NAS access.

  • 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 Protect with SM-BC.

  • Cascade deployments are not supported with SM-BC.

  • Beginning with ONTAP 9.13.1, you can non-disruptively add volumes to a consistency group with an active SM-BC relationship. Any other changes to a consistency group require you to break the SM-BC relationship, modify the consistency group, then reestablish and resynchronize the relationship.

Tip To configure SM-BC with the CLI, see Protect with SM-BC.
Steps for System Manager
  1. Ensure you have met the prerequisites for using SM-BC.

  2. Select Storage > Consistency groups.

  3. Select the consistency group you have created from the Consistency group menu.

  4. At the top right of the overview page, select More then Protect.

  5. System Manager auto-fills source-side information. Select the appropriate cluster and storage VM for the destination. Select a protection policy. Ensure that Initialize relationship is checked.

  6. Select Save.

  7. The consistency group needs to initialize and synchronize. Confirm synchronization has completed successfully by returning to the Consistency group menu. The SnapMirror (Remote) status displays Protected next to green shield icon.

Configure asynchronous SnapMirror protection

Beginning with ONTAP 9.13.1, you can configure asynchronous SnapMirror protection for a single consistency group. Beginning with ONTAP 9.14.1, you can use asynchronous SnapMirror to replicate volume-granular Snapshot copies to the destination cluster using the consistency group relationship.

About this task

To replicate volume-granular Snapshot copies, you must be running ONTAP 9.14.1 or later. For MirrorAndVault and Vault policies, the volume-granular Snapshot policy's SnapMirror label must match the consistency group's SnapMirror policy rule. Volume-granular Snapshots abide by the keep value of the consistency group's SnapMirror policy, which is calculated independently of the consistency group Snapshots. For example, if you have a policy to keep two Snapshot copies on the destination, you can have two volume-granular Snapshot copies and two consistency group Snapshot copies.

When resynchronizing the SnapMirror relationship with volume-granular Snapshot copies, you can preserve volume-granular Snapshot copies with the -preserve flag. Volume-granular Snapshot copies newer than consistency group Snapshot copies are preserved. If there is not a consistency group Snapshot copy, no volume-granular Snapshot copies can be transferred in the resync operation.

Before you begin
  • Asynchronous SnapMirror protection is only available for single consistency groups. It is not supported for hierarchical consistency groups. To convert a hierarchical consistency group into a single consistency group, see modify consistency group architecture.

  • The policy labels in the source and destination cluster must match.

  • You can non-disruptively add volumes to a consistency group with an active asynchronous SnapMirror relationship. Any other changes to a consistency group require you to break the SnapMirror relationship, modify the consistency group, then reestablish and resynchronize the relationship.

  • If you have configured an asynchronous SnapMirror protection relationship for multiple individual volumes, you can convert those volumes into a consistency group while retaining the existing Snapshot copies. To convert volumes successfully:

Steps
  1. From the destination cluster, select Storage > Consistency groups.

  2. Select the consistency group you have created from the Consistency group menu.

  3. At the top right of the overview page, select More then Protect.

  4. System Manager auto-fills source-side information. Select the appropriate cluster and storage VM for the destination. Select a protection policy. Ensure that Initialize relationship is checked.

    When selecting an asynchronous policy, you have the option to Override Transfer Schedule.

    Note The minimum supported schedule (recovery point objective, or RPO) for consistency groups with asynchronous SnapMirror is 30 minutes.
  5. Select Save.

  6. The consistency group needs to initialize and synchronize. Confirm synchronization has completed successfully by returning to the Consistency group menu. The SnapMirror (Remote) status displays Protected next to green shield icon.

Configure SVM disaster recovery

Beginning in ONTAP 9.14.1, SVM disaster recovery supports consistency groups, enabling you to mirror consistency group information from the source to the destination cluster.

If you are enabling SVM disaster recovery on an SVM that already contains a consistency group, following the SVM configuration workflows for System Manager or the ONTAP CLI.

If you are adding a consistency group to an SVM that is in an active and healthy SVM disaster recovery relationship, you must update the SVM disaster recovery relationship from the destination cluster. For more information, see Update a replication relationship manually. You must update the relationship any time you expand the consistency group.

Limitations
  • SVM disaster recovery does not support hierarchical consistency groups.

  • SVM disaster recovery does not support consistency groups protected with Asynchronous SnapMirror. You must break the SnapMirror relationship before configuring SVM disaster recovery.

  • Both clusters must be running ONTAP 9.14.1 or later.

  • Fan-out relationships are not supported for SVM disaster recovery configurations that contain consistency groups.

  • For other limits, see consistency group limits.

Visualize relationships

System Manager visualizes LUN maps under the Protection > Relationships menu. When you select a source relationship, 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 download operation runs in the background.