Library Table of Contents Index Previous Next Comments

Defining source and destination through snapmirror.conf

What the snapmirror.conf file does  Top

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.

How to distribute an snapmirror.conf file  Top

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. Each time the file is read, a warning message is displayed for each line that is ignored.

When changes to the snapmirror.conf file take effect  Top

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.

Creating and editing the snapmirror.conf file  Top

To create or edit the /etc/snapmirror.conf file, complete the following steps.

Step

Action

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
When you use a qtree as a source, you do not create another qtree to serve as the destination. SnapMirror automatically creates one for you, using the name you specify. However, you must specify the name of the qtree destination in the volume where you want it to be placed, either in the /etc/snapmirror.conf file or in the snapmirror initialize command.

Note
Do not specify more than 254 destination qtrees for any one volume in your /etc/snapmirror.conf file entries.

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
The data in /vol/source_volume/- qtree can only be a SnapMirror source, never a destination. That is, after you create the /- qtree, you can copy data from it to another qtree you name, but you cannot copy data to it from another qtree.

4

Save edits to the file.

snapmirror.conf file entry syntax  Top

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:

parameter

description

src_filer

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.

Example

Assume 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.

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_filer

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.

Example

If the name of the destination filer is filerA, enter filerA in the dest_filer 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.

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

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 (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:

    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/5

Example of snapmirror.conf schedule entries  Top

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.

Additional snapmirror.conf examples  Top

Example setting maximum update speed

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.

Example specifying always restart

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
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.

filerA:vol0 filerA: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:

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.

What restarts and retries are  Top

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.

Library Table of Contents Index Previous Next Comments