Table of ContentsView in Frames

How a SnapMirror-SnapVault cascade works

A SnapMirror-SnapVault cascade deployment, which is supported on FlexVol volumes, consists of a chain of relationships in which a volume is replicated to a destination volume, and then the destination volume becomes the primary for a SnapVault backup on a tertiary volume. This deployment adds a SnapVault backup, which fulfills more strict protection requirements.

In a typical SnapMirror-SnapVault cascade, only the exported Snapshot copies from the SnapMirror destination are transferred to the SnapVault secondary when the SnapVault update occurs. These exported Snapshot copies are created by Data ONTAP and have a "snapmirror" prefix and a "sm_created" SnapMirror label.

If the default SnapVault policy is used, the SnapVault destination will accumulate up to 251 "sm_created" Snapshot copies. After this limit is reached, when a newer "sm_created" Snapshot copy is transferred, the oldest one is rotated out. This retention and rotation behavior can be managed by adding a rule for the "sm_created" SnapMirror label to the SnapVault policy.

For example, if a rule is added with a -snapmirror-label of "sm_created" and with a -keep value of 40, then only 40 "sm_created" Snapshot copies are retained on the SnapVault destination. If the -preserve value for this rule is set to true, then no rotation will occur and "sm_created" Snapshot copy transfers will halt when the SnapVault destination reaches a count of 40 "sm_created" Snapshot copies. If the -preserve value for this rule is set to false, then "sm_created" Snapshot copy transfers will occur after 40 Snapshot copies with the oldest copy rotating out for the newest copy.

Note: A cascade chain can contain multiple SnapMirror relationships but only one SnapVault relationship. The SnapVault relationship can occur anywhere in the chain, depending on your data protection requirements.

As with other cascade configurations, a source or destination volume can become unavailable and you might consider temporarily breaking that relationship to bypass the issue and resynchronizing the relationship after fixing the issue. Before you perform a resynchronization operation in a cascade, you should be aware that a resynchronization operation deletes Snapshot copies and might cause a relationship in the cascade to lose its common Snapshot copy. If this happens, the relationship will require a new baseline.

The following illustration depicts a SnapMirror-SnapVault cascade chain:
SnapMirror deployment: Source to mirror-vault cascade chain