SnapMirror Snaps - How Many? Ok to Delete? Resync on Other Snaps? & More …

In the following post, via examples, we answer a few questions about SnapMirror. This is SnapMirror in Clustered Data ONTAP.

Contents

Q1: How many “snapmirror.” snaps should there be in a 1 to 1 SnapMirror?
Q2: How many “snapmirror.” snaps should there be in a 1 to many fan-out SnapMirror?
Q3: How to pause a SnapMirror relationship?
Q4: Can we resync on a non “snapmirror.” named snapshot?
Q5: What “snapmirror.” snaps and others can we delete?

The examples below are taken from a lab where the SVM vs1 holds the source volumes, and vs2 holds the destination volumes. For volume SnapMirror fan-out examples, we have the SVM vsa which holds the source volume, and vsb and vsc hold the destination volumes.

We’re only considering Volume SnapMirror - since Clustered ONTAP does not have Qtree SnapMirror - and Volume SnapMirror Fan-Out. There is no Qtree SnapMirror Fan-In without Qtree SnapMirror (there is Vserver Fan-In - that is - volumes from many different Vservers can fan into one Vserver but different volumes!)

Answers

Q1: How many “snapmirror.” snaps should there be in a 1 to 1 SnapMirror?

Assuming the SnapMirror is not updating at the time of checking, there should be one “snapmirror.” snapshot on the source, and two “snapmirror.” snapshots on the destination, as below:

::> snapshot show -snapshot *snapmirror* -volume vs1_cifs_vol1 -fields snapshot
vserver volume        snapshot
------- ------------- ------------------------------------------------------------------------------
vs1     vs1_cifs_vol1 snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_4_2147484680.2013-12-28_133001

::> snapshot show -snapshot *snapmirror* -volume vs2_vs1_cifs_vol1 -fields snapshot
vserver volume            snapshot
------- ----------------- ------------------------------------------------------------------------------
vs2     vs2_vs1_cifs_vol1 snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_4_2147484680.2013-12-28_132500
vs2     vs2_vs1_cifs_vol1 snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_4_2147484680.2013-12-28_133001

Why one on the source and two on the destination?

Well, prior to updating the SnapMirror, the source has to take a “snapmirror.” snapshot, so there’s two on the source at the start of the SnapMirror transfer, and these are replicated to DR. Once the SnapMirror transfer is complete, the source deletes the oldest “snapmirror.” snapshot leaving only one, but the destination retains the two.

Q2: How many “snapmirror.” snaps should there be in a 1 to many fan-out SnapMirror?

Assuming the SnapMirror is not updating at the time of checking:
On the source, for each fan-out Volume SnapMirror relationship, there will be one “snapmirror.” reference snapshot
On the destinations, it’s going to depend on whether the SnapMirror updates are occurring at the same time, and in that case, which relationship started first. It is always going to be at least one more that the number of SnapMirror fan-out relationships as in the example below:

::> snapshot show -snapshot *snapmirror* -volume vsa_cifs_vol1 -fields snapshot
vserver volume        snapshot
------- ------------- ------------------------------------------------------------------------------
vsa     vsa_cifs_vol1 snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_6_2147484687.2013-12-28_133000
vsa     vsa_cifs_vol1 snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_7_2147484688.2013-12-28_133000
2 entries were displayed.

::> snapshot show -snapshot *snapmirror* -volume vsb_vsa_cifs_vol1 -fields snapshot
vserver volume            snapshot
------- ----------------- ------------------------------------------------------------------------------
vsb     vsb_vsa_cifs_vol1 snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_6_2147484687.2013-12-28_132500
vsb     vsb_vsa_cifs_vol1 snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_7_2147484688.2013-12-28_132500
vsb     vsb_vsa_cifs_vol1 snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_6_2147484687.2013-12-28_133000

::> snapshot show -snapshot *snapmirror* -volume vsc_vsa_cifs_vol1 -fields snapshot
vserver volume            snapshot
------- ----------------- ------------------------------------------------------------------------------
vsc     vsc_vsa_cifs_vol1 snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_6_2147484687.2013-12-28_132500
vsc     vsc_vsa_cifs_vol1 snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_7_2147484688.2013-12-28_132500
vsc     vsc_vsa_cifs_vol1 snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_6_2147484687.2013-12-28_133000
vsc     vsc_vsa_cifs_vol1 snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_7_2147484688.2013-12-28_133000

In the example above, our source has two “snapmirror.” snapshots - that’s one reference snapshot for each volume SnapMirror relationship. On the first fan-out volume, we have three “snapmirror.” snapshots, that’s the two existing reference snapshots and one that was taken on the source prior to the update commencing. The second fan-out volume has four “snapmirror.” snapshots since it triggered whilst the first relationship was in progress, capturing those three snapshots and the one required for its own update.

Q3: How to pause a SnapMirror relationship?

There are actually three ways to do this depending on the circumstance:

1: Delete the SnapMirror relationship

::> snapmirror delete -destination-path nac1://vs2/vs2_vs1_cifs_vol1

This leaves the destination as a read-only DP type volume. To resync it is simply:

::> snapmirror resync -source-path nac1://vs1/vs1_cifs_vol1 -destination-path nac1://vs2/vs2_vs1_cifs_vol1

