Home > Web Searches > snapmirror.conf basics

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.
  • “restart=” to set how a transfer is transferred and how it is resumed when it suffers a communication failure. “never” defines to always start the SnapMirror from the beginning of the transfer, and never set a checkpoint. “always” will try to resume from a checkpoint during the transfer. “default” means that they are updated and checkpointed providing it doesn’t conflict with a schedule.

If you need to set both these options, then separate them with a comma, but not a space. If you set one, but not the other, the other is assumed to be the default.

Schedules can be defined in a variety of ways…

  • Simple numbers, or comma delimited numbers. On a hourly schedule, “0” for midnight or “0,12” for midnight and noon.
  • Timeframes. You can set to take snapshots during a period of time. “8-18″ may be used to set on an hour schedule to set during 8am and 6pm for office hours.
  • A mix of timeframs and numbers. “4,8-18,22″ to do a replica at 4am, then during office hours, and then again at 10pm.
  • Frequency. So if you want to set every three hours during the day, “0-23/3″. Perhaps more commonly used, every 5 minutes “0-59/5″

One thing to watch out for is if you are looking for vague scheduling. So perhaps every midnight, or every Monday, you might do one of the following…

filer:vol filer:vol – * * * 1
filer:vol filer:vol – * 0 * *

The first will actually run every single minute of every hour of every Monday (but no other time). The second will not run an update every hour, but infact run an update every minute between midnight and 00:59. The * is not a default, so if you want midnight, don’t forget to include 0 minutes past the hour! However if you want to run a schedule every Monday, you need to make sure the dom is left as a *, or it’ll only ever schedule if the Monday is on x day of the month! So always try review your schedules.

A nice little trick is setting up multi-pathing for SnapMirror. Out of the box SnapMirror will only really be able to use one path. By setting up SnapMirror with multiple paths you can make full use of what bandwidth you have. This is really useful if you are doing a large baseline and the two systems and in the same datacentre.

At the top of the snapmirror.conf file, declare the following…

name = mode (src_filer1, dest_filer1) (src_filer2, dest_filer2)

The “name” is the connection you want to refer to, which would then be used everytime you define a replica schedule instead of the source filer name. The mode would be defined as “multi” or “failover”.

For as an example, I want to multi-path from filer1 to filer2. Both filers have 2 VIFs defined that use separate paths between the systems (vif1, vif2). To define this, I would declare this at the top of my snapmirror.conf with something like…

filer1 = multi (filer1_vif1, filer2_vif1) (filer1_vif2, filer2_vif2)

One last thing that is very important. When you are setting up SnapMirrors for the first time, make sure you have a console open to both to the primary and the secondary systems. A lot of errors get displayed to the console, and so it makes it very easy to troubleshoot. Some errors are also only displayed obviously on one end of the relationship, so it is useful to have both open.

For reference I would strongly recommend reading through the “Data Protection: Online Backup and Recovery Guide” available on the NOW site  (Section 4, page 77 with the ONTAP version). There should be a Red Book version of this also. This is a great guide and covers almost every area of SnapMirror that you should need to know.

Web Searches , , , , ,

  1. No comments yet.
  1. No trackbacks yet.

This site is not affiliated or sponsored in anyway by NetApp or any other company mentioned within.
%d bloggers like this: