Copying from one destination to another in a series (cascading)

When to copy from a destination

It can be useful to copy from a SnapMirror destination when the data you want to copy is on a destination that is closer to you than the same data on a source. It is also useful to copy from a destination when you need to copy data from one site to many sites. Instead of propagating the data from one central master site to each of the destination sites, which would require expensive network connections or excessive CPU time, you can propagate the data from one destination to another destination and from that one to the next, in a series.

In the example below, the data on filerA is copied on nine different filers, but only two of the filers copy the data directly from the source. The other seven filers copy the data from a destination site.

Note
The cascading procedure is supported for SnapMirror volume replication only. Cascading is not supported for SnapMirror qtree replication.

How to copy from a destination

You can copy from a destination volume the same way you copy from a writable source volume. For information on how to set up a destination, see Enabling SnapMirror.

Sample cascade setup

To support a series of cascading volume destinations as shown in the diagram above, the /etc/snapmirror.conf file in each of the cascaded filers would look like this:

filerA:vol1 filerB:vol1 - 15 * * 1,2,3,4,5

filerA:vol1 filerL:vol1 - 15 * * 1,2,3,4,5

filerB:vol1 filerC:vol1 - 25 * * 1,2,3,4,5

filerC:vol1 filerD:vol1 - 35 * * 1,2,3,4,5

filerL:vol1 filerM:vol1 - 25 * * 1,2,3,4,5

filerM:vol1 filerX:vol1 - 35 * * 1,2,3,4,5

filerM:vol1:filerN:vol1 - 35 * * 1,2,3,4,5

filerX:vol1 filerY:vol1 - 45 * * 1,2,3,4,5

filerX:vol1 filerZ:vol1 - 45 * * 1,2,3,4,5

Note
When specifying the destination update schedule in the snapmirror.conf file, stagger the update times instead of starting multiple destination updates at the same time. If SnapMirror does not have enough resources to perform all scheduled destination updates, it postpones some updates. As a result, SnapMirror might need to perform subsequent updates at times that are different from those you specify in the snapmirror.conf file.

How SnapMirror handles snapshots for cascading destinations

SnapMirror retains the snapshots on the original source volume needed for transfers to destinations further down the line. Snapshots that are still needed by a destination are labeled "snapmirror" in the output of the snap list command. SnapMirror deletes the snapshots it no longer needs.

If you remove a destination from the cascade, you use the snapmirror release command from the immediate source to tell SnapMirror to delete the snapshots associated with that destination.

Cascading from a synchronous SnapMirror

You can cascade volume destinations from a synchronous Snapmirror destination, but the cascading series is slightly different from that for asynchronous SnapMirror. For a synchronous SnapMirror, the first replication is the only synchronous SnapMirror replication in the cascade, and the synchronous replication can be to one destination filer only. Subsequent SnapMirror replications cascading from that destination filer must be asynchronous and can be to multiple destination filers.

Listing SnapMirror destinations for a volume in a cascading series

To display the SnapMirror destinations for a source volume, complete the following step.

Step	Action
1	From the filer with the volume serving as the source, enter the following command: *snapmirror destinations [-s] [volume_name]* The `-s` option generates a list of the names of the snapshots retained for each destination. volume_name is the name of the source volume for which you want to see the destinations.

Step

Action

From the filer with the volume serving as the source, enter the following command:

snapmirror destinations [-s] [volume_name]

The -s option generates a list of the names of the snapshots retained for each destination.

volume_name is the name of the source volume for which you want to see the destinations.

Sample snapmirror destinations command output

Following is an example of the snapmirror destinations command output for the configuration in the diagram above.

filerA> snapmirror destinations vol1

Path        Destination

/vol/vol1   filerB:vol1->filerC:vol1->filerD:vol8

/vol/vol1   filerL:vol1->filerM:vol1->filerX:vol1->filerY:vol1

/vol/vol1   filerL:vol1->filerM:vol1->filerX:vol1->filerZ:vol1

/vol/vol1   filerL:vol1->filerM:vol1->filerN:vol1

If you do not specify a volume name in the command, the output includes information about each destination volume on the filer.

Restructuring a cascade

You might restructure a cascade to balance loading of your filers; to use a filer or volume for a different purpose; or to perform upgrades, maintenance, or repairs. For example, in the cascade structure below, you might want to make filerD:vol1 a destination of filerM:vol1 instead of a destination of filerC:vol1.

To restructure the relationship of the destinations in a cascade, complete the following steps.

Step	Action
1	On the destination filer, change the /etc/snapmirror.conf file to indicate the new source for the destination. Example filerM:vol1 filerD:vol1 - 35 * * 1,2,3,4,5
2	If...	Then
2	The newest snapshot on the destination exists on the source	Use the following command to update the destination from the new source: snapmirror update -S source_volume dest_filer:dest_volume Example snapmirror update -S filerM:vol1 filerD:vol1
3	The newest snapshot on the destination does not exist on the source	Perform one of the following tasks: Update the new source from the original source using the `snapmirror update`command. Wait for the destination to update. Make the destination writable using the `snapmirror break` command. Then resynchronize the destination with the new source using the `snapmirror resync`command.
4	Release the former source using the following command: *snapmirror release source_volume* [[dest_filer:]dest_volume]** Example filerC> snapmirror release filerC:vol1 filerD:vol1

Example of disconnecting a destination from a cascading series

For the example shown in the diagram below, suppose that from filerB you enter the following command:

snapmirror release vol1 filerC:vol1

These results follow:

filerA:vol1 continues to be the source for the destination filerB:vol1.
filerC:vol1 no longer copies from filerB:vol1. SnapMirror retains snapshots for filerC and below.
If filerC requests an update from filerB, the destination is reestablished if it is still not writable and the base snapshot still exists on the source.
filerD:vol1 still copies filerC:vol1.
All the destinations that depend on filerL:vol1 continue functioning as before.

You can check that the destination was released by running the snapmirror destinations command on filerA, as follows:

filerA> snapmirror destinations -s filerA:vol1

Volume Snapshot                     Destination

vol1   filerB(0015269532)_vol1.37   filerB:vol1

vol1   filerL(0015269532)_vol1.42   filerL:vol1->filerM:vol1-
>filerXvol1->filerY:vol1

vol1   filerL(0015269532)_vol1.42   filerL:vol1->filerM:vol1-
>filerXvol1->filerZ:vol1

vol1   filerL(0015269532)_vol1.42   filerL:vol1->filerM:vol1-
>filerN:vol1

Note
If you want to permanently release a destination, you need to either delete the entry in the /etc/snapmirror.conf file or comment out the entry by preceding it with a pound sign (#). Otherwise, SnapMirror continues to try to update the destination.