Manual Pages


Table of Contents

NAME

na_snapvault - disk-based data protection

SYNOPSIS ON THE SECONDARY

snapvault start [ options ] secondary_qtree

snapvault modify [ options ] secondary_qtree

snapvault update [ options ] secondary_qtree

snapvault stop [-f] secondary_qtree

snapvault prerevert [-f]

snapvault snap sched [-f] [-x] [-o options ] [volume [snapname [schedule]]]

snapvault snap unsched [-f] [-d] [volume [snapname]]

snapvault snap create [ -o options ] volume snapname

snapvault snap retain [-f] volume snapname count{d|m|y}

snapvault snap preserve volume snapname [ tagname ]

snapvault snap unpreserve volume snapname { [ tagname ] [ -all ] }

snapvault snap preservations volume [ snapname ]

snapvault abort { [-f] [-h] [dst_node:]dst_path | -s vol_ume snapname }

snapvault status { [ options ] [ path ] | -s [volume [snapname]] | -c [qtree] | -b [volume] }

snapvault release secondary_qtree pri_mary_node:restored_qtree

snapvault destinations [options] [[secondary_node:]sec_ondary_qtree]

SYNOPSIS ON THE PRIMARY

snapvault snap sched [ -o options ] [volume [snapname [schedule]]]

snapvault snap unsched [-f] [-d] [volume [snapname]]

snapvault snap create [ -o options ] volume snapname

snapvault abort [-f] [-h] [dst_node:]dst_path

snapvault status { [ options ] [ path ] | -s [volume [snapname]] }

snapvault release primary_path secondary_node:sec_ondary_qtree

snapvault restore [ options ] -S secondary_node:sec_ondary_path primary_path

snapvault destinations [options] [[primary_node:]primary_path]

DESCRIPTION

The snapvault command is used to configure and control SnapVault, a product for protecting data against loss and preserving old versions of data. SnapVault replicates data in primary system paths to qtrees on a SnapVault secondary node. A node can act as a primary, a secondary, or both, depending on its licenses. The primary system can either be a node or an open system with a SnapVault agent installed on it. When the primary system is a node, the path to be replicated can be a qtree, non-qtree data on a volume, or a volume path. The SnapVault secondary manages a set of snapshots to preserve old versions of the data. The replicated data on the secondary may be accessed via NFS or CIFS just like regular data. The primary nodes can restore qtrees directly from the secondary.

NOTE: Although data sets other than individual qtrees may be replicated from primary nodes, users should be aware that the snapvault restore command on a primary node will always restore to a primary qtree regardless whether the original data set was a qtree, non-qtree data, or an entire primary volume.

The snapvault command has a number of subcommands. The set of subcommands differs on the primary and secondary.

On the primary, the subcommands allow users to configure and manage a set of snapshots for potential replication to the secondary, to abort replication transfers to the secondary, to check status, to restore data from the secondary, and to release resources when a primary qtree will no longer be replicated to a secondary.

On the secondary, the subcommands allow users to configure and manage the replication of primary paths to secondary qtrees, to configure and manage the snapshot schedules which control when all the qtrees in a secondary volume are updated from their respective primary paths and how many snapshots to save, to abort transfers, to check status, and to release resources preserved to restart backups from a restored qtree.

On an appliance which is both a primary and a secondary, all the subcommands and options are available. However, mixing primary and secondary data sets within the same volume is strongly discouraged, since the synchronization delays inherent in secondary-side snapshot schedules will interfere with primary-side snapshot schedules.

SnapVault is built upon the same logical replication engine as qtree snapmirror. (See na_snapmirror(1) for more details on snapmirror.) An initial transfer from a primary data set to a secondary qtree replicates and thereby protects all the data in the primary data set. Thereafter, on a user-specified schedule, the SnapVault secondary contacts the primaries to update its qtrees with the latest data from the primaries. After all the updates are complete, the secondary creates a new snapshot which captures and preserves the contents of all the newly updated qtrees. For their part, the primaries create snapshots according to a user-defined schedule. When the secondary contacts the primary, it transfers data from one of these primary-created snapshots. The secondary qtrees are read-only.

