Retrieving data for disaster recovery: A special use for snapmirror resync

When disaster disables the source of a SnapMirror relationship, you can use the snapmirror resync command as part of a strategy to update the repaired source and reestablish the original configuration of the storage systems.

Considerations

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:

Temporarily make systemB:volB the source and systemA:volA the destination to restore mirrored data back to systemA:volA and to update systemA:volA.
Restore systemA:/vol/volA and systemB:volB to their original roles as SnapMirror source and SnapMirror destination volume.

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

After the source volume (in this case, systemA:volA) is disabled, the administrator uses the snapmirror break command to make the destination volume, systemB:volB, writable.snapmirror break systemB:volB
The administrator redirects the clients of source systemA to source systemB.
The former clients of systemA are now accessing and writing to systemB.
The administrator temporarily makes the original source volume into a read-only destination volume.
- If systemA:volA is recoverable, and its data is intact, then the administrator on systemA uses the snapmirror resync command to resynchronize systemA with systemB.snapmirror resync -S systemB:VolB systemA:volA
- If systemA:volA is unrecoverable, the administrator makes a new volA on systemA, and from systemA, initializes 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 storage system.
The administrator then redirects 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.
The administrator updates systemA:volA from systemB to transfer the latest data from system B.
Example
Perform the following step from system B.snapmirror update -S systemB:volB systemA:volA
Now, the administrator uses the snapmirror break command to make systemA:volA writable. In systemA the administrator enters the following command:snapmirror break volA
From systemB, the administrator uses the snapmirror resync command to make systemB, the original destination, the destination again.snapmirror resync volB

Parent topic: What the snapmirror resync command does