SnapVault and Cloud Backup Relationships
What this domain tests
This section focuses on long-term retention to another volume or to object storage, and on restoring from those copies.
Core rules
- SnapVault relationships use an XDP relationship with a vault or unified policy, keeping many versions for retention instead of one mirror copy.
- A unified policy (
MirrorAndVault) sends a mirror copy plus vaulted copies identified by label, so one relationship serves both fast failover and long retention. - Fan-out protects one source to several destinations; fan-in vaults many sources into one destination volume with per-source qtrees or volumes.
- Restoring from a vault copy is usually done by cloning or restoring the specific Snapshot copy, not by breaking the relationship.
- Cloud Backup uses SnapMirror technology to send volume backups to object storage such as Amazon S3, Azure Blob, or Google Cloud Storage; SnapMirror Cloud provides similar object-store replication. Both need a bucket or container and a license, and are configured per volume.
Worked example
A source volume needs 30 daily copies kept for a year on a second cluster and a fast local mirror. Create one relationship with a MirrorAndVault policy, set the daily label count to 365, and keep the mirror schedule at hourly. Retention is controlled by the policy's label counts, not by the volume's own Snapshot policy alone.
Traps
Assuming a pure Vault policy gives an instantly usable mirror - it does not provide the latest mirror copy semantics. Expecting object-store backups to be mounted directly as a volume without a restore. Forgetting that the destination needs enough space for all retained versions.