Documente Academic
Documente Profesional
Documente Cultură
SnapVault
SNAPVAULT
SnapVault is a disk-based storage backup feature of Data ONTAP. SnapVault enables data stored on
multiple storage systems to be backed up to a central, secondary storage system quickly and efficiently as
read-only Snapshot copies.
In the event of data loss or corruption on a storage system, backed-up data can be restored from the
SnapVault secondary with less downtime and uncertainty than is associated with conventional tape
backup and restore operations.
Additionally, users who wish to perform a restore of their own data may do so without the intervention of
a system administrator. The SnapVault secondary may be configured with NFS exports and CIFS shares
to let users copy the file from the Snapshot copy to the correct location.
THEORY OF OPERATION
On storage systems running Data ONTAP, the qtree is the basic unit of SnapVault backup and restore.
SnapVault backs up specified qtrees on the primary system to associated qtrees on the SnapVault
secondary system. If data needs to be restored to the primary system, SnapVault transfers the specified
versions of the qtrees back to their associated primary qtrees.
The non-qtree part of a primary system volume can be replicated to a SnapVault secondary qtree. Nonqtree data is any data on a storage system that is not contained in a qtree. The backed-up data can be
restored to a qtree on the primary system, but cannot be restored as non-qtree data.
You can also back up a primary volume to a qtree on the secondary system. Any qtrees in the primary
volume become directories in the secondary qtree. SnapVault cannot restore the data back to a volume.
When restoring data, what was a source volume is restored as a qtree.
Note that volume-to-qtree backups are not supported for volumes containing Data ONTAP LUNs.
SNAPVAULT CONFIGURATION
PREREQUISITES
You must purchase and install a separate SnapVault license for each primary (sv_ontap_pri) and
secondary (sv_ontap_sec) storage system.
SnapVault evaluation licenses are available upon request on the NOW (NetApp on the Web) site:
now.netapp.com/eservice/evallicense
In Data ONTAP 7.3 and later, you can install both the sv_ontap_pri and the sv_ontap_sec
licenses on the same storage system. This system is then able to send and receive SnapVault backups,
whether from other appliances or locally within itself.
NOTE: You cannot mix primary and secondary qtrees in the same volume, as this is unsupported and
causes undesirable effects.
You cannot license a SnapVault secondary and a SnapVault primary on the same node of an active-active
configured system.
Optionally, you can increase the number of possible concurrent streams on FAS2040, FAS3040,
FAS3070, FAS3100 and FAS6000 storage systems by installing the nearstore_option license. This
license should not be installed on these storage systems if they are intended to handle primary application
workloads.
Port 10566 must be open in both directions for SnapVault backup and restore operations.
If NDMP is in use for control management, then port 10000 must be open on the primary and the
secondary systems.
9
Set up schedules for the daily backups.
sec> snapvault snap sched -x vault sv_daily 12@23@sun-fri
This schedule checks all primary qtrees backed up to the vault volume once each day at 11:00 p.m.
(except on Saturdays) for a new Snapshot copy called sv_daily.0. If it finds such a copy, it updates the
SnapVault qtrees with new data from the primary and then takes a Snapshot copy on the destination
volume, called sv_daily.0.
In this example, you maintain the most recent 12 daily backups, which, combined with the most recent 2
weekly backups (see next page).
10
SNAPVAULT ADMINISTRATION
11
12
-s lists all the Snapshot copies scheduled on the primary or secondary storage system. Information
includes volume, Snapshot copy base name, current status, and Snapshot copy schedule.
13
14
LOG FILES
The SnapVault logs record whether the transfer finished successfully or failed. If there is a problem with
the updates, it is useful to look at the log file to see what has happened since the last successful update.
The logs include the start and end of each transfer, along with the amount of data transferred.
The SnapVault logs information is stored on the primary and secondary storage systems root volume, in
the /etc/log/snapmirror file.
APPLICATION-CONSISTENT BACKUP
15
16
SINGLE-FILE RESTORE
Users who wish to perform a restore of their own data may do so without the intervention of a system
administrator. The SnapVault secondary may be configured with NFS exports and CIFS shares to let users
copy the file from the Snapshot copy to the correct location.
NOTE: SnapVault backups transfer all of the file permissions and access control lists held by the original
data; if users were not authorized to access a file on the original file system, they will not be authorized to
access the backup copies of that file. This allows self-service restores to be performed safely.
To restore a single file, you can also use the Data ONTAP ndmpcopy command or the NetApp
Protection Manager software (if deployed).
17
18
INCREMENTAL RESTORE
SnapVault incremental restore is based on qtree SnapMirror resync-style Snapshot copy negotiation.
The primary qtree is resynced to the specified Snapshot copy on the secondary.
The resync rolls back the primary qtree to the specified Snapshot copy and an incremental restore transfer
is initiated from the specified Snapshot copy.
The restore operation transfers only incremental changes from the secondary qtree to the specified
primary qtree.
You use the new -r option to perform a SnapVault incremental restore.
Example:
pri> snapvault restore -r -S sec:/vol/vault/pri_users /vol/vol1/users
Restore will overwrite existing data in /vol/volname/pri_qtree
Are you sure you want to continue (yes/no)? Yes
Transfer started.
Monitor progress with 'snapvault status' or the snapmirror log.
19
When you want to restore over an existing primary qtree, it is recommended that you first attempt an
incremental restore. If the incremental restore fails due to lack of common Snapshot copies, then attempt
an in-place baseline restore. This is because the incremental restore is a more efficient restore.
20
NONDISRUPTIVE RESTORE
SCSI connectivity to LUNs is maintained throughout the in-place and incremental restores by way of the
following process:
The primary qtree is made read-only. The LUNs attributes in the primary qtree are reserved in a
temporary staging area. LUN maps are updated. External SCSI requests are processed using the
information stored in the staging area. Hosts see the same LUNs with the same drive letters at all times.
To display the LUNS in the preserved staging qtrees, use the lun show staging command.
Example:
Original LUN location: /vol/san_vol1/qtree1/LUN1
Staging qtree naming convention:
/vol/<vol_name>/Staging_<Volume_UUID>_<Transaction_ID>
pri> lun show staging
/vol/san_vol1/Staging_19e45590-8948-11dc-bb1500a09802437a_199999999999999999/LUN1 100m (104857600)
(r/w,online,mapped)
When the restore has completed, the LUNs attributes that are stored in the staging area are applied to the
restored LUNs. The primary qtree is broken to be write-enabled, and I/O operations are resumed to the
restored LUNs.
21
22
@@@@@@@@
6.7 SnapVault
SnapVault performs backup of qtrees and directories from a primary storage system (source) to a
secondary storage system (destination).
23
24
@@@@@@@@@@@@@@@@@@
SNAPVAULT FEATURE
The SnapVault feature enables you to create and archive Snapshot copies from one volume to another
volume or, typically, from a local controller to a remote controller. The feature provides a consistent,
recoverable, offsite, long-term backup and archive capability.
CONFIGURATION
SnapVault is a licensed feature that must be enabled before it can be configured and used. The SnapVault
feature has two licenses. One license is for the primary controller (the backup source), and the other
license is for the secondary controller (the archive destination).
License the primary controller (sv_ontap_pri).
license add <licnum>
License the secondary controller (sv_ontap_sec).
license add <licnum>
NOTE: The two licenses enable different functionalities, and the correct license must be enabled on the
appropriate controller (for example, the production or the disaster recovery controller).
25
The second step in configuring a SnapVault relationship (after licensing) is to create the destination
volume. Typically, you create the destination volume on a remote controller that provides lower-cost
storage (for example, Serial Advanced Technology Attachment or SATA disks).
Create a normal destination volume by running the following command on the destination system:
vol create <vol_name> (with parameters to suit)
Check the volumes status and size by running the following command:
vol status b
NOTE: The volume must be online and in a writable state.
Do not create the destination qtrees. The destination qtrees are created automatically when the
SnapVault relationship is initialized.
NOTE: Although the destination volume remains writable, the individual destination qtrees are readonly.
It is important that you know the requirements and states of the source and destination volumes and that
you understand how SnapMirror requirements for the source and destination volumes differ.
NetApp University
The technology behind the SnapVault feature is based on the qtree SnapMirror function. This function
determines many of the features and limitations of the SnapVault feature. For example, the basic unit of
SnapVault backup is the qtree, and all SnapVault transfers are based on schedules for asynchronous mode.
Before you can enable the SnapVault relationship, you must configure the SnapVault access control
between the source and destination storage controllers. For descriptions of the access control settings,
refer to the Security section.
After the source and destination volumes are defined, you can configure the SnapVault schedules on the
primary and secondary controllers and start the incremental backups. You can also perform the initial
baseline transfer, copying the data from the source qtree to the destination qtree.
1. Configure the primary controller and define a SnapVault schedule.
snapvault snap sched vol1 sv_hourly 5@mon-fri@9-19
26
2. Configure the secondary controller and perform the baseline transfer.
snapvault start S pri:/vol/vol1/q1 sec:/vol/vol1/q1
When the baseline transfer is completed, the destination volume is an exact replica of the source volume.
3. Define a SnapVault schedule.
snapvault snap sched x vol1 sv_hourly 5@mon-fri@9-19
The x parameter instructs the secondary controller to request a resynchronization with the primary
controller. This request reports the current file system state and then creates a Snapshot copy to retain the
data.
NOTE: The SnapVault schedule definition is in the following format:
<snapshots_to_retain>@<day_of_the_week><@hour_of_the_day>
The schedule can be specified in more than one way. Because the day of the week is specified as a
mnemonic expression, you can define the schedule as the following:
<snapshots_to_retain><@hour_of_the_day>@<day_of_the_week>
ADMINISTRATION
The administration of a SnapVault relationship can be performed from either the primary or the secondary
system, although some functions are available only on their respective systems.
You use the snapvault status command to display the state of the currently defined SnapVault
relationships, as shown in Figure 23:
NOTE: You can use the snapvault status c option to display the SnapVault qtree configuration
parameters.
You can use the snapvault command to manage all aspects of the SnapVault relationship, such as
updating the secondary system or restoring the backup. The following are examples of frequently used
snapvault functions:
snapvault update sec_hostname:/vol/vol_name/qtree
When executed on the secondary system, this command triggers a manual (unscheduled) update of the
specified qtree destination.
snapvault release <path> <other_hostname>:<path>
When executed on either system, this command deletes the SnapVault relationship.
snapvault restore S sec_hostname:/vol/vol_name/qtree
pri_hostname:/vol/vol_name/qtree
When executed on the primary system, this command restores the qtree contents from the backup.
To restore to the original qtree location on the primary system, you must break the SnapVault
relationship or restore to a new qtree (and rename later).
To restore a small amount of data (like one file), you may prefer to copy the files from a CIFS share on
the secondary qtree.
27
snapvault start r <path>
When executed on the secondary system, this command resynchronizes the relationship and resumes
backup operations after the SnapVault restore is completed.
NOTE: For information about the other SnapVault commands, refer to the product manual.
Some third-party backup applications use SnapVault integration. To enable these applications to
communicate with the controller, you must enable the NDMP protocol and define the user name and
password for the application.
PERFORMANCE
One of the challenges of a new SnapVault configuration is the transfer of the baseline copy from the
primary to the secondary system. Although the WAN connection may be adequate to handle the
incremental backup traffic, it may not be adequate to complete the baseline transfer in a timely manner. In
this case, you should consider using the Logical Replication (LREP) function. The LREP function can
perform the initial baseline transfer by using external disk media, such as a USB drive connected to a
laptop computer.
Because SnapVault backups are scheduled activities (asynchronous), they are constrained only by the
bandwidth of the connection and are not significantly affected by the link latency.
Similar to the qtree SnapMirror process, the SnapVault process accesses the primary qtree at the filesystem level and therefore sees (and backs up) the original version of any deduplicated data. Although
this process may cause more data to be sent across the WAN than is expected, the secondary qtree is
written in the original capacity. Further deduplication can be scheduled on the secondary system.
SECURITY
By default, no access is granted for SnapVault traffic, and specific access must be granted to any remote
controller in a backup relationship.
The primary controller must grant access to the secondary controller so that the secondary controller can
pull backups from the source. And the secondary controller must grant access to the primary
controller so that the primary controller can request restores of the backups.
SnapVault access can be configured on the primary and secondary controllers by using the following
command:
options snapvault.access host=<other controller>
TROUBLESHOOTING
Comprehensive logging of all SnapVault activity is enabled by default. Because the SnapVault function is
based on the qtree SnapMirror function, all log information for the SnapVault and qtree SnapMirror
functions is stored to the same file.
The log information is saved to the /etc/log/snapmirror.[0-5] files. The log can be disabled by executing
the following command: options snapmirror.log.enable [on|off]
@@@@@@@@@@@
SnapVault protects data on both NetApp and non-NetApp primary systems by maintaining a number
of read-only versions of that data on a SnapVault secondary system and the SnapVault primary
system
28
What SnapVault is
SnapVault is a disk-based storage backup feature of Data ONTAP. SnapVault enables data stored on
multiple systems to be backed up to a central, secondary system quickly and efficiently as read-only
Snapshot copies.
In the event of data loss or corruption on a system, backed-up data can be restored from the
SnapVault secondary system with less downtime and uncertainty than is associated with conventional
tape backup and restore operations.
The following terms are used to describe the SnapVault feature:
Primary systema system whose data is to be backed up
Secondary systema system to which data is backed up
Primary system qtreea qtree on a primary system whose data is backed up to a secondary qtree
on a secondary system
Secondary system qtreea qtree on a secondary system to which data from a primary qtree on a
primary system is backed up
Open systems platforma server running AIX, Solaris, HP-UX, Red Hat Linux, SUSE Linux, or
Windows, whose data can be backed up to a SnapVault secondary system
Open Systems SnapVault agenta software agent that enables the system to back up its data to a
SnapVault secondary system
SnapVault relationshipthe backup relationship between a qtree on a primary system or a
directory on an open systems primary platform and its corresponding secondary system qtree
SnapVault Snapshot copythe backup images that SnapVault creates at intervals on its primary
and secondary systems
SnapVault Snapshot copies capture the state of primary qtree data on each primary system. This
data is transferred to secondary qtrees on the SnapVault secondary system. The secondary system
creates and maintains versions of Snapshot copies of the combined data for long-term storage and
possible restore operations.
SnapVault Snapshot basenamea name that you assign to a set of SnapVault Snapshot copies
using the snapvaultsnapschedcommand. As incremental Snapshot copies for a set are
taken and stored on both the primary and secondary systems, the system appends a number (0, 1,
2, 3, and so on) to the basenames to track the most recent and earlier Snapshot updates.
SnapVault baseline transferan initial complete backup of a primary storage qtree or an open
systems platform directory to a corresponding qtree on the secondary system
SnapVault incremental transfera follow-up backup to the secondary system that contains only
the changes to the primary storage data between the current and last transfer actions
29
primary or secondary system, and the aggregate type. For example, you can back up data from a
primary system that has Data ONTAP 7.3 installed to a secondary system that has Data ONTAP
7.1 installed. You can also back up data from a primary system that has Data ONTAP 7.1 installed
to a secondary system that has Data ONTAP 7.3 installed.
The destination system uses a slightly more disk space and directories than the source system.
Note: You can back up the qtrees from multiple primary systems, or directories from multiple open
30
31
32
using SnapVault. The space savings at the destination and the source systems are the same if inline
compression is enabled on the source system.
1. On the primary system: To set the primary systems to grant access only to the secondary
systems, enter the following command:
optionssnapvault.accesshost=snapvault_secondary
Note: In the snapvault.accessoption, up to 255 characters are supported after host=.
Setting this option on the SnapVault primary system determines which secondary system can
access data from that primary system.
2. On the secondary system: To allow the primary systems to restore data from the secondary
system, enter the following command:
optionssnapvault.accesshost=snapvault_primary1,snapvault_primary2,...
Setting this option on the SnapVault secondary system determines which SnapVault primary
systems can access the secondary system.
The system must be able to resolve the host name entered as snapvault_primaryto an IP
address in the /etc/hostsfile, or else the system needs to be running DNS or NIS. You can also
use the literal IP address instead of the host name. The syntax for specifying which systems are
allowed access to the secondary system is described in the na_protocolaccess(8) man page. For
more information about the optionscommand, see the na_options(1) man page.
33
34
Management Console data protection capability.
It is not a simple process to restore data.
SnapVault cannot restore the data back to a volume. When restoring data, the original source
volume is restored as a qtree. Also, incremental restores are not supported.
Volume-to-qtree backup is not supported for volumes containing Data ONTAP LUNs.
1. To restore the backed-up qtree to the original volume structure with multiple qtrees on the
primary system, re-create all of the qtrees in the volume on the primary system by using the
qtreecreatecommand.
pri_system>qtreecreate/vol/projs/project_x
3. Stop qtree updates and remove the qtree on the secondary system by using the snapvault
stopcommand. The following command removes the projsqtree from the secondary system:
sec_system>snapvaultstop/vol/vol1/projs
4. Reinitialize a baseline copy of each qtree to the secondary system by using the snapvault
startcommand. The following command reinitializes the SnapVault backup:
sec_system>snapvaultstartSpri_system:/vol/projs/vol/vol1/projs
command to create Snapshot copies. Therefore, to track the schedule for creating Snapshot copies,
look at the snapvaultsnapschedoutput, and not the snapschedoutput.
35
Attention: The combined total of Snapshot copies retained for this and other
Snapshot sets cannot exceed 251 Snapshot copies per volume. If it does, SnapVault
will not create new Snapshot copies.
1. To check the status of a data transfer and see how recently a qtree has been updated, enter the
following command:
snapvaultstatus[l|s|c|t][[[system_name:]qtree_path]...]
ldisplays the long format of the output, which contains more detailed information.
sdisplays the SnapVault Snapshot copy basename, status, and schedule for each volume.
cdisplays the configuration parameters of all SnapVault qtrees on the system. This option
of the following activities: transferring data to or from the network, reading or writing to a
tape device, waiting for a tape change, or performing local on-disk processing or clean-up.
system_nameis the name of the system for which you want to see the status of SnapVault
operations.
qtree_pathis the path of the qtree or qtrees for which you want to see the status of SnapVault
operations. You can specify more than one qtree path.
36
37
38
39
40
41
running Data ONTAP only. For descriptions and procedures pertaining to SnapVault backup of
open systems drives and directories, see the Open Systems SnapVault documentation.
The snapvaultmodifycommand is available only from the secondary system. You can also use
this command to modify the tries count after the relationship has been set up. This is useful when
there is a planned network outage.
You use the snapvaultmodifycommand to change the source if the primary system, volume, or
qtree is renamed. This ensures the continuity of the existing SnapVault relationship between the
primary and secondary systems. However, you cannot copy a primary qtree to another volume or
42
system and use this command to take backups from that new location.
If you need to change the SnapVault schedule, use the snapvaultsnapschedcommand.
1. From the secondary system, enter the following command on a single line:
snapvaultmodify[kkbs][tn][ooptions][S
[pri_system:]pri_qtree_path][sec_system:]sec_qtree_path
kkbsspecifies a value in kilobytes per second for the throttle (transfer speed) for the primary
system. A value of unlimitedlets the transfer run as fast as it can. Other valid values are whole
positive numbers.
tnspecifies the number of times to try the transfer before giving up. The default is 2.
If set to 0, the secondary system does not update the qtree. This is one way to temporarily stop
updates to a qtree.
optionsis opt_name=opt_value[[, opt_name=opt_value]...]. For more details about the
43
running Data ONTAP only. For SnapVault backup of open systems drives and directories, see the
Open Systems SnapVault documentation.
44
Snapvault consists of major two entities snapvault clients and a snapvault storage server. A
snapvault client (Netapp filers and unix/windows servers) is the system whose data should be
backed-up. The SnapVault server is a Netapp filer which gets the data from clients and backs
up data. For Server to Netapp Snapvault, we need to install Open System Snapvault client
software provided by Netapp, on the servers. Using the snapvault agent software, the Snapvault
server can pull and backup data on to the backup qtrees. SnapVault protects data on a client
system by maintaining a number of read-only versions (snapshots) of that data on a SnapVault
filer. The replicated data on the snapvault server system can be accessed via NFS or CIFS. The
client systems can restore entire directories or single files directly from the snapvault filer.
Snapvault requires primary and secondary license.
How snapvault works?
When snapvault is setup, initially a complete copy of the data set is pulled across the network to
the SnapVault filer. This initial or baseline, transfer may take some time to complete, because it
is duplicating the entire source data set on the server much like a level-zero backup to tape.
Each subsequent backup transfers only the data blocks that has changed since the previous
backup. When the initial full backup is performed, the SnapVault filer stores the data on a qtree
and creates a snapshot image of the volume for the data that is to be backed up. SnapVault
creates a new Snapshot copy with every transfer, and allows retention of a large number of
copies according to a schedule configured by the backup administrator. Each copy consumes an
amount of disk space proportional to the differences between it and the previous copy.
Snapvault commands :
Initial step to setup Snapvault backup between filers is to install snapvault license and enable
snapvault on all the source and destination filers.
Source filer filer1
filer1> license add XXXXX
filer1> options snapvault.enable on
filer1> options snapvault.access host=filer2
Destination filer filer2
filer2> license add XXXXX
filer2> options snapvault.enable on
filer2> options snapvault.access host=filer1
Consider filer2:/vol/snapvault_volume as the snapvault destination volume, where all backups
are done. The source data is filer1:/vol/datasource/qtree1. As we have to manage all the backups
on the destination filer (filer2) using snapvault manually disable scheduled snapshots on the
45
destination volumes. The snapshots will be managed by Snapvault. Disabling Netapp scheduled
snapshots, with below command.
filer2> snap sched snapvault_volume 0 0 0
Creating Initial backup: Initiate the initial baseline data transfer (the first full backup) of the data
from source to destination before scheduling snapvault backups. On the destination filer execute
the below commands to initiate the base-line transfer. The time taken to complete depends upon
the size of data on the source qtree and the network bandwidth. Check snapvault status on
source/destination filers for monitoring the base-line transfer progress.
filer2> snapvault start -S filer1:/vol/datasource/qtree1 filer2:/vol/snapvault_volume/qtree1
Creating backup schedules: Once the initial base-line transfer is completed, snapvault schedules
have to be created for incremental backups. The retention period of the backup depends on the
schedule created. The snapshot name should be prefixed with sv_. The schedule is in the form
of [@][@].
On source filer:
For example, let us create the schedules on source as below 2 hourly, 2 daily and 2 weekly
snapvault . These snapshot copies on the source enables administrators to recover directly from
source filer without accessing any copies on the destination. This enables more rapid restores.
However, it is not necessary to retain a large number of copies on the primary; higher retention
levels are configured on the secondary. The commands below shows how to create hourly, daily
& weekly snapvault snapshots.
filer1> snapvault snap sched datasource sv_hourly 2@0-22
filer1> snapvault snap sched datasource sv_daily 2@23
filer1> snapvault snap sched datasource sv_weekly 2@21@sun
On snapvault filer:
Based on the retention period of the backups you need, the snapvault schedules on the
destination should be done. Here, the sv_hourly schedule checks all source qtrees once per hour
for a new snapshot copy called sv_hourly.0. If it finds such a copy, it updates the SnapVault
qtrees with new data from the primary and then takes a Snapshot copy on the destination volume,
called sv_hourly.0. If you dont use the -x option, the secondary does not contact the primary and
transfer the Snapshot copy. It just creates a snapshot copy of the destination volume.
filer2> snapvault snap sched -x snapvault_volume sv_hourly 6@0-22
filer2> snapvault snap sched -x snapvault_volume sv_daily 14@23@sun-fri
filer2> snapvault snap sched -x snapvault_volume sv_weekly 6@23@sun
46
To check the snapvault status, use the command snapvault status either on source or
destination filer. And to see the backups, do a snap list on the destination volume that will
give you all the backup copies, time of creation etc.
Restoring data : Restoring data is as simple as that, you have to mount the snapvault destination
volume through NFS or CIFS and copy the required data from the backup snapshot.
You can also try Netapp Protection manager to manage the snapvault backups either from OSSV
or from Netapp primary storage. Protection manager is based on Netapp Operations manager
(aka Netapp DFM). It is a client based UI, with which you connect to the Ops Manager and
protect your storages.
SNAPVAULT VERSUS SNAPMIRROR: WHATS THE DIFFERENCE?
The following list describes some of the key differences between SnapVault software and the qtree-based
SnapMirror feature.
SnapMirror software uses the same software and licensing on the source appliance and the
destination server. SnapVault software has SnapVault primary systems and SnapVault secondary
systems, which provide different functionality. The SnapVault primaries are the sources for data
that is to be backed up. The SnapVault secondary is the destination for these backups.
NOTE: As of Data ONTAP 7.2.1, SnapVault Primary and SnapVault secondary can be installed on
different heads of the same cluster. Data ONTAP 7.3 supports installing both the primary and
secondary on a standalone system.
SnapVault destinations are typically read-only. Unlike SnapMirror destinations, they cannot be
made into read-write copies of the data. This means that backup copies of data stored on the
SnapVault server can be trusted to be true, unmodified versions of the original data.
Note: A SnapVault destination can be made into read-write with the SnapMirror/SnapVault bundle.
For more information, see Appendix B.
SnapMirror transfers can be scheduled every few minutes; SnapVault transfers can be scheduled
at most once per hour.
Multiple qtrees within the same source volume consume one Snapshot copy each (on the source
system) when qtree-based SnapMirror software is used, but consume only one Snapshot copy total
when SnapVault software is used.
The SnapMirror software deletes SnapMirror Snapshot copies when they are no longer needed for
replication purposes. The copies are retained or deleted on a specified schedule.
SnapMirror relationships can be reversed, allowing the source to be resynchronized with changes
made at the destination. SnapVault provides the ability to transfer data from the secondary to the
primary only for restore purposes. The direction of replication cannot be reversed.
SnapMirror can be used to replicate data only between NetApp storage systems running Data
ONTAP. SnapVault can be used to back up both NetApp and Open Systems primary storage,
although the secondary storage system must be a FAS system or a NearStore system.
47
4 CONFIGURING SNAPVAULT
This section provides step-by-step procedures for configuring SnapVault and examples of configurations.
The following examples assume that you are configuring backups for a single FAS system named
fas3050-pri, using a single NearStore system named fas3070-sec. The home directories are in a
qtree on fas3050-pri called /vol/vol1/users; the database is on fas3050-pri in the volume
called /vol/oracle, and is not in a qtree.
STEP TWO: SCHEDULE SNAPSHOT COPIES ON THE SNAPVAULT PRIMARIES
The following steps occur on the SnapVault primary, fas3050-pri.
1. License SnapVault and enable it.
fas3050-pri> license add ABCDEFG
fas3050-pri> options snapvault.enable on
fas3050-pri> options snapvault.access host=fas3070-sec
2. Turn off the normal Snapshot schedules, which will be replaced by SnapVault Snapshot schedules.
fas3050-pri> snap sched vol1 0 0 0
fas3050-pri> snap sched oracle 0 0 0
3. Set up schedules for the home directory hourly Snapshot copies.
fas3050-pri> snapvault snap sched vol1 sv_hourly 22@0-22
This schedule takes a Snapshot copy every hour, except for 11 p.m. It keeps nearly a full day of
hourly copies, and, combined with the daily or weekly backups at 11 p.m., makes copies from the
most recent 23 hours always available.
4. Set up schedules for the home directory daily Snapshot copies.
fas3050-pri> snapvault snap sched vol1 sv_daily 7@23
This schedule takes a Snapshot copy once each night at 11 p.m. and retains the seven most recent
copies.
The schedules created in steps 3 and 4 give 22 hourly and 7 daily Snapshot copies on the source
to recover from before needing to access any copies on the secondary. This enables more rapid
restores. However, it is not necessary to retain a large number of copies on the primary; higher
retention levels are configured on the secondary.
STEP THREE: SCHEDULE SNAPSHOT COPIES ON THE SNAPVAULT SECONDARY
The following steps occur on the SnapVault secondary, fas3070-sec.
1. License SnapVault and enable it.
fas3070-sec> license add HIJKLMN
fas3070-sec> options snapvault.enable on
fas3070-sec> options snapvault.access host=fas3050-pri
2. Create a FlexVol volume for use as a SnapVault destination.
fas3070-sec> aggr create sv_flex 10
fas3070-sec> vol create vault sv_flex 100g
The size of the volume should be determined by how much data you need to store and other
48
site-specific requirements, such as the number of Snapshot copies to retain and the rate of
change for the data on the primary FAS system.
Depending on site requirements, you may want to create several different SnapVault
destination volumes. You may find it easiest to use different destination volumes for data sets
with different schedules and Snapshot copy retention needs.
3. Optional (recommended): Set the Snapshot reserve to zero on the SnapVault destination volume.
fas3070-sec> snap reserve vault 0
Due to the nature of backups using SnapVault, a destination volume that has been in use for a
significant amount of time often has four or five times as many blocks allocated to Snapshot copies
as it does to the active file system. Because this is the reverse of a normal production environment,
many users find that it is easier to keep track of available disk space on the SnapVault secondary if
SnapReserve is effectively turned off.
4. Turn off the normal Snapshot schedules, which will be replaced by SnapVault Snapshot schedules.
fas3070-sec> snap sched vault 0 0 0
5. Set up schedules for the hourly backups.
fas3070-sec> snapvault snap sched -x vault sv_hourly 4@0-22
This schedule checks all primary qtrees backed up to the vault volume once per hour for a new
Snapshot copy called sv_hourly.0. If it finds such a copy, it updates the SnapVault qtrees with new
data from the primary and then takes a Snapshot copy on the destination volume, called
sv_hourly.0.
Note that you are keeping only the four most recent hourly Snapshot copies on the SnapVault
secondary. A user who wants to recover from a backup made within the past day has 23 backups
to choose from on the primary FAS system and has no need to restore from the SnapVault
secondary. Keeping four hourly Snapshot copies on the secondary merely lets you have at least
the most recent four backups in the event of a major problem affecting the primary system.
Note: If you do not use the -x option, the secondary does not contact the primary and transfer the
Snapshot copy. Only a Snapshot copy of the destination volume is created.
6. Set up schedules for the daily backups.
fas3070-sec> snapvault snap sched -x vault sv_daily 12@23@sun-fri
This schedule checks all primary qtrees backed up to the vault volume once each day at 11 p.m.
(except on Saturdays) for a new Snapshot copy called sv_daily.0. If it finds such a copy, it updates
the SnapVault qtrees with new data from the primary and then takes a Snapshot copy on the
destination volume, called sv_daily.0.
In this example, you maintain the most recent 12 daily backups, which, combined with the most
recent 2 weekly backups (see step 7), slightly exceeds the requirements shown in Table 2, in
Section 2.7.
7. Set up schedules for the weekly backups.
fas3070-sec> snapvault snap sched vault sv_weekly 13@23@sat
This schedule creates a Snapshot copy of the vault volume at 11 p.m. each Saturday for a new
Snapshot copy called sv_weekly.0. There is no need to create the weekly schedule on the primary.
Because you have all the data on the secondary for this Snapshot copy, you will simply create and
retain the weekly copies only on the secondary.
In this example, you maintain the most recent 13 weekly backups, for a full three months of online
backups.
49
50
51
Notice that in the example qtree4 is still transferring while all other qtrees are in a quiescing state. It would
be a good idea to monitor qtree4 in this SnapVault transfer to see if it continues to cause the other qtrees to
be in a quiescing state. The change rate of qtree 4 may not be similar to the other qtrees on the destination
volume, and it would make more sense to move this qtree to another volume.
52
(snapvault release).
For single file restores, use the ndmpcopy command in Data ONTAP or Protection Manager (if available); or
use CIFS/NFS and copy the file from the Snapshot copy to the correct location.
Each storage system in a cluster has a maximum number of simultaneous replication operations. If
a failover occurs, the surviving storage system cannot process more than the maximum number of
simultaneous replication operations specified for that storage system. These can be operations that
were scheduled for the surviving storage system, the failover storage system, or both.
Note: Take this limitation into consideration when you are planning SnapMirror or SnapVault replications
using clusters.
NetApp systems with a NearStore license are optimized as a destination for QSM and SnapVault replication
operations. Replication operations of which the NearStore system is the QSM source, SnapVault source,
53
Volume SnapMirror (VSM) source, or VSM destination count twice against the maximum number.
For details on the maximum concurrent streams, see the Data ONTAP Data Protection Online Backup and
Recovery Guide for your version of Data ONTAP.
54
retention policy. After the Snapshot copies are in place, SnapVault then calls FAS deduplication to start.
After FAS deduplication completes successfully, SnapVault takes another snapshot and moves the previous
archive snapshot to the new archive snapshot. If dedupe fails/aborts, the archive snapshot is not moved and
the duplicate blocks will remain locked in the snapshot until that snapshot is recycled.
FAS deduplication might be implemented and scheduled on the SnapVault primary system, but SnapVault
and FAS deduplication are not integrated; the schedules are independent of each other. Because SnapVault
is replicated at the qtree level, deduplication is not maintained during the transfer.
For more information on FAS Deduplication, please see TR3505, NetApp Deduplication for FAS Deployment
and Implementation Guide.
Enabling SnapVault
Setting up SnapVault backup on the primary systems means preparing the primary storage system
and SnapVault secondary storage system to perform their backup tasks. In Data ONTAP 8.2 and later,
a single SnapVault license is used for SnapVault primary and SnapVault secondary instead of two
separate SnapVault licenses. You must license and prepare your storage system before you can use
SnapVault to back up data.
@@@@
55