Posts Tagged ‘snapmirror.conf’


July 7th, 2009

Table of Contents


snapmirror.conf – volume and qtree replication schedules and configurations




The /etc/snapmirror.conf file exists on the filer containing the mirror used for SnapMirror.

There are two types of lines in the configuration file: lines that define mirror relationships and lines that define connections to source filers to be used in the relationship definitions. Relationship definition lines are used to define the mirror relationships for destination volumes on this filer. Connection definition lines are optional and are used to specify specific network connections to the source volume and allow the specification of dual paths to the source volume.

Each relationship line of the file specifies the volume or qtree to be replicated, arguments for the replication, and the schedule for updating the mirror. You may only have one line for each destination volume or qtree. The maximum number of relationship entries supported is limited to 712. Any entry after this limit is ignored.

Each relationship entry of the /etc/snapmirror.conf file is a single line containing space-separated fields. The entry has this format:

source destination arguments schedule

If the source or destination field contains one or more space characters (on account of it including a qtree name with space(s)), then the field must be enclosed in double quotes. If the field value itself contains one or more double quotes, then each of these double quotes must be escaped by preceding it with an additional double quote.

The following list describes the fields in each entry:

source This is the name of the source host, and the volume name, or the path of the qtree to be mirrored. The name is specified as two colon-separated fields, as follows:



Note that the host field is not necessarily the hostname of the filer (unlike the first field of the destination entry). You can specify a network resolvable name, IP address or connection name. The host field can be considered a definition of how to reach the source over the network.

This is the hostname (must match the result of the hostname command) of the destination filer and the name of the destination volume or the path of the destination qtree. The name is specified as two colon-separated fields, as follows:



The name field must match the hostname of the destination filer (use the hostname function to check this).

These are a comma-separated list of arguments for the transfer. To specify no arguments, enter a dash (“-”) in this field. Each argument is specified as a key and a value pair, as follows:


Currently, there are the following argument keys:

cksum This controls which checksum algorithm is used to protect the data transmitted by SnapMirror. Currently supported values are "crc32c" and "none”.

The value for this argument specifies the maximum speed (in kilobytes per second) at which SnapMirror data is transferred over the network. The kbs setting is used to throttle network bandwidth consumed, disk I/O, and CPU usage. By default, the filer transfers the data as fast as it can. The throttle value is not used while synchronously mirroring.

tries The value for this argument specifies the maximum number of attempts that the destination will make to complete a scheduled snapmirror update. A retry will be attempted on the first minute after the previous attempt was abandoned. Notice that retries are only attempted for retry-able errors, and that some errors do not count as a retry. The tries setting is used to limit the number of retries, for instance to assure that backup transfers are started within a designated backup window, or else abandoned entirely until the next scheduled update. The syntax is "tries=N" or "tries=unlimited”, where N is greater or equal to 0, and N is less or equal to 1000000000. If this value is set to 0, the transfer is never started. If no try count is specified, the default is "unlimited”. Manually started transfers are never retried irrespective of the the value of this argument.

This controls the behavior of the SnapMirror scheduler with respect to restartability. If value is set to always, then an interrupted transfer will always restart, if it has a restart checkpoint and the conditions are the same as before the transfer was interrupted. If value is set to never, then an interrupted transfer will never restart, even if it has a restart checkpoint. By default, SnapMirror behaves like the always case, unless it has passed the next scheduled transfer time, in which case it will begin that scheduled transfer instead of restarting.

The value for this argument can be enable or disable. This option only applies to Qtree SnapMirror relationships. When the value is enable, SnapMirror will ignore files which have only their access times changed for incremental transfers. When the value is disable, SnapMirror will transfer metadata for all modified files. If not specified, the default is disable.

outstanding (deprecated)
This argument controls the performance versus synchronicity trade-off for synchronous mirrors. The value for this argument is a number followed by the suffixes: ops (operations), ms (milliseconds) or s (seconds). Setting a value less than 10s configures the mirror to run in fully synchronous mode. Setting a value greater than or equal to 10s configures the mirror to run in semi-synchronous mode. This argument is ignored for asynchronous mirrors. Please note that this is a deprecated option. Use the schedule field to specify the synchronous mode for the mirror.