There are three steps to configure SnapVault. The first is basic configuration: licensing, enabling, setting access permissions, and (only for nodes which will have SnapLock secondary volumes) configuring the LockVault log volume. The SnapVault secondary and primary are separately licensed and require separate sv_ontap_sec and sv_ontap_pri licenses (see na_license(1) for details). However, both may be licensed together. To enable SnapVault on the primaries and secondaries, use the options command to set the snapvault.enable option to on (see na_options(1) for details). To give the SnapVault secondary permission to transfer data from the primaries, set the snapvault.access option on each of the primaries. (see na_protocolaccess(8) for details). To give primaries permission to restore data from the secondary, set the snapvault.access option on the secondary. To configure the LockVault log volume (only for nodes which will have SnapLock secondary volumes), set the snapvault.lockvault_log_volume option on the secondary.

The second step is to configure the primary paths to be replicated to secondary qtrees. This is done on the secondary. The snapvault start command both configures a primary_path-secondary_qtree pair and launches the initial complete transfer of data from the primary to the secondary. The snapvault status command reports current status for the qtrees. The snapvault status -c command reports the qtree configurations. The snapvault modify command changes the configuration set with the snapvault start command.

The third configuration step is to establish the SnapVault snapshot schedules on the primaries and the secondary with the snapvault snap sched command. A snapshot schedule in a volume creates and manages a series of snapshots with the same root name but a different extension such as sv.0, sv.1, sv.2, etc. (For snapshots on SnapLock secondary volumes, the extensions are representations of the date and time the snapshot was created rather than .0, .1, etc.). The primaries and secondary must have snapshot schedules with matching snapshot root names. On the secondary, the -x option to the snapvault snap sched command should be set to indicate that the secondary should transfer data from the primaries before creating the secondary snapshot. If -x is set, when the scheduled time arrives for the secondary to create its new sv.0 (or sv.yyyymmdd_hhmmss_zzz for SnapLock volumes) snapshot, the secondary updates each qtree in the volume from the sv.0 snapshot on the respective primary. Thus, the primaries and secondaries need snapshot schedules with the same base snapshot names. However, snapshot creation time and the number of snapshots preserved on the primary and secondary may be different.

In normal operation, qtree updates and snapshot creation proceed automatically according to the snapshot schedule. However, SnapVault also supports manual operation. The snapvault update command on the secondary initiates an update transfer from the primary to the secondary for an individual qtree. The snapvault snap create command begins snapshot creation just as if the scheduled time had arrived. On the secondary, if the -x option for the snapshot schedule is set, the secondary will contact the primaries to begin update transfers for all the qtrees in the volume, just as it would if the scheduled time had arrived.

If an entire primary qtree needs to be restored from an older version available on the secondary, the user can use the snapvault restore command on the primary. If an existing primary qtree needs to be reverted back to an older version available on the secondary, the user can use the snapvault restore -r command on the primary. The primary qtree will be read-only until the restore transfer completes, at which time it becomes writable. After a restore, the user may choose to resume backups from the restored qtree to the secondary qtree from which it was restored. In this case, the user should issue the snapvault start -r command on the secondary. If not, the user should tell the secondary that the snapshot used for the restore is not needed to resume backups by issuing the snapvault release command on the secondary. If the user does not issue one of these two commands, a snapshot will be saved on the secondary indefinitely.

SnapVault is supported on regular vfilers, as well as the physical node named vfiler0. Use vfiler context or vfiler run to issue SnapVault commands on a specific vfiler. See na_vfiler(1) for details on how to issue commands on vfilers. The use of SnapVault on vfilers requires a MultiStore license.

When used on a vfiler, a few restrictions apply. The vfiler must be rooted on a volume. In order to run any SnapVault operations on qtrees, the vfiler must have exclusive ownership of the volume containing the qtrees.

SnapVault can be turned on or off on a vfiler independently. SnapVault commands issued on a vfiler can only operate on qtrees it has ownership of. Furthermore, the vfiler must have exclusive ownership of the hosting volume.

