Asynchronous XDP FlexVol relationship · AFF/FAS example
Example: source svm_prod:vol_projects replicates to dr_svm:vol_projects_dr every hour. This is an example RPO, not a promise of zero data loss.
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.
01Prepare both sides
- Confirm ONTAP version compatibility, intercluster LIF reachability, DNS/routes, licenses, and destination capacity. Peer clusters and SVMs with the approved authentication process.
- Choose the relationship type and policy: mirror for DR, vault for longer retention, or a supported combined policy. Define schedule, retention, and the recovery objective.
cluster peer show
vserver peer show
network interface show02Create and initialize
- Create the destination volume with suitable capacity on the destination SVM. In System Manager, select the source volume, choose Protect, select the destination and approved policy/schedule, and create the relationship.
- Initialize the relationship. Baseline transfer can be large; monitor progress and network capacity. After completion, record source/destination path, relationship UUID, policy, lag and schedule.
snapmirror show
snapmirror show -fields health,lag-time,last-transfer-error03Worked CLI example: initialize the DR relationship
- Run relationship creation on the destination cluster after peering and destination volume preparation. Confirm the policy and schedule are available; this example uses MirrorLatest and a schedule named hourly.
- Initialize the baseline and monitor it to completion. The source path and destination path must match the approved worksheet.
cluster peer show
vserver peer show
snapmirror policy show -policy MirrorLatest
job schedule show -name hourly
snapmirror create -source-path svm_prod:vol_projects -destination-path dr_svm:vol_projects_dr -type XDP -schedule hourly -policy MirrorLatest
snapmirror initialize -destination-path dr_svm:vol_projects_dr
snapmirror show -destination-path dr_svm:vol_projects_drBaseline is complete, relationship is healthy, and the latest transfer meets the agreed RPO.
04Monitor and test
- Check relationship health, last transfer error, and lag against the RPO daily. A healthy relationship with excessive lag may still miss the objective.
- Plan a non-disruptive failover test with a clone or isolated environment where supported. Document application dependencies, client DNS and routing changes, and failback.
Relationship healthy; baseline complete; observed lag within the agreed RPO.
05Worked relationship worksheet and peering gates
A DP destination volume and an XDP relationship are not contradictory: one describes the volume’s protection role and the other the replication relationship type. Specify and inspect the policy deliberately. MirrorLatest, MirrorAllSnapshots and vault/unified policies select recovery points differently. They are not interchangeable retention promises.
| Object | Example | Check |
|---|---|---|
| Source | svm_prod:vol_projects | Online read/write source with accepted protection requirements |
| Destination | svm_dr:vol_projects_dr | Suitable DP volume and physical capacity |
| Peering | Cluster peers and SVM peers | Available and approved for SnapMirror |
| Policy | Explicit asynchronous policy | Inspect which snapshots are selected |
| Schedule | Example 15-minute interval | Verify transfer time and usable point against the RPO |
- Verify cluster compatibility, intercluster reachability, SVM peers, source/destination language and destination headroom using the appropriate official workflow. Do not expose peering passphrases in a public example or change record.
- Inspect the policy and schedule actually present on the destination before creating the relationship. Choose them from the application RPO and retention requirement.
- Run initialization on the destination, wait for a terminal result and inspect the instance output. Plan the baseline outside peak demand where possible.
cluster peer show
vserver peer show
snapmirror policy show
snapmirror show -destination-path svm_dr:vol_projects_dr -instance
snapmirror initialize -destination-path svm_dr:vol_projects_drA completed baseline and an accepted destination point exist; a submitted initialize command is insufficient.
06Measure a realistic baseline and ongoing transfer budget
For an illustrative 1 TiB baseline at a sustained effective transfer rate of 80 MiB/s, the no-overhead estimate is about 3.64 hours. The effective rate already needs to reflect what your environment actually achieves; line speed alone omits competing traffic, source/destination work and transfer behavior. Rehearse a representative subset and update the forecast.
| Observed example | Interpretation |
|---|---|
| Schedule every 15 min; transfer takes 2 min | Potentially workable, but measure completed-point age. |
| Schedule every 15 min; transfer takes 25 min | The intended schedule cannot imply a guaranteed 15-minute RPO. |
| Healthy relationship; last usable point 45 min old | Health and RPO compliance are separate checks. |
| No recent completed transfer | Inspect errors, source availability, peers and space first. |
- Create a disposable source marker after the baseline and request an incremental update. Verify the destination recovery point contains the marker through an approved isolated restore/clone test.
- Track completed-point age, transfer duration, last error and destination space over a representative peak period.
- Rehearse recovery with the related DR guide. Do not break a live production mirror merely to prove that transfers occur.
The relationship meets a measured recovery objective and the destination data has been exercised in an isolated recovery 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.