Manual Pages
Table of Contents
na_snapvault - disk-based data protection
snapvault start [ options ] secondary_qtree
snapvault modify [ options ] secondary_qtree
snapvault update [ options ] secondary_qtree
snapvault stop [-f] secondary_qtree
snapvault snap sched [-f] [-x] [-o options ] [volume
[snapname [schedule]]]
snapvault snap unsched [-f] [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_filer:]dst_path | -s vol_ume
snapname }
snapvault status { [ options ] [ path ] | -s [volume
[snapname]] | -c [qtree] | -b [volume] }
snapvault release secondary_qtree pri_mary_filer:restored_qtree
snapvault destinations [options] [[secondary_filer:]sec_ondary_qtree]
snapvault snap sched [ -o options ] [volume [snapname
[schedule]]]
snapvault snap unsched [-f] [volume [snapname]]
snapvault snap create [ -o options ] volume snapname
snapvault abort [-f] [-h] [dst_filer:]dst_path
snapvault status { [ options ] [ path ] | -s [volume
[snapname]] }
snapvault release primary_path secondary_filer:sec_ondary_qtree
snapvault restore [ options ] -S secondary_filer:sec_ondary_path
primary_path
snapvault destinations [options] [[primary_filer:]pri_mary_path]
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
filer. A filer can act as a primary, a secondary,
or both, depending on its licenses. The primary system
can either be a filer or an open system with a SnapVault
agent installed on it. When the primary system is a
filer, 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
filers can restore qtrees directly from the secondary.
NOTE: Although data sets other than individual qtrees may
be replicated from primary filers, users should be aware
that the snapvault restore command on a primary filer 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 filers 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 filers 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 filer 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 filer (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.
The snapvault subcommands are:
start [ -r ] [ -k n ] [ -t n ] [ -w ] [-p {inet | inet6
unspec}] [ -o options ] [ -S [primary_filer:]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 pri_mary_filer
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 filer 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 filer 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
filer.
modify [ -k n ] [ -t n ] [-p {inet | inet6 | unspec}] [ -o
options ] [ -S primary_filer:primary_path ] sec_ondary_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.
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.
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, behaviour 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 ] [ 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.
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_filer:]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 filer. However,
the -h option is only effective on the destination
filer. The option will be ignored
if specified on the source filer.
The -f option forces the abort command to
proceed without first asking for confirmation
from the user.
status [ -l | -t | -m ] [ path ]
Available on the primary and secondary.
Reports status of all the SnapVault relationships
for which the filer 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 )
If the -m option is given, the output displays
counts of successful and failed
updates as well as a count of the times an
update could not start immediately and was
deferred.
On a vfiler, the status command shows
entries related to the vfiler only. On the
physical filer, 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 filer 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_filer: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_filer.
On the secondary, tells SnapVault that qtree
src_qtree, which had previously been
restored to qtree dst_qtree on primary
dst_filer, 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_filer:sec_ondary_path
primary_path
Available on the primary only. If
rapid_restore is not licensed, 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_filer,
to the primary_path on the
primary filer. 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.
If rapid_restore is licensed, both the sec_ondary_path
and the primary_path can be
either a qtree path or volume path. A volume
path is valid only for Rapid Restore. Rapid
Restore restores the specified volume path
from the secondary_path on the sec_ondary_filer,
to the primary_path on the
primary_filer. The volume on the primary is
accessible while the restore is in progress.
The -f option forces the Rapid Restore process
to proceed without first asking for
confirmation from the user. When the restore
completes, the volume on the primary is
detached from the secondary.
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 ] [[filer:]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 filer and/or
tape.
The -s option includes in the listing names
of snapshots retained on this filer 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 filer, if specified,
must be the hostname of the filer this command
is being executed on.
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 filer
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=filer1,filer2
AND if=e10,e11"
This command allows SnapVault transfer
requests from filers filer1 and filer2, 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.
/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.
na_license(1)
na_options(1)
na_date(1)
na_snapvault(1)
na_protocolaccess(8)
Table of Contents