Table of ContentsView in Frames

How a SnapVault-SnapMirror cascade works

A SnapVault-SnapMirror cascade consists of a chain of relationships in which a volume has a SnapVault backup on a secondary volume, and then that secondary volume data is replicated to a tertiary volume. In effect, this deployment provides two SnapVault backups.

A SnapVault-SnapMirror cascade deployment is only supported on FlexVol volumes. The first leg of the cascade consists of a SnapVault backup. A cascade chain in which the first leg is a SnapVault relationship behaves in the same manner as does a single leg SnapVault relationship. The updates to the SnapVault backup include the Snapshot copies that are selected in conformance with the SnapVault policy assigned to the relationship. In a typical SnapVault-SnapMirror cascade, all Snapshot copies up to the latest one are replicated from the SnapVault backup to the SnapMirror destination.

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 SnapVault-SnapMirror cascade chain:
SnapMirror deployment: Source to vault to mirror cascade chain