You can use the snapmirror command on a nondefault vFiler unit in the same way as you do on a storage system. You can perform SnapMirror operations on a vFiler unit only when a vFiler unit has a volume as root storage resource. However, there are some exceptions.
The exceptions are as follows:
- Qtree SnapMirror is only supported for qtrees inside volumes owned by a vFiler unit.
- Qtree SnapMirror is only supported if a vFiler unit is rooted on a volume.
- Tape devices are not supported.
- SnapMirror sources and destinations cannot be qtrees in shared volumes.
- Synchronous SnapMirror is not supported.
For more information, see the na_snapmirror(1) man page.
Additionally, SnapMirror in a MultiStore context has the following features:
- The feature can be turned on and off independently on each vFiler unit.
- The snapmirror.access, snapmirror.checkip.enable, and snapmirror.enable options can be managed independently on each vFiler unit.
- Each vFiler unit has its own snapmirror.conf file in the /etc directory.
- A nondefault vFiler unit can only operate on the volumes and qtrees the vFiler unit owns.
- vFiler units do not require additional SnapMirror licenses and they use the same license as the storage system.
- SnapMirror relationships established between vFiler units are maintained during vFiler unit migration.
- SnapMirror destination updates are supported on both the hosting storage system and the vFiler unit.
Note: SnapMirror relationships between vFiler units and all the Snapshot copies in vFiler units are destroyed before a revert operation.
When specifying a path name in the/etc/snapmirror.conf file, ensure that you use the storage system name, and not the vFiler unit name. For more information, see the na_snapmirror.conf(5) man page.