2011-10-27 08:53 AM
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.
Application: SQL (using SnapManger for SQL)
<Source is back up and functional>
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?
2011-10-31 06:09 AM
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.
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
5. Update systemA:volA from systemB to transfer the latest data from systemB.
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
1.snapmirror Update -s filer2;mir-vol2 filer1:vol1