For backward compatibility, the physical node (vfiler0) can operate on all qtrees, even if they are owned by vfilers. It is highly recommended, however, that all qtrees be backed up from either vfiler0 or the hosting vfiler, not both. When vfiler storage units are backed up via vfiler0, leave snapmirror off on the vfiler.

USAGE

The snapvault subcommands are:

start [ -r ] [ -k n ] [ -t n ] [ -w ] [-p {inet | inet6 unspec}] [ -o options ] [ -S [primary_node:]primary_path ] secondary_qtree

options
is opt_name=opt_value[[,opt_name=opt_value]...]

Available on the secondary only. Configures the secondary to replicate primary_path on primary_node to secondary_qtree on the secondary. The secondary qtree is specified by a path such as /vol/vol3/my_qtree. The primary_path can be a qtree, represented in a similar way; it can refer to the set of non-qtree data on a volume, represented by a path such as /vol/vol3/-; or it can refer to the contents of the entire volume, including all qtrees, by a path such as /vol/vol3. After configuring the qtree, the secondary begins a full baseline transfer from the primary to initialize the qtree unless the qtree has already been initialized. The command may also be used to restart baseline transfers which were aborted.

The -k option sets the maximum speed at which data is transferred in kilobytes per second. It is used to throttle disk, CPU, and network usage. If this option is not set, the node transmits data as fast as it can. The setting applies to the initial transfer as well as subsequent update transfers from the primary.

The -t option sets the number of times that updates for the qtree should be tried before giving up. The default is 2. When the secondary starts creating a snapshot, it first updates the qtrees in the volume (assuming the -x option was set on the snapshot schedule). If the update fails for a reason such as a temporary network outage, the secondary will try the update again one minute later. This option says how many times the secondary should try before giving up and creating a new snapshot with data from all the other qtrees. If set to 0, the secondary will not update the qtree at all. This is one way to temporarily disable updates to a qtree.

The -w option causes the command not to return once the baseline transfer starts. Instead, it will wait until the transfer completes (or fails), at which time it will print the completion status and then return.

The -p option is used for selecting the IP connection mode when the SnapVault secondary contacts the primary for transfers. The value for this argument can be inet, inet6 or unspec.

When the value is inet6, the connection between the primary and secondary will be established using IPv6 addresses only. If there is no IPv6 address configured for the primary, then the connection will fail. When the value is inet, the connection between primary and secondary will be established using IPv4 addresses only. If there is no IPv4 address configured on the primary, then the connection will fail. When this argument is not specified, then the connection will be tried using both IPv6 and IPv4 addresses. inet6 mode will have higher precedence than inet mode. If a connection request using inet6 mode fails, SnapVault will retry the connection using inet mode.

This option is not meaningful when an IP address is specified instead of a hostname. If the IP address format and connection mode doesn't match, the operation prints an error message and aborts.

The -S option specifies the primary node and path. It must be given the first time to configure the qtree. It is optional when restarting an initial transfer for a previously configured qtree.

The -r option tells the secondary to restart updates from a different primary path. Most often, this command will be used after a snapvault restore to tell the secondary to restart updates from a qtree that was previously restored from the secondary to a primary. It may also be used after a primary data set is migrated to a new primary volume.

The -o option sets user configurable options for this relationship. These option settings apply to the initial transfer as well as subsequent update transfers for this relationship. We currently support the following options:

back_up_open_files

The supported values for this option are on and off. The default value for this option is on.

When this option is turned off, the open systems SnapVault agent will not back up any files that are open on the primary at the time of the back up transfer. Files on the primary that changed after the agent had begun transferring the file contents will also be excluded from that back up transfer.

When turned on, the OSSV agent includes the open files in the back up transfer.

Note that this option setting only affects primary systems using OSSV 2.0 or higher.

ignore_atime

The supported values for this option are on and off. The default value for this option is off.

When this option is turned on, SnapVault will ignore files which have only their access times changed for incremental transfers.

When turned off, SnapVault will transfer metadata for all modified files.

compression

Available on secondary only. The supported values for this option are on and off. The default value for this option is off.

When this option is turned on, SnapVault secondary will interpret the network data received from source as compressed stream. When this option is turned off SnapVault assumes that the data stream from network is not compressed. This option is valid only for data transfer between OSSV and node.