Remember to apply a SnapMirror schedule (new and resync-ed SnapMirrors have a schedule of “-“ or none)!

::> snapmirror modify -destination-path nac1://vs2/vs2_vs1_cifs_vol1 -schedule 5min

2: Break the SnapMirror relationship

::> snapmirror break -destination-path nac1://vs2/vs2_vs1_cifs_vol2

This leaves the destination as a writeable RW type volume. To resync it is simply:

::> snapmirror resync -source-path nac1://vs1/vs1_cifs_vol2 -destination-path nac1://vs2/vs2_vs1_cifs_vol2

A difference this time is that it will warn that data newer than the most recent snapmirror snapshot will be deleted!

Warning: All data newer than Snapshot copy snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_4_2147484681.2013-12-28_151501 on volume nac1://vs2/vs2_vs1_cifs_vol2 will be deleted.
Do you want to continue? {y|n}: y

Again, remember to re-apply the SnapMirror schedule.

3: Quiesce the SnapMirror relationship

::> snapmirror quiesce -destination-path nac1://vs2/vs2_vs1_cifs_vol3

This is the best method if you just want to temporarily pause a SnapMirror relationship. To resume:

::> snapmirror resume -destination-path nac1://vs2/vs2_vs1_cifs_vol3

Q4: Can we resync on a non “snapmirror.” named snapshot?

Yes! If you delete the SnapMirror relationship, this will allow you to delete the existing “snapmirror.” snapshot on the source, then, when you come to resync the relationship, it will use the latest in-common snapshot as below:

::> snapmirror delete -destination-path nac1://vs2/vs2_vs1_cifs_vol5

::> snapshot show -volume vs1_cifs_vol5
Vserver Volume  Snapshot
------- ------- --------
vs1     vs1_cifs_vol5
hourly.2013-12-28_1405
hourly.2013-12-28_1505
snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_4_2147484692.2013-12-28_154001

::> snapshot show -volume vs2_vs1_cifs_vol5
Vserver Volume  Snapshot
------- ------- --------
vs2     vs2_vs1_cifs_vol5
hourly.2013-12-28_1405
hourly.2013-12-28_1505
snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_4_2147484692.2013-12-28_153500
snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_4_2147484692.2013-12-28_154001

::> snapshot delete -volume vs1_cifs_vol5 -snapshot snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_4_2147484692.2013-12-28_154001 -vserver vs1

::> snapmirror resync -source-path nac1://vs1/vs1_cifs_vol5 -destination-path nac1://vs2/vs2_vs1_cifs_vol5
Warning: All data newer than Snapshot copy hourly.2013-12-28_1505 on volume nac1://vs2/vs2_vs1_cifs_vol5 will be deleted.
Do you want to continue? {y|n}: y

Again, remember to re-apply the SnapMirror schedule.

Note 1: There is no flag to choose a specific snapshot to resync upon!
Note 2: In a broken SnapMirror relationship, you cannot delete reference “snapmirror.” snapshots without using the “set advanced” flag -ignore-owners true!

Error: command failed: This Snapshot copy is currently used as a reference Snapshot copy by one or more SnapMirror relationships. Deleting the Snapshot copy can cause future SnapMirror operations to fail.

Q5: What “snapmirror.” snaps and others can we delete?

Firstly: in an active SnapMirror relationship, you cannot delete anything from the read-only destination volumes.
Secondly: on the source, Clustered Data ONTAP will not let you delete a reference SnapMirror snapshot by mistake.
Thirdly: beyond the SnapMirror snapshots that were discussed in Q1 and Q2, anything older named “snapmirror.” is likely to have been created by a failed SnapMirror transfer.

The general rule when it comes to re-syncing a SnapMirror relationship is that you must have one in-common snapshot on the source and the destination, and (as we’ve seen in Q4) this does not need to be a “snapmirror.” snapshot. So, the answer to the above becomes:

You can delete all the snapshots except there must be one remaining in-common snapshot on the source and destination volumes!

Note: If you’re tidying up and thinking of doing this, one thing to watch out for is that this one in-common snapshot isn’t auto deleted.

The current SnapMirror reference snapshot can be easily identified using a snapmirror show -instance, and looking at the ‘Newest Snapshot’ and ‘Exported Snapshot’ fields as in the example below (these will match unless an update is in progress):

::> snapmirror show -source-path nac1://vs1/vs1_cifs_vol1 -instance
                Source Path: nac1://vs1/vs1_cifs_vol1
           Destination Path: nac1://vs2/vs2_vs1_cifs_vol1
          Relationship Type: DP
           Managing Vserver: vs2
        SnapMirror Schedule: 5min
                Tries Limit: 8
          Throttle (KB/sec): unlimited
               Mirror State: Snapmirrored
        Relationship Status: Idle
          Transfer Snapshot: -
          Snapshot Progress: -
             Total Progress: -
        Snapshot Checkpoint: -
            Newest Snapshot: snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_4_2147484680.2013-12-28_171501
  Newest Snapshot Timestamp: 12/28 17:15:01
          Exported Snapshot: snapmirror.f2b20bdd-6da5-11e3-9034-123478563412_4_2147484680.2013-12-28_171501
Exported Snapshot Timestamp: 12/28 17:15:01
                    Healthy: true
   Constituent Relationship: false

Comments