wsize This sets the TCP window size to use for the connection. Due to how TCP negotiates window sizes, the size of the receive window will initially be large and gradually work its way down to the size specified.

The value for this argument is a number optionally followed by the suffixes: s (seconds), m (minutes) or h (hours). If a suffix is not specified, value is interpreted as seconds. This argument controls the amount of time before an automatic snapshot is created on the source volume that is synchronously mirrored. The value is the number of seconds between automatically created snapshots. The default value is 3 minutes. A small number here can negatively affect the performance of the mirror. This argument is ignored for asynchronous mirrors.

This is the schedule used by the destination filer for updating the mirror. It informs the SnapMirror scheduler when transfers will be initiated. The schedule field can contain the word sync to specify fully synchronous mirroring, semi-sync to specify semi-synchronous mirroring, or a cron-style specification of when to update the mirror. The cronstyle schedule contains four space-separated fields:

minute hour day-of-month day-of-week

Each field consists of one or more numbers or ranges. If a field contains more than one value, the values are separated from each other by a comma. A field consisting solely of an asterisk (“*”) is the same as a field enumerating all possible legal values for that field. A field consisting solely of a dash (“-”) represents a null value; any schedule with a dash in one of its fields will never run any scheduled transfers. Values in a field can take any of the following forms:




A value with a dash in it specifies a range; it is treated as containing all the values between first and last, inclusive. A range value with a slash specifies skips of step size in the range. For example, the value of the entry “0-23/4” would be the same as that of the entry “0, 4, 8, 12, 16, 20”.

minute Which minutes in each hour to update on. Values are from 0 to 59.

hour Which hours in the day to update on. Values are from 0 to 23.

Which days in the month to update on. Values are from 1 to 31.

Which days in the week to update on. Values are from 0 (Sunday) to 6 (Saturday).

Whenever the current time matches all the specified schedule fields, a transfer from the source to the destination will be invoked.

The other type of line allowed in this file is a connec_tion definition line. These lines define an alternate name for the source filer that can be used as the source host in the relationship lines. They are used to describe more specifically the parameters for the connection(s) to the source filer. SnapMirror supports the multi path specification for both asynchronous and synchronous mirrors.

Each connection definition is a single line giving a name to one or two pairs of IP addresses along with a mode of operation for the connection. The lines are specified in the following format:

name = mode( source_ip_addr1 , dest_ip_addr1 ) ( source_ip_addr2 , dest_ip_addr2 )

name This is the name of the connection you would like to define. This name is to be used as the source filer in relationship definitions.

mode The mode is optional and specifies the mode in which two IP address pairs will be used. Two modes are allowed multiplexing and failover mode and are specified by using the multi and failover keywords. If not specified, multiplexing mode is used.

The multiplexing mode causes snapmirror to use both paths at the same time. If one should fail, it will switch to use the remaining path only and use both again should the failing path be repaired.

Failover mode causes snapmirror to use the first path as the desired path and only use the second path should problems arise with the first path.

source_ip_addr1 source_ip_addr2 dest_ip_addr1 dest_ip_addr2
These are resolvable network names or IP addresses that define a path through the network between the source and the destination. The source addresses are the IP addresses of interfaces to use on the source and respectively for the destination. The pairing denotes a path from source to destination.


The following snapmirror.conf entry indicates that filer fridge’s qtree home, in volume vol2 will mirror qtree home, in volume vol1 from the filer toaster. Transfer speed is set at a maximum rate of 2, 000 kilobytes per second. The four asterisks mean transfers to the mirror are initiated every minute, if possible. (If a previous transfer is in progress at the minute edge, it will continue; a new transfer will be initiated at the first minute edge after the transfer has completed.)

  toaster:/vol/vol1/home fridge:/vol/vol2/home kbs=2000 * * * * 

