| Parameter |
Description |
|---|
| src_system |
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 storage system name, it should find the IP address for the source storage system on the network over which you want the transfer to occur.
Example: Suppose you created a private network connecting a source storage system and a destination storage system and you named the interface on the source storage system systemA-e0. The interface name systemA-e0 is what you enter in the src_system field.
|
| src_vol/src_qtree |
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. Example: If 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.
|
| dest_system |
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.
Example: If the name of the destination system is systemA, enter systemA in the dest_system field.
|
| dest_vol [/dest_qtree] |
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. Example: If 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.
|
| kbs=kbs |
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={ never | always | default } |
Restart mode that SnapMirror uses to continue an incremental transfer from a checkpoint, if it is interrupted. There are three options.- never—Transfers are always restarted from the beginning of a transfer and never from where they were before an interruption. This mode is useful if you must have the latest data on the destination.
- always—Transfers are always restarted if possible from where they were before an interruption. This mode is useful for copying large volumes.
- default—Transfers are restarted if they do not conflict with a scheduled transfer. This is the recommended option.
SnapMirror always restarts from where the transfer was before an interruption. However, it does not restart if the restart occurs after a scheduled transfer, because the scheduled transfer gives more up-to-date data than the restarted transfer.
|
| cksum= { none | crc32c } |
Selects the checksum algorithm that is used to protect SnapMirror transmitted data. |
| visibility_interval={xs | xm | xh} |
Determines the amount of time before an automatic Snapshot copy is
created on the source volume that is being replicated using synchronous or semi-synchronous SnapMirror. When replicating synchronously or
semi-synchronously, using SnapMirror, changes to the source volume
do not show immediately on the destination volume, even though the
changes have been replicated. The changes are shown only after the
source system takes an automatic Snapshot copy of the source
volume. This occurs every three minutes by default. You can change
the interval for automatic Snapshot copies, but performance can
degrade if you set smaller intervals because Snapshot copies are
taken more often. The smallest interval you can set is 30 seconds. Note: The s, m, and h suffixes specify seconds, minutes, and hours,
respectively.
|
| wsize=size |
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. Note: The TCP window size is specified in bytes.
|
| schedule |
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 to 23.
- 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:
8-17 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:
0-59/5Typing sync instead of the four space-separated fields specifies synchronous replication. For more information, see the na_snapmirror.conf(5) man page.
|
Example of snapmirror.conf file schedule entries
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.
Figure 1. snapmirror.conf schedule entry
Example of snapmirror.conf file entry with space character and double quotes in qtree name
The following snapmirror.conf file entry shows how qtree names with space character and double quotes must be specified. This entry indicates that data from the qtree vol/vol1/x y"z on systemA will be replicated to the qtree vol/vol2/x y"z on systemB.
"systemA:/vol/vol1/x y""z" "systemB:/vol/vol2/x y""z" - * * * *
Note: Qtree names with space character or double quotes might not work with previous versions of
Data ONTAP. Therefore, when reverting to a previous version of
Data ONTAP, you must check for compatibility.
Example specifying always restart
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
Example specifying default values for maximum speed and restart
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
Example specifying 15-minute interval updates during specific hours
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 might 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.
