The /etc/snapmirror.conf file defines the relationship between the source and the destination, the schedule used by the destination to copy data, and the arguments that control SnapMirror when copying data. This file resides on the destination filer.
You can create a single /etc/snapmirror.conf file for your site and copy it to all the filers that use SnapMirror. The /etc/snapmirror.conf file can contain entries pertaining to other filers. For example, the /etc/snapmirror.conf file on filerB can contain an entry for copying a volume from filerC to filerD. When filerB reads the /etc/snapmirror.conf file, it ignores the entries for other filers. However, each time the file is read, a warning message is displayed on the system console for each line that is ignored.
There is no limit on the total number of entries in the /etc/snapmirror.conf file; however, there is a limit of 600 entries for each filer in the /etc/snapmirror.conf file. There is a 150 entry limit for each filer for Data ONTAP 6.2 and 210 entry limit for each filer for Data ONTAP 6.3 through Data ONTAP 6.4.2. Entries beyond the entry limit for each filer are ignored and a warning message is displayed on the system console.
Note
This limitation is different from the maximum number of of simultaneous replications you can have on a filer. For that information, see Maximum number of simultaneous replications on a filer.
If SnapMirror is enabled, changes to the /etc/snapmirror.conf file take effect within two minutes. If SnapMirror is not enabled, changes to the /etc/snapmirror.conf file take effect immediately after you enter the snapmirror on command to enable SnapMirror.
To create or edit the /etc/snapmirror.conf file, complete the following steps.
| 1 | If it does not already exist, use a text editor to create a file called snapmirror.conf in the /etc directory on the root volume of the destination filer. |
| 2 | If you want to add comments to the /etc/snapmirror.conf file, precede the comment with a pound sign (#). Example# Replicating from filerA |
| 3 | For each destination volume or qtree that is to be located on this filer, type an entry specifying the source, destination, characteristics and schedule of the data transfer on one line using the following syntax: source_filer:{source_volume | /vol/volume_name/qtree_name}
dest_filer:{dest_volume | /vol/volume_name/qtree_name}
arguments schedule
For a full description of the snapmirror.conf file entry syntax see snapmirror.conf file entry syntax. Note Note If you want to combine all non-qtree data in a volume into a qtree to use as a SnapMirror source, use this syntax: source_filer:/vol/source_volume/- dest_filer:/vol/dest_volume/qtree_name The dash (-) character indicates all non-qtree data in the specified volume. Note |
| 4 |
The syntax for entries in the snapmirror.conf file is as follows:
src_filer:/vol/src_vol/[src_qtree]
dest_filer:/vol/dest_vol[/dest_qtree] [kbs=kbs],
[restart={never|always}] [sched]
The parameters in the entries are:
|
The name of the filer from which you are copying data. SnapMirror uses the /etc/hosts file or the database used by DNS and NIS for name resolution. When SnapMirror searches for the source filer name, it should find the IP address for the source filer on the network over which you want the transfer to occur. ExampleAssume you created a private network connecting a source filer and a destination filer and you named the interface on the source filer filerA-e0. The interface name filerA-e0 is what you enter in the source_filer field. |
|
|
The name of the volume or qtree that you are copying. Use the volume name alone for volumes. Use the full path name for qtrees. ExampleIf the name of the volume is vol1, enter vol1 in the src_vol/src_qtree field. If the name of the qtree is qtree3, and it is contained in volume vol3, enter the full path, /vol/vol3/qtree3, in the src_vol/src_qtree field. |
|
|
The host name of the filer to which the data is copied. The name you use must be the exact host name of the destination filer. The dest_filer field is case-sensitive. You can use the hostname command on the destination filer to determine what you enter for this field. ExampleIf the name of the destination filer is filerA, enter filerA in the dest_filer field. |
|
|
The name of the destination volume or qtree to which you are copying data. Use the volume name alone for volumes. Use the full path name for qtrees. ExampleIf the name of the volume is vol1, enter vol1 in the dest_vol[/dest_qtree] field. If the name of the qtree is qtree4, and it is in vol2, enter the full path, /vol/vol2/qtree4, in the dest_vol[/dest_qtree] field. |
|
Maximum transfer speed, in kilobytes per second, that Data ONTAP can use to transfer data. The kbs and restart arguments are expressed as a comma-separated list of name=value pairs, with no spaces, for example: kbs=2000,restart=always |
|
Restart mode that SnapMirror uses to continue an incremental transfer from a checkpoint if it is interrupted. There are three options:
The kbs and restart arguments are expressed as a comma-separated list of name=value pairs, with no spaces, for example: kbs=2000,restart=always |
|
Selects the checksum algorithm that is used to protect SnapMirror transmitted data. See Improving data protection using checksum for more information. |
|
Determines the synchronicity level of the synchronous SnapMirror. The ops suffix allows x number of outstanding write operations before forcing the client to wait for an acknowledgement. The ms and s suffixes allow x number of milliseconds and seconds, respectively. See Controlling the synchronicity level to improve performance for more information. |
|
Determines the amount of time before an automatic snapshot is created on the source volume that is synchronously mirrored. The s, m, and h suffixes specify seconds, minutes, and hours, respectively. See Controlling how quickly data becomes visible on the destination filer for more information. |
|
Determines the TCP window size used by a connection. Different from the snapmirror.window_size option which determines the TCP window size for all snapmirror replications. TCP window size is in bytes. See Changing the TCP window size for a connection for more information. |
|
|
Determines the schedule the destination uses for updating data. The schedule is mandatory. The schedule consists of four space-separated fields in order: minute hour dayofmonth dayofweek minute can be a value from 0 to 59. hour can be a value from 0 (midnight) to 23 (11 p.m.). dayofmonth can be a value from 1 to 31. dayofweek can be a value from 0 (Sunday) to 6 (Saturday).
|
Suppose you create a private network between filerA and filerB. In the /etc/hosts file on filerA, you give the host name for the interface as filerA-e0, and you ensure that filerA-e0 is also in the /etc/hosts file on filerB, the destination filer. You want to copy vol0 of filerA to vol1 of filerB over the private network every Monday, Wednesday, and Friday at 11 p.m. You also want to use the default for the arguments field.
To copy the data over the private network every Monday, Wednesday, and Friday at 11 p.m., you would enter the following in the /etc/snapmirror.conf file:
filerA-e0:vol0 filerB:vol1 - 0 23 * 1,3,5
The following figure illustrates what the entry in each field in the example means.
The following line in an /etc/snapmirror.conf file sets the speed to 2000 kilobytes per second.
filerA:vol0 filerA:vol1 kbs=2000 15 * * 1,2,3,4,5
Note
The specified transfer speed might not be achievable because transfer speed is limited by factors such as network bandwidth.
The following line in an /etc/snapmirror.conf file sets the restart value to always.
filerA:vol0 filerA:vol1 kbs=2000,restart=always 15 * * 1,2,3,4,5
If you set the value of only one argument (kbs or restart), the other will use the default value. If you want to use the default argument for both values, enter a dash (-).
The following line in an /etc/snapmirror.conf file sets both arguments to the default value.
filerA:vol0 filerA:vol1 - 15 * * 1,2,3,4,5
If you want to schedule an update every afternoon at 1:00, 1:15, 1:30, 1:45, 5:00, 5:15, 5:30, 5:45, 7:00, 7:15, 7:30, and 7:45, you enter the following in the schedule field:
filerA:vol0 filerA:vol1 0,15,30,45 13,17,19 * *
Note
An update is started when the current time matches a value in all four fields. Be careful that a value in the day of the month field does not exclude a value in the day of the week field. For example, the following schedule would update the destination every afternoon at 1:00, 1:30, 3:00, 3:30, 5:00 and 5:30 but only when the first day of the month falls on a Monday.
filerA:vol0 filerA:vol1 0,30 13,15,17 1 1
Note
The schedule represents the goal of the SnapMirror feature. Factors that may prevent SnapMirror from updating every minute include resource limitations or network stability. If an update is in progress when another is scheduled to occur, SnapMirror will start another transfer as soon as the first is complete. However, if three updates pass while the current transfer is in progress, SnapMirror does only one more update; it does not go back and run updates that have been made obsolete by those scheduled later.
In SnapMirror, a retry is an automatic attempt to start the transfer process after an interruption, whether or not any data was successfully transferred. A restart is the resumption of a previous transfer process from a restart checkpoint.
If a transfer fails, because of network failure, for example, SnapMirror automatically retries the transfer. SnapMirror makes a restart checkpoint every five minutes during a transfer. If a restart checkpoint exists and conditions are right, SnapMirror restarts the previous transfer where it left off. If not, SnapMirror creates a new snapshot and starts a new transfer.
After a reboot, SnapMirror does not automatically retry a transfer that was interrupted, but the next scheduled or manual transfer restarts it at the restart checkpoint, if the checkpoint is still valid.
A restart can happen if all of the following conditions are present:
An initial transfer can be restarted but will not be retried automatically. To restart an initial transfer, you need to re-enter the snapmirror initialize command. Scheduled incremental updates automatically retry the transfer. A manual update issued from the command line is not retried automatically.
Copyright © 1994-2003, Network Appliance, Inc. All rights
reserved.
Part No. 210-00476
File: mirror7.htm
Last updated: 11/13/03 17:17:26