If you are upgrading to ONTAP 9.12.1 or later, you must convert DP-type relationships to XDP before upgrading. ONTAP 9.12.1 and later does not support DP-type relationships. You can easily convert an existing DP-type relationship to XDP to take advantage of version-flexible SnapMirror.

About this task

SnapMirror does not automatically convert existing DP-type relationships to XDP. To convert the relationship, you need to break and delete the existing relationship, create a new XDP relationship, and resync the relationship. For background information, see XDP replaces DP as the SnapMirror default.
When planning your conversion, you should be aware that background preparation and the data warehousing phase of an XDP SnapMirror relationship can take a long time. It is not uncommon to see the SnapMirror relationship reporting the status "preparing" for an extended time period.

After you convert a SnapMirror relationship type from DP to XDP, space-related settings, such as autosize and space guarantee are no longer replicated to the destination.

Steps

From the destination cluster, ensure that the SnapMirror relationship is type DP, that the mirror state is SnapMirrored, the relationship status is Idle, and the relationship is healthy:

snapmirror show -destination-path <SVM:volume>

The following example shows the output from the snapmirror show command:

cluster_dst::>snapmirror show -destination-path svm_backup:volA_dst

Source Path: svm1:volA
Destination Path: svm_backup:volA_dst
Relationship Type: DP
SnapMirror Schedule: -
Tries Limit: -
Throttle (KB/sec): unlimited
Mirror State: Snapmirrored
Relationship Status: Idle
Transfer Snapshot: -
Snapshot Progress: -
Total Progress: -
Snapshot Checkpoint: -
Newest Snapshot: snapmirror.10af643c-32d1-11e3-954b-123478563412_2147484682.2014-06-27_100026
Newest Snapshot Timestamp: 06/27 10:00:55
Exported Snapshot: snapmirror.10af643c-32d1-11e3-954b-123478563412_2147484682.2014-06-27_100026
Exported Snapshot Timestamp: 06/27 10:00:55
Healthy: true

You might find it helpful to retain a copy of the snapmirror show command output to keep track existing of the relationship settings.

From the source and the destination volumes, ensure that both volumes have a common Snapshot copy:

volume snapshot show -vserver <SVM> -volume <volume>

The following example shows the volume snapshot show output for the source and the destination volumes:

cluster_src:> volume snapshot show -vserver vsm1 -volume volA
---Blocks---
Vserver Volume Snapshot State Size Total% Used%
-------- ------- ------------------------------- -------- -------- ------ -----
svm1 volA
weekly.2014-06-09_0736 valid 76KB 0% 28%
weekly.2014-06-16_1305 valid 80KB 0% 29%
daily.2014-06-26_0842 valid 76KB 0% 28%
hourly.2014-06-26_1205 valid 72KB 0% 27%
hourly.2014-06-26_1305 valid 72KB 0% 27%
hourly.2014-06-26_1405 valid 76KB 0% 28%
hourly.2014-06-26_1505 valid 72KB 0% 27%
hourly.2014-06-26_1605 valid 72KB 0% 27%
daily.2014-06-27_0921 valid 60KB 0% 24%
hourly.2014-06-27_0921 valid 76KB 0% 28%
snapmirror.10af643c-32d1-11e3-954b-123478563412_2147484682.2014-06-27_100026
valid 44KB 0% 19%
11 entries were displayed.


cluster_dest:> volume snapshot show -vserver svm_backup -volume volA_dst
---Blocks---
Vserver Volume Snapshot State Size Total% Used%
-------- ------- ------------------------------- -------- -------- ------ -----
svm_backup volA_dst
weekly.2014-06-09_0736 valid 76KB 0% 30%
weekly.2014-06-16_1305 valid 80KB 0% 31%
daily.2014-06-26_0842 valid 76KB 0% 30%
hourly.2014-06-26_1205 valid 72KB 0% 29%
hourly.2014-06-26_1305 valid 72KB 0% 29%
hourly.2014-06-26_1405 valid 76KB 0% 30%
hourly.2014-06-26_1505 valid 72KB 0% 29%
hourly.2014-06-26_1605 valid 72KB 0% 29%
daily.2014-06-27_0921 valid 60KB 0% 25%
hourly.2014-06-27_0921 valid 76KB 0% 30%
snapmirror.10af643c-32d1-11e3-954b-123478563412_2147484682.2014-06-27_100026

To ensure scheduled updates will not run during the conversion, quiesce the existing DP-type relationship:
```
snapmirror quiesce -source-path <SVM:volume> -destination-path <SVM:volume>
```
For complete command syntax, see the man page.

You must run this command from the destination SVM or the destination cluster.

The following example quiesces the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup:
```
cluster_dst::> snapmirror quiesce -destination-path svm_backup:volA_dst
```
Break the existing DP-type relationship:
```
snapmirror break -destination-path <SVM:volume>
```
For complete command syntax, see the man page.

You must run this command from the destination SVM or the destination cluster.

The following example breaks the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup:
```
cluster_dst::> snapmirror break -destination-path svm_backup:volA_dst
```

If automatic deletion of Snapshot copies is enabled on the destination volume, disable it:

volume snapshot autodelete modify -vserver _SVM_ -volume _volume_ -enabled false

The following example disables Snapshot copy autodelete on the destination volume volA_dst:

cluster_dst::> volume snapshot autodelete modify -vserver svm_backup -volume volA_dst -enabled false

Delete the existing DP-type relationship:
```
snapmirror delete -destination-path <SVM:volume>
```
For complete command syntax, see the man page.

You must run this command from the destination SVM or the destination cluster.

The following example deletes the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup:
```
cluster_dst::> snapmirror delete -destination-path svm_backup:volA_dst
```

Release the origin SVM disaster recovery relationship on the source:

snapmirror release -destination-path <SVM:volume> -relationship-info-only true

The following example releases the SVM disaster recovery relationship:

cluster_src::> snapmirror release -destination-path svm_backup:volA_dst -relationship-info-only true

You can use the output you retained from the snapmirror show command to create the new XDP-type relationship:
```
snapmirror create -source-path <SVM:volume> -destination-path <SVM:volume>  -type XDP -schedule <schedule> -policy <policy>
```
The new relationship must use the same source and destination volume. For complete command syntax, see the man page.

You must run this command from the destination SVM or the destination cluster.

The following example creates a SnapMirror disaster recovery relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup using the default MirrorAllSnapshots policy:
```
cluster_dst::> snapmirror create -source-path svm1:volA -destination-path svm_backup:volA_dst
-type XDP -schedule my_daily -policy MirrorAllSnapshots
```

Resync the source and destination volumes:

snapmirror resync -source-path <SVM:volume> -destination-path <SVM:volume>

To improve resync time, you can use the -quick-resync option, but you should be aware that storage efficiency savings can be lost. For complete command syntax, see the man page: SnapMirror resync command.

You must run this command from the destination SVM or the destination cluster. Although resync does not require a baseline transfer, it can be time-consuming. You might want to run the resync in off-peak hours.

The following example resyncs the relationship between the source volume volA on svm1 and the destination volume volA_dst on svm_backup:

cluster_dst::> snapmirror resync -source-path svm1:volA -destination-path svm_backup:volA_dst

If you disabled automatic deletion of Snapshot copies, reenable it:

volume snapshot autodelete modify -vserver <SVM> -volume <volume> -enabled true

After you finish

Use the snapmirror show command to verify that the SnapMirror relationship was created.
Once the SnapMirror XDP destination volume begins updating Snapshot copies as defined by the SnapMirror policy, use the output of snapmirror list-destinations command from the source cluster to display the new SnapMirror XDP relationship.