The following snapmirror.conf entry is similar to the above example, except that it shows how qtree names with spaces and double quotes can be specified. This entry indicates that filer fridge’s qtree x y”z in volume vol2 will mirror qtree x y”z in volume vol1 from the filer toaster.

  “toaster:/vol/vol1/x y”../index.htm” “fridge:/vol/vol2/x y”../index.htm” kbs=2000 * * * * 

The following snapmirror.conf entry indicates that filer myfiler1’s volume home_mirror will mirror volume home via the myfiler0-gig interface. (The myfiler0-gig interface is whatever IP address myfiler1 can resolve that name to. In this case, it might be a gigabit ethernet link on filer myfiler0.) The mirror is updated at 9:30 a.m., 1:30 p.m., and 7:30 p.m., Monday through Friday. The asterisk means that the data replication schedule is not affected by the day of month; it is the same as entering numbers 1 through 31 (comma-separated) in that space. The dash in the argu_ments field indicates that both the kbs and restart arguments are set to default.

  myfiler0-gig:home myfiler1:home_mirror – 30 9, 13, 19 * 1, 2, 3, 4, 5 

The following snapmirror.conf entry makes transfers every half hour, with the first at 8:15 a.m., and the last at 6:45 p.m. The asterisks mean that the data replication schedule is not affected by the day of month or week; in other words, this series of transfers are initiated every day.

  filer1:build filer2:backup – 15, 45 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18 * * 

The following snapmirror.conf entry, between the docs qtree on dev and docs_bak on icebox, is kicked off on every Sunday, at 12:00 midnight.

  dev:/vol/dept/docs icebox:/vol/backup/docs_bak – 0 0 * 0 

The following snapmirror.conf entry, between the home and backup volume on icebox, is kicked off once every halfpast the hour between 7:30 a.m. and 9:30 p.m., and once at midnight.

  icebox:home icebox:backup – 30 0, 7-21 * * 

The following snapmirror.conf entry, between the db volumes on fridge-gig dev and icebox, is kicked off on every five minutes, starting at 0. (Note that fridge-gig is just a network interface name. In this case, it could be a gigabit ethernet link on fridge.)

  fridge-gig:db icebox:db – 0-55/5 * * * 

This can be extended to use the multiple path options and synchronous mirroring.

  fridge-con = failover(fridge-gig, icebox-gig)(fridge-slow, icebox-slow)   fridge-con:db icebox:db – sync 

This changes the relationship into synchronous mode and the connection specifies that we should use a gigabit ethernet path for the mirroring where only if that connection fails, use a slower network connection. Even if you would like to use one path from source to destination, it is a good idea to specify a connection line in your configuration file. This can reduce problems seen with name resolution affects on the relationship configuration line.


The number of concurrent replication streams are limited for each ONTAP platform. This limitation is put in order to restrict the overuse of resources and bandwidth on the source and destination of the streams. These limits do not scale with the capabilities of the platform, e.g. cpu, memory, networking, etc. The following tables give the maximum number of concurrent transfers that each platform may allow.

Personality: Default

  ====================   # Model   Maximum  #   #        Transfers #   ====================   |                  |   | FAS250      4    |   |__________________|   |                  |   | F810             |   | F820             |   | F825             |   | FAS920      8    |   | FAS270           |   | GF270            |   | GF825            |   |__________________|   |                  |   | F840             |   | F880             |   | FAS940           |   | FAS960     16    |   | GF940            |   | GF960            |   | GF980            |   |__________________| 
The above platforms have the same maximum concurrent transfer limit for each transfer type.

Personality: Default

  ========================================================   # Model     Volcopy                                    #   #           Sync SM                                    #   #           Legacy QSM                        QSM      #   #           Legacy SV  Legacy VSM   MP VSM    SV       #   #             Src       Src  Dst     Src      Src      #   #             Dst                    Dst      Dst      #   ========================================================   | FAS980                                               |   | FAS3020                                              |   | FAS3040                                              |   | FAS3050     16        16    16      50      64       |   | V3020                                                |   | V3040                                                |   | V3050                                                |   |______________________________________________________|   |                                                      |   | FAS3070     16        16    64      50      64       |   | V3070                                                |   |______________________________________________________|   |                                                      |   | FAS6030     24        24    24     100      96       |   | V6030                                                |   |______________________________________________________|   |                                                      |   | FAS6070     32        32    32     150     128       |   | V6070                                                |   |______________________________________________________|  