modify [ -k n ] [ -t n ] [-p {inet | inet6 | unspec}] [ -o options ] [ -S primary_node:primary_path ] secondary_qtree

options
is opt_name=opt_value[[,opt_name=opt_value]...]

Available on the secondary only. The command changes the configuration for a qtree that was previously established with the snapvault start command. The meaning of the options is the same as for the snapvault start command. If an option is set, it changes the configuration for that option. If an option is not set, the configuration of that option is unchanged.

The -p option is used for selecting the IP connection mode when the SnapVault secondary contacts the primary for transfers. The value for this argument can be inet, inet6 or unspec.

When the value is inet6, the connection between the primary and secondary will be established using IPv6 addresses only. If there is no IPv6 address configured for the primary, then the connection will fail. When the value is inet, the connection between primary and secondary will be established using IPv4 addresses only. If there is no IPv4 address configured on the primary, then the connection will fail. When this argument is not specified, then the connection will be tried using both IPv6 and IPv4 addresses. inet6 mode will have higher precedence than inet mode. If a connection request using inet6 mode fails, SnapVault will retry the connection using inet mode.

This option is not meaningful when an IP address is specified instead of a hostname. If the IP address format and connection mode doesn't match, the operation prints an error message and aborts

update [ -k n ] [ -s snapname ] [ -w ] sec_ondary_qtree

Available on the secondary only. Immediately starts an update of the specified qtree on the secondary. The qtree must have previously been configured with the snapvault start command.

The -k option sets the maximum transfer rate in kilobytes per second just as it does in the snapvault start command. However, in this case, the setting only applies to this one transfer. It does not permanently change the configuration for the qtree.

The -s option says which snapshot on the primary should be used for the update. If the option is not set, the primary creates a new snapshot and transfers its contents to the secondary.

The -w option causes the command not to return once the incremental transfer starts. Instead, it will wait until the transfer completes (or fails), at which time it will print the completion status and then return. When the command returns successfully, the status of the transfer can be Idle or Quiescing.

stop [ -f ] secondary_qtree

Available on the secondary only. Unconfigures the qtree so there will be no more updates of the qtree and then deletes the qtree from the active file system. The deletion of the qtree can take a long time for large qtrees and the command blocks until the deletion is complete. The qtree is not deleted from snapshots that already exist on the secondary. However, after the deletion, the qtree will not appear in any future snapshots. To keep the qtree indefinitely, but stop updates to the qtree, use the snapvault modify -t 0 command to set the tries for the qtree to 0.

The -f option forces the stop command to proceed without first asking for confirmation from the user.

prerevert

Available on the secondary only. The prerevert command prepares OSSV secondary qtrees for reverting to a previous ontap release. It also breaks all the OSSV secondary qtree relationships and changes their state to broken-off. All these broken off relationships cannot be used for further back-up unless restarted using snapvault start -r.

The -f option forces the prerevert command to proceed without issuing any warning.

snap sched [ -f ] [ -x ] [ -o options ] [ volname [ snapname [ schedule ]]]

options
is opt_name=opt_value[[,opt_name=opt_value]...]

schedule is cnt[@day_list][@hour_list] or cnt[@hour_list][@day_list]

Available on the primary and secondary. Sets, changes, or lists snapshot schedules. The -f and -x options are only available on the secondary. If no schedule argument is given, the command lists currently configured snapshot schedules.

If volname, snapname, and schedule are all specified, the command sets or changes a snapshot schedule. The snapshots will be created in volume volname. The root name of the snapshots will be snapname. For example, if snapname is sv, the snapshots will be given names sv.0, sv.1, sv.2, etc., for nonSnapLock volumes and primary SnapLock volumes. The snapshots will be given names sv.yyyymmdd_hhmmss_zzz, where yyyym_mdd_hhmmss_zzz is the date/time/timezone
when the snapshot is created, for secondary SnapLock volumes.

The -f option forces the snapvault snap sched command on a SnapLock volume to proceed without first asking for confirmation from the user. It is ignored for nonSnapLock volumes and for primaries.

