Long-term off-cluster retention design · mirror/vault policy behavior must be inspected
Example: preserve daily snapshots for 30 days and monthly snapshots for 12 months on a secondary cluster. Match labels and retention to actual compliance and recovery requirements.
About the command and output examples
Names, addresses and results are illustrative. Commands have not been executed against a live storage system or SAN switch for this publication. Confirm syntax and compatibility for your release, then rehearse in an approved lab. Existing-data recovery and destructive changes need an environment-specific plan. Read the editorial standards.
01Define backup policy
- Document which applications and volumes are in scope, the retention periods, legal hold needs, RPO and acceptable restore time. Decide whether a vault or unified mirror-vault policy is appropriate.
- Check the default policies for the actual ONTAP release. Ensure local snapshot labels match the destination policy rules; unlabeled snapshots may not transfer as expected. Budget destination capacity for change rate and retention.
volume snapshot show
snapmirror policy show
snapmirror show02Configure and verify
- Peer clusters/SVMs and create a destination volume on separate storage. In System Manager, protect the source with the selected policy and schedule, then initialize.
- Confirm the expected daily and monthly recovery points appear on the destination after at least one cycle. Monitor transfer errors, lag, destination free space, and retention.
Multiple recovery dates are present on the destination and capacity is adequate for the retention period.
03Perform a restore drill
- Choose an older point in time and restore a test file or isolated volume. Compare checksums or application data, permissions, and elapsed restore time.
- Document how to locate a snapshot, choose destination, and avoid overwriting live data. A backup is useful only when its restore has been exercised.
Restored data passes owner validation, and the production source is unchanged.
04Worked label and retention worksheet
A daily source schedule does not automatically imply a daily destination rule. Verify the label on actual source snapshots and the rule selection in the intended policy. A missing label or mismatched rule can leave retention different from the business requirement despite successful transfers. Budget destination consumption using workload changes and retained history, not the source volume’s current active data alone.
| Source snapshot label | Example destination retention | Pilot evidence |
|---|---|---|
| daily | 14 selected daily points | A completed transfer places a daily point at the destination. |
| weekly | 8 selected weekly points | A weekly labeled point is retained as expected. |
| monthly | 12 selected monthly points | Older points remain discoverable in the restore workflow. |
- Inspect a representative source Snapshot and the destination policy/rules. Transfer a pilot point for each required label and confirm the intended point exists on the destination.
- Select an older retained point and recover it into a separate test target. Check application content and authorization, then record elapsed recovery time.
- Before changing counts, labels or deletion behavior, review business retention and recovery dependencies. The presence of a mirror is not a legal-hold guarantee.
Every required label has a transferred/retained example and an older destination point has passed an isolated restore test.
Use the section links to revisit a step, or follow a related guide below.
Official references and further reading
Choose the matching release in the vendor documentation before using a command or design. References open on the publisher’s website; linked material remains with its publisher.