Personality: Nearstore
  ==============================================================================   # Model                                               Legacy QSM     QSM     #   #          Volcopy    Legacy VSM   MP VSM    Sync SM  Legacy SV      SV      #   #         Src  Dst    Src  Dst    Src  Dst    Src     Src  Dst     Src  Dst  #   #                                             Dst                            #   ==============================================================================   |                                                                            |   | R100                                                                       |   | R150     64   64     64   64     64   64     16     64   128     64   128  |   | R200                                                                       |   |____________________________________________________________________________|   |                                                                            |   | FAS3020  16   16     16   16     50  100     16     16    32     80    80  |   |____________________________________________________________________________|   |                                                                            |   | FAS3040  16   32     16   32     50  100     16     16    64    160   160  |   |____________________________________________________________________________|   |                                                                            |   | FAS3050  16   32     16   32     50  100     16     16    64    120   120  |   |____________________________________________________________________________|   |                                                                            |   | FAS3070  16   64     16   32     50  100     16     16   128    320   320  |   |____________________________________________________________________________|   |                                                                            |   | FAS6030  24   48     24   48    100  200     24     24    96    512   512  |   |____________________________________________________________________________|   |                                                                            |   | FAS6070  32   64     32   64    150  300     32     32   128    512   512  |   |____________________________________________________________________________|    VSM Src – Volume Snapmirror Source   VSM Dst – Volume Snapmirror Destination   QSM Src – Qtree  Snapmirror Source   QSM Dst – Qtree  Snapmirror Destination   SV  Src – Snapvault Source   SV  Dst – Snapvault Destination  


snapmirror , snapmirror.allow

Table of Contents

7-mode Manual Pages , , , ,

snapmirror.conf basics

April 4th, 2009

This search seems to come up quite a lot, so I thought I’d cover it quickly. I’m going to steer away from covering SnapMirror as a whole, and just look at the format of the snapmirror.conf file. I will also steer away from Synchronous SnapMirror as I’m not a huge fan, I prefer SyncMirror!

First, you can find it in /etc/snapmirror.conf. Edit it using either rdfile / wrfile (see “[cref basic-file-manipulation-on-a-filer]” for a bit more on these), or map to /vol/etc and edit them with your favourite text editor (but not Windows Notepad please!). Once you get used to the formatting, you’ll be writing these with your eyes closed! Having said that, I usually need to refer to something for reference!

The basic layout is…

source_filer:volume_name destination_filer:volume_name options min hour dom dow

This drops it down into very simple terms, a good reference to start with. The “volume_name” can of course be a QTree if you are doing qsm, but I will concentrate on VSM for now.

The options section is often left blank. Any blank entry from options through the schedule will be filled in with “-“. So if you are setting up SnapManager for Exchange or SQL, you would create a relationship with this setting, do a baseline, then get SMx to manage the replication. Leaving the option as a single “-” assumes you accept the default for all settings. If you define one setting, the others are assumed to stay the defaults.

The options you can choose from are…

  • “kbs=” to limit the transfer speeds to whatever number you define here. This is in kilobytes, so remember to convert it for WAN speeds.

Web Searches , , , , ,

SnapMirror Replication Scheduling Spreadsheet

February 21st, 2009

I created an Excel spreadsheet as I was tasked with creating a SnapMirror replication schedule for a customer that only had an 8meg line. The problem was that the replication would fail if more than 1 transferred happened at the same time. So I needed a way of calculating the rate of change, and designing the replication based on this.

The spreadsheet will calculate the snapmirror.conf schedule, but will also give you the commands to create, restrict and initialize the volumes.

General , , ,

This site is not affiliated or sponsored in anyway by NetApp or any other company mentioned within.