When setting or changing a snapshot schedule, the -x option tells SnapVault to transfer new data from all primary paths before creating the snapshot. In most cases, this option should be set when configuring snapshots schedules on the secondary because this is how SnapVault does scheduled backups. In special cases, for example, to create weekly snapshots on the secondary when no weekly snapshots are scheduled on the primaries, the user may choose not to set the -x option on the secondary. The -x option is not allowed when not setting a schedule.

The -o option sets user configurable options for this snapshot schedule. We currently support the following options:

retention_period=count{d|m|y}|default

This option is used to specify a retention period for the snapshots that are being scheduled by the snapvault snap sched command for SnapLock secondary volumes. The retention period is specified as a count followed by a suffix. The valid suffixes are d for days, m for months and y for years. For example, a value of 6m represents a retention period of 6 months. The maximum valid retention period is 30 years, or the maximum retention period set for the volume, whichever is shorter. The minimum valid retention period is 0 days, or the minimum retention period set for the volume, whichever is longer. If the option value is default or the retention_period option is not specified, then the snapshots will be created with retention periods equal to the default retention period of the secondary SnapLock volume, or 30 years, whichever is shorter. This option is ignored if the volume is not a SnapLock volume.

preserve=on|off|default

This option is used to prevent SnapVault from deleting older snapshots created by this snapvault snapshot schedule on snapvault secondary volumes. When this option is set to on, SnapVault stops deleting older snapshots to create new backup snapshots when running out of allocated snapshots for this schedule. When this option is not specified or set to default, behavior of preserving snapshots is guided by the global snapvault.preservesnap option. This option is valid only for snapvault snapshot schedules on snapvault secondary volumes and ignored for snapvault snapshot schedules on snapvault primary volumes. If this option is set to on, after snapvault creating cnt number of schedule snapshots, it fails creating further schedule snapshots and issues a warning message on every attempt of snapshot creation for this schedule.

warn=wcount

This option is used to specify a warning level for the remaining number of snapshots for this schedule. This option is honored only for the snapvault snapshot schdeules on secondary volumes. Valid values are from 0 to cnt - 1. The default value is 0. If the value is 0 snapvault does not issue any warning message. Otherwise, SnapVault issues a warning message along with a SNMP trap if the number of remaining schedule snapshots for this schedule are below wcount.

tries=count

This option sets the number of times SnapVault should try creating each scheduled snapshot before giving up. If the snapshot creation fails due to transient errors such as the volume being out of space, SnapVault will keep trying to create the snapshot every minute until the request is fulfilled. The allowed range is from 0 to 120. The default value is unlimited. If set to 0, attempts to create the snapshot target will be disabled. If the tries option is not specified, then the option value will remain unchanged and the already configured value is used.

If only volname and snapname are specified, the command displays the schedule for snapshots with name snapname in volume volname. If only volname is specified, the command displays the schedules for all snapshots in volume volname. If no arguments are given, the command displays the schedules for all configured snapshots in all volumes.

In the schedule, cnt tells SnapVault how many of the snapshots to keep for primaries and for non-SnapLock secondary volumes. The snapshots will be numbered newest to oldest from 0 to cnt-1. When creating a new snapshot, SnapVault will delete the oldest snapshots, increment by one the number on the remaining snapshots and then create a new number 0 snapshot. If a snapshot is missing from the sequence (e.g. sv.0, sv.1, and sv.3 exist but sv.2 does not), only snapshots that need to be renumbered to make room for the new sv.0 snapshot will be renumbered. In the example, sv.0 and sv.1 would be renamed to sv.1 and sv.2, but sv.3 would remain unchanged.

The cnt in the schedule is interpreted differently for SnapVault secondary SnapLock volumes. For SnapLock secondary volumes, snapshots are created with a name that includes an encoded date and time of when the snapshot is created. These snapshots are never renamed and they are never automatically deleted. These snapshots may be deleted using snap delete after the retention period of the snapshot has expired. If cnt is 0, no snapshots will be taken. If cnt is any non-zero value, snapshots will be taken and no snapshots will be automatically deleted.

