SnapMirror/DR (High-Level) Steps

gigabyte1 — Thu, 05 Jun 2025 06:42:36 GMT

Sadly the traing we received from our VAR was less than acceptable. However, now we're stuck with figuring out all the required steps to execute a Production -> DR -> Production scenario. Below are very high-level steps and enough detail to paint the picture. We have most of it figured out, however, it's the very last steps that we're stumbling upon and would appreciate any feedback.

SourceFiler: Filer1

Volume: vol1

Destination/DRFiler: Filer2

Volume: mir_vol1

Application: SQL (using SnapManger for SQL)

Establish SnapMirror relationship from destination with the source filer1:vol1 -> filer2:mir_vol1
Perform Snapshots on source as needed.

Assuming source is offline, Quiesce and Break the applicable SnapMirror relationships on the destination.
Mount the applicable SnapShot(s) to the DRservers.

Schedule downtime
Issue snapmirror resync –S filer2:mir_vol1 filer1:vol1
Issue/wait for update to complete

Here is my question. How do you get the vol1 to be updated with all the changes that occured in the DR environment? The changes are in the replicated snapshot, no? Do the changes in the snapshot automatically/transparentlyupdate the original vol1? Or are there additional steps? If there areadditional steps, at a high-level, what are they?

SnapMirror/DR (High-Level) Steps

senthilb — Mon, 31 Oct 2011 13:09:01 GMT

In the following example, the original source (the one disabled by the disaster) is systemA:vol/volA and the original destination is systemB:/vol/volB. You use a combination of snapmirror break and snapmirror resync or snapmirror initialize commands to perform the following tasks:

In this example, all data from the last scheduled SnapMirror Snapshot copy before the source was
disabled and all the data written to systemB:vol/volB after it was made writable is preserved. Any
data written to systemA:vol/volA between the last SnapMirror Snapshot copy and the time that
systemA:vol/volA was disabled is not preserved.

Steps
1. After the source volume (in this case, systemA:volA) is disabled, use the snapmirror break
command to make the destination volume, systemB:volB, writable.
snapmirror break systemB:volB
2. Redirect the clients of source systemA to source systemB.
The former clients of systemA are now accessing and writing to systemB.
3. Temporarily make the original source volume a read-only destination volume.
• If systemA:volA is recoverable, and its data is intact, then use the snapmirror resync
command on systemA to resynchronize systemA with systemB.
snapmirror resync -S systemB:VolB systemA:volA
• If systemA:volA is unrecoverable, make a new volA on systemA, and from systemA,
initialize systemA:volA from systemB.
snapmirror initialize -S systemB:volB systemA:volA
This command also makes systemA:volA a read-only destination.
Note: These commands need to be performed on the original source system.
4. Redirect the clients from systemB to systemA.
The clients cannot access or write to systemA:volA, but they are no longer writing new data to
systemB:volB.
5. Update systemA:volA from systemB to transfer the latest data from systemB.

Example
Perform the following step from systemA.
snapmirror update -S systemB:volB systemA:volA
6. Use the snapmirror break command to make systemA:volA writable. On systemA, enter
the following command:
snapmirror break volA
7. On systemB, use the snapmirror resync command to make systemB, the original
destination, the destination again.
snapmirror resync volB

Ans

1.snapmirror Update -s filer2;mir-vol2 filer1:vol1

2.yes

3.yes

4.no---

topic SnapMirror/DR (High-Level) Steps in ONTAP Discussions

SnapMirror/DR (High-Level) Steps

SnapMirror/DR (High-Level) Steps