Resynchronizing SnapMirror
Why you resynchronize a source and destination volume
You can use the snapmirror resync command to restore or redefine a SnapMirror source or destination relationship that was broken with the snapmirror break command. You might want to resynchronize a source and a destination volume or qtree when
- You are changing the current source to a different volume or qtree
- You make a destination volume writable for application testing and then want to make it a SnapMirror destination again
- You need to recover from a disaster that disabled the source
- You want to reverse the functions of the source and the destination
What the snapmirror resync command does
After the snapmirror break command, you apply the snapmirror resync command to either the original SnapMirror destination or the original source.
- Applied to the original destination-- the snapmirror resync command will put a volume or qtree back into a SnapMirror relationship and resynchronize its contents with the source without repeating the initial transfer.
- Applied to the source volume-- the snapmirror resync command can turn the source volume into a copy of the original destination volume. In this way, the roles of source and destination can be reversed.
How the snapmirror resync command helps minimize data loss
The snapmirror resync command enables you to re-establish a broken SnapMirror relationship without a lengthy baseline transfer.
This command offers the choice of either source or destination to serve as the source in the restarted SnapMirror relationship. It finds the newest common Snapshot copy (NCS) shared by the two volumes or qtrees, and removes all newer information on the storage system on which the command is run.
Note
The snapmirror resync command requires that the two volumes or qtrees have at least one Snapshot copy in common. You can resynchronize a volume or qtree to any other volume or qtree as long as both have at least one Snapshot copy in common.
Resynchronization will cause the loss of all data written to the destination after the base Snapshot copy was made. The snapmirror resync command informs you what data could be lost during the resynchronization and requests permission to proceed. If you want to save the data on the destination, you can stop the resynchronization, manually copy the desired data elsewhere, and reissue the snapmirror resync command to the destination.
Note
To support data integrity in a restrictive SnapLockTM Compliance environment, the resync operation saves all data that was written after the common Snapshot copy to a directory on the volume. For details see Qtree SnapMirror resync for SnapLock Compliance volumes.
Resynchronizing a SnapMirror relationship
To resynchronize a destination to a source, complete the following steps.
Step
|
Action
|
|---|
|
1
|
From the destination system, enter the following command:
snapmirror resync [options]
[dest_system:]{dest_volume | /vol/qtree_path}
options can be any of the following:
- -n does not execute the resynchronization, but displays what would be done if the snapmirror resync command were run. You can use this option to find whether you have a Snapshot copy on the source and on the destination that can be used as the newest common Snapshot copy (base Snapshot copy) so that you can resync a specific SnapMirror relationship.
- -f forces the operation to proceed without prompting you for confirmation.
- -k n sets the maximum transfer speed to n kilobytes per second. This option has the same effect as the kbs argument in the /etc/snapmirror.conf file.
- -S [source_system:]{source_volume | qtree_path}specifies the system and volume or qtree you want to use as the source for resynchronization.
The source specified by the -S option must match a source entry in the /etc/snapmirror.conf file. If entries exist but the source does not match, the operation displays an error message and terminates. If there is no entry for the specified source, the command runs.
If the -S option is not set, the source must be specified in the /etc/snapmirror.conf file. If it is not specified, the operation displays an error message and terminates.
|
Step
|
Action
|
|---|
|
|
dest_system is the name of the destination system.
dest_volume or /vol/qtree_path is the destination volume or qtree. If it is a scheduled destination as specified in the /etc/snapmirror.conf file, that source volume or qtree is assumed to be the source. If the destination volume or qtree specified is not in a scheduled relationship, then the -S option must be used to provide a source.
Result
SnapMirror identifies the newest common Snapshot copy, which will be used as the base for resynchronization, and generates a list of Snapshot copies on the destination volume that
SnapMirror then prompts you to choose whether to continue.
|
|
2
|
If...
|
Then...
|
|
You want to
- Reestablish the SnapMirror pair
- Delete the listed Snapshot copies on the destination volume (if you are resynchronizing volumes)
|
Type y at the prompt.
Result
SnapMirror
- Deletes the listed Snapshot copies on the destination volume (if you are resynchronizing volumes).
- Makes the destination read-only.
- Initiates an update of the destination.
|
|
|
If...
|
Then...
|
|
You do not want to lose the data in a Snapshot copy that was created after the common Snapshot copy on the destination, but you want to resynchronize the two volumes or qtrees after the data is saved
|
- Type n at the prompt.
- Manually copy the data you want to save to the source or other volume.
- Return to Step 1 to rerun the snapmirror resync command.
|
|
You do not want to reestablish the SnapMirror relationship
|
Type n at the prompt.
Result
SnapMirror terminates the command.
|
Volume example
systemB> snapmirror resync systemB:vol2
The resync base snapshot will be vol2(0001234567)_d.4
These newer snapshots will be deleted from the destination:
hourly.0
hourly.1
These older snapshots have already been deleted from the source and
will be deleted from the destination:
vol2(0001234567)_d.3
Are you sure you want to resync the volume?
Qtree example
systemB> snapmirror resync -S
systemA:/vol/vol2/qtreeBob systemB:/vol/vol3/qtreeBak
The resync base snapshot will be vol2(0001234567)_d.4
Data could be lost as a result of this operation.
Are you sure you want to resync the volume?
If no common Snapshot copy on the source and destination exists
If SnapMirror cannot find a common Snapshot copy on the source and destination to use as the basis for resynchronization, resynchronization is not possible. SnapMirror generates an error message that states the problem and terminates the command. You must reinitialize the destination to establish the SnapMirror relationship.
Database application testing: a special use for snapmirror resync
Testing software applications that run on a database can sometimes change or even corrupt the database. To ensure that you do not lose data while testing such software applications, you can copy the data to another volume for testing purposes, break the destination volume to return it to writable state, and run the test application on it. Upon completion of the test, you can resynchronize the source and the destination volume to restore the data and repeat the testing as often as you need.
In the following procedure, you can use a combination of the snapmirror break and snapmirror resync commands to
- make a destination volume writable for testing.
- restore the newly writable volume to its original state if further testing is required.
To set up a destination for testing software applications, complete the following steps.
Step
|
Action
|
|---|
|
1
|
Create or choose a volume or qtree to be used as a destination for the volume or qtree containing the database. (This example uses a qtree called Testqtree.)
|
|
2
|
Follow the steps described in Enabling SnapMirror.
|
|
3
|
On the destination system, enter the following command to make the destination writable:
snapmirror break Testqtree
|
|
4
|
Run the application on the data in the former destination (Testqtree).
|
|
5
|
Check the data in the former destination (Testqtree).
|
|
6
|
If the data...
|
Then...
|
|
Has been altered in some way that is not useful and you want to import a fresh copy of the data for further testing
|
From the destination system, enter the following command:
snapmirror resync Testqtree
Result
SnapMirror makes the former destination volume into a SnapMirror destination again and updates the destination with the latest data.
|
|
|
Has not been altered deleteriously, or you wish to stop testing
|
You have finished.
|
|
7
|
Repeat Steps 4, 5, and 6 until you are satisfied with the testing.
|
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.
Example summary
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
- 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.
What data is preserved
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.
Step
|
Action
|
|---|
|
1
|
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
|
|
2
|
The administrator redirects the clients of source systemA to source systemB.
The former clients of systemA are now accessing and writing to systemB.
|
|
3
|
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 FilberB.
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.
|
|
4
|
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.
|
|
5
|
The administrator updates systemA:volA from systemB to transfer the latest data from system B.
snapmirror update -S systemB:volB systemA:volA
|
|
6
|
Now, the administrator uses the snapmirror break command to make systemA:volA writable. In systemA the administrator enters:
snapmirror break volA
|
|
7
|
From systemB, the administrator uses the snapmirror resync command to make systemB, the original destination, the destination again:
snapmirror resync volB
|
Copyright © 1994-2005, Network Appliance, Inc. All rights
reserved.
Part No. 210-01081_B0
File: mirror23.htm
Last updated: 01-Dec-2005 16:36:03