If specified, the day_list specifies which days of the week the snapshot should be created. The day_list is a comma-separated list of the first three letters of the day: mon, tue, wed, thu, fri, sat, sun. The names are not case sensitive. Day ranges such as mon-fri can also be given. The default day_list is mon-sun, i.e. every day.

If specified, the hour_list specifies which hours of the day the snapshot should be created, on each scheduled day. The hour_list is a comma-separated list of the hours during the day, where hours are integers from 0 to 23. Hour ranges such as 8-17 are allowed. Also, step values are allowed in conjuction with ranges. For example, 0-23/2 means "every two hours". The default hour_list is 0, i.e. midnight on the morning of each scheduled day.

snap unsched [ -f ] [ -d ] [ volname [ snapname ]]

Available on the primary and secondary. Unsets the schedule for a snapshot or a set of snapshots. If both volname and snapname are specified, the command unsets that single snapshot schedule. If only volname is specified, the command unsets all snapshot schedules in the volume. If neither volname nor snapname are specified, the command unsets all snapshot schedules on the system.

The -f option forces the snapshots to be unscheduled without first asking for confirmation from the user.

The -d option deletes ACS softlock set by schedule.

Snapshots which are currently active as reported by the snapvault status -s command cannot be unset. Either wait for the qtree updates and snapshot creation to complete or abort the snapshot creation with snapvault abort -s first and then unschedule the snapshot.

snap create [ -w ] [ -o options ] volname snapname

options
is opt_name=opt_value[[,opt_name=opt_value]...]

Available on the primary and secondary. Initiates creation of the previously configured snapshot snapname in volume volname just as if its scheduled time for creation had arrived. Old snapshots are deleted, existing ones are renamed, and a new one is created. On the secondary, if the -x option was given to the snapvault snap sched command when the snapshot schedule was configured, then update transfers from the primaries for all the qtrees in the volume will start just as they would when the scheduled time arrives. If another SnapVault snapshot is actively being created in the same volume, activity on this snapshot will be queued until work on the other snapshot completes.

The -w option has no effect if only the primary is licensed. If the secondary is licensed, the -w option causes the command not to return once the snapshot creation starts. Instead, it will wait until the snapshot creation completes (or fails), at which time it will print the completion status and then return.

The -o option sets user configurable options for this snapshot schedule. We currently support the following option:

tries=count

This option works similarly to the tries option in the snap sched command.

snap retain [ -f ] volname snapname count{d|m|y}

Available on the secondary only. Extends the retention period on the existing snapshot snapname in a SnapLock volume volname to the retention period specified. The specified retention period begins at the time the command is entered. The retention period is specified as a count followed by a suffix. The valid suffixes are d for days, m for months and y for years. For example, a value of 6m represents a retention period of 6 months. The maximum valid retention period is 30 years, or the maximum retention period set for the volume, whichever is shorter.

The retention period may only be extended by this command. This command does not permit the retention period of the snapshot to be reduced. In addition, if the snapshot does not have a retention period, this command will not establish a retention period on the snapshot. Initial retention periods are established on snapshots which are created according to a SnapVault snapshot schedule or as the result of the snapvault snap create command on SnapLock volumes. Retention periods may not be set on any other snapshots, nor on snapshots which are not on SnapLock volumes.

The -f option forces the retention period to be extended without first asking for confirmation from the user.

snapvault snap preserve volume snapname [ tagname ]

Add preservation on the specified snapshot, which needs to be retained at the primary in a cascaded system. tagname uniquely identifies this preserve operation. When not specified, preservation will be added with default tagname.

This command does not need SnapVault license.

snapvault snap unpreserve volume snapname { [ soft_lock-name ] | [ -all ] }

Remove preservation on the specified snapshot. When tagname specified, preservation with this tagname will be removed. When not specified, preservation with default tagname will be removed. When option -all is specified, all preservations on given snapshot will be removed.

This command does not need SnapVault license.

snapvault snap preservations volume [ snapname ]

List preservations. When no snapname specified, lists all those snapshots which are preserved. When snapname specified, lists all preservations on the snapshot.

This command does not need SnapVault license.

abort [-f] [ -h ] [dst_node:]dst_path

