Skip to main content

Convert an existing ONTAP DP-type relationship to XDP

Contributors netapp-lenida netapp-aaron-holt netapp-aherbin netapp-ahibbard netapp-dbagwell
PDFs

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.

Before upgrading to ONTAP 9.12.1, you must convert existing DP-type relationships to XDP before you can upgrade to ONTAP 9.12.1 and later releases.

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.

  • 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.

Note

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

  1. 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>
    Cli
    Copy

    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
    Note

    You might find it helpful to retain a copy of the snapmirror show command output to keep track existing of the relationship settings. Learn more about snapmirror show in the ONTAP command reference.

  2. From the source and the destination volumes, ensure that both volumes have a common snapshot:

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

    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

  3. 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>
    Cli
    Copy

    Learn more about snapmirror quiesce in the ONTAP command reference.

    Note

    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

  4. Break the existing DP-type relationship:

    snapmirror break -destination-path <SVM:volume>
    Cli
    Copy

    Learn more about snapmirror-break in the ONTAP command reference.

    Note

    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

  5. If automatic deletion of snapshots is enabled on the destination volume, disable it:

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

    The following example disables snapshot autodelete on the destination volume volA_dst:

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

  6. Delete the existing DP-type relationship:

    snapmirror delete -destination-path <SVM:volume>
    Cli
    Copy

    Learn more about snapmirror-delete in the ONTAP command reference.

    Note

    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

  7. Release the origin SVM disaster recovery relationship on the source:

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

    The following example releases the SVM disaster recovery relationship:

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

  8. 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>
    Cli
    Copy

    The new relationship must use the same source and destination volume. Learn more about the commands described in this procedure in the ONTAP command reference.

    Note

    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

  9. Resync the source and destination volumes:

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

    To improve resync time, you can use the -quick-resync option, but you should be aware that storage efficiency savings can be lost. Learn more about snapmirror resync in the ONTAP command reference.

    Note

    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

  10. If you disabled automatic deletion of snapshots, reenable it:

    volume snapshot autodelete modify -vserver <SVM> -volume <volume> -enabled true
    Cli
    Copy
After you finish

  1. Use the snapmirror show command to verify that the SnapMirror relationship was created.

  2. Once the SnapMirror XDP destination volume begins updating snapshots 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.

Additional information about DP-type relationships

Beginning with ONTAP 9.3, XDP mode is the default, and any invocations of DP mode on the command line or in new or existing scripts are automatically converted to XDP mode.

Existing relationships are not affected. If a relationship is already of type DP, it will continue to be of type DP. Beginning with ONTAP 9.5, MirrorAndVault is the default policy when no data protection mode is specified or when XDP mode is specified as the relationship type. The table below shows the expected behavior.

If you specify…​

The type is…​

The default policy (if you do not specify a policy) is…​

DP

XDP

MirrorAllSnapshots (SnapMirror DR)

Nothing

XDP

MirrorAndVault (unified replication)

XDP

XDP

MirrorAndVault (unified replication)

As the table shows, the default policies assigned to XDP in different circumstances ensure that the conversion maintains the functional equivalence of the previous types. Of course, you can use different policies as needed, including policies for unified replication:

If you specify…​

And the policy is…​

The result is…​

DP

MirrorAllSnapshots

SnapMirror DR

XDPDefault

SnapVault

MirrorAndVault

Unified replication

XDP

MirrorAllSnapshots

SnapMirror DR

XDPDefault

SnapVault

MirrorAndVault

Unified replication

The only exceptions to conversion are as follows:

  • SVM data protection relationships continue to default to DP mode in ONTAP 9.3 and earlier.

    Beginning with ONTAP 9.4, SVM data protection relationships default to XDP mode.

  • Root volume load-sharing data protection relationships continue to default to DP mode.

  • SnapLock data protection relationships continue to default to DP mode in ONTAP 9.4 and earlier.

    Beginning with ONTAP 9.5, SnapLock data protection relationships default to XDP mode.

  • Explicit invocations of DP continue to default to DP mode if you set the following cluster-wide option:

    options replication.create_data_protection_rels.enable on

    This option is ignored if you do not explicitly invoke DP.