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
Post a Comment