abort -s volname snapname

Available on the primary and secondary. Cancels transfers to all dst_paths specified or, with the -s option, cancels the creation of a snapshot. The destination dst_path is on the secondary for normal updates, but is on the primary for restores. When cancelling a snapshot creation, the command also cancels all update transfers initiated as part of creating the snapshot.

Any transfer with a restart checkpoint (you can view this via the snapvault status command) may be restartable; to clear out the restart checkpoint and force any subsequent transfer to start from the beginning and possibly a different snapshot on the primary, you can use abort -h on the dst_path. 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 primary or the secondary node. However, the -h option is only effective on the destination node. The option will be ignored if specified on the source node.

The -f option forces the abort command to proceed without first asking for confirmation from the user.

status [ -l | -t ] [ path ]

Available on the primary and secondary. Reports status of all the SnapVault relationships for which the node is either a primary or a secondary. This command also reports whether SnapVault is on or off. If any path arguments are given to the command, only the relationships with a matching source or destination will be reported. If the argument is invalid, there won't be any status in the output.

Without any options, the command behaves just like the snapmirror status command, displaying the short form of each relationship's status. This shows the state of the local side of the relationship, whether a transfer is in progress (and if so, the progress of that transfer), and the mirror lag, i.e. the amount of time by which the mirror lags behind the source. This is a simple difference of the current time and the source-side timestamp of the last successful transfer. The lag time will always be at least as much as the duration of the last successful transfer, unless the clocks on the source and destination are not synchronized (in which case it could even be negative).

If the -l option is given, the output displays more detailed information for each relationship.

If the -t option is given, the output displays the relationships that are active. A relationship is considered as active if the source or destination is involved in:

1. data transfer to or from the network. 2. reading or writing to a tape device. 3. Performing local on-disk processing or cleanup. (eg. snapvault stop command )

On a vfiler, the status command shows entries related to the vfiler only. On the physical node, active transfer entries from all vfilers are displayed. Inactive transfers are only displayed on the relevant vfiler. The preferred way to get a comprehensive and more readable list of SnapVault transfers is to run vfiler run * snapvault status. It iterators through all vfilers and lists its transfers.

status -s [ volname [ snapname ]]

Available on the primary and the secondary. Reports status of all the configured snapshot targets. Also shows the currently configured schedule for each snapshot target displayed. The snapshot targets displayed may be restricted to a single volume by specifying that volume, or to a single snapshot target by specifying the volume and snapshot name.

status -c [ qtree ]

Available only on the secondary. Reports the currently configured SnapVault relationships. For each relationship, displays the destination, source, throttle, tries count and the user configurable options settings. The configurations reported may be restricted to only those which involve a specific qtree by specifying the path to that qtree. Optionally, the node on which the qtree resides may also be specified.

status -b [ volume ]

Available only on the secondary. Reports the space savings information on all SnapVault for NetBackup volumes. The space savings information displayed may be restricted to a single volume by specifying that volume.

release src_path dst_node:dst_qtree

On the primary, tells SnapVault that primary path src_path will no longer be replicated to qtree dst_qtree on SnapVault secondary dst_node.

On the secondary, tells SnapVault that qtree src_qtree, which had previously been restored to qtree dst_qtree on primary dst_node, will not be used as a replica for the restored qtree. After a restore, the user can restart replication from the restored qtree with the snapvault start -r command. The release command on the secondary tells SnapVault that replication will not be restarted and the snapshot being saved for the restart may be released for normally scheduled deletion.

restore [-f] [ -k n ] [-r] [-w] [-p {inet | inet6 unspec}] [ -s snapname ] -S secondary_node:sec_ondary_path primary_path

Available on the primary only. The sec_ondary_path and the primary_path must be
qtree paths. The specified qtree paths are restored from the secondary_path on the sec_ondary_node, to the primary_path on the primary node. When the restore completes, the qtree on the primary becomes writable. The primary path may be an existing qtree or a non-existent one. If the primary qtree specified does not exist, the restore will create it before the transfer. If the primary qtree exists, then its contents will be overwritten by the transfer.

