目录表
snapmirror – volume, and qtree mirroring
snapmirror {
on |
off }
snapmirror status [ options ] [ volume | qtree ... ]
snapmirror initialize [ options ] destination
snapmirror update [ options ] destination
snapmirror quiesce destination
snapmirror resume destination
snapmirror break [ options ] destination
snapmirror resync [ options ] destination
snapmirror destinations [ option ] [ source ]
snapmirror release source destination
snapmirror { store | retrieve } volume tapedevices
snapmirror use destination tapedevices
snapmirror throttle <n> destination
snapmirror abort [ options ] destination …
snapmirror migrate [ options ] source destination
The
snapmirror command is used to control SnapMirror, a method of mirroring volumes and qtrees. It allows the user to enable and disable scheduled and manual data transfers, request information about transfers, start the initializing data transfer, start an update of a mirror, temporarily pause updates to a mirror, break mirror relationships, resynchronize broken mirrors, list destination information, release child mirrors, store volume images to tape, retrieve volume images from tape, and abort ongoing transfers.
SnapMirror can be used to replicate volumes or qtrees. The processes and behaviors involved are slightly (and sometimes subtly) different between the various kinds of data mirroring.
The SnapMirror process is destination-driven. The snapmirror initialize command starts the first transfer which primes the destination with all the data on the source. Prior to the initial transfer, the destination must be ready to be overwritten with the data from the source; destination volumes must be restricted (see vol ), and destination qtrees must not yet exist.
For asynchronous mirrors, the destination periodically requests an update from the source, accepts a transfer of data, and writes those data to disk. These update transfers only include changes made on the source since the last transfer. The SnapMirror scheduler initiates these transfers automatically according to schedules in the snapmirror.conf file.
Synchronous mirrors will initially behave asynchronously, but will transition to synchronous mode at first opportunity. These mirrors may return to asynchronous mode on error (eg a network partition between the mirroring filers) or at the request of the user.
The snapmirror update command can be used to initiate individual transfers apart from the scheduled ones in snapmirror.conf .
After the initial transfer, the destination is available to clients, but in a read-only state. The status of a destination will show that it is snapmirrored (see aggr , vol , or qtree for more details on displaying the destination state).
To use the destination for writing as well as reading, which is useful when a disaster makes the source unavailable or when you wish to use the destination as a test volume/qtree, you can end the SnapMirror relationship with the snapmirror break command. This command changes the destination's status from snapmirrored to broken-off , thus making it writable. The snapmirror resync command can change a former destination's status back to snapmirrored and will resynchronize its contents with the source. (When applied to a former source, snapmirror resync can turn it into a mirror of the former destination. In this way, the roles of source and destination can be reversed.)
A filer keeps track of all destinations, either direct mirrors or mirrors of mirrors, for each of its sources. This list can be displayed via the snapmirror destinations command. The snapmirror release command can be used to tell a filer that a certain direct mirror will no longer request updates.
To save network bandwidth, tape can be used to prime a new mirror volume instead of the snapmirror initialize command. The snapmirror store command dumps an image of the source to tape. The snapmirror retrieve command restores a volume image from tape and prepares the volume for update transfers over the network. If multiple tapes are used to create a volume image, the snapmirror use command is used to instruct a waiting store or retrieve process to write output or accept input to/from a new tape device. The store and retrieve commands cannot be used with qtrees.
The snapmirror migrate command is used on an existing source and destination pair to make the destination volume a writable "mimic" of the source. The destination assumes the NFS filehandles of the source, helping the filer administrator to avoid NFS re-mounting on the client side.
The snapmirror.conf file on the destination filer's root volume controls the configuration and scheduling of SnapMirror on the destination. See snapmirror.conf for more details on configuration and scheduling of SnapMirror.
Access to a source is controlled with the snapmirror.access option on the source filer. See options and protocolaccess (8) for information on setting the option.
(If the snapmirror.access option is set to "legacy”, access is controlled by the snapmirror.allow file on the source filer's root volume. See snapmirror.allow for more details.)
SnapMirror is a licensed service, and a license must be obtained before the snapmirror command can be used. SnapMirror must be licensed on both source and destination filers. See license for more details.
SnapMirror is supported on regular vfilers, as well as the physical filer named vfiler0. Use vfiler context or vfiler run to issue snapmirror commands on a specific vfiler. See vfiler for details on how to issue commands on vfilers. The use of SnapMirror on vfilers requires a MultiStore license.
vfiler使用时，一些限制。 The vfiler must be rooted on a volume and SnapMirror sources and destinations cannot be qtrees in shared volumes. Tape devices and Synchronous SnapMirror are not supported on vfilers. For a qtree SnapMirror, the vfiler must own the containing volume of the Qtree.
Each vfiler has its own /etc/snapmirror.conf file in its root volume. SnapMirror can be turned on or off on a vfiler independently. SnapMirror commands issued on a vfiler can only operate on volumes or qtrees it has exclusive ownership of.
For backward compatibility, the physical filer (vfiler0) can operate on all volumes and all qtrees, even if they are owned by vfilers. It is highly recommanded, however, that all storage units (volumes and qtrees) be mirrored from either vfiler0 or the hosting vfiler, not both. When vfiler storage units are mirrored via vfiler0, leave snapmirror off on the vfiler.
The
snapmirror command has many subcommands. Nearly every command takes a
destination argument. This argument takes three different forms. The form used for a particular invocation depends on whether you're specifying a volume or a qtree.
Volumes are specified by their name:
vol1
Qtrees are specified by their fully-qualified path:
/vol/vol1/qtree
There is a special path that can be used to SnapMirror all the data in a volume which does not reside in a qtree. This path can only be used as a SnapMirror source, never a SnapMirror destination. The path is specified as:
/vol/vol1/-
All commands which don't say otherwise can take any of these forms as an argument.
The snapmirror subcommands are:
on
Enables SnapMirror data transfers and turns on the SnapMirror scheduler. This command must be issued before initiating any SnapMirror data transfers with the initialize , update , resync , store , or retrieve subcommands. This command also turns on the SnapMirror scheduler, which initiates update transfers when the time matches one of the schedules in the snapmirror.conf file. This command must be issued on the source side for the filer to respond to update requests from destinations.
off
Aborts all active SnapMirror data transfers and disables the commands which initiate new transfers ( initialize , update , resync , store , and retrieve ), and turns the SnapMirror scheduler off.
The on/off state of SnapMirror persists through reboots, and is reflected by the snapmirror.enable option. This option can be set off and on, and doing so has the exact same effect as the snapmirror on or snapmirror off commands.
status [ -l | -t | -q ] [ volume | qtree ... ]
报告所有源和/或目的地在这个文件管理器的SnapMirror关系的地位。 此命令还报告是否SnapMirror的是或关闭。 如果任何卷或配额树参数的命令，只有匹配的源或目标的SnapMirror关系将报道。 如果参数是无效的，不会有任何状态输出。
不带任何选项，每个关系中的地位短期形式显示出来。 这显示了本地端的关系状态，是否传送过程中（如果有的话，该转让的进展情况），和镜子滞后，即镜子背后的源滞后的时间。 这是一个简单的区别，当前时间和最后成功转移的源端的时间戳。 滞后时间将始终至少尽可能最后成功转移的时间，除非源和目标上的时钟不同步（在这种情况下，甚至有可能是负的）。
如果是- l选项，输出显示每个的SnapMirror关系的更详细的信息。 如果A *显示关系在短短的SnapMirror的状态命令的形式输出，然后多余的信息有关这种关系的特殊地位，是可见的，只有与- l选项。
如果给出了- t选项，输出显示之间的关系是积极的。 如果源或目标是参与一个关系被视为积极：
1。 或从网络的数据传输。 2。 读取或写入到磁带设备。 3。 等待更换磁带。
4。 执行本地磁盘上的处理或清理。
如果给出了- q选项，输出显示卷和配额树，停顿或静止。 见QUIESCE命令，下面，这意味着什么。
SnapMirror的状态的更多信息，请参见示例部分。
vfiler，status命令显示相关vfiler只的项。 在物理文件管理器，所有vfilers的积极转移条目显示。 只显示无效转让有关vfiler。 得到全面和更具可读性的SnapMirror传输列表的首选方法是运行vfiler运行* SnapMirror的地位 。 通过所有vfilers，并列出其转让的迭代器。
初始化 源 [- S] [- K 千字节 ] [- S src_snap] [- C create_dest_snap] [- W] 的目的地
通过网络启动的初始转移。 最初的转让无论是在网络上或从磁带需要更新转移之前可以发生。 必须在目标文件管理器发出初始化命令。 如果目标是一个卷，它必须受到限制（见卷如何检查和限制卷的信息）。 如果目标是配额树，它必须尚不存在（见配额树如何列出配额树的信息）。 如果配额树已经存在，它必须将其改名或删除（使用NFS或CIFS客户端），或SnapMirror的初始化配额树将无法正常工作。
如果SnapMirror的状态命令报告中止初次转让已重新启动检查点，初始化条命令将离开的地方重新开始传输。
- s选项指定源文件管理器和卷或配额树路径，在类似的格式des_吨ination参数。 源必须为在snapmirror.conf文件中的目的地的条目相匹配。 如果不匹配，操作打印一条错误消息并中止。 如果- S选项没有设置，使用的是源，在snapmirror.conf文件中的目的地的指定的。 如果没有这样的条目，操作打印一条错误消息并中止。
- k选项集数据通过网络传输的每秒千字节的最高速度。 它是用来扼杀磁盘，CPU和网络使用。 此选项只设置一个传输速度的最大值，它并不能保证转移会那么快。 如果这个选项没有设置，文件管理器传输数据，这在 snapmirror.conf文件中的关系（见snapmirror.conf）的KBS设置。 但是，如果不设置此选项，并没有这种关系在 snapmirror.conf 文件的KBS设置，文件管理器一样快，因为它可以传输数据。
- c选项只适用于一个配额树的初始化。 使用此选项，SnapMirror的命名create_dest_snap目的地后的初始化已成功完成（因此，它并没有竞争与任何持续更新）创建一个快照。 SnapMirror的不锁或删除此快照。create_dest_snap不能hourly.x，nightly.x，或weekly.x，因为这些名称是保留预定快照。
- s选项仅适用于一个配额树的初始化。 它指定名为src_snap的SnapMirror传输的配额树快照，而不是创建一个源快照和新的快照传送的配额树。 此选项是用来传输一个特定的快照的内容，例如，它可以将一个数据库在一个稳定的，一致的状态，而采取的快照。 SnapMirror的不锁或删除src_snap。src_snap不能hourly.x，nightly.x，weekly.x，snapshot_for_backup.x或snapshot_for_volcopy.x。
- w选项将导致该命令不返回，一旦最初的转让开始。 相反，它会等待，直到传输完成（或失败），此时将打印完成状态，然后返回。
更新[- S 源 ] [- K 千字节 ] [- S src_snap] [- C create_dest_snap] [- W] 的目的地
对于异步镜像，更新是立即开始从源头到目的地 ，更新的内容源的镜像。
对于同步镜像，快照创建源卷上变得可见目标卷的客户。
必须在目标文件管理器发出更新命令。
- S选项设置传送源 ， 更新工程，因为它为初始化 。
- k选项设置油门，在每秒千字节的转移，，用于更新相同，因为它为初始化 。
- c选项仅适用于配额树的更新。 使用此选项的SnapMirror目标create_dest_snap更新完成后，（因此，它并没有竞争与任何持续更新）创建一个快照。 SnapMirror的不锁或删除此快照。create_dest_snap不能hourly.x，nightly.x，或weekly.x，因为这些名称是保留预定快照。
- s选项仅适用于配额树的更新。 它指定名为src_snap的SnapMirror传输的配额树快照，而不是创建一个源快照和新的快照传送的配额树。 此选项是用来传输一个特定的快照的内容，例如，它可以将一个数据库在一个稳定的，一致的状态，而采取的快照。 SnapMirror的不锁或删除src_snap。src_snap不能hourly.x，nightly.x，weekly.x，snapshot_for_backup.x或snapshot_for_volcopy.x。
- w选项将导致该命令不返回一旦增量开始传输。 相反，它会等待，直到传输完成（或失败），此时将打印完成状态，然后返回。
静默 目的地
允许在建工程转让的目标完成后，新的转移是不允许启动。 将采取同步模式同步镜子。 更新此卷或配额树的任何进一步的请求将失败，直到SnapMirror的恢复命令适用于它。
此命令具有特殊的意义配额树目的地。 现正由SnapMirror的转移过程中修改的一个配额树的目的地将在它的变化。 这些变化将不会出口到NFS或CIFS客户。 但是，如果在此期间采取的一个快照，快照将包含配额树。静默的过渡内容，配额树，将带来一个过渡状态，通过整理或撤消转移的任何更改 。SnapMirror的状态可以报告是否一个配额树是静止或没有。 停顿过程可能需要一段时间才能完成，而SnapMirror的配额树的内容进行更改。 配额树是静止而采取的任何快照将包含一个出口NFS和CIFS客户的内容相匹配，配额树的形象。
恢复 的目标
简历传输到目的地 。 SnapMirror的恢复命令可用于中止正在进行的SnapMirror停顿或撤消先前完成的SnapMirror停顿 。 命令恢复的目的地从静止状态或静止停顿操作之前，不管它是什么。
打破[- F] 的目的地
打破通过一个snapmirrored目标变成一个正常的读/写卷或配额树一个的SnapMirror关系。 此命令必须在目标文件管理器发出。
- f选项势力之间snaplocked量关系的SnapMirror决裂 ，而不提示为构象。
此命令不会修改snapmirror.conf的文件。 任何预定转移到一个破碎的镜子将失败。
卷，此命令具有同等效力卷选项关闭命令snapmirrored，并会从卷中删除 snapmirrored选项。 fs_size_fixed音量选项，仍将上，它必须从量回收任何磁盘空间的SnapMirror可复制截断手动删除。 （这两卷选项的更多信息，请参见“选项”一节和卷）。
一个目的地配额树必须停顿，才可以被打破。
重新同步[- N] [- F] [- S 源 ] [- K 千字节 ] [- S src_snap] [- C create_dest_snap] [- W] 的目的地
重新同步前源断离的目的地，将在 snapmirrored状态的目标，并使其更新转移的准备。 必须在目标文件管理器发出resync命令。
resync命令，可能会导致对目标数据丢失。 因为它是有效地利用desti_ ñ ATION源副本，任何修改，取得突破后目标将被取消。
对于以前的镜像卷，resync命令有效执行最新的快照，这是共同的源和目标的目标的一个SnapRestore（见卷）。 在大多数情况下，这是最后的快照从源传输到目的地，但它可以是任何的SnapMirror复制的源和目的地的快照。 如果新的数据已写入到目标，因为最新的共同创建快照，该数据将丢失在resync操作。
对于以前的镜像配额树SnapMirror的SnapMirrorcreated从最新的目标卷上的快照文件系统的数据恢复。 与体积的情况下不同，它需要这最后一个快照，以便执行重新同步。
SnapRestore或配额树数据恢复完成后，resync命令启动更新传输。
- n选项报告resync命令的执行会做，但不执行命令。
- f选项强制不提示确认的情况下进行操作。
- S选项设置传送源 ，工程同步 ，因为它为初始化 。
- k选项设置油门，在千字节每秒的传输，， 工程同步，因为它为初始化。
- c选项仅适用于对一个配额树重新同步 。 有了这个选项的SnapMirror快照创建一个名为目标 create_dest_snap后重新同步传输完成（因此，它并没有竞争与任何持续更新） 。 SnapMirror的不锁或删除此快照。create_dest_snap不能hourly.x，nightly.x，或weekly.x，因为这些名称是保留预定快照。
- s选项仅适用于一个重新同步到配额树。 它指定名为src_snap的SnapMirror传输的配额树快照，而不是创建一个源快照和新的快照传送的配额树。 此选项是用来传输一个特定的快照的内容，例如，它可以将一个数据库在一个稳定的，一致的状态，而采取的快照。 SnapMirror的不锁或删除src_snap。src_snap不能hourly.x，nightly.x，weekly.x，snapshot_for_backup.x或snapshot_for_volcopy.x。
- w选项将导致该命令不返回，一旦重新同步开始传输。 相反，它会等待，直到传输完成（或失败），此时将打印完成状态，然后返回。 如果还指定了- n选项，这个选项没有效果。
目的地[- S] [ 来源 ]
列出这个文件管理器上的来源目前已知的所有目的地。 卷，该命令还列出任何级联目的地，这些都是直达目的地的副本的任何卷。 此命令将列出所有它知道的后裔。
- s选项包括在保留上为每个目标源卷的快照上市名。
如果指定了一个特定的源，该卷的唯一目的地将陆续上市。 源可以是一个卷的名称或配额树的路径。
释放 源文件管理器 ： 体积 | 文件管理器 ： 配额树 }
推荐的SnapMirror一定直接镜不再要求更新。
如果某一个目标是不再要求更新，你必须告诉的SnapMirror，以便将不再保留该目标的快照。 此命令将删除不再需要复制到该目的地的快照，并可以用来清理SnapMirror的突破后目标端 发出的SnapMirror，创建快照。
源参数，目标是要释放源卷或配额树。 Destination参数应目标Filer和目标卷的名称或目标文件管理器和目标配额树的路径。 从这个命令的参数设置为目的地的SnapMirror的命令输出，您可以使用一条线。
存储[- G 几何 ] 目的地tapedevices
转储tapedevices指定目标卷的形象。 这很像SnapMirror的初始化命令，而是从源卷到磁带设备。 您可以使用磁带和检索命令，任何限制卷上执行初始，吸转移。
使用- g选项上的SnapMirror存储优化为特定目标的传统卷磁带。 几何参数是一个字符串，它描述的预期目标的传统卷几何。 它可以收购上使用传统的卷SnapMirror的检索- g命令。 使用此选项可以SnapMirror的检索性能显着提高。 - g选项是唯一与传统卷的有效。
只有卷可以存储或从磁带中检索。 配额树不能被存储或从磁带中检索。
这个命令的 tapedevices领域是一个有效的磁带设备commaseparated的清单。 磁带设备名的更多信息，请参阅磁带。
Tape devices are not supported on vfilers. This command runs on the physical filer only.
retrieve { destination tapedevices | -h tapedevice | -g volume }
Restores the image on the tapedevices to the desti_ n ation specified. This is much like the snapmirror initialize command, but from a tape device to a destination volume. If destination is part of a SnapMirror relationship with the source volume from the store performed to create these tapes, the two volumes can be mirrored as if volume had been primed via an initial transfer over the network.
You can use the -h flag to read the header off of the single tapedevice specified. This will provide information on the tape source and index.
The -g option provides the volume geometry string for the specified volume . This string, when given to the snapmirror store -g command, will dramatically improve snapmirror retrieve performance to this volume .
The tapedevices field of this command is a commaseparated list of valid tape devices. See tape for more information on tape device names.
This feature only works for volumes. Qtrees cannot be stored to or retrieved from tape.
Tape devices are not supported on vfilers. This command runs on the physical filer only.
use destination tapedevices
Continues a tape transfer to destination with the specified tapedevices .
If a store or retrieve operation runs out of tape, it will prompt the user to provide another tape. After another tape has been provided, the use command is invoked to tell the SnapMirror process where to find it.
The destination field is specified by filer : volume in the case of retrieve , and filer : tapedevices in the case of store .
The tapedevices field of this command is a commaseparated list of valid tape devices. See tape for more information on tape device names.
Tape devices are not supported on vfilers. This command runs on the physical filer only.
throttle <n> destination
Modifies the throttle value for the snapmirror transfer to the destination with the specified value in kilobytes per second. This sets the maximum speed at which the data is trasfered over the network for the current transfer. A value of zero can be used to disable throttling.
The new value will be used only for the current transfer. The next scheduled transfer will use the kbs value specified in the snapmirror.conf file. If the value for the kbs option in the snapmirror.conf is changed while transfer is going on, then the new value will take effect within two minutes.
abort [ -h ] destination …
Aborts currently executing transfers to all specified destination s. It may take a few minutes for a transfer to clean up and abort. This does not stop new updates from starting. If you are interested in stopping further updates use the snapmirror quiesce command.
Any transfer with a restart checkpoint (you can view this via the snapmirror status command) may be restartable; to clear out the restart checkpoint and force any subsequent transfer to start with a fresh snapshot on the source, you can use abort -h on the destination. The -h option specifies that this is a hard abort; the restart checkpoint will be cleared out in addition to the transfer being stopped.
The abort command can be invoked from either the source or the destination filer. However, the -h option is only effective on the destination filer. The option will be ignored if specified on the source filer.
migrate [ -n ] [ -f ] [ -k kilobytes ] [ source_filer :] source_volume [ destination_filer :] desti t ion_volume
snapmirror migrate is run on the filer which holds the source volume. It must be run on two volumes which are already the source and destination of a SnapMirror pair.
snapmirror migrate will transfer data and NFS filehandles from the source_volume to the desti t ion_filer 's destination_volume (if no filer is specified, then migrate assumes the volume is local). If source_filer is specified, then the migrate destination will use that network interface to connect up to the source filer for the transfer of information.
The first thing migrate will do is check the source and destination sides for readiness. Then, it will stop NFS and CIFS service to the source. This will prevent changes to the source volume's data, which will make it appear to clients as though nothing has changed during the migration. It will run a regular SnapMirror transfer between the two volumes. At the end of the transfer, it will migrate the NFS filehandles, bring the source offline, and make the destination volume writable.
The -n flag will make a test run; that is, it will run all the pre-transfer checks, but stop short of transferring data. The -f flag will not prompt the user for confirmation. The -k flag will throttle the speed at which the transfer runs (at kilobytes kilobytes per second), in a manner similar to that used in the snapmirror update command.
If one filer in a cluster failover pair goes down, any active transfers are aborted. The SnapMirror scheduler and services will continue for volumes on the downed filer. The configurations of the SnapMirror relationships are taken from the downed filer's
snapmirror.access option or
snapmirror.allow and
snapmirror.conf files.
Here are a few examples of use of the
snapmirror command:
The following example turns the scheduler on and off:
toaster> snapmirror on toaster> snapmirror status Snapmirror is on. toaster> snapmirror off toaster> snapmirror status Snapmirror is off. toaster>
The following example presents the
snapmirror status with transfers running. Two are idle destinations (both from fridge); one of these has a restart checkpoint, and could be restarted if the setup of the two volumes has not changed since the checkpoint was made. The transfer from
vol1 to
arc2 has just started, and is in the initial stages of transferring. The transfer from toaster to icebox is partially completed; here, we can see the number of megabytes transferred.
toaster> snapmirror status Snapmirror is on. Source Destination State Lag Status fridge:home toaster:arc1 Snapmirrored 22:09:58 Idle toaster:vol1 toaster:arc2 Snapmirrored 01:02:53 Transferring toaster:vol2 icebox:saved Uninitialized – Transferring (128MB done) fridge:users toaster:arc3 Snapmirrored 10:14:36 Idle with restart checkpoint (12MB done) toaster>
The following example presents detailed status for one of the above snapmirror relationships specified as argument to the command. It displays extra information about base snapshot, transfer type, error message, and last transfer, etc.
toaster> snapmirror status -l arc1 Snapmirror is on. Source: fridge:home Destination: toaster:arc1 Type: Volume Status: Idle Progress: – State: Snapmirrored Lag: 22:09:58 Mirror Timestamp: Wed Aug 8 16:53:04 GMT 2001 Base Snapshot: toaster(0001234567)_arc1.1 Current Transfer Type: – Current Transfer Error: – Contents: Replica Last Transfer Type: Initialize Last Transfer Size: 1120000 KB Last Transfer Duration: 00:03:47 Last Transfer From: fridge:home
The following example shows how to get all the volumes and qtrees that are quiesced or quiescing on this filer with the status command.
filer> snapmirror status -q Snapmirror is on. vol1 has quiesced/quiescing qtrees: /vol/vol1/qt0 is quiesced /vol/vol1/qt1 is quiescing vol2 is quiescing
The following example starts writing an image of
vol1 on toaster to the tape on tape device
rst0a and continues with the tape on
rst1a . When the second tape is used up, the example shows how to resume the store using a new tape on
rst0a .
toaster> snapmirror store vol1 rst0a, rst1a snapmirror: Reference Snapshot: snapmirror_tape_5.17.100_21:47:28 toaster> SNAPMIRROR: store to toaster:rst0a, rst1a has run out of tape. toaster> snapmirror use toaster:rst0a, rst1a rst0a toaster> Wed May 17 23:36:31 GMT [worker_thread:notice]: snapmirror: Store from volume 'vol1′ to tape was successful (11 MB in 1:03 minutes, 3 tapes written).
The following example retrieves the header of the tape on tape device
rst0a . It then retrieves the image of
vol1 from the tape on tape device
rst0a .
toaster> snapmirror retrieve -h rst0a Tape Number: 1 WAFL Version: 12 BareMetal Version: 1 Source Filer: toaster Source Volume: vol0 Source Volume Capacity: 16MB Source Volume Used Size: 11MB Source Snapshot: snapmirror_tape_5.17.100_21:47:28 toaster> toaster> snapmirror retrieve vol8 rst0a SNAPMIRROR: retrieve from tape to toaster:vol8 has run out of tape. toaster> snapmirror use toaster:vol8 rst0a SNAPMIRROR: retrieve from tape to toaster:vol8 has run out of tape. toaster> snapmirror use toaster:vol8 rst0a toaster> snapmirror status Snapmirror is on. Source Destination State Lag Status toaster:rst1a, rst0a toaster:dst1 Unknown – Transferring (17MB done) toaster> Wed May 17 23:54:29 GMT [worker_thread:notice]: snapmirror: Retrieve from tape to volume 'vol8′ was successful (11 MB in 1:30 minutes).
The following example examines the status of all transfers, then aborts the transfers to
volm1 and
volm2 , and checks the status again. To clear the restart checkpoint,
snapmirror abort is invoked again.
toaster> snapmirror status Snapmirror is on. Source Destination State Lag Status fridge:home toaster:volm1 Uninitialized – Transferring (10GB done) fridge:mail toaster:volm2 Snapmirrored 01:00:31 Transferring (4423MB done) toaster> snapmirror abort toaster:volm1 volm2 toaster> snapmirror status Snapmirror is on. Source Destination State Lag Status fridge:home toaster:volm1 Snapmirrored 00:01:25 Idle fridge:mail toaster:volm2 Snapmirrored 01:03:11 Idle with restart checkpoint (7000MB done) toaster> snapmirror abort toaster:volm2 toaster> snapmirror status Snapmirror is on. Source Destination State Lag Status fridge:home toaster:volm1 Snapmirrored 00:02:35 Idle fridge:mail toaster:volm2 Snapmirrored 01:04:21 Idle
The following example examines the status of all transfers, then aborts the transfers to
volm1 and
volm2 with the
-h option and checks the status again. No restart checkpoint is saved.
toaster> snapmirror status Snapmirror is on. Source Destination State Lag Status fridge:home toaster:volm1 Uninitialized – Transferring (10GB done) fridge:mail toaster:volm2 Snapmirrored 01:00:31 Transferring (4423MB done) toaster> snapmirror abort -h toaster:volm1 toaster:volm2 toaster> snapmirror status Snapmirror is on. Source Destination State Lag Status fridge:home toaster:volm1 Snapmirrored 00:02:35 Idle fridge:mail toaster:volm2 Snapmirrored 01:04:21 Idle
Here is an example of the use of the
snapmirror migrate command:
toaster> snapmirror migrate home mirror negotiating with destination….
This SnapMirror migration will take local source volume home and complete a final transfer to destination toaster:mirror using the interface named toaster. After that, open NFS filehandles on the source will migrate to the destination and any NFS filehandles open on the destination will be made stale. Clients will only see the migrated NFS filehandles if the destination is reachable at the same IP addresss as the source. The migrate process will not take care of renaming or exporting the destination volume.
As a result of this process, the source volume home will be taken offline, and NFS service to this filer will be stopped during the transfer. CIFS service on the source volume will be terminated and CIFS will have to be set up on the destination.
Are you sure you want to do this? yes nfs turned off on source filer performing final transfer from toaster:home to mirror…. (monitor progress with “snapmirror status”) transfer from toaster:home to mirror successful starting nfs filehandle migration from home to mirror source volume home brought offline source nfs filehandles invalidated destination toaster:mirror confirms migration migration complete toaster> vol status Volume State Status Options root online normal root, raidsize=14 mirror online normal home offline normal toaster> vol rename home temp home renamed to temp you may need to update /etc/exports toaster> vol rename mirror home mirror renamed to home you may need to update /etc/exports toaster> exportfs -a
If a source volume is larger than the replica destination, the transfer is disallowed.
Notes on the snapmirror migrate command:
The migrate command is only a partial step of the process. It is intended to work when an administrator desires to move the data of one volume to another, possibly because they want to move to a new set of disks, or to a larger volume without adding disks.
We intend that migrate be run in as controlled an environment as possible. It is best if there are no dumps or SnapMirror transfers going on during the migration.
The clients may see stale filehandles or unresponsive NFS service while migrate is running. This is expected behavior. Once the destination volume is made writable, the clients will see the data as if nothing has happened.
migrate will not change exports or IP addresses; the new destination volume must be reachable in the same way as the source volume once was.
CIFS service will need to be restarted on the migrate destination.
Here are SnapMirror-related options (see options , protocolaccess , snapmirror , and snapmirror.allow for details on these options):
snapmirror.access
Controls SnapMirror access to a filer.
snapmirror.checkip.enable
Controls SnapMirror IP address checking using snapmirror.allow .
snapmirror.delayed_acks.enable
Controls a SnapMirror networking option.
replication.volume.transfer_limits
Controls increased stream counts. This option is provided to revert stream counts to legacy limits.
replication.volume.reserved_transfers
Guarantees that specified number of volume SnapMirror source/destination transfers always start. This option will reduce the maximum limit on all other transfers types and will be equivalent to maximum number of transfers possible.
snapmirror.enable
Turns SnapMirror on and off. SnapMirror can only be enabled on vfilers which are rooted on volumes.
snapmirror.log.enable
Turns SnapMirror logging on and off.
replication.volume.use_auto_resync
Turns auto resync functionality on and off for Synchronous SnapMirror relations. This option if enabled on Synchronous SnapMirror, destination will update from the source using the latest common base snapshot deleting all destination side snapshots newer than the common base snapshot.
Here are SnapMirror-related volume pseudo-options (see vol for more details):
snapmirrored
Designates that the volume is read-only.
fs_size_fixed
Effectively truncates the filesystem on the destination volume to the size of the source.
Options snapmirror.access , snapmirror.checkip.enable , and snapmirror.enable can be manipulated independently on a per-vfiler basis.
/etc/snapmirror.allow This file controls SnapMirror's access to a source filer. See snapmirror.allow , for details.
/etc/snapmirror.conf
This file controls SnapMirror schedules and relationships. See snapmirror.conf for details.
/etc/log/snapmirror
This file logs SnapMirror activity. See snapmirror for details.
aggr license options qtree vol tape(4) protocolaccess(8) snapmirror(5) snapmirror.allow(5) snapmirror.conf(5)
目录表
Read more... (6038 words, estimated 24:09 mins reading time) 
