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 storage system.
You can create a single /etc/snapmirror.conf file for your site and copy it to all the systems that use SnapMirror. The /etc/snapmirror.conf file can contain entries pertaining to other systems. For example, the /etc/snapmirror.conf file on systemB can contain an entry for copying a volume from systemC to systemD. When systemB reads the /etc/snapmirror.conf file, it ignores the entries for other storage systems. 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 system in the /etc/snapmirror.conf file. There is a 150-entry limit for each system for Data ONTAP 6.2 and a 210-entry limit for each system for Data ONTAP 6.3 through Data ONTAP 6.4.2. Entries beyond the entry limit for each system are ignored and a warning message is displayed on the system console.
If you have a cluster, the limit on the number of entries applies to the storage system pair combination. For example, if your cluster is running Data ONTAP 6.4.2, the 210 entry limit is shared by both systems in the cluster. If one system is using 120 entries, the other systems has 90 entries available for its use.
Note
This limitation is different from the maximum number of of simultaneous replications you can have on a storage system. For that information, see Maximum number of simultaneous replication operations.
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 storage system. |
| 2 |
If you want to add comments to the /etc/snapmirror.conf file, precede the comment with a pound sign (#). Example# Replicating from systemA |
| 3 |
For each destination volume or qtree that is to be located on this storage system, type an entry specifying the source, destination, characteristics and schedule of the data transfer on one line using the following syntax: source_system:{source_volume |
/vol/volume_name/qtree_name} dest_system:{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_system:/vol/source_volume/- dest_system:/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_system:/vol/src_vol/[src_qtree] dest_system:/vol/dest_vol[/dest_qtree] [arguments] [sched]
The parameters in the entries are shown in the following table.
|
The name of the storage system 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 system name, it should find the IP address for the source system on the network over which you want the transfer to occur. ExampleAssume you created a private network connecting a source system and a destination system and you named the interface on the source system systemA-e0. The interface name systemA-e0 is what you enter in the source_system 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 system to which the data is copied. The name you use must be the exact host name of the destination system. The dest_system field is case-sensitive. You can use the hostname command on the destination system to determine what you enter for this field. ExampleIf the name of the destination system is systemA, enter systemA in the dest_system 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. | |
|
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. | |
|
Determines the amount of time before an automatic Snapshot copy is created on the source volume that is synchronously mirrored. With synchronous SnapMirror, changes to the source volume do not show immediately on the destination volume, even though the changes have been mirrored. The changes are shown only after the source system takes an automatic Snapshot copy of the source volume. This happens every three minutes by default. You can change the interval for automatic Snapshot copies, but performance can degrade if you set smaller intervals because more Snapshot copies are taken more often. The smallest interval you can set is 30 seconds. The s, m, and h suffixes specify seconds, minutes, and hours, respectively. | |
|
Determines the TCP window size used by a connection. Different from the snapmirror.window_size option which determines the TCP window size for allSnapMirror replications. Use the formula shown in Adjusting the TCP window size to calculate a TCP window size that works well for a particular connection. TCP window size is in bytes. | |
|
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). Multiple values, separated by commas, can be entered for any field. All possible values for a field can be applied with an asterisk (*). If you specify an asterisk in each field of the schedule, SnapMirror updates the destination every minute. A single dash (-) in any field means "never" and prevents this schedule entry from executing. (This is useful if you want the server to appear in the /etc/snapmirror.conf file so that snapmirror update can find it, but you do not want the SnapMirror scheduler to run automatically.) A range of values for any field can be indicated with a low value and a high value separated by a dash. For example, you can indicate that you want an update every hour from 8:00 a.m. to 5:00 p.m by entering this value in the hour field: A range of values followed by a slash and a number indicates the frequency of the update. For example, you can indicate that you want an update every five minutes by entering this value in the minutes field: Typing sync instead of the four space-separated fields specifies synchronous replication. See the na_snapmirror.conf(5) man page for more information. |
Suppose you create a private network between systemA and systemB. In the /etc/hosts file on systemA, you give the host name for the interface as systemA-e0, and you ensure that systemA-e0 is also in the /etc/hosts file on systemB, the destination system. You want to copy vol0 of systemA to vol1 of systemB 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:
systemA-e0:vol0 systemB: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.
systemA:vol0 systemA: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.
systemA:vol0 systemA: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.
systemA:vol0 systemA: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:
systemA:vol0 systemA: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:
systemA:vol0 systemA: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 copy 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-2005, Network Appliance, Inc. All rights
reserved.
Part No. 210-01081_B0
File: mirror9.htm
Last updated: 01-Dec-2005 16:36:03