Resynchronizing SnapMirror
Why to 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 (NCS) shared by the two volumes or qtrees, and removes all newer information on the filer on which the command is run.
Note
The snapmirror resync command requires that the two volumes or qtrees have at least one snapshot in common. You can resynchronize a volume or qtree to any other volume or qtree as long as both have at least one snapshot in common.
Resynchronization will cause the loss of all data written to the destination after the base snapshot 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.
Resynchronizing a SnapMirror relationship
To resynchronize a destination to a source, complete the following steps.
Step
|
Action
|
|---|
|
1 |
From the destination filer, enter the following command:
snapmirror resync [options]
[dest_filer:]{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 on the source and on the destination that can be used as the newest common snapshot (base snapshot) 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_filer:]{source_volume | qtree_path}specifies the filer 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_filer is the name of the destination filer.
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, which will be used as the base for resynchronization, and generates a list of snapshots 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 snapshots on the destination volume (if you are resynchronizing volumes)
|
Type y at the prompt.
Result
SnapMirror
- Deletes the listed snapshots 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 that was created after the common snapshot 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
filerB> snapmirror resync filerB: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
filerB> snapmirror resync -S
filerA:/vol/vol2/qtreeBob filerB:/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 on the source and destination exists
If SnapMirror cannot find a common snapshot 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 re-initialize 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 filer, 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 filer, 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 filers.
Example summary
In the following example, the original source (the one disabled by the disaster) is FilerA:vol/volA and the original destination is FilerB:/vol/volB. You use a combination of snapmirror break and snapmirror resync or snapmirror initialize commands to
- temporarily make FilerB:volB the source and FilerA:volA the destination to restore mirrored data back to FilerA:volA and to update FilerA:volA.
- restore FilerA:/vol/volA and FilerB: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 before the source was disabled and all the data written to FilerB:vol/volB after it was made writable is preserved. Any data written to FilerA:vol/volA between the last SnapMirror snapshot and the time that FilerA:vol/volA was disabled is not preserved.
Step
|
Action
|
|---|
|
1 |
After the source volume (in this case, FilerA:volA) is disabled, the administrator uses the snapmirror break command to make the destination volume, FilerB:volB, writable.
snapmirror break FilerB:volB
|
|
2 |
The administrator redirects the clients of source FilerA to source FilerB.
The former clients of FilerA are now accessing and writing to FilerB.
|
|
3 |
The administrator temporarily makes the original source volume into a read-only destination volume.
- If FilerA:volA is recoverable, and its data is intact, then the administrator on FilerA uses the snapmirror resync command to resynchronize FilerA with FilberB.
snapmirror resync -S FilerB:VolB FilerA:volA
- If FilerA:volA is unrecoverable, the administrator makes a new volA on FilerA, and from FilerA, initializes FilerA:volA from FilerB.
snapmirror initialize -S FilerB:volB FilerA:volA
This command also makes FilerA:volA a read-only destination.
|
|
4 |
The administrator then redirects the clients from FilerB to FilerA.
The clients cannot access or write to FilerA:volA, but they are no longer writing new data to FilerB:volB.
|
|
5 |
The administrator updates FilerA:volA from FilerB to transfer the latest data from Filer B.
snapmirror update -S FilerB:volB FilerA:volA
|
|
6 |
Now, the administrator uses the snapmirror break command to make FilerA:volA writable. In FilerA the administrator enters:
snapmirror break volA
|
|
7 |
From FilerB, the administrator uses the snapmirror resync command to make FilerB, the original destination, the destination again.
snapmirror resync volB
|
Copyright © 1994-2003, Network Appliance, Inc. All rights
reserved.
Part No. 210-00476
File: mirror20.htm
Last updated: 11/13/03 17:17:26