Skip to main content
A newer release of this product is available.

snapmirror policy create

Contributors
Suggest changes
PDFs

Create a new SnapMirror policy

Availability: This command is available to cluster and Vserver administrators at the admin privilege level.

Description

The snapmirror policy create command creates a SnapMirror policy. When applied to a SnapMirror relationship, the SnapMirror policy controls the behavior of the relationship and specifies the configuration attributes for that relationship. The policies DPDefault , MirrorAllSnapshots , MirrorAndVault , MirrorLatest , Unified7year and XDPDefault are created by the system for asynchronous replication. The policies Sync and StrictSync are created by the system for synchronous replication.

Note All SnapMirror policies have a field create-snapshot . This field specifies whether SnapMirror creates a new Snapshot copy on the primary volume at the beginning of a snapmirror update or snapmirror resync operation. Currently this field cannot be set or modified by the user. It is set to true for SnapMirror policies of type async-mirror and mirror-vault at the time of creation. SnapMirror policies of type vault have create-snapshot set to false at the time of creation.
Note Use the snapmirror policy add-rule command to add a rule to a policy.

Parameters

-vserver <vserver name> - Vserver Name

Specifies the Vserver for the SnapMirror policy.

-policy <sm_policy> - SnapMirror Policy Name

This parameter specifies the SnapMirror policy name. A policy name can be made up of the characters A to Z, a to z, 0 to 9, ".", "-", and "_". The name can be up to 256 characters in length.

[-type {vault|async-mirror|mirror-vault|strict-sync-mirror|sync-mirror}] - Snapmirror Policy Type

This parameter specifies the SnapMirror policy type. The supported values are async-mirror , vault , mirror-vault , sync-mirror and strict-sync-mirror . Data protection (DP) relationships support only async-mirror policy type, while extended data protection (XDP) relationships support all policy types.

If the type is set to async-mirror then the policy is for Disaster Recovery. When the policy type is associated with extended data protection (XDP) relationships, snapmirror update and snapmirror resync operations transfer selected Snapshot copies from the primary volume to the secondary volume. The selection of Snapshot copies is governed by the rules in the policy. However snapmirror initialize and snapmirror update operations on data protection (DP) relationships ignore the rules in the policy and transfer all Snapshot copies of the primary volume which are newer than the common Snapshot copy on the destination. For both data protection (DP) and extended data protection (XDP) relationships, the Snapshot copies are kept on the secondary volume as long as they exist on the primary volume. Once a protected Snapshot copy is deleted from the primary volume, it is deleted from the secondary volume as part of the next transfer. The policy type supports rules with certain pre-defined label names only. Refer to the man page for the snapmirror policy add-rule command for the details.

If the type is set to vault then the policy is used for Backup and Archive. The rules in this policy type determine which Snapshot copies are protected and how long they are retained on the secondary volume. This policy type is supported by extended data protection (XDP) relationships only.

If the type is set to mirror-vault then the policy is used for unified data protection which provides both Disaster Recovery and Backup using the same secondary volume. This policy type is supported by extended data protection (XDP) relationships only.

If the type is set to sync-mirror or strict-sync-mirror then the policy is used for synchronous Disaster Recovery. These are supported only by extended data protection (XDP) relationships between FlexVol volumes. Once the relationship is initialized with snapmirror initialize , the relationship will be InSync such that all writes to the primary will be replicated to the secondary before the write is acknowledged to the client. Upon a replication failure, relationship falls OutOfSync. Upon an OutOfSync event, the strict-sync-mirror variant restricts further client IO on the primary, whereas the sync-mirror variant does not. SnapMirror will automatically trigger resync to bring the OutOfSync relationships back InSync as soon as it can, unless the relationship is Quiesced or Broken-off . Once a relationship is initialized, you normally use the snapmirror quiesce command to stop synchronous replication and the snapmirror resume command to resume synchronous replication. These policy types do not support replication of user Snapshot copies.

[-comment <text>] - Comment

Specifies a text comment for the SnapMirror policy. If the comment contains spaces, it must be enclosed within quotes.

[-tries <unsigned32_or_unlimited>] - Tries Limit

Determines the maximum number of times to attempt each manual or scheduled transfer for a SnapMirror relationship. The value of this parameter must be a positive integer or unlimited . The default value is 8 .

[-transfer-priority {low|normal}] - Transfer Scheduling Priority

Specifies the priority at which a transfer runs. The supported values are normal or low . The normal transfers are scheduled before the low priority transfers. The default is normal .

[-ignore-atime {true|false}] - Ignore File Access Time

This parameter applies only to extended data protection (XDP) relationships. It specifies whether incremental transfers will ignore files which have only their access time changed. The supported values are true or false . The default is false .

[-restart {always|never|default}] - Restart Behavior

This parameter applies only to data protection relationships. It defines the behavior of SnapMirror if an interrupted transfer exists. The supported values are always , never , or default . If the value is set to always , an interrupted SnapMirror transfer always restarts provided it has a restart checkpoint and the conditions are the same as they were before the transfer was interrupted. In addition, a new SnapMirror Snapshot copy is created which will then be transferred. If the value is set to never , an interrupted SnapMirror transfer will never restart, even if a restart checkpoint exists. A new SnapMirror Snapshot copy will still be created and transferred. Data ONTAP version 8.2 will interpret a value of default as being the same as always . Vault transfers will always resume based on a restart checkpoint, provided the Snapshot copy still exists on the source volume.

[-is-network-compression-enabled {true|false}] - Is Network Compression Enabled

Specifies whether network compression is enabled for transfers. The supported values are true or false . The default is false .

[-common-snapshot-schedule <text>] - Common Snapshot Copy Creation Schedule for SnapMirror Synchronous (privilege: advanced)

Specifies the common Snapshot creating schedule. This parameter is only supported for SnapMirror Synchronous relationships.

[-are-data-ops-sequentially-split {true|false}] - Is Sequential Splitting of Data Operations Enabled?

This parameter specifies whether I/O, such as write, copy-offload and punch-holes, are split sequentially, rather than being run in parallel on the source and destination. Spliiting I/O sequentially will make the system more robust, and less prone to I/O errors. However, it will also make I/O performance slower. The default value for the parameter -are-data-ops-sequentially-split is false . The parameter -are-data-ops-sequentially-split should only be used if too frequent I/O timeout or OutOfSync has happened. The parameter -are-data-ops-sequentially-split requires an effective cluster version of Data ONTAP 9.6.0 or later on both the source and destination clusters.

[-discard-configs <network>,…​] - Configurations Not Replicated During Identity Preserve Vserver DR

Specifies the configuration to be dropped during replication. The supported values are:

  • network - Drops network interfaces, routes, and kerberos configuration.

This parameter is supported only for policies of type async-mirror and applicable only for identity-preserve Vserver SnapMirror relationships.

Examples

The following example creates a SnapMirror policy named TieredBackup on a Vserver named vs0.example.com .

vs0.example.com::> snapmirror policy create -vserver vs0.example.com
       -policy TieredBackup -type vault -tries 10 -restart never