By default, snapvault restore performs a baseline transfer from the secondary qtree. If the -r option is used, an incremental restore will be attempted. The incremental restore can be used to revert back the changes made to a primary qtree since any backed up version on the secondary. Since it transfers only the required changes from secondary to primary, it is more efficient than a baseline restore.

By default, the command restores data from the most recent snapshot on the secondary. The -s option specifies that the restore should instead be from snapshot snapname on the secondary. The -k option sets the maximum transfer rate in kilobytes per second. The -f option forces the operation to proceed without prompting for confirmation. The -w option causes the command not to return once the restore transfer starts. The -p option sets the IP connection mode. Restores are restartable; reissue the restore command to restart an aborted restore.

After the restore, the user should either restart backups on the secondary from the restored volume or qtree on primary or release snapshot resources held on the secondary to enable restarting backups. To restart backups after restoring to a nonexistent primary qtree, the snapvault start -r command must be issued. After restoring to an existing primary qtree either a snapvault start -r or a snapvault update may be used to restart backups. However, it should be noted that a snapvault update will be much more inefficient. If it is not required to restart the backup, release the snapshot resources on the secondary. To release snapshot resources on the secondary, issue the snapvault release command as described above.

destinations [ -s ] [[node:]path]

Available on the primary and secondary. On the primary, this lists all the known destinations for SnapVault primary paths. On the secondary, this lists all the known destinations for SnapVault secondary qtrees, if the secondary volume has been replicated using snapmirror.

If the secondary volume has been replicated using snapmirror, this command, on both the primary and secondary, reports the existence of the SnapVault secondary qtrees within the snapmirrored volumes on another node and/or tape.

The -s option includes in the listing names of snapshots retained on this node for the reported destinations.

If a specific path is provided, only destinations for that path will be listed. If the command is being run on the primary, path must be a primary path. If the command is being run on the secondary, path must be a secondary qtree. The node, if specified, must be the hostname of the node this command is being executed on.

OPTIONS

snapvault.enable
This option turns SnapVault on and off. Valid settings are on and off. The option must be set to on on the primaries and the secondary for SnapVault to transfer data from the primary to the secondary and create new snapshots. See na_options(1) for more information on setting options.

SnapVault can only be enabled on vfilers which are rooted on volumes.

snapvault.access
This option controls which SnapVault secondaries may transfer data from a primary and which primaries may restore data from a SnapVault secondary. The option string lists the hosts from which SnapVault transfer requests are allowed or disallowed, or the network interfaces on the source node over which these transfers are allowed or disallowed. Set the option on the primary to grant permission to the secondary. Set the option on the secondary to grant permission to the primaries.

An example of the snapvault.access command is:

options snapvault.access "host=node1,node2 AND if=e10,e11"

This command allows SnapVault transfer requests from node1 and node2, but only over the network interfaces e10 and e11. See na_options(1) and na_protocolaccess(8) for more details.

snapvault.lockvault_log_volume
This option controls which volume should be used as the LockVault log volume. This volume contains logs of SnapVault activity when the secondary is a SnapLock volume. The LockVault log volume must be an online SnapLock volume. It must not also be used as a SnapMirror destination or SnapVault secondary. The compliance clock must be initialized before the LockVault log volume can be configured. See na_date(1) for a description of how to set the compliance clock. The LockVault log volume must be configured before any SnapVault relationships that include a SnapLock secondary volume may be established.

An example of the snapvault.lockvault_log_volume command is:

options snapvault.lockvault_log_volume wormlog

This command configures an existing, online SnapLock volume, wormlog, as the LockVault log volume.

See the Data Protection Online Backup and Recovery Guide for a description of the LockVault log volume and its purpose.

Options snapvault.access and snapvault.enable can be manipulated independently on a per-vfiler basis.

FILES

/etc/log/snapmirror
This file logs SnapVault and SnapMirror activity. See na_snapmirror(5) for details.

See the Data Protection Online Backup and Recovery Guide for a description of the log files in the LockVault log volume.

SEE ALSO

  na_license(1)
  na_options(1)
  na_date(1)
  na_snapvault(1)
  na_protocolaccess(8)


Table of Contents