Data Protection STRSW Ilt Dataprot Rev3 SG - Studentguide

NetApp University
Student Guide
NetApp Protection Software
Administration Data ONTAP 7.3

NETAPP UNIVERSITY
NetApp Protection Software Administration
Data ONTAP
7.3

Course Number: STRSW-ILT-DATAPROT-REV3
Part Number: STRSW-ILT-DATAPROT-REV3-SG

2 NetApp Protection Software Administration Data ONTAP 7.3: Welcome
2008 NetApp. This material is intended for training use only. Not authorized for reproduction purposes.
ATTENTION
The information contained in this guide is intended for training use only. This guide contains information
and activities that, while beneficial for the purposes of training in a closed, non-production environment,
can result in downtime or other severe consequences and therefore are not intended as a reference guide.
This guide is not a technical reference and should not, under any circumstances, be used in production
environments. To obtain reference materials, please refer to the NetApp product documentation located
at www.now.com for product information.
COPYRIGHT
2008 NetApp. All rights reserved. Printed in the U.S.A. Specifications subject to change without notice.
No part of this book covered by copyright may be reproduced in any form or by any meansgraphic,
electronic, or mechanical, including photocopying, recording, taping, or storage in an electronic retrieval
systemwithout prior written permission of the copyright owner.
NetApp reserves the right to change any products described herein at any time and without notice.
NetApp assumes no responsibility or liability arising from the use of products or materials described
herein, except as expressly agreed to in writing by NetApp. The use or purchase of this product or
materials does not convey a license under any patent rights, trademark rights, or any other intellectual
property rights of NetApp.
The product described in this manual may be protected by one or more U.S. patents, foreign patents,
or pending applications.
RESTRICTED RIGHTS LEGEND
Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph
(c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.277-7103
(October 1988) and FAR 52-227-19 (June 1987).
TRADEMARK INFORMATION
NetApp, the NetApp logo, and Go further, faster, FAServer, NearStore, NetCache, WAFL, DataFabric,
FilerView, SecureShare, SnapManager, SnapMirror, SnapRestore, SnapVault, Spinnaker Networks,
the Spinnaker Networks logo, SpinAccess, SpinCluster, SpinFS, SpinHA, SpinMove, SpinServer, and
SpinStor are registered trademarks of Network Appliance, Inc. in the United States and other countries.
Network Appliance, Data ONTAP, ApplianceWatch, BareMetal, Center-to-Edge, ContentDirector, gFiler,
MultiStore, SecureAdmin, Smart SAN, SnapCache, SnapDrive, SnapMover, Snapshot, vFiler, Web Filer,
SpinAV, SpinManager, SpinMirror, and SpinShot are trademarks of NetApp, Inc. in the United States and/or
other countries.
Apple is a registered trademark and QuickTime is a trademark of Apple Computer, Inc. in the United States
and/or other countries.
Microsoft is a registered trademark and Windows Media is a trademark of Microsoft Corporation in the
United States and/or other countries.
RealAudio, RealNetworks, RealPlayer, RealSystem, RealText, and RealVideo are registered trademarks
and RealMedia, RealProxy, and SureStream are trademarks of RealNetworks, Inc. in the United States
and/or other countries.
All other brands or products are trademarks or registered trademarks of their respective holders and should
be treated as such.
NetApp is a licensee of the CompactFlash and CF Logo trademarks.

TABLE OF CONTENTS
WELCOME .................................................................................................................................... 1
MODULE 1: DATA PROTECTION OVERVIEW............................................................................1-1
MODULE 2: DATA ONTAP SNAPSHOT COPY...........................................................................2-1
MODULE 3: SNAPRESTORE........................................................................................................3-1
MODULE 4: SNAPMIRROR ..........................................................................................................4-1
MODULE 5: SNAPVAULT.............................................................................................................5-1
MODULE 6: OPEN SYSTEMS SNAPVAULT ...............................................................................6-1
MODULE 7: SNAPLOCK...............................................................................................................7-1
MODULE 8: PROTECTION MANAGER AND PROVISIONING MANAGER................................8-1

Welcome to the NetApp
Protection Software
Administration Course
Course Part#:
STRSW-ILT-DATAPROT-REV3

WELCOME

2 2008 NetApp. All rights reserved.
Logistics
Welcome
Schedule (start time, breaks, lunch, close)
Telephones and messages
Food and drinks
Restrooms

LOGISTICS


SAFETY

Course Objectives
At the end of this module, you should be able to:
Explain what is data protection backup and recovery
Set up and maintain Snapshot copy
Plan and perform data recovery using SnapRestore
Replicate data using SnapMirror
Deploy SnapVault
for storage systems and open

system platforms
Deploy SnapLock
and LockVault
to control data
access and protection
Provision storage, protect and recover data using
Protection Manager and Provisioning Manager

COURSE OBJECTIVES

Course Agenda Day 1
Morning
Welcome
Data Protection Overview
Hands-on: Data Protection Overview
Data ONTAP Snapshot Copy
Hands-on: Data ONTAP Snapshot Copy
SnapRestore
Hands-on: SnapRestore
Afternoon
SnapMirror
Hands-on: SnapMirror

COURSE AGENDA DAY 1

Course Agenda Day 2
Morning
SnapVault
Hands-on: SnapVault
Afternoon
Open Systems SnapVault
Hands-on: Open Systems SnapVault
SnapLock
Hands-on: SnapLock

COURSE AGENDA DAY 2

Course Agenda Day 3
Morning
Afternoon
Hands-on: Protection Manager and Provisioning
Manager

COURSE AGENDA DAY 3

Information Sources
NOW
TM
(NetApp on the Web) Site
http://NOW.NetApp.com
NetApp University
http://www.netapp.com/us/services/university/
NetApp University Support
http://netappusupport.custhelp.com

INFORMATION SOURCES

Typographic Conventions
Words or characters you type, for example:
Enter the following command:
options httpd.enable on
Bold monospaced font
Command names, daemon names, and
option names.
Information displayed on the system console
or other computer monitors.
The contents of files.
Monospaced font
Book titles.
Word or characters that require special
attention.
Variable names or placeholders for
information you must supply, for example:
Enter the following command:
ifstat [-z] {-a interface}
Interface is the name of the interface for
which you want to view statistics.
Italic Font
Type of Information Convention

TYPOGRAPHIC CONVENTIONS

1-1 NetApp Protection Software Administration Data ONTAP 7.3: Data Protection Overview
MODULE 1: DATA PROTECTION OVERVIEW
Data Protection
Overview
Administration
Data ONTAP 7.3

INTRODUCTION
This module introduces the concept of data protection and disaster recovery.

Objectives
At the end of this module, you should be able to:
Explain why data needs protection
List the Data ONTAP disk-based backup
solutions
List the methods of managing data
Explain what is a data loss disaster
Describe the purpose a disaster recovery plan

OBJECTIVES

Data Protection Overview
Data protection means backing up data and
being able to recover it
Business data protection requirements are:
Fast recovery of accidentally deleted files; and
recovery from application crashes, data
corruption, and viruses
Archiving data for future use
Fast recovery from a disaster
Data protection for compliance regulation
purposes and referencing

DATA PROTECTION OVERVIEW
Data protection means backing up data and being able to recover it. You protect the data by
making copies of it so that it is available for restoration even if the original is no longer available.

Businesses need data backup and protection for the following reasons:

To protect data from accidentally deleted files, application crashes, data corruption, and
viruses
To archive data for future use
To minimize backup and recovery windows
Fast recovery from natural or human-caused disasters
Data protection for compliance regulation purposes and referencing

Depending on your data protection and backup needs, Data ONTAP offers a variety of features
and methods to ensure against accidental, malicious, or disaster-induced loss of storage system
data.

Disk-based Backup Solutions
Data ONTAP Snapshottechnology for daily
online backups
SnapRestore for near-instantaneous
recovery of files or entire file systems to an
earlier state
SnapMirror for automated data replication
SnapVault for disk-based backup and
recovery of NetApp storage systems and open
systems
SnapMirror Open Systems

DISK-BASED BACKUP SOLUTIONS

Data ONTAP Snapshot technology, enabling online Snapshot copies throughout the day,
provides online file recovery plus a potential replacement for time-consuming incremental tape
backups.
SnapRestore allows near-instantaneous recovery of individual files or entire volumes,
minimizing downtime to recover from virus infections or database corruption.
SnapMirror technology enables organizations to replicate data volumes/qtrees at high speeds
over a network, providing an up-to-date mirrored volume/qtree to ensure uninterrupted operation
in case of disaster.
SnapVault enables efficient disk-to-disk backup and recovery of both NetApp storage systems
and open systems.
Open Systems SnapVault leverages the block-level incremental backup technology found in
SnapVault to protect Windows, Linux, UNIX, and VMware systems running on mixed
storage.
SnapMirror for Open Systems allows you to recover your production data with almost no data
loss in the event of any disaster. SnapMirror for Open Systemsmaintains an up-to-the-second and
enterprise-wide consistent copy on your target infrastructure.

Data Management Solutions
Data ONTAP SnapLock technology
SnapLock Compliance for strict regulatory
environments
SnapLock Enterprise for organizations with self-
regulated data protection requirements
Automates data backup and recovery
Provides capabilities for disaster recovery (DR)
verification, testing, and failover process

DATA MANAGEMENT SOLUTIONS
Data ONTAP SnapLock technology is a software feature that allows companies to implement
the data permanence functionality of traditional write once, read many (WORM) storage in an
easier-to-manage, faster access, lower cost magnetic diskbased solution.

SnapLock Compliance is a comprehensive archival solution that meets current U.S. Securities
and Exchange Commission regulations for data retention.

SnapLock Enterprise is designed for organizations with self-regulated and best-practice
requirements for protecting digital assets with WORM-like storage devices.

Protection Manager and Provisioning Manager automate and simplify the management of
heterogeneous data and application backup and recovery. Protection Manager provides global
monitoring and alerting along with easy-to-use policies. Protection Manager simplifies common
data protection tasks and helps automate the SnapMirror and SnapVault family management.

Data Loss Disaster
Service on the network is lost for an extended
period of time
Can affect all the computing infrastructure
including storage systems, application servers,
networking and connectivity
Failures and Disasters
Application
Failures
Increasing Probability Increasing Downtime
Operational
Failures
Components
Failures
Site & Data
Center
Failures
Regional
Disasters

DATA LOSS DISASTER
A data loss disaster is a situation in which service from one physical site (for example, a building
or a corporate campus) on the network is lost for an extended period of time.

The following are examples of disasters:
Fire
Earthquake
Prolonged power outages at a site
Prolonged loss of connectivity from clients to the storage system at a site

When a disaster occurs, it can affect the entire computing infrastructure including storage
systems, application servers, networking connectivity, and client connectivity. As companies
have become increasingly dependent on data and access to that data, DR has become a major
concern. The ability to provide a highly available, 24x7 operation with disaster recovery
capabilities is very desirable. Levels of protection may be needed in the data center, at a campus
level, at a regional level, or a combination of all three.

Data Protection and Disaster Recovery
UNIX
Server
Windows
Server
DR Site
Storage
System
Monthly
Full Backup
to Tape
WAN
Hourly/Daily
Incremental Backup
Storage System
Only changed blocks
stored in daily or weekly
Snapshot copies
Data Center Remote Office
Storage System
WAN
LAN LAN
Data
Replication

DATA PROTECTION AND DISASTER RECOVERY
You need an appropriate plan to perform data protection and disaster recovery. In this scenario,
the primary data center offloads the data and provides data protection to a disaster recovery site.

Disaster Recovery Plan
Before you deploy a backup strategy, you
need to set up a disaster recovery plan
To ensure continuity of operations
To guarantee availability of critical resources
To quickly recover vital business data
The DR solution must be well-planned,
rehearsed, tested and documented before a
disaster occurs

DISASTER RECOVERY PLAN
There are several approaches to protect data and maintain data availability in the face of
hardware, software, or even site failures. However, before you deploy a backup strategy, purchase
redundant hardware components, or replicate data between sites, you need to set up a disaster
recovery plan.

A disaster recovery plan ensures the continuity of operations, the availability of critical resources
and lists how to recover vital business operations successfully and quickly in the event of a
disaster. The DR solution must be well-planned, rehearsed, tested, and documented before a
disaster occurs.

Considerations for Disaster Recovery
When deploying a disaster recovery solution,
consider:
The distance between the data center and the
disaster recovery site
Which data needs protection
The Recovery Point Objective (RPO)
The maximum age of the data to be recovered
The Recovery Time Objective (RTO)
The length of time required to recover

CONSIDERATIONS FOR DISASTER RECOVERY
When deciding which type of Disaster Recovery solution to implement, you have to consider the
following:
How far away from the primary storage site will the disaster recovery site be located? The
distance between the main production center and the DR site depends on the likely
geographic impact of the disaster that the customer is protecting against.
Which applications need protection?
What are the Recovery Point Objective (RPO) and the Replication Time Objective (RTO) in
case of a disaster?

RPO is the maximum age of the data that the company must be able to recover in the event of a
disaster. This parameter defines the amount of time for which work may be lost in the event of an
unplanned outage at the primary site. It is used to define how frequently data is replicated to the
disaster recovery site. A zero RPO implies no data loss, which can only be addressed by a
synchronous replication solution. For higher RPO, an asynchronous replication solution with
RPO in minutes or hours is flexible and cost-effective.

RTO is the length of time required to recover from a disaster. This parameter defines how
quickly you need to fail over to a disaster recovery site in seconds, minutes, hours, or days.
Customers have to typically make tradeoffs between RPO, RTO and cost. The target storage, the
networking infrastructure, the software license and the deployment costs all contribute to the
overall disaster recovery solution total cost.

Summary
In this module, you should have learned to:
Explain why data needs protection
List the Data ONTAP disk-based backup
solutions
List the methods of managing data
Explain what is a data loss disaster
Describe what is a disaster recovery plan

SUMMARY

Exercise
Module 1: Data Protection Overview
Estimated Time: 10 minutes

EXERCISE

2-1 NetApp Protection Software Administration: Snapshot Copies
MODULE 2: DATA ONTAP SNAPSHOT COPY
Data ONTAP
SnapshotCopy
Administration
Data ONTAP 7.3

INTRODUCTION
This module discusses what Snapshot copies are and how to manage them.

Objectives
By the end of this module, you should be able to:
Describe the function of Snapshot copies
Describe how Snapshot copies consume disk
space
Create and schedule Snapshot copies
Explain how to access Snapshot copies
Restore files from Snapshot copies
Manage Snapshot copies

OBJECTIVES

Overview
A Snapshot copy is a read-only image of a
volume or an aggregate that captures the state
of the file system at a point in time
Allows users to browse backed-up files online
to perform restoration upon request
Data ONTAP backup, mirror, replication, and
restore services are based on Snapshot
technology
You can store up to 255 Snapshot copies per
volume

OVERVIEW
A Snapshot copy is a frozen, read-only image of a traditional volume, a flexible volume, or an
aggregate that captures the state of the file system at a point in time.
Snapshot technology is the foundation of the Data ONTAP backup and recovery services.
SyncMirror
, SnapMirror, SnapVault, SnapRestore, FlexClone
, SnapManager
, and SnapDrive

software are based on Snapshot technology.

Snapshot copies enable end-users to recover older versions or sets of files that were accidentally
changed or deleted with minimum system administrator intervention.
You can store up to 255 Snapshot copies per volume and as well specify the percentage of disk
space that Snapshot copies can occupy.

A B C
Active File System
MYFILE
Theory of Operation
SNAP1
MYFILE is made of disk blocks A, B, and C
The active file system is captured in Snapshot copy SNAP1
SNAP1 points to blocks A, B, and C and does not use additional disk space

THEORY OF OPERATION
Data ONTAP preserves pointers to all the disk blocks currently in use at the time the Snapshot
copy is created.
In this illustration, the active file system contains a file named MYFILE made of three blocks: A,
B, and C.
Based on a schedule or in response to the snap create command, the active file system is
captured in a Snapshot copy named SNAP1. This Snapshot copy uses almost no additional disk
space because the version of MYFILE within this Snapshot copy are the same blocks as the
blocks for MYFILE in the active file system.

Theory of Operation (Cont.)
A B C
Active File System
MYFILE
SNAP1
C block is modified; WAFL writes the change in new disk block C
MYFILE is now made of disk blocks A, B, and C
Snapshot copy SNAP1 still points to disk blocks A, B, and C
C

THEORY OF OPERATION (CONT.)
When a file is changed, the Snapshot copy still points to the disk blocks where the file existed
before it was modified, and changes are written to new disk blocks. Snapshot copies begin to
consume extra space only when corresponding files in the active file system are changed or
deleted.
In the illustration, a client modifies some data in MYFILE, causing the contents of block C to
change. The WAFL (Write Anywhere File Layout) file system uses a copy-on-write policy that
writes the modified block to a new location on disk, creating block C. The active file system
version of MYFILE is now composed of disk blocks A, B, and C, whereas the Snapshot copy
SNAP1 still points to blocks A, B and C.

In addition to the disk space used by block C in the modified active file system, disk space used
by the original blocks A, B, and C is still reserved in the Snapshot copy SNAP1. Deleting
MYFILE in the active file system wont free-up disk blocks A, B, and C because the Snapshot
copy SNAP1 still points to those blocks.

Automatic Snapshot Copies
Data ONTAP provides a default Snapshot schedule for
each volume and aggregate
Use the snap sched command to display the
Snapshot schedule
This example is the default schedule for volumes:
System> snap sched vol0
Volume vol0: 0 2 6@8,12,16,20
No weekly Snapshot copies are created
Two nightly Snapshot copies are kept
Six hourly Snapshot copies are kept
Hourly Snapshot copies are taken at 8 a.m., noon, 4 p.m., and 8 p.m.

AUTOMATIC SNAPSHOT COPIES
Data ONTAP provides a default Snapshot copies schedule for each volume and aggregate. This
schedule creates and deletes Snapshot copies automatically. You use the snap sched
command to display the Snapshot copies schedule.
The example shown here is the default schedule for the root volume vol0:
System> snap sched vol0
Volume vol0: 0 2 6@8,12,16,20

0: no weekly Snapshot copies are taken.
2: the two most recent nightly Snapshot copies are retained.
6: the most recent six hourly Snapshot copies are kept.
8,12,16,20: hourly Snapshot copies are taken at 8 a.m., noon, 4 p.m., and 8 p.m. (24-hour clock).

The following example is the default schedule for aggregate aggr0:
System> snap sched A aggr0
Aggregate aggr0: 0 1 4@9,14,19

Scheduling Snapshot Copies
New volumes inherit the Snapshot schedule
from the root aggregate
Use the snap sched command to configure
the schedule to fit your needs
snap sched volume_name weekly nightly hourly@<hour_list>
Weekly Snapshot created every Sunday at midnight
Nightly Snapshot copies created every night at midnight
Hourly Snapshot copies created on the hour
Hourly Snapshot copies created at the specified hours
Volume name
Snapshot copies retention count

SCHEDULING SNAPSHOT COPIES
When you create a new volume, the volume inherits the Snapshot copies schedule from the root
aggregate. After you use the volume for a while, check how much disk space the Snapshot copies
consume and how often users need to recover lost files, and then adjust the schedule as necessary.
Use the snap sched command to configure the schedule to fit your needs.

snap sched volume_name weekly nightly hourly@<hour_list>

A value in the weekly, nightly and hourly fields specifies how many Snapshot copies will be
retained for archiving. A zero in the weekly, nightly and hourly fields means that no Snapshot
copies are created.
Weekly Snapshot copies are created every Sunday at midnight.
Nightly Snapshot copies are created every night at midnight, except when a weekly Snapshot
copy is scheduled to occur at the same time.
Hourly Snapshot copies are created on the hour or at the specified hours, except at midnight if
a nightly or weekly Snapshot copy is scheduled to occur at the same time.

Weekly, nightly, and hourly Snapshot copies are named respectively weekly.n, nightly.n, and
hourly.n, where n is an integer. The higher the value of n, the older the Snapshot copy. Whenever
the Snapshot copies schedule creates a new Snapshot copy of a particular type, it deletes the
oldest one and renames the existing ones.

Disabling Snapshot Copies
To disable automatic Snapshot copies for a
given volume use either one of the following
commands:
snap sched volume_name 0 0 0
Removes the schedule
vol options volume_name nosnap on
Disables Snapshot copies but preserves the
schedule

DISABLING SNAPSHOT COPIES
To disable automatic Snapshot copies for a given volume, use either one of the following
commands:
snap sched volume_name 0 0 0

vol options volume_name nosnap on
Setting the volume option nosnap preserves the schedule while disabling it. This method
makes it easy to enable the schedule at a later date.

Creating and Deleting Snapshot Copies
You can create Snapshot copies manually at
any time using the command:
snap create volume_name snapshot_name
To delete a Snapshot copy, use the command
syntax:
snap delete volume_name snapshot_name
To delete all Snapshot copies within a volume,
use the a option:
snap delete a volume_name

CREATING AND DELETING SNAPSHOT COPIES
You can create Snapshot copies manually at any time using the snap create command.

snap create volume_name snapshot_name

To delete a Snapshot copy, use the command syntax:

snap delete volume_name snapshot_name

To delete all Snapshot copies within a volume, use the a option.

snap delete a volume_name

Automatic Snapshot Deletion
Use the snap autodelete command to define and
enable a policy for automatically deleting Snapshot
copies
This example lists the default autodelete settings for
volumes
System> snap autodelete vol0 show
snapshot autodelete settings for vol0:
state : off
commitment : try
trigger : volume
target_free_space : 20%
delete_order : oldest_first
defer_delete : user_created
prefix : (not specified)

AUTOMATIC SNAPSHOT DELETION
The snap autodelete command allows system administrators to define and enable a policy
for automatically deleting Snapshot copies. For example, you can define which Snapshot copies
(oldest or newest) will be automatically deleted when the volume is nearly full or when the
Snapshot reserve reached a specified threshold. You can also choose whether a Snapshot copy
linked to a backup, a replication, or a clone service will be automatically deleted.
snap autodelete volume_name on option value
on enables the Snapshot copy autodelete policy.

Options and values can be one or more of the following:
commitment try, disrupt
trigger volume, snap_reserve, space_reserve
target_free_space 1-100
delete_order oldest_first, newest_first
defer_delete scheduled, user_created, prefix, none
prefix <string>

For details on the snap autodelete command syntax, options, and values, refer to the Data
ONTAP Data Protection Online Backup and Recovery Guide.
CONFIGURING AUTOMATIC FREE SPACE PRESERVATION FOR A FLEXVOL
VOLUME
When you configure a FlexVol volume for automatic free space preservation, the FlexVol
volume attempts to provide more free space when it becomes nearly full. It can provide more

free space by increasing its size or by deleting Snapshot copies, depending on how you have
configured the volume.
The following command allows you to configure how FlexVol will react to a nearly full volume:
vol options vol_name try_first [volume_grow | snap_delete]
If you specify volume_grow, Data ONTAP attempts to increase the volumes size
before deleting any Snapshot copies. Data ONTAP increased the volume size based on
specifications you provided using the vol autosize command.
If you specify snap_delete, Data ONTAP attempts to create more free space by
deleting Snapshot copies, before increasing the size of the volume. Data ONTAP deletes
Snapshot copies based on the specifications you provided using the snap
autodelete command.

Snapshot Reserve
Specifies a set of percentage of disk
space for Snapshot copies
20% per volume (default)
5% per aggregate (default)
Snapshot copies can exceed the
Snapshot reserve and consume
disk space available to the active
file system
Use the snap reserve command
to change the % of the Snapshot
reserve
Aggregate Space
90% 80%
20%
Volume Space
snap reserve
snap reserve 5%
WAFL Overhead
10%
Active File
System

SNAPSHOT RESERVE
The Snapshot reserve specifies a set percentage of disk space for Snapshot copies. By default, the
Snapshot reserve per volume is 20% of disk space and 5% of disk space per aggregate.
The Snapshot reserve can be used only by Snapshot copies, not by the active file system. If the
active file system runs out of disk space, any disk space still remaining in the Snapshot reserve is
not available for active file system use. Although the active file system cannot consume disk
space reserved for Snapshot copies, Snapshot copies can exceed the Snapshot reserve and
consume disk space normally available to the active file system. Note that aggregate Snapshot
copies are not allowed to grow out of the Snapshot reserve.
Whenever Snapshot copies consume more than 100% of the Snapshot reserve, the volume is in
danger of becoming full. In this case, you can create files only after you delete enough Snapshot
copies. When deleting files in the active file system, Data ONTAP reassigns the freed space from
the active file system to the Snapshot reserve.
Whenever Snapshot copies consume more than 100% of the Snapshot reserve, future Snapshot
copies can grow into the volume data space. In this case, the df command will show a larger
number for the used column for the volume but does not specify that the used column is a
combination of both active file system blocks and Snapshot reserve blocks.

The snap reserve command allows system administrators to change the percentage of disk
space used for the Snapshot reserve.
snap reserve volume_name percent

To display the current Snapshot reserve for a volume, use the command syntax:
snap reserve volume_name

To display the current Snapshot reserve for an aggregate, use the A option.
snap reserve A aggregate_name

Monitoring Snapshot Disk Consumption
Use the df command to display the amount of
free space
The Snapshot reserve displays separately from
the active file system
Example:

MONITORING SNAPSHOT DISK CONSUPTION
Use the df command to display the amount of total, used, and available disk space in one or
more volumes or aggregates. The default, shown above, displays the number of 1,024-byte
blocks, but you can choose to display the disk space in megabytes, gigabytes, and so on by using
the following options.

-h causes Data ONTAP to scale to the appropriate size
-t shows terabytes
-g gigabytes
-m megabytes
-k kilobytes

On a separate line, the df command displays statistics about how much space is consumed by
the Snapshot copies for each volume or aggregate. Blocks that are referenced by both the active
file system and by one or more Snapshot copies are counted only in the active file systems.

Rate of Data Change
Use the snap delta command to determine the rate of data
change between Snapshot copies
Can be run against a single Snapshot copy, multiple Snapshot
copies, or all volumes
System> snap delta vol0
Volume vol0 working...
From Snapshot To KB changed Time Rate (KB/hour)
------------- ------------------ ---------- ---------- --------------
hourly.0 Active File System 149812 0d 03:43 40223.985
hourly.1 hourly.0 326232 0d 08:00 40779.000
hourly.2 hourly.1 2336 1d 12:00 64.888
hourly.3 hourly.2 1536 0d 04:00 384.000
hourly.4 hourly.3 1420 0d 04:00 355.000
nightly.0 hourly.4 1568 0d 12:00 130.666
hourly.5 nightly.0 1400 0d 04:00 350.000
nightly.1 hourly.5 10800 201d 21:00 2.229
Summary...
From Snapshot To KB changed Time Rate (KB/hour)
------------- ------------------ ---------- ---------- --------------
nightly.1 Active File System 495104 204d 20:43 100.697

RATE OF DATA CHANGE
You use the snap delta command to determine the rate of data change between Snapshot
copies on a volume. The command can be run against a single Snapshot copy, multiple Snapshot
copies, or all volumes on the storage system.

The first row displays the differences between the youngest Snapshot copy and the active file
system.
Each row displays the names of the two Snapshot copies being compared, the amount of data
that changed between them, how long the first Snapshot copy listed has been in existence,
and how fast the data changed between the two Snapshot copies.
The summary displays the rate of change between the oldest Snapshot copy and the active file
system.

Reclaimable Space
Use the snap reclaimable command to
display the amount of space you can reclaim
by deleting Snapshot copies
snap reclaimable vol_name snapshot_name
Example
System>snap reclaimable vol1 hourly.4
hourly.5 nightly.0
Processing (Press Ctrl-C to exit)...
snap reclaimable: Approximately 240
kbytes would be freed.

RECLAIMABLE SPACE
You use the snap reclaimable command to display the amount of space you can reclaim by
deleting one or more Snapshot copies in a volume.
snap reclaimable vol_name snapshot_name
The amount of space displayed is an approximation because writing to the volume, creating
Snapshot copies, or deleting Snapshot copies cause the reclaimed amount to change.

This example displays the amount of space reclaimed by deleting the hourly.4, hourly.5, and
nightly.0 Snapshot copies in the vol1 volume:

System> snap reclaimable vol1 hourly.4 hourly.5 nightly.0
Processing (Press Ctrl-C to exit) ...
snap reclaimable: Approximately 240 kbytes would be freed.

NOTE: The snap reclaimable command does not consider blocks that are held by multiple
Snapshot copies.

Snapshot Statistics
Use the snap list command to display the
amount of disk space consumed by Snapshot
copies
Helps to determine an appropriate Snapshot reserve
System> snap list vol0
Volume vol0
working...
%used %total date name
------- ------ ------------ --------
0% (0%) 0% (0%) Apr 20 12:00 hourly.0
17% (20%) 1% (1%) Apr 20 10:00 hourly.1
33% (20%) 2% (1%) Apr 20 08:00 hourly.2

SNAPSHOT STATISTICS
The snap list command shows the amount of disk space consumed by Snapshot copies in a
specified volume. This command enables you to see how much disk space each Snapshot copy is
using and helps you determine an appropriate Snapshot reserve.
Example:

System> snap list
Volume vol0
working...
%used %total date name
------- ------ ------------ --------
0% (0%) 0% (0%) Apr 20 12:00 hourly.0
17% (20%) 1% (1%) Apr 20 10:00 hourly.1
33% (20%) 2% (1%) Apr 20 08:00 hourly.2

The % used column shows the relationship between accumulated Snapshot copies and the total
disk space consumed by the active file system. Values in parentheses show the contribution of
this individual Snapshot copy. The % used number is the most useful for planning the Snapshot
reserve because it is more likely to remain constant as the file system fills.

The % total column shows space consumed by Snapshot copies as a percentage of total disk space
(both space used and space available) in the volume. Values in parentheses show the contribution
of this individual Snapshot copy.

Accessing Snapshot Copies
Snapshot copies are stored in the .snapshot
directory in the root of each volume
To make the .snapshot directory visible, use the
options:
For CIFS clients
options cifs.show_snapshot on
For NFS clients
options nfs.hide_snapshot off
To turn off client access to Snapshot copies, use
the vol options command:
vol options volname nosnapdir off

ACCESSING SNAPSHOT COPIES
Snapshot copies are stored in a directory named .snapshot that can be made accessible to
Windows and UNIX clients so users can access and recover their own files without assistance.
Users can gain access to Snapshot copies depending on the file-sharing protocol usedNFS or
CIFS. Snapshot files carry the same read permissions as the original file. A user who has
permission to read a file in the volume can read that file in a Snapshot copy. Snapshot copies do
not have write permissions.

By default, CIFS clients cannot see the .snapshot directory. Use the
cifs.show_snapshot option to allow CIFS users to see the .snapshot directory.

options cifs.show_snapshot on

The .snapshot directory can be made visible in a directory listing or Internet Explorer
display if the client operating system is configured to show hidden files.

By default, NFS clients can see the .snapshot directory. Use the nfs.hide_snapshot
option to disable Snapshot copies access. If this option is turned on, the .snapshot directory itself is
visible, but the actual Snapshot copies will be hidden.

options nfs.hide_snapshot [ on | off ]

By default access to Snapshot copies at the volume level is enabled. You might want to disable
client access to Snapshot copies for security reasons or to prevent access to corrupted or virus-
infected files. To turn off access to Snapshot copies, use the vol options command.

vol options volname nosnapdir on

Recovering Data
Copying data from a Snapshot copy
Method used by CIFS and NFS clients to
perform on-demand restore
1. Access the .snapshot directory
2. Locate the Snapshot copy
3. Copy the data to the original location or to a
new location
Recover data using SnapRestore
Preferred method to revert a large data set
Requires the snaprestore license
Supports single file, volume and aggregate
restores

RECOVERING DATA
You might need to restore a file, an entire volume or a whole aggregate from a Snapshot copy if
the data was accidentally erased or corrupted.
If CIFS and NFS clients have access to Snapshot copies, users can restore files from Snapshot
copies without system administrator intervention. Users have to access to the .snapshot
directory at the root of the mounted file system, and then locate the Snapshot copy that contains
the version of the file to recover and copy the data to their original location (the file will be
overwritten) or to a new location. NOTE: When you copy the data to a new location, you will
need enough disk space for the original copy and the new copy.

If you have purchased the SnapRestore option, you can automatically revert a local volume, an
aggregate, or a file to the state it was in when a particular Snapshot copy was taken. SnapRestore
carries out Snapshot copy restoration more quickly and uses less disk space than an administrator
can achieve by manually copying data from a Snapshot copy.

The SnapRestore service requires the snaprestore license and system administrator access to
the storage system from which the Data ONTAP snap restore command will be issued.

For more information about the SnapRestore service, refer to the SnapRestore module of this
course.

Summary
Describe the function of Snapshot copies
Describe how Snapshot copies consume
disk space
Create and schedule Snapshot copies
Explain how to access Snapshot copies
Restore files from Snapshot copies
Manage Snapshot copies

SUMMARY

Exercise
Module 2: Data ONTAP Snapshot
Copy

EXERCISES

3-1 NetApp Protection Software Administration Data ONTAP 7.3: SnapRestore
MODULE 3: SNAPRESTORE
SnapRestore

Administration
Data ONTAP 7.3

INTRODUCTION
This module describes how to restore data to a file or volume using the Data ONTAP
SnapRestore feature.

Objectives
Explain how SnapRestore works with Snapshot
copies
Describe what SnapRestore reverts
Revert a volume or a file using SnapRestore
Explain how SnapRestore works with SnapMirror
Describe the effects of SnapRestore on backup

operations

OBJECTIVES

Overview
SnapRestore reverts a file system back to any
specified Snapshot copy
Fast online restores of files and volumes
Multiple recovery points
Easy recovery process based on a single
command input
Requires the snaprestore license code
Use SnapRestore to recover from data
corruption or to revert a file system to pretest
conditions

OVERVIEW
SnapRestore enables you to quickly revert a local volume or a file on a storage system to the state
it was in when a particular Snapshot copy was taken. In most cases, reverting a file or volume is
much faster than restoring files from tape or copying files from a Snapshot copy to the active file
system.
You use SnapRestore to recover from data corruption. If a primary storage system application
corrupts data files in a volume, you can revert the volume or specified files in the volume to a
Snapshot copy taken before the data corruption. You can also use SnapRestore if you are testing a
volume or file and want to restore that volume or file to pretest conditions.
You must purchase and install the snaprestore license code to enable and use the
SnapRestore service.

When to Use SnapRestore
To decide which recovery method to use, you
have to consider:
The size of the file system
The available space
Where the data will be restored
Large File
System
Small File
System
SnapRestore
Copying files from Snapshot copy
Restore from tape

WHEN TO USE SNAPRESTORE
When restoring large quantities of data, it takes a long time to either copy files from a Snapshot
copy or restore them from tape. In this case, SnapRestore is the preferred method for
recovering data because it saves time.
Also, if the file(s) to be recovered are larger than the amount of free space in the active file
system, copying from a Snapshot copy is not possible without the creation of additional space. In
this case, SnapRestore can quickly recover the file, and save you the time it would take to
make the necessary space available.

If the amount of data to recover is small, it is easier to copy the files from a Snapshot copy or
restore the files from tape than to use SnapRestore for these reasons:
You can preserve the data in other storage systems in the same volume
If the corrupted volume is a root volume, you can avoid the reboot if necessary to revert a
root volume

Time
How SnapRestore Works
The active file system, or AFS, points at each
of its 4K data blocks
AFS

HOW SNAPRESTORE WORKS
In this illustration, the active file system points at each of its 4K data blocks. In this example,
there are five blocks in the active file system.

How SnapRestore Works (Cont.)
The active file system is captured in a first
Snapshot copy named hourly.0
hourly.0 points at the same blocks as the AFS
Time
AFS hourly.0

HOW SNAPRESTORE WORKS (CONT.)
In response to the snap create command input; the active file system is captured in a first
Snapshot copy named Snap1.
Data ONTAP preserves pointers to all the disk blocks currently in use at the time the Snapshot
copy is created. Hourly.0 does not use additional disk space because it points at the same blocks
as the active file system.

In this example, how many blocks are owned by the active file system? Six
How many blocks does the Snapshot copy point to? Five
How many blocks are owned by the Snapshot copy? Three

Automatic Snapshot copies have names like hourly and daily that are followed by a number. The
most recent Snapshot copy will have the number 0. When the next Snapshot copy is created,
hourly.0 will become hourly.1 and the new Snapshot copy is called hourly.0.

As time goes by, some new files are created
and other files are modified
New and modified data is written to new 4K
blocks
Time
AFS hourly.0

As time goes by, new files are created and others are modified. New or modified data is written to
new 4K blocks. The Snapshot copy hourly.0 still points to the disk blocks where the files existed
before they were modified.
In this example, how many blocks are owned by the active file system?
How many blocks does the Snapshot copy, hourly.0 point to?
How many blocks are owned by the Snapshot copy, hourly.0?

The AFS continues to be modified while a new
Snapshot copy is taken
The original hourly.0 becomes hourly.1
Some data blocks have new pointers from the
AFS and from hourly.0 and hourly.1
Time
AFS hourly.1 hourly.0

The AFS continues to be modified while a new Snapshot copy, hourly.0, is taken. Some data
blocks have new pointers from the active file system and from the Snapshot copies hourly.0 and
hourly.1.
In this example, how many blocks are owned by the active file system?

And so on
Time
hourly.1 hourly.3 hourly.2
AFS hourly.0

The process continues. The active file system changes while new Snapshot copies are created.

A virus has attacked your data
The blocks that make the AFS are inconsistent
hourly.0 may point to inconsistent blocks as well
You decide to revert to hourly.3 using
SnapRestore technology
Time
hourly.1 hourly.3 hourly.2
AFS hourly.0

In the present scenario, a virus has corrupted your data. The blocks that make the active file
system are inconsistent and the Snapshot copy hourly.0 may point to inconsistent blocks as well.
You decide to revert to the Snapshot copy to hourly.3 using SnapRestore technology.
Do you need to go all the way back to hourly.3?

All data that existed before the reversion is gone
Everything that was created after the former
hourly.3 Snapshot copy ceases to exist
Hourly.3 is renamed to what it was called back
then: hourly.0
Time
Gone! hourly.3 Gone!
Gone! Gone!

After you select a Snapshot copy for reversion, all data that existed before the reversion is gone.
All Snapshot copies that were taken after the selected Snapshot copy are lost.
As illustrated, after you revert the active file system to hourly.3, you no longer have access to the
more recent Snapshot copy hourly.2, nor hourly.1 and hourly.0. This is because at the creation
time of hourly.3, the other Snapshot copies did not exist.

All blocks included in hourly.0 (previously
hourly.3) become the active file system
Time
hourly.0 AFS

After the reversion completes, the active file system is reverted to contain the same data and
timestamps as it did when the Snapshot copy hourly.3 was taken.

What SnapRestore Reverts
SnapRestore reverts all file contents
When reverting an aggregate, all FlexVol
volumes in the aggregate are reverted
SnapRestore does not revert volume attributes
such as:
Snapshot copies schedule
Volume option settings
RAID group size
Maximum number of files per volume

WHAT SNAPRESTORE REVERTS
SnapRestore reverts all file contents. SnapRestore does not revert attributes of a volume,
such as the Snapshot copies schedule, volume option settings, RAID group size, and maximum
number of files.

SnapRestore Rules
You cannot undo a SnapRestore reversion
Snapshot copy deletions are irrevocable
You cannot revert a volume to recover a deleted
Snapshot copy
While SnapRestore is in progress, Data
ONTAP cannot delete and create Snapshot
copies
Scheduled Snapshot copies will be suspended
for the duration of the restore
A dump or other command attempts that depend
on creating a Snapshot copy will fail

SNAPRESTORE RULES
Be sure that you understand the following rules before using SnapRestore.
You cannot undo a SnapRestore reversion to change the volume back to the state it was in
prior to the reversion.

Snapshot copies deletions are irrevocable. If you delete a Snapshot copy, you cannot recover
the Snapshot copy by using SnapRestore. For example, if you delete the hourly.2
Snapshot copy and revert the volume to the hourly.1 Snapshot copy, you cannot find hourly.2
after the reversion. Although hourly.2 existed at the creation time of hourly.1,
SnapRestore cannot revert the contents of hourly.2 because you have already deleted it.

Snapshot copies cannot be created or deleted while a SnapRestore operation is in
progress. Scheduled Snapshot copies on the volume will be suspended for the duration of the
restore. As well, if a dump or other command attempts to execute while SnapRestore is in
progress, it will fail.

Reverting a Volume
1. Verify that the volume is online and writable
2. List the Snapshot copies in the volume
snap list vol_name
3. Notify network users
4. Initiate the restore
snap restore -t vol -s snapshot_name
/vol/vol_name
Reverting a root volume
Restore configuration files including the
registry
Will initiate a system reboot

REVERTING A VOLUME
Follow these steps to revert a volume.
1. Verify that the volume is online and writable.

2. List the Snapshot copies in the volume.
System> snap list vol_name

3. Notify network users that you are going to revert a volume so that they know that the data in
the volume will be replaced by that of the selected Snapshot copy. NFS users should dismount the
files and directories in the volume before the reversion. If they do not dismount the files and
directories, they might see the stale file handle error message after the reversion.

4. If you know the name of the Snapshot copy for reverting the volume, enter the following
command:
System> snap restore -t vol -s snapshot_name /vol/vol_name
You must use the -t option followed by vol to indicate that a volume SnapRestore is to be
performed. Data ONTAP displays a warning message and prompts you to confirm your decision
to revert the volume. Press Y to confirm that you want to revert the volume. If you do not want to
proceed enter Ctrl-C.

If you do not know the name of the Snapshot copy, you can list the Snapshot copies available for
volume reversion using the command:
System> snap restore -t vol /vol/vol_name

When reverting a root volume, option settings applicable to the entire storage system,
configuration files, and the registry are reverted to the version that was in use at the Snapshot
copy creation time. Note that reverting a root volume initiates a system reboot.

Reverting a File
1. Verify that the volume is online and writable
2. List the Snapshot copies in the volume
snap list /vol/vol_name
3. Notify network users
4. Initiate the reversion
snap restore -t file -s snapshot_name
path_and_file_name
Use the r option to revert a file to a different
location
snap restore -t file -s snapshot_name
r new_path_and_file_name
path_and_file_name

REVERTING A FILE
Follow these steps to revert a single file.
1. Verify that the volume is online and writable.

2. List the Snapshot copies in the volume.
System> snap list /vol/vol_name

3. Notify network users that you are going to revert a file.

4. If you know the name of the Snapshot copy, initiate the restore using the command:
System> snap restore -t file -s snapshot_name
path_and_file_name

-t file indicates that a file SnapRestore is to be performed.
path_and_file_name is the complete path to the name of the file to be reverted.
Data ONTAP displays a warning message and prompts you to confirm your decision to revert the
file. Press Y to confirm that you want to revert the file. If you do not want to proceed enter
Ctrl-C.
If the file already exists in the active file system, it will be overwritten with the version in the
Snapshot copy.

Use the r option to restore a file to a different location:
System> snap restore -t file -s snapshot_name -r
restore_as_new_path path_and_file_name
-r restore_as_new_path restores the file to a location different from (but in the same
volume as) the location in the Snapshot copy.

If you do not know the name of the Snapshot copy, you can list the Snapshot copies available for
file reversion using the command:
System> snap restore -t file /vol/vol_name

File Reversion Considerations
A file can only be restored to an existing
directory
Files other than normal files (files with NT
streams) and LUNs are not restored
The single-file restore operation will stop if the
volume runs out of space
A performance penalty is encountered during
Snapshot copies deletion
Tree, user and group quota limits are not
enforced
Free space in the active file system

FILE REVERSION CONSIDERATIONS
Some notes concerning SnapRestore file reversion:
A file can only be restored to an existing directory. The SnapRestore default is to restore the
file to its original directory path. The -r option can be used to specify a different directory so
long as the directory already exists.

To use the single-file SnapRestore feature you must have enough free space on the volume to
recover the single file. The single-file restore operation will stop if the volume runs out of
space.

When you do a single-file SnapRestore from a given Snapshot copy, the file is brought back
to the active file system. All Snapshot copies that were taken after the selected Snapshot copy
are lost. A performance penalty is encountered during Snapshot copies deletion, because the
active maps across all Snapshot copies need to be checked.

Tree, user and group quota limits are not enforced for the owner, group and tree in which the
file is being restored. Thus if the user, group or tree quotas are exceeded, /etc/quotas
will need to be altered after the single-file SnapRestore operation has completed. Then quota
resize will need to be run.

SnapRestore and SnapMirror
You can revert a source volume but not a
destination volume
You can revert to any Snapshot copy,
including SnapMirror Snapshot copies
DO NOT select a Snapshot copy taken before
a SnapMirror Snapshot copy
Incremental update will fail
The relationship must be reinitialized

SNAPRESTORE AND SNAPMIRROR
You can revert a volume that is a source volume for SnapMirror data replication, however you
cannot revert a volume that is currently a SnapMirror destination volume.
You can revert to any Snapshot copy that is displayed by the snap list command. This can be
a regular volume Snapshot copy or a Snapshot copy created by SnapMirror for data replication.

Do not select a Snapshot copy taken before a SnapMirror Snapshot copy. If you do this, after the
reversion, the volume will not contain the SnapMirror Snapshot copy that is needed for the
incremental update. The SnapMirror relationship must be reinitialized.

Example

Volume vol1 is the source volume for SnapMirror replication. It contains two Snapshot copies:
hourly.0 and SystemB(0050404361)_vol1.0.
hourly.0 was taken earlier than SystemB(0050404361)_vol1.0. A system administrator reverts
vol1 to hourly.0.

SystemA> snap list vol1
Volume vol1
date name
-------- --------
Sep 13 20:45 hourly.0 SnapRestore
Sep 13 21:00 SystemB(0050404361)_vol1.0 (snapmirror)

As a result, the SystemB(0050404361)_vol1.0 Snapshot copy disappears after the
reversion and the next incremental update aborts. The relationship must be reinitialized again.

SnapRestore and Backup Operations
After a reversion, incremental backup and
restore operations can no longer rely on the
active file system timestamps
Recommendations
After the reversion, perform a level-0 backup
When restoring from tape, use only backups
created after the volume reversion

SNAPRESTORE AND BACKUP OPERATIONS
Because all files in a reverted volume have timestamps that are the same as those when the
selected Snapshot copy was created, the Data ONTAP dump and restore commands are
affected. After a reversion, incremental backup and restore operations can no longer rely on
timestamps to determine what data needs to be backed up and restored.

Recommendations
After reverting a volume, perform a level-0 backup of the volume. After the level-0 backup is
finished, Data ONTAP can correctly perform subsequent incremental backups.
If you need to restore data from tape to this volume, use only backups created after the
volume reversion.

Summary
In this module, you should have learned:
How SnapRestore works
What SnapRestore does and does not
revert
How to revert a single file or an entire
volume
The effects of reverting a root volume
Important effects of SnapRestore on
SnapMirror replication and backup
operations

SUMMARY

Exercise
Module 3: SnapRestore

EXERCISES

4-1 NetApp Protection Software Administration Data ONTAP 7.3: SnapMirror
MODULE 4: SNAPMIRROR
SnapMirror

Administration
Data ONTAP
7.3

INTRODUCTION
This module discusses the role of SnapMirror in data protection and disaster avoidance, and
introduces participants to SnapMirror asynchronous and synchronous replication.

Objectives
Explain the SnapMirror Async, Sync and Semi-
Sync modes of operation
Describe how Volume SnapMirror and Qtree
SnapMirror replicate data
Configure SnapMirror
Perform advanced SnapMirror operations
Explain SnapMirror performance impact

OBJECTIVES

Features and Benefits of SnapMirror
A fast and flexible enterprise solution that
addresses critical applications areas:
Data migration
Data replication
Remote access and load sharing
Disaster recovery
Remote tape archival

FEATURES AND BENEFITS
SnapMirror provides a fast and flexible enterprise solution for replicating data over local area,
wide area, and Fibre Channel networks. SnapMirror addresses multiple application areas such as
mission-critical data protection, and business continuance in case of a disaster.
Data migration from one storage system to another can be done without interrupting network
service.
SnapMirror replication allows the distribution of large amounts of data to remote sites as a
read-only replica. Remote data access provides fast access to data by local clients.
If critical data is replicated to a different location, in case of a disaster at the source site, the
replica can be made available to clients across the network until the damage caused by the
disaster is repaired.
Additionally, as the source data can be replicated at a time chosen by systems administrators,
the solution minimizes network utilization.
SnapMirror is also used for backup offloading. SnapMirror technology attaches the off-site
storage device to the SnapMirror destination system, offloading tape backup overhead from
production servers.

Replication Modes
Async
Replicates Snapshot copies from a source
volume or qtree to a destination volume or qtree
Incremental updates are based on schedules
Sync
Replicates writes from a source volume to a
secondary volume at the same time it is written
to the source volume
Semi-Sync
Minimizes source system performance impact

REPLICATION MODES
The Data ONTAP SnapMirror feature enables an administrator to replicate data either
asynchronously or synchronously.
The SnapMirror Async mode replicates Snapshot copies from a source volume or qtree to a
destination volume or qtree. Incremental updates are based on a schedule or are performed
manually using the snapmirror update command. Async mode works with both Volume
SnapMirror and Qtree SnapMirror.
SnapMirror Sync mode replicates writes from a source volume to a destination volume at the
same time it is written to the source volume. SnapMirror Sync is used in environments that have
zero tolerance for data loss.
SnapMirror Semi-Sync provides a middle-ground solution that keeps the source and destination
systems more closely synchronized than Async mode, but with less impact on performance. It can
configure a SnapMirror Sync replication to lag behind the source volume by a user-defined
number of write operations or milliseconds.

Volume and Qtree
SnapMirror

VOLUME AND QTREE SNAPMIRROR

Volume SnapMirror
Block-for-block replication
Supports Async, Sync, and Semi-Sync
Can be initialized using a tape device
Support volume cascade in a series
Source volume
Online/writable
Destination volume
Online/read-only
Volume
SnapMirror
Destination
Storage System
online
read-only
VOL1
VOL2
Source
Storage System
online
writable
VOL2
VOL1

VOLUME SNAPMIRROR
Volume SnapMirror enables block-for-block replication. The entire volume, including its qtrees,
and all the associated Snapshot copies, are replicated to the destination volume.
Volume SnapMirror can be initialized using a tape device and a volumes replica can be cascaded
in a series.
Volume SnapMirror can be asynchronous, synchronous or semi-synchronous.
The source volumes are visible, accessible, and writable by the clients.
The destination volumes are visible, accessible, and read-only and usually on a separate system to
which the source volumes are replicated.

Initial Transfer and Replication
Initial baseline transfer
Create a nonroot-restricted destination volume
All data in all Snapshot copies on the source are
transferred to the destination volume
Read-only destination volume brought online after
initial transfer completed
Replication
Scheduled process updates the mirror
Current Snapshot copy is compared with the
previous Snapshot copy
Changes are synchronized from source to
destination

INITIAL TRANSFER AND REPLICATION
To initialize a volume, you first have to restrict the destination volume in which the replica will
reside. During the baseline transfer, the source storage system takes a Snapshot copy of the
volume. All data blocks referenced by this Snapshot copy, including volume metadata such as
language translation settings, as well as all Snapshot copies of the volume, are transferred and
written to the destination volume.
After the initialization completes, the source and destination file systems have one Snapshot copy
in common. Updates occur from this point and are based on the schedule specified in a flat-text
configuration file known as the snapmirror.conf file or by using the snapmirror
update command.
To identify new and changed blocks, the block map in the new Snapshot copy is compared to the
block map of the baseline Snapshot copy. Only the blocks that are new or have changed since the
last successful replication are sent to the destination. Once the transfer has completed, the new
Snapshot copy becomes the baseline Snapshot copy and the old one is deleted.

Requirements and Limitations
Destinations Data ONTAP version must be equal
to or more recent than the source
Like-to-like transfers only: flex-to-flex, trad-to-trad
Destination volume capacity equal to or greater
than source
Quota cannot be enabled on destination volume
TCP port range 1056510569 must be open

REQUIREMENTS AND LIMITATIONS
With Volume SnapMirror, the destination must run a version of Data ONTAP that is equal to or
more recent than the source. In addition, the source and destination must be on the same Data
ONTAP release.
Volume SnapMirror replication can only occur with volumes of the same type: both traditional
volumes or both flexible volumes.
Volume SnapMirror requires that the size of the destination volume be equal to or greater than the
size of the source volume. Administrators can thin provision the destination so that it appears to
be equal to or greater than the size of the source volume.
The source volume disks checksum type (block or zone checksum) must be identical to the
destination disks checksum type.
NOTE: For traditional volume, disks checksum type, size, and geometry must be identical. The
destination volume has to contain the same number of disks and the same size disks as the source
volumes, allowing more efficient deployment of resources. This limitation applies only to
traditional volumes.
Quotas cannot be enabled on destination volume.
It is recommended that you allow a range of TCP ports from 10565 to 10569.

Qtree SnapMirror
Logical replication
Independent of the type of volume
Source volume and qtree are online/writable
Destination volume is online/writable
Destination qtree is read-only
Qtree
SnapMirror
Destination
Storage System
Read-only
qtrees replica
qtree_a
qtree_b
qtree_c
Online/writable
volume
VOL1 Online/writable
volume and
qtrees
Source
Storage System
qtree_a
qtree_b
qtree_c
VOL1

QTREE SNAPMIRROR
Qtree SnapMirror is a logical replication. All the files and directories in the source file system are
created in the target destination qtree.
Qtree SnapMirror replication occurs between qtrees regardless of the type of the volume
(traditional or flexible). You can mirror qtrees using SnapMirror from a traditional volume to a
flexible volume and from a flexible volume to a traditional volume. Note that volume size and the
disk geometry do not make any difference for Qtree SnapMirror.
Qtrees from different sources can be replicated to a destination and Qtree SnapMirror replication
can occur between different releases of Data ONTAP.
With Qtree SnapMirror, the source volume and qtree are online and writable. The destination
qtree is read-only, while the destination volume remains writable and may contain replicated
qtrees from multiple source volumes, and qtrees or nontree data not managed by SnapMirror.
NOTE: Unlike volume SnapMirror, a Qtree SnapMirror does not require that the size of the
destination volume be equal to or greater than the size of the source qtree.

Initial Transfer and Replication
Initial baseline transfer
Destination qtree is created automatically upon first-
time replication
Replication
Scheduled process updates the qtree replica
Current Snapshot copy is compared with the
previous Snapshot copy
Only changed blocks are transferred to the
destination; Snapshot copy is not transferred
When transfer completes, Qtree SnapMirror creates
a Snapshot copy associated with the qtree replica

INITIAL TRANSFER AND REPLICATION
To initialize a qtree, you do not need to create a destination qtree; the qtree is automatically
created when the baseline transfer is started. The baseline transfer is created when Qtree
SnapMirror creates a Snapshot copy of the source volume that contains the qtree to be replicated.
This Snapshot copy contains all the source volume data, including both the data in the qtree to be
replicated and the metadata.
After the initialization completes, the source and destination file systems have one Snapshot copy
in common. Updates occur from this point and are based on the schedule specified in a flat-text
configuration file known as the snapmirror.conf file or by using the snapmirror
update command.
Qtree SnapMirror determines changed data by first looking through the inode file for inodes that
have changed and then looking through the changed inodes of the replicated qtree for changed
data blocks. Only new or changed blocks associated with the designated qtree are transferred to
the destination. Qtree SnapMirror does not transfer the Snapshot copy from the source to the
destination. When the transfer completes, Qtree SnapMirror creates a Snapshot copy of the
destination volume associated with the replicated qtree.

Supports Async mode only
Destination volume must have 5% extra space
Destination qtree cannot be /etc
Cannot be initialized using a tape device
Does not support cascading of mirrors
Deep directory structure and large number of
small files may impact performance

Qtree SnapMirror is available with asynchronous mode only.
The destination volume must contain 5% more free space than the source qtree.
A destination qtree cannot be /etc.
Qtree SnapMirror cannot be initialized using a tape device and does not support cascading of
mirrors.
Qtree SnapMirror performance is impacted by deep directory structure and large number (tens of
millions) of small files replicated.

To determine changed data, Qtree SnapMirror looks at the inode file and defines which inodes are
in the qtree of interest and which inodes have changed. If the inode file is large, but the inodes of
interest are few, Qtree SnapMirror spends a lot of time going through the inode file to find very
few changes.

SnapMirror
Deployment

SNAPMIRROR DEPLOYMENT

Licensing SnapMirror
One snapmirror license is required per
source and destination storage system
Evaluation license keys are available upon
request on the NOW(NetApp on the Web)
site
SnapMirror Sync and Semi-Sync require the
additional snapmirror_sync license
Special license keys are available in the Data
ONTAP Data Protection Online Backup and
Recovery Guide

LICENSING SNAPMIRROR
SnapMirror requires a snapmirror license on both the source and the destination storage
systems. If the SnapMirror source and destination are on the same storage system, only one
license is to be installed.
SnapMirror Sync and Semi-Sync require an additional snapmirror_sync free license
available in the Data ONTAP Data Protection Online Backup and Recovery Guide on the NOW
site.

Configuration Process
1. Install the SnapMirror license
2. Set SnapMirror access
3. Perform the initial baseline transfer
4. Create the snapmirror.conf configuration
file to set the SnapMirror mode of replication
NOTE: The snapmirror.conf configuration file
resides on the destination

CONFIGURATION PROCESS
The SnapMirror configuration process consists of the following four steps:
1. Install the SnapMirror license on the source and destination systems:
license add <code>

2. On the source, specify the host name or IP address of the SnapMirror destination systems you
wish to authorize to replicate this source system.
options snapmirror.access host=dst_hostname1,dst_hostname2

3. For each source volume or qtree to replicate, perform an initial baseline transfer.
For Volume SnapMirror, restrict the destination volume first:
vol restrict dst_vol

Then initialize the Volume SnapMirror baseline, using the following syntax on the
destination:
snapmirror initialize -S src_hostname:src_vol
dst_hostname:dst_vol

For a Qtree SnapMirror baseline transfer, use the following syntax on the destination:
snapmirror initialize S src_hostname:/vol/src_vol/src_qtree
dst_hostname:/vol/dst_vol/dst_qtree

4. Once the initial transfer completes, set the SnapMirror mode of replication by creating the
/etc/snapmirror.conf file in the destinations root volume.

snapmirror.conf
FAS1:vol1
- 23 * 1,3,5 FAS2:vol1
Source storage
system hostname
and source path
Destination storage
system hostname
and destination path
0
Use default values for arguments
Updates on the hour
Source Destination Arguments Schedule
Updates at 11 p.m.
Updates on all (applicable) days of the month
Updates on Monday, Wednesday, and Friday

SNAPMIRROR.CONF
The snapmirror.conf configuration file entries define the relationship between the source
and the destination, the mode of replication, and the arguments that control SnapMirror when
replicating data.

The syntax for entries in the snapmirror.conf file is as follows:
src_system:/vol/src_vol/[src_qtree]
dest_system:/vol/dest_vol[/dest_qtree] [arguments] [schedule]

The arguments field lets you define the transfer speed and the restart mode. In this field you
can also enable checksum, set the synchronicity level and the visibility interval. A dash (-)
indicates that all arguments default values apply.

The schedule consists of four space-separated fields in order:
minute hour day_of_month day_of_week
All possible values can be applied with an asterisk (*).
A single dash (-) means never and prevents this schedule entry from executing.

NOTE: SnapMirror updates can be scheduled to occur as frequently as every minute.

For more information on the snapmirror.conf file entries, refer to the Data ONTAP Data
Protection Online Backup and Recovery Guide.

snapmirror.conf File Examples
Example entries from snapmirror.conf
file that resides on the destination
Qtree SnapMirror
src:/vol/vol1/q1 dst:/vol/vol1/q1 15 *
* *
Volume SnapMirror
src:vol2 dst:vol2 kbs=2000 10 8,20 * *

SNAPMIRROR.CONF FILE EXAMPLES
src:/vol/vol1/q1 dst:/vol/vol1/q1 15 * * *
The source qtree q1 is replicated to the destination qtree q1 every 15 minutes, everyday of the
week and everyday of the month.

The source volume vol2 is replicated to the destination volume vol2 at 10 minutes past 8:00 a.m.
and 8:00 p.m. of every day of the month and every day of the week. In other words, the source
volume vol2 is replicated at 8:10 a.m. and 8:10 p.m. Data ONTAP can use a maximum of 2,000
kilobytes per second to transfer data for this relation.

Monitoring Transfer
Use the snapmirror status command to monitor
transfer progress, check relationship status, and
control the lag
NY1> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
Dallas:vol1 NY1:vol1 Snapmirrored 00:05:30 Idle
Dallas:/vol/vol2/q1 NY1:/vol/vol2/q1 Snapmirrored 00:09:53 Quiescing
Dallas:/vol/vol2/q2 NY1:/vol/vol2/q2 Snapmirrored 00:15:20 (Transferring
12288 MB done)

MONITORING TRANSFER
Use the snapmirror status command either from the source or the destination storage system to
monitor the transfer progress, check relationships state and status, control the transfer lag (age of
backup).
Command syntax:
snapmirror status [options] [system:][path]]

The value for options can be -l or -q
The -l option displays the long format of the output.
The -q option displays which volumes or qtrees are quiesced or quiescing.

The snapmirror quiesce command waits for all existing transfers to both volumes and qtrees
to complete and blocks any further updates. If a qtree is not in a stable state (is in transition), the
snapmirror quiesce command forces it into a stable state. You can quiesce only volumes and
qtrees that are online and that are SnapMirror destinations.You cannot quiesce a restricted or
offline volume or a qtree in a restricted or offline volume.
For details on the snapmirror status command output, refer to the Data ONTAP Data
Protection Online Backup and Recovery guide.

Listing Snapshot Copies
Use the snap list command to monitor
Snapshot copies deletion and creation
DO NOT delete SnapMirror Snapshot copy
NY1> snap list vol1
Volume vol1
date name
-------- --------
Sep 13 21:00 hourly.0
Sep 13 20:45 NY1(0050404361)_vol1.0 (snapmirror)
Destination system
Destination system ID
Destination volume
Transfer incremental number

LISTING SNAPSHOT COPIES
Use the snap list command to list all Snapshot copies, including the SnapMirror Snapshot
copies stored in the source and the destination volumes.
SnapMirror Snapshot copies are distinguished from system Snapshot copies by a more elaborate
naming convention. The default name of a SnapMirror volume Snapshot copy is as follows:

dest_system(sysid)_name.number

dest_system is the host name of the destination storage system
sysid is the destination system ID number
name is the name of the destination volume
number is the number of successful transfers for the Snapshot copy, starting at 1. Data ONTAP
increments this number for each transfer.

The snap list command displays the keyword snapmirror next to the necessary Snapshot
copy.
Caution: do not delete Snapshot copies that SnapMirror creates in the source volume. The most
recent SnapMirror Snapshot copy is referred to as the newest common Snapshot copy.
Incremental changes to the destination depend on this Snapshot copy. If SnapMirror cannot find
the required Snapshot copy on the source, it cannot perform incremental changes to the
destination. The affected relationship will have to be reinitialized.

Log Files
SnapMirror logging
options snapmirror.log.enable[on|off]
The option is on by default
Log files /etc/log/snapmirror.[0-5] are saved in
the root volume
Example
dst Thu Sep 13 20:41:09 GMT Dallas:vol1 NY1:vol1 Request (Initialization)
dst Thu Sep 13 20:41:32 GMT Dallas:vol1 NY1:vol1 Abort
(Destination not allowed)
dst Thu Sep 13 20:45:31 GMT Dallas:vol1 NY1:vol1 Request (Initialization)
dst Thu Sep 13 20:45:35 GMT Dallas:vol1 NY1:vol1 Start
dst Thu Sep 13 21:10:40 GMT Dallas:vol1 NY1:vol1 End (104857600 KB)

LOG FILES
The SnapMirror 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.
Use the option snapmirror.log.enable to record SnapMirror data transfer logs. By
default, the option is on.

options snapmirror.log.enable [on|off]

Log files are stored on the source and the destination storage systems root volume, in the
/etc/logs/snapmirror directory.

A new log file is generated every week as snapmirror.0. Older log files are renamed
snapmirror.[1-5] and the oldest log file is deleted.

NearStore Personality
Converts the destination storage system to a
NearStore system
Increases the number of concurrent transfers
on those destination systems
Requires the nearstore_option license on
the secondary and Data ONTAP 7.1 or later
Supported on FAS3000 and FAS6000 series
systems

NEARSTORE PERSONALITY
NearStore Personality allows you to utilize FAS storage systems as secondary systems.
This feature requires the nearstore_option license, which is available on Data ONTAP 7.1
and later for FAS3000 and on Data ONTAP 7.2 and later for FAS6000 series.

When enabled, the nearstore_option license increases the number of possible concurrent
destination qtree SnapMirror and SnapVault replications by optimizing the transfer resources
required for those replications.

This license should not be installed on these storage systems if they intend to handle primary
application workloads.

For more information on transfer resources required for NearStore replications, refer to the latest
Data ONTAP Data Protection Online Backup and Recovery Guide on the NOW site.

Concurrent Transfers
Each storage system model supports a maximum
number of simultaneous replication operations
In Data ONTAP 7.3, stream counts are increased for
certain platforms
SOURCE Platform VSM QSM
FAS6080 150 128
FAS6080_nearstore 150 512
DESTINATION Platform VSM QSM
FAS6080 150 128
FAS6080_nearstore 300 512

CONCURRENT TRANSFERS
Each storage system model supports a maximum number of simultaneous replication operations.

In Data ONTAP 7.3, the Volume SnapMirror and Qtree SnapMirror maximum stream counts are
increased for certain platforms. This enhancement allows customers to accommodate the use of
large numbers of flexible volumes and multiple concurrent transfers.

The new concurrent stream counts apply only to the snapmirror initialize and the
snapmirror update Data ONTAP commands.

Refer to the latest Data ONTAP Online Data Protection Backup and Recovery Guide for new
supported stream counts.

Managing Transfers
In Data ONTAP 7.3, use the following options
to manage Volume SnapMirror transfers:
replication.volume.reserved_transfers <n>
Guarantees that specified number of Volume
SnapMirror source/destination transfers always
start
Default is 0
replication.volume.transfer_limits
[current|previous]
Allows reversion to stream counts from versions
of Data ONTAP earlier than 7.3
Default is current

MANAGING TRANSFERS
In Data ONTAP 7.3, you can specify the number of Volume SnapMirror transfers for which you
want resources by using the following Data ONTAP option:

options replication.volume.reserved_transfers <n>

<n> is the number of Volume SnapMirror transfers for which you want resources reserved.
The default value is 0.
The reason for reserving transfers is that reserved resources will not be available for other
replication types like Qtree SnapMirror or SnapVault transfers.

The stream count setting was increased in Data ONTAP 7.3. You can revert back to the previous
stream count setting by using the following option:

options replication.volume.transfer_limits [current | previous]

If the value is set to current, the maximums for the current release will be used. If the value is set
to previous, maximums for 7.2.0 will be used. The default value is current.

Throttling Network
Per transfer
Use the kbs argument in snapmirror.conf
Dynamic throttle
Allows changing the throttle for a SnapMirror
relationship while the transfer is active
snapmirror throttle <n> dst_hostname:dst_path
System-wide throttle
Limits the total bandwidth for all transfers
options replication.throttle.enable on
options replication.throttle.incoming.max_kbs
options replication.throttle.outgoing.max_kbs

THROTTLING NETWORK
Throttle network usage can be configured on a per transfer basis, using the kbs argument in the
snapmirror.conf.
Dynamic throttle allows you to change the throttle value for a SnapMirror relationship while the
transfer is active. This feature is available from Data ONTAP 7.1 and later.

snapmirror throttle <n> dst_hostname:dst_path
<n> is the new throttle value in kilobytes per second

System-wide throttling is available from Data ONTAP 7.2 and later and limits the total
bandwidth used by all transfers at any time (SnapMirror and SnapVault transfers).

There are three options.

Enable or disable system-wide throttling on all systems:
replication.throttle.enable [on|off]

Set maximum bandwidth for all incoming transfers:
replication.throttle.incoming.max_kbs <value>

Set maximum bandwidth for all outgoing transfers:
replication.throttle.outgoing.max_kbs <value>

The default value is unlimited, which means there is no limit on total bandwidth used. Valid
transfer rate values are 1 to 125,000 kilobytes per second.

Space Guarantee
In Data ONTAP 7.3, space is guaranteed for
SnapMirror destination flexible volumes
Preallocates space in the aggregate for the volume
Volume guarantee is enabled by default
Guarantee is maintained even when the volume is
made offline
To enable/disable space guarantee on an existing
SnapMirror destination volume
vol options vol_name guarantee [volume|none]

SPACE GUARANTEE
In Data ONTAP 7.3, space is guaranteed for SnapMirror destination flexible volumes. This new
feature preallocates space in the aggregate for the volume. However, it is still possible for
transfers to fail when the aggregate is full. When you create a flexible volume, by default its
volume guarantee is enabled.
Support for space guarantee on the SnapMirror destination volume allows for maintenance of this
guarantee after the initial baseline transfer is completed. The destination volume is set to an
internal guarantee type called Replica (RAID label). The guarantee is also maintained across
when the volume is offline. When the SnapMirror destination storage system is upgraded to Data
ONTAP 7.3, you can enable or disable space guarantee on the existing SnapMirror destination
volumes using the vol options command. Note that file guarantee is not supported on
SnapMirror destination volumes.

Destination> vol options vol_name guarantee [volume | none]

An upgraded_replica volume option is added to display if a volume is an upgraded SnapMirror
destination as a part of the vol status command.

Destination> vol status
Volume State Status Options
dst_vol online raid_dp, flex snapmirrored=on,
snapmirrored upgraded_replica,
read-only fs_size_fixed=on,
guarantee=volume(disabled)
vol0 online raid4, trad root

Synchronous
SnapMirror

SYNCRHONOUS SNAPMIRROR

Sync Mode
Volume SnapMirror Async is the base of
SnapMirror Sync
Replicates Snapshot copies from a source
volume to a secondary volume at the same time
is it written to the source
To configure Sync mode, replace the schedule
field by sync in the snapmirror.conf file
SystemA:vol1 SystemB:vol1 sync

SYNC MODE
SnapMirror in synchronous mode is a mode of replication that sends updates from the source to
the destination as they occur, rather than according to a predetermined schedule. This guarantees
that data written on the source system is protected on the destination even if the entire source
system fails.
Volume SnapMirror Async is the base of SnapMirror Sync. The first step involved in SnapMirror
sync mode replication is a one-time baseline transfer of the source volume. When the baseline
transfer is completed, SnapMirror transitions through a series of states, becoming more and more
synchronous until the relationship gets in synchronous mode.

To configure SnapMirror Sync mode, the schedule field is replaced by sync in the
snapmirror.conf configuration file.
Example:
SystemA:vol1 SystemB:vol1 sync

Note that when changes are made to the snapmirror.conf file for a SnapMirror Sync entry,
the SnapMirror relationship will go out of sync momentarily and then attempt to return to
synchronous state.

CP and NVLOG Forwarding
SnapMirror Sync forwards consistency point
(CP) to the destination to keep consistency
between the source and the destination
volumes
SnapMirror Sync also forwards the NVRAM
requests to the destination
Stored in NVLOG files
/etc/sync_snapmirror_nvlog/<dstfsid>.log[0|1]
NVLOG files are replayed only in disaster
recovery scenario

CP AND NVLOG FORWARDING
SnapMirror Sync forwards all consistency point (CP) writes to the destination to keep
consistency between the source and the destination volumes.
A consistency point is generally taken when the NVRAM is half-full, when the timer generates a
CP (10 seconds), and when a Snapshot copy is created although other events can cause a CP.

Before Data ONTAP 7.2.2, the source CP will not complete until the destination has completed
its CP. From Data ONTAP 7.2.2 and later, CPs are not synchronized but are forwarded to the
destination and data is saved in memory.

SnapMirror Sync forwards the NVRAM logs to the destination to ensure that NVRAM
operations on the source are replicated to the destination for replay in case of a disaster on the
source system.

NVLOG data is treated as a stream of writes to a pair of special files named the NVLOG files
/etc/sync_snapmirror_nvlog/<dstfsid>.log[0|1]

Before Data ONTAP 7.2.2, NVLOG files are written in the root volume of the destination
system. From Data ONTAP 7.2.2 and later, NVLOG files are written in the parent aggregate of
the destination volume.

Theory of Operation
Client writes are acknowledged after the writes
have been logged to the NVRAM on the source
and to the NVLOG files on the destination
Source waits for each transaction to be
acknowledged from the destination; it may
impact client application performance
SnapMirror
Sync
1
2
4
3
CP
6 5
Client
VOL1
VOL1

THEORY OF OPERATION
Client writes are acknowledged after the writes have been logged to the NVRAM on the source
and to the NVLOG files on the destination. Because the source waits for each transaction to be
acknowledged from the destination before moving forward, it may impact client application
performance.
1. The source system receives a write request from a client. The request is journaled in the
systems NVRAM and recorded in cache memory.
2. The request and the NVLOG metadata are forwarded to the SnapMirror destination system
where they are also journaled in NVRAM and cache memory.
3. The destination responds to the source system.
4. Data ONTAP acknowledges the write to the client system, and the application that requested
the write is free to continue processing.
5. When a consistency point is triggered, Data ONTAP uses the transaction data in cache
memory to build a list of data block changes that need to be written to disk.
6. This list of data blocks is sent to the destination, which initiates its own write to disk and
returns an acknowledgment to the WAFL software on the source system.

Semi-Sync Mode
Prior to Data ONTAP 7.3, Semi-Sync mode
provided different synchronicity levels to control
synchronicity versus performance
Use the outstanding argument in the SnapMirror
configuration file to set the synchronicity level
SystemA:vol1 SystemB:vol1 outstanding=5s sync
Value Description
No value (default) SnapMirror operates in a fully synchronous manner
x ops
Allows x number of outstanding write operations before
forcing the clients to wait for an acknowledgment
x s | x ms
Defines the amount of time (seconds or milliseconds) a
destination waits before sending a write acknowledgment
outstanding={x ops | x ms | x s}

SEMI-SYNC MODE
Versions of Data ONTAP earlier than 7.3, allowed for Semi-Sync mode which provided different
synchronicity levels to control synchronicity versus performance.
The field in the configuration file that controls the synchronicity level is the outstanding
argument. This variable allows you to modify the amount of time or the number of operations a
destination waits before sending a write acknowledgment to the source.
outstanding={x ops | x ms | x s}
Default is no value: SnapMirror operates in a fully synchronous manner.
The ops suffix allows x number of outstanding write operations before forcing the clients to
wait for an acknowledgment.
s or ms defines the amount of time (seconds or milliseconds) a destination waits before
sending a write acknowledgment.

When the outstanding value is less than 10 seconds, the source forwards the NVLOG like it
would in sync mode, but it does not wait for the acknowledgment from the destination system.
This provides performance improvement for the client writing to the source volume. However,
there is a possibility of data loss during that interval should the source crash prior to forwarding
the NVLOG.

When the outstanding value is set to 10 seconds or more, only the CP streams are forwarded to
the destination; NVLOG data are not forwarded. Eliminating NVLOG forwarding reduces the
load on the storage systems.

Semi-Sync Mode (Cont.)
In Data ONTAP 7.3, the outstanding argument
is deprecated
To configure Semi-Sync mode, replace the
schedule field by semi-sync
SystemA:vol1 SystemB:vol1 semi-sync
Only the CP streams are forwarded to the
destination; NVLOG data are not forwarded
Saves processing power and bandwidth
1
2
3
4
Client application writes
Acknowledgment to client application
Data replication
Request acknowledgment

SEMI-SYNC MODE (CONT.)
In Data ONTAP 7.3, the outstanding argument is deprecated. To configure Semi-Sync
mode, replace the schedule field by semi-sync in the snapmirror.conf file.

Example:
SystemA:vol1 SystemB:vol1 semi-sync

Only the CP streams are forwarded to the destination. NVLOG data are not forwarded. This mode
minimizes performance impact on client applications, reduces storage systems processing power,
and saves bandwidth.

Deployment Examples
Compare these entries from the destination
snapmirror.conf file
Qtree SnapMirror
Volume SnapMirror
Sync
src:vol3 dst:vol3 sync
Semi-Sync
src:vol4 dst:vol4 semi-sync

DEPLOYMENT EXAMPLES
Example 1: Qtree SnapMirror
The source qtree q1 is replicated to the destination qtree q1 every 15 minutes, everyday of the
week and everyday of the month.
Example 1: Volume SnapMirror
The source volume vol2 is replicated to the destination volume vol2 at 10 minutes past 8:00 a.m.
and 8:00 p.m. of every day of the month and every day of the week. In other words, the source
volume vol2 is replicated at 8:10 a.m. and 8:10 p.m. Data ONTAP can use a maximum of 2,000
kilobytes per second to transfer data for this relation.
Example 1: SnapMirror Sync
src:vol3 dst:vol3 sync
The source volume vol3 is synchronously replicated to the destination volume vol3.
Example 1: SnapMirror Semi-Sync
src:vol4 dst:vol4 semi-sync
The source volume vol4 is replicated to the destination volume vol4 in Semi-Sync mode. Only
the CP-Sync mechanism is used. NVLOG data are not forwarded to the destination.

Performance Tuning
Do not change the visibility_interval
default value
Snapshot copies are taken more often
Before Data ONTAP 7.2.2, NVLOG files are
written in the root volume
Impacts on how quickly NVLOG may be committed
to disk
For traditional volume, ensure that the root volume
spans enough disks
crc32 checksums are more CPU-intensive than
TCP checksums

PERFORMANCE TUNING
In Sync mode, changes are shown on the destination only after the source takes a Snapshot copy
of the source volume (every three minutes by default) and then transfers it to the destination. To
control the view of the data on the destination, you use the visibility_interval argument
in the snapmirror.conf file. If visibility_interval is set too low, the source system
will be kept very busy creating Snapshot copies and this can impact performance. Changing the
visibility_interval default value of three minutes is not recommended.
In versions of Data ONTAP earlier than 7.2.2, NVLOG data are written in the root volume. This
may impact on how quickly NVLOG data may be committed to disk. For traditional volumes,
ensure that the root volume spans enough disks. Note that with Data ONTAP 7.2.2 and later, the
NVLOG files are written in the destination volumes parent aggregate.
The checksums algorithm is used to protect SnapMirror transmitted data. Cyclic redundancy
check checksums, also known as crc32c, are computed by the CPU on the destination storage
system and may have undesired effects on performance. TCP checksums are computed directly
on the network interface card, or NIC, and are less CPU-intensive; therefore the TCP checksums
computation is the recommended method.

Supports only volume replication
Supports bidirectional sync relationships from Data
ONTAP 7.2.1 and later
Storage system platforms must be identical and run
the same major Data ONTAP release
One source cannot have sync relationships to multiple
destinations
Cascading sync relationships is not supported
Source and destination cannot be on the same storage
system
An active-active configuration cannot have SnapMirror
Sync relationships from one half of the configuration to
the other half of the configuration

SnapMirror Sync can only be used on volumes, not qtrees.
SnapMirror Sync follows the same volume type matrix as Volume SnapMirror. Replication must
be from traditional volume to traditional volume or flexible volume to flexible volume.

Bidirectional SnapMirror Sync is supported on storage systems using Data ONTAP 7.2.1 and
later.

Replications are allowed only between identical storage system platforms running the same major
Data ONTAP release.

One source system cannot have SnapMirror Sync relationships to multiple destination systems.

Cascading sync relationships is not supported.

The source and destination of the SnapMirror Sync relationship cannot be on the same storage
system, such as: SystemA:src_vol SystemA:dst_vol

An active-active configuration cannot have SnapMirror Sync relationships from one half of the
configuration to the other half of the configuration.

Advanced Features

ADVANCED FEATURES

SnapMirror over Multiple Paths
Allows Fibre Channel and/or Ethernet as transport
Supports Async and Sync modes
One or two paths allowed
2 FC NIC adapters per storage system
2 Ethernet NIC adapters per storage system
One of each per storage system
Multiplexing: both paths are used at the same time
for load balancing
Failover: 1
st
path specified is active, the 2
nd
path is
in standby and becomes active if the 1
st
path fails

SNAPMIRROR OVER MULTIPLE PATHS
SnapMirror supports up to two paths for a particular SnapMirror relationship. The paths can be
Ethernet, Fibre Channel, or a combination of Ethernet and Fibre Channel.
Multiple paths are supported by SnapMirror Async and Sync replication modes.
The two paths can be used in one of two modes:
Multiplexing mode: SnapMirror uses both paths at the same time, essentially load balancing
the transfers. If one path fails, the transfers occur on the remaining path. After the failed path
is repaired, the transfers resume using both paths.

Failover mode: SnapMirror uses the first specified path as the desired path and uses the
second specified path only after the first path fails.

Configuring Multiple Paths
Add a connection name line in the
snapmirror.conf file
Define connection mode and network interfaces
Edit the schedule entry to reflect the new
connection name as the source system
/etc/snapmirror.conf
FAS1_conf = multi (FAS1-e0a,FAS2-e0a) (FAS1-e0b,FAS2-e0b)
FAS1_conf:vol1 FAS2:vol1 sync
e0a e0b e0a e0b
SnapMirror
Sync
FAS2 FAS1
VOL1 VOL1

CONFIGURING MULTIPLE PATHS
To implement multiple paths between the source and destination storage system, edit the
snapmirror.conf file to add a connection name line that defines the mode of the connection
and what the two connections are. Then, edit the schedule entry to reflect the new connection
name as the source system.
In this following illustration, the source volume vol1 on the storage system FAS1 is
synchronously replicated to the destination volume vol1 on the storage system FAS2. Two gigabit
Ethernet paths are configured and replication occurs using both connections in multiplexing mode
as specified in the snapmirror.conf file.

FAS1_conf = multi (FAS1-e0a,FAS2-e0a) (FAS1-e0b,FAS2-e0b)
The first entry defines the connection name (FAS1_conf), the mode of the connection (multi) and
what the two connections are (FAS1-e0a connected to FAS2-e0a and FAS1-e0b connected to
FAS2-e0b).

FAS1_conf:vol1 FAS2:vol1 sync
The second entry defines the sync relationship for volume vol1.

SnapMirror over Fibre Channel
Source and destination must have NetApp X1024
FC HBA (IP over FCP)
At least one FC switch between the source and
the destination
Switches must be from the same vendor
Supported vendors: Cisco
, Brocade
or McDATA
SnapMirror traffic must use dedicated zones
SnapMirror
FC Switches
FC-VI HBA FC-VI HBA
VOL1
VOL1

SNAPMIRROR OVER FIBRE CHANNEL
SnapMirror over Fibre Channel enables you to use the SnapMirror Async and Sync features over
a Fibre Channel SAN environment.
SnapMirror over FC requires at least one Fibre Channel switch in the data path. The supported
switch vendors are Cisco, Brocade, or McDATA. To comply with SnapMirror over Fibre
Channel certification, use only switches from one vendor in the SnapMirror data path. Supported
switches and firmware versions are specified in Requirements for SnapMirror Over Fibre
Channel Transport (Asynchronous, Synchronous, and Semi-synchronous modes) on the NOW
site.
The storage system must be configured with NetApp X1024 FC HBA (two 2-GB ports) or X1124
(two 4-GB ports) for IP over Fibre Channel functionality. The adapters translate the SnapMirror
IP packets to and from FC frames and supports the multiple paths configurations.
To begin the SnapMirror over FC configuration process, first configure the FC NIC adapters and
connect the systems to the Fibre Channel switches. Optionally, you can set up multiple
SnapMirror traffic zones. SnapMirror traffic must be configured within dedicated zones. Once the
switches have been set up, configure SnapMirror and baseline the initial transfers. For details on
SnapMirror over Fibre Channel configuration steps, refer to the latest Data ONTAP Data
Protection Online Backup and Recovery Guide on the NOW site.

SnapMirror to Tape
Accommodates the initial transfer over low-bandwidth
connections using a physically transported tape
Incremental updates are performed over the network
SnapMirror to tape supports volume replication only
connection
3
2
Low-bandwidth
4
Data Center
Remote Office
VOL1
SnapMirror
VOL1
5
1
Tape
Drive A
Tape
Drive B
FAS2
FAS1

SNAPMIRROR TO TAPE
SnapMirror to tape is a deployment that supports SnapMirror replication over low-bandwidth
connections by accommodating the initial transfer between the source and the destination systems
using a physically transported tape. When baseline transfer has been carried out with the local
tape device, incremental SnapMirror updates can be performed over the network. The
SnapMirror-to-tape function is available for volume replication only.
1. On the source system, use the snapmirror store command to copy all volume Snapshot
copies, including the base Snapshot copy, to tape.
2. Physically transport the backup tapes from the source system to the destination system.
3. On the destination system, use the vol create and vol restrict commands to set
up a SnapMirror target volume. Use the snapmirror retrieve command to copy the
initial SnapMirror tape to the destination system.
4. Use the snapmirror update command to trigger an incremental update from the source
to the destination system over the low-bandwidth connection, or edit the
snapmirror.conf file to set up an incremental update schedule from the source to
destination volume.
5. Finally, use the snapmirror release command to eliminate the source-to-tape
relationship and associated Snapshot copy.

Baseline SnapMirror Using LREP
LREP is a logical replication tool used to initialize
SnapMirror transfers over low-bandwidth connections
using a portable device
Applies only to Qtree SnapMirror
LREP is downloadable from the NOW site
2
5
3
6 7
FAS
lrep_reader
lrep_writer
1 4
Client1
Client2
connection Low-bandwidth
Data Center
Remote Office
SnapMirror
5
qtree1
qtree1
FAS
FAS2
FAS1

BASELINE SNAPMIRROR USING LREP
Logical Replication Reader and Writer (LREP) is a logical replication tool used to perform
SnapMirror initial transfers using a portable device (tape, external drive, or a NetApp storage
system) and without traversing the network. This process is often referred to as seeding the
baseline transfer. LREP applies only to Qtree SnapMirror. The LREP tool set is downloadable
from the NOW site.
The illustration sets up a Qtree SnapMirror baseline transfer from FAS1 (source system at the
data center) to FAS2 (destination system at the remote office) using the LREP utilities.
1. Install the lrep_reader utility on Client1 at the data center.
2. Run the lrep_reader utility from Client1 to snapmirror initialize from the source
to the portable media; here a FAS250 shared between sites.
3. The FAS250 is then transferred to the remote office.
4. The lrep_writer utility is installed on Client 2 at the remote office.
5. Run lrep_writer utility from Client2 to reconstruct the replication streams by reading from
files, which were created by lrep_reader.
6. From the destination, run the snapmirror initialize command to read the logical
replication stream data from the lrep_writer.
7. The Qtree SnapMirror initial transfer completes. Edit the snapmirror.conf file to reflect
the correct source storage system.

Converting a Replica to a Writable File
System
To convert a replica to a writable file system, break
the SnapMirror relationship
dst> snapmirror break dst_vol
To resume the replication operations,
resynchronize the broken off relationship
src> snapmirror resync
To make the break permanent, release the
relationship from its direct source
src> snapmirror release src_vol

CONVERTING A REPLICA TO A WRITABLE FILE SYSTEM
You might want to convert a read-only replica to a writable qtree or volume to migrate data to a
new location or in case of a disaster, when the source becomes unavailable and you wish to
redirect a CIFS or NFS clients access to the destination.
To convert a replica to a read/write volume or qtree, use the snapmirror break command:
snapmirror break dst_vol
Note that to convert a qtree replica to be writable, you must first quiesce the destination qtree:
snapmirror quiesce /vol/dst_vol/dst_qtree
snapmirror break /vol/dst_vol/dst_qtree

After breaking a SnapMirror relationship, to resume incremental updates, use the snapmirror
resync command. To avoid losing data, always resync from the storage system that has the less
up-to-date file system:

snapmirror resync dst_hostname:dst_vol

SnapMirror identifies the newest common Snapshot copy created for the last successful update.
This Snapshot copy will be used as the basis for resynchronization.
To make the break permanent, release the volume or the qtree relationship from its immediate
source:
snapmirror release src_vol dst_hostname:dst_vol

Reestablishing the Broken Relationship
To resume the replication operations, resynchronize
the broken off relationship
NOTE: Changes stored on the destination during
the break will be lost upon resynchronization
snapmirror resync src_hostname:src_vol
e0a e0b e0a e0b
SnapMirror
VO1 VOL1
SnapMirror
Destination
SnapMirror
Source
dst>

REESTABLISHING THE BROKEN RELATIONSHIP
You can use the snapmirror resync command to restore or redefine a SnapMirror source or
destination relationship that was broken with the snapmirror break command.
Applied to the original destinationthe snapmirror resync command will put a volume or
qtree back into a SnapMirror relationship and resynchronize its contents with the source without
repeating the initial transfer.
Applied to the source volumethe snapmirror resync command can turn the source
volume into a copy of the original destination volume. In this way, the roles of source and
destination can be reversed
Considerations
You might want to resynchronize a source and a destination volume or qtree when:
You are changing the current source to a different volume or qtree.
You make a destination volume writable for application testing and then want to make it a
SnapMirror destination again.
You need to recover from a disaster that disabled the source.
You want to reverse the functions of the source and the destination.

snapmirror resync dst_hostname:dst_vol
Reestablishing the Broken Relationship
Resynchronizing from the original
source reverses the roles of the source
volume and destination volume
e0a e0b e0a e0b
SnapMirror
VO1 VOL1
SnapMirror
Destination is now
the new source
SnapMirror
Source is now
the new destination
src>

REESTABLISHING THE BROKEN RELATIONSHIP (CONT)
Applied to the source volumethe snapmirror resync command can turn the source
volume into a copy of the original destination volume. In this way, the roles of source and
destination can be reversed.

Making the Break Permanent
To make the break permanent, release the
relationship from its direct source
src> snapmirror release src_vol
e0a e0b e0a e0b
VO1 VOL1
FAS2 FAS1

MAKING THE BREAK PERMANENT
To permanently end a SnapMirror relationship between a source and destination pair of volumes
or qtrees, you need to use different commands on the source and destination storage systems.
CONSIDERATIONS
Source systemUse the snapmirror release command. Releasing a source from a destination
volume or qtree allows the source to delete its base Snapshot copy for the SnapMirror
relationship.
Destination systemUse the snapmirror break command. After breaking the relationship, you
need to scrub the destination with additional steps. Unless these extra steps are taken, the
Snapshot copies associated with the broken relationship remain stored on the destination system,
and a snapmirror status command will continue to list the former destination object as a current
destination object.
STEPS
1. On the source system, enter the following command:
snapmirror release {source_volume |
qtree_path}[dest_system:]{dest_volume | qtree_path}
Example:
For a SnapMirror volume relationship
systemA> snapmirror release vol0 systemB:vol2
Example
For a SnapMirror qtree relationship

systemA> snapmirror release vol/vol1/qtree2 systemB:/vol/vol2/qtree5
SnapMirror frees all resources on the source system that had been dedicated to the
SnapMirror relationship.
2. On the destination system, enter the following command to break the SnapMirror relationship
between the source and destination objects. S
snapmirror break {vol_name | qtree_path}

3. On the destination system, use the snapmirror status -l command to determine which
Snapshot copy basename is associated with the SnapMirror relationship that you just broke.
For a broken SnapMirror volume relationship
snapmirror status -l <dest_vol>
For a broken SnapMirror qtree relationship
snapmirror status -l </vol/dest_vol/dest_qtree>
In the detailed output that is displayed, note the Snapshot copy basename associated with the
SnapMirror relationship that you just broke.
4. On the destination system, use the following command to delete the Snapshot copy set that
you displayed in the previous step.
snap delete dest_vol <snapshot_basename>
5. Through the Adminhost client, edit the /etc/snapmirror.conf file on the destination
system. Locate and delete the entry that specifies the SnapMirror relationship you want to
end.

Migrating SnapMirror Volumes
Use the snapmirror migrate command to
migrate data between volumes that are in a
SnapMirror relationship
SnapMirror migration:
1. Performs a SnapMirror incremental transfer to the
destination volume
2. Stops NFS and CIFS services to the source volume
3. Migrates NFS file handles to the destination volume
4. Makes the source volume restricted
5. Makes the destination volume read-write

MIGRATING SNAPMIRROR VOLUMES
SnapMirror can migrate data between volumes and redirect NFS clients to the new volume
without rebooting the storage system or remounting the volume on NFS clients. The migration
must be run on two volumes that are currently the source volume and destination volume in a
SnapMirror relationship.
You use the snapmirror migrate command on the storage system, which holds the source
volume.

snapmirror migrate src_hostname:src_volume
dst_hostname:dst_volume

The SnapMirror migration process does the following:
1. Performs a SnapMirror incremental transfer to the destination volume
2. Stops NFS and CIFS services to the source volume
3. Migrates NFS file handles to the destination volume
4. Makes the source volume restricted
5. Makes the destination volume read-write

Note that the SnapMirror does not transfer IP addresses, license keys, or quota information. You
must remount on the NFS clients. SnapMirror does not migrate CIFS clients. You must
reestablish CIFS client sessions after migrating data to the destination volume.

Cascading SnapMirror Volumes
SnapMirror creates and retains the Snapshot copies
on the original source volume
The SnapMirror Snapshot copies are cascaded down
the line to replicate the volumes on each destination
system

CASCADING SNAPMIRROR VOLUMES
Instead of propagating data from one central master site to many destinations, which would
require expensive network connections and excessive CPU time, you can propagate data from one
volume to another volume and from that one to the next, in a series.
In a volumes cascade, SnapMirror creates and retains the Snapshot copies on the original source
volume. The SnapMirror Snapshot copies are cascaded down the line to be able to replicate the
volumes on each destination system.
In this illustration, volume vol1 on storage system FAS1 is replicated to seven storage systems.
To set up cascading volumes as shown in the diagram, on each storage system, the
snapmirror.conf file would look like this:
FAS1:vol1 FAS7:vol1 15 * * 1,2,3,4,5
FAS1:vol1 FAS2:vol1 - 15 * * 1,2,3,4,5
FAS7:vol1 FAS8:vol1 - 25 * * 1,2,3,4,5
FAS2:vol1 FAS3:vol1 35 * * 1,2,3,4,5
FAS2:vol1 FAS4:vol1 35 * * 1,2,3,4,5
FAS3:vol1 FAS5:vol1 45 * * 1,2,3,4,5
FAS3:vol1 FAS6:vol1 45 * * 1,2,3,4,5

To remove a destination from the cascade, use the snapmirror release command from the
immediate source. SnapMirror will delete the Snapshot copies associated with that destination.

Cascade Support Matrix
SnapMirror Sync is allowed only on the source
Qtree SnapMirror cannot cascade more than one hop
Configuration of SnapMirror Relationships Support
SM Sync VSM
SM Sync SM Sync
SM Sync QSM
VSM VSM
VSM SM Sync
VSM QSM
QSM VSM

QSM SM Sync
QSM QSM

CASCADE SUPPORT MATRIX
Not all cascading configurations are supported. The following limitations apply to both traditional
and flexible volumes as of Data ONTAP 7.2.2 and later.
This table can be reduced to two simple rules:
1. Synchronous SnapMirror is allowed only on the source; and
2. Qtree SnapMirror cannot cascade more than one hop.

SnapMirror
Performance

SNAPMIRROR PERFORMANCE

Volume SnapMirror Performance
With SnapMirror Async, performance tends to
be centered on:
Update frequency
Having enough network bandwidth
Storage system utilization
Volume SnapMirror Async performance is
particularly affected by:
Volume size and rate of data changed
Storage system utilization
Disk geometry for traditional volumes

VOLUME SNAPMIRROR PERFORMANCE
Volume SnapMirror performance is centered on the update frequency, the network bandwidth,
and the storage system utilization. Volume SnapMirror Async performance is particularly
affected by the volume size, the rate of data changed, and the disk geometry for traditional
volumes.
DISK GEOMETRY
For versions of Data ONTAP earlier than 7.0 and traditional volumes, it is recommended that the
source and destination volumes contain disks of the same size, and be organized in the same
RAID group configuration to gain optimal performance. For flexible volumes, disk geometry
matching is no longer a consideration.
SNAPSHOT COPIES CREATION AND UPDATE FREQUENCY
SnapMirror creates a Snapshot copy before every update and deletes a Snapshot copy at the end.
On heavily loaded storage systems, Snapshot copy creation time can stretch out and restricts the
frequency of SnapMirror updates. Stretched SnapMirror schedules result in SnapMirror creating
many Snapshot copies on the source storage system at the same time, which can impact client
access. For this reason staggered SnapMirror schedules are recommended to avoid performance
bottlenecks.
VOLUME SIZE AND CHANGED BLOCKS
To perform an incremental update, the block map in the new Snapshot copy is compared to the
block map in the baseline Snapshot copy. The time required to determine the block changes
depends on the volume size. From Data ONTAP 7.0 and later, you can use the snap delta
command to determine the rate of data change between Snapshot copies on a volume.

Qtree SnapMirror Performance
Qtree SnapMirror performance is impacted by:
Directory structure
Large number (tens of millions) of small files
Transfer size
Qtree
SnapMirror
Source
Storage System
/vol/vol1/q1
dir
dir1 dir2
dir5 dir6 dir3 dir4
Destination
Storage System
/vol/vol1/q1
dir
dir1 dir2
dir5 dir3 dir4 dir6

QTREE SNAPMIRROR PERFORMANCE
Qtree SnapMirror performance is impacted by deep directory structure and large numbers, such
as tens of millions, of small files replicated.
DIRECTORY STRUCTURES AND LARGE NUMBERS OF SMALL FILES
To determine changed data, Qtree SnapMirror looks at the inode file and defines which inodes are
in the qtree of interest and which inodes have changed. If the inode file is large, but the inodes of
interest are few, Qtree SnapMirror spends a lot of time going through the inode file to find very
few changes. Disk I/Os used to access the data become small and inefficient.
TRANSFER SIZE
When a Qtree SnapMirror update is transferring, the snapmirror status l command
shows how many kilobytes have been transferred so far; the value may be greater than the
expected delta (changes expected). This overhead is due to metadata transfer, for example: 4-KB
header, file creation, deletion, ACLs, and so on.
When the update has completed, you can use the Data ONTAP df command for the destination
volume to verify that the expected change size is correct.

Concurrent Transfer Limitation
Updates fail when the system exceeds the
maximum simultaneous replication operations
it supports
Each transfer beyond the limit will reattempt to
run once per minute
To optimize
Stagger update schedules
For Qtree SnapMirror, if there are too many
qtrees per destination volume, rebaseline those
qtrees to another volume

CONCURRENT TRANSFER LIMITATION
The transfer fails when the system reaches the maximum number of simultaneous replication
operations. Each transfer beyond the limit will reattempt to run once per minute.
To optimize SnapMirror deployment, it is recommended the schedules be staggered. For Qtree
SnapMirror, if there are too many qtrees per destination volume, the solution is to rebaseline
those qtrees to another volume.

CPU Utilization
SnapMirror consumes available CPU cycles on
a storage system
100% CPU utilization does not mean that
performance is degraded
SnapMirror may have some impact, but in the
majority of cases, it is not very significant
Monitor storage system CPU using
Operations Manager Performance Advisor
Data ONTAP sysstat command

CPU UTILIZATION
SnapMirror consumes available CPU cycles on a storage system.
When the source storage system shows that the CPU utilization is up to 100%, it does not mean
that the system performance or the SnapMirror throughput is degraded.
SnapMirror may have some impact, but in the majority of cases, it is not very significant.
You can monitor storage system CPU using Operations Manager Performance Advisor or the
Data ONTAP sysstat command.

System Activities
On heavily loaded systems, SnapMirror
competes with other processes and may
impact response times
To address this problem consider these
alternatives:
Use FlexShare
Schedule SnapMirror updates at times when

NFS or CIFS traffic is low
Reduce update frequency
Upgrade to a more powerful NetApp controller

SYSTEM ACTIVITIES
On heavily loaded systems, SnapMirror competes with other processes and may impact response
times.
To address this problem you can set the system priority to High or Very High on dedicated
storage systems for SnapMirror replication using FlexShare software.
You can also schedule SnapMirror updates at times when NFS or CIFS traffic is low and reduce
the frequency of updates.
Finally, consider upgrading to a more powerful NetApp controller when the system resources
become the bottleneck.

Network Distance and Bandwidth
Network distance causes write latency
To address network issues
Limit the bandwidth using network throttle
features
Utilize a dedicated network for SnapMirror
Use multipath for load balancing/failover
Look for typical network problems
For example, duplex mismatches

NETWORK DISTANCE AND BANDWIDTH
When deploying SnapMirror, you have to consider the round-trip travel time of a packet from the
source to the destination storage system, because network distance causes write latency. The
round trip has a latency of approximately 2 milliseconds if the source and the destination storage
systems are 100 miles apart.
Networking issues impacting SnapMirror performance can be addressed by limiting the
bandwidth using the system-wide or per-transfer network throttle features.
Networking issues can also be addressed by using a dedicated path for SnapMirror transfers or
using multiple paths for load balancing and failover.
If the network still does not perform up to expectations, look for typical network problems. For
example, duplex mismatches can cause networks to be very slow.

Documents and References
Data ONTAP Data Protection Online Backup
and Recovery Guide
SnapMirror Best Practices Guide
media.netapp.com/documents/tr-3446.pdf
Synchronous SnapMirror Design and
Implementation Guide

DOCUMENTS AND REFERENCES
You can obtain additional information about SnapVault and related technologies from the
following:
MANUAL
Data ONTAP Data Protection Online Backup and Recovery Guide
TECHNICAL REPORTS
TR-3446: SnapMirror Best Practices Guide
TR-3326: SnapMirror Design and Implementation Guide

Summary
How Volume SnapMirror and Qtree SnapMirror
replicate data
The characteristics of the SnapMirror Async, Sync,
and Semi-Sync modes of operation
How to configure SnapMirror for basic deployment
and advanced features
How to address SnapMirror performance issues

SUMMARY

Exercise
Module 4: SnapMirror

EXERCISE

5-1 NetApp Protection Software Administration Data ONTAP 7.3: SnapVault
MODULE 5: SNAPVAULT
SnapVault

Administration
Data ONTAP 7.3

INTRODUCTION
This module describes the SnapVault theory of operation, major features and enhancements,
management options, and typical deployment in a storage system environment.

Objectives
Describe SnapVault components and benefits
Configure and administer SnapVault
Perform advanced SnapVault operations
Deploy SnapVault for NetBackup
Explain how SnapVault for NetBackup optimizes
space utilization through the use of block sharing
and deduplication

OBJECTIVES

Overview
Back up multiple
storage systems to a
central secondary
system
Minimize media
consumption and
system overhead
through incremental
backup
Allow users to browse
backed-up files online
to perform restoration
upon request
Primary
Storage Systems
Secondary
Storage System
SnapVault
Data Center
Central
Repository
SnapVault
SnapVault
FAS1
FAS2
FAS3

OVERVIEW
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 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
The qtree is the basic
unit of SnapVault backup
and restore
You can back up a
primary qtree, non-qtree
data, and volume data to
a qtree on the secondary
system
If necessary, data is
restored from the
secondary qtrees back to
their associated primary
qtrees
SnapVault
qtree_a
qtree_b
vol1
FAS1
/vol/vol2/-
FAS2
/vol/vol3/
FAS3
Primary
Storage Systems
qtree_a
qtree_b
qtree_vol2
qtree_vol3
VOL1
Secondary
Storage System

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.
Non-qtree 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.

Initial Transfer and Backup
The initial transfer establishes the relationship
between the primary and the secondary qtrees
Incremental backup
The primary creates scheduled SnapVault
Snapshot copies of the volume containing the
qtrees to be backed up
The secondary carries out scheduled updates
Changed blocks are retrieved from the Snapshot
copy of each primary qtree
When transfers completed, the secondary takes a
Snapshot copy of its own volume

INITIAL TRANSFER AND BACKUP
INITIAL TRANSFER
In response to the snapvault start command, the secondary system requests initial
transfers of qtrees specified for backup from the primary system volume to the secondary system
volume. These transfers establish SnapVault relationships between the primary and secondary
qtrees. To initialize qtrees, you do not need to create the qtrees on the secondary; the qtrees are
created when the baseline transfers are started.
INCREMENTAL BACKUP
In response to the snapvault snap sched command-line input, the primary system creates
scheduled SnapVault Snapshot copies of the volume containing the qtrees to be backed up.
In response to the snapvault snap sched x command-line input, the secondary system
carries out scheduled update transfers and Snapshot copies creation.
For each secondary qtree, SnapVault retrieves, from the Snapshot data of each corresponding
primary qtree, the incremental changes to the primary qtrees made since the last data transfer.
Only the changed data blocks are sent to the secondary.
When the transfer is completed, the secondary takes a Snapshot copy of its own volume. Note
that SnapVault does not transfer Snapshot copies; it only transfers selected data from within
Snapshot copies.

SnapVault versus SnapMirror
SnapMirror SnapVault
Deployment
Data migration and
replication
Data archiving
Disaster
recovery
Integrated failover
capability
SnapMirror/SnapVault bundle
is required for failover
Cascading
Supports cascading
volume in a series
Cascading SnapVault qtrees
replica is not supported
Snapshot
copy
Does not create
Snapshot copy for
archiving
Provides Snapshot copy
scheduling and retention on
the secondary
Update
frequency
Up to per-minute updates Up to per-hour updates

SNAPVAULT VERSUS SNAPMIRROR
SnapMirror is more likely to be used in an environment requiring an immediate failover
capability. SnapMirror is a data migration and replication solution in a one-to-one or one-to-many
systems deployment. SnapVault is likely to be used with applications that can afford to lose some
data (backup) and do not require immediate failover. SnapVault can archive from multiple
sources to a consolidated archive.
You can propagate data from one Volume SnapMirror to another volume in a series. However,
cascading SnapVault qtree replicas in a series are not supported.
SnapMirror does not create a Snapshot copy for archiving. SnapVault adds Snapshot copy
scheduling, retention, and expiration, providing versions (backups) on the secondary.
SnapMirror transfers can be scheduled as frequently as once every minute. SnapVault transfers
can be scheduled once every hour.

SnapVault Deployment

SNAPVAULT DEPLOYMENT

Prerequisites
A separate license for the primary,
sv_ontap_pri, and for the secondary,
sv_ontap_sec, is required
In Data ONTAP 7.3, you can install both licenses on
the same storage system
You can increase the number of concurrent
transfers by installing the nearstore_option
license
TCP port 10566 must be open on both sides and
10000 as well for central management (optional)

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 site:
now.netapp.com/eservice/evallicense

In Data ONTAP 7.3, 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.

Notes:
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 SnapVault FAS3000
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.

Configuration Process
1. Install the SnapVault license
2. Set SnapVault access
3. Perform the initial baseline transfer
4. Schedule Snapshot copy creation on the
primary system
5. Schedule Snapshot copy creation and
incremental updates on the secondary system

CONFIGURATION PROCESS
The SnapVault configuration process consists of the following five steps.

1. Install the SnapVault license on the primary and secondary systems:
license add <license_code>

2. Specify the host name of the SnapVault secondary you wish to authorize to backup the
primary system:
Primary> options snapvault.access host=secondary_hostname

Specify the name of the primary system you wish to authorize for SnapVault restore
operations:
Secondary> options snapvault.access host=primary_hostname

3. For each primary qtree you wish to back up, perform an initial baseline transfer. The
destination qtree must not exist on the secondary volume.
Secondary> snapvault start S
pri_hostname:/vol/pri_vol/pri_qtree
sec_hostname:/vol/sec_vol/sec_qtree

4. Schedule SnapVault Snapshot copy time of volumes on the primary system to capture new
and changed data in the qtrees that have a SnapVault relationship:
Primary> snapvault snap sched vol_name snap_name
count@day_list@hour_list

5. Schedule SnapVault update transfers and SnapVault Snapshot copy creation of the volumes
containing the qtrees replica on the secondary system:
Secondary> snapvault snap sched (-x) vol_name snap_name

snapvault snap sched
The following is an example of the snapvault snap
sched command issued on the secondary system
snapvault snap sched -x vol1 sv_hourly 11@mon-fri@7-18
Secondary volume name
SnapVault Snapshot copy basename
SnapVault Snapshot copy retention count
Updates from Monday through Friday
Schedule
Used only on the Secondary
Updates hourly from 7 a.m. to 6 p.m.

SNAPVAULT SNAP SCHED
snapvault snap sched (-x) vol_name snap_name

The -x parameter is used only when issuing the command on the secondary and causes
SnapVault to copy new or modified data from the primary qtree to its associated qtree on the
secondary. After all the secondary qtrees on the specified volume have been updated, the
secondary then creates a Snapshot copy of this volume for archiving.

vol_name is the name of the volume on which to create this set of Snapshot copies.

snap_name is the Snapshot copy base name. It must be identical on the primary and secondary
for a given scheduled set and must differ from the regular volume Snapshot copy name. For each
Snapshot copy set, SnapVault saves the number of the Snapshot copies you specify and assigns
each Snapshot copy a version number (0 for most current, 1 for second most recent, and so on).

count defines the number of SnapVault Snapshot copies you want to maintain for archiving.
Zero (0) in this field means no new instance of this Snapshot copy will be created.

day_list specifies the days on which a new Snapshot copy for this set is created. Valid entries
are mon tue wed thu fri sat sun. The default value is mon-sun.

hour_list specifies the hours at which a new Snapshot copy is created for this set. Valid
entries are whole numbers from 0 to 23. The default is midnight (0).

Although Snapshot copies may be scheduled on the primary and secondary systems to occur at
the same hour, the transfer on the secondary system actually occurs five minutes later. This
allows time for the primary system to take its Snapshot copies and for the data to transfer.

Monitoring Transfer
Use the snapvault status command to monitor
transfer progress, check relationship status, and control
the lag
NY1> snapvault status
Snapvault secondary is ON.
Dallas:/vol/vol1/q1 NY1:/vol/vol1/q1 Snapvaulted 00:09:53 Quiescing
Dallas:/vol/vol1/q2 NY1:/vol/vol1/q2 Snapvaulted 00:15:20 (Transferring
12288 MB done)
Use the -c option to display the SnapVault qtree
configuration parameters
NY1> snapvault status c
/vol/vol1/q1 source=Dallas:/vol/vol1/q1 kbs=unlimited tries=2
/vol/vol1/q2 source=Dallas:/vol/vol1/q2 kbs=10000 tries=10

MONITOR TRANSFER
Use the snapvault status command either from the primary or the secondary system to
check the status of a data transfer, and to see how recently a qtree has been updated.
snapvault status [option] hostname:/vol/vol_name/qtree_name

Options can be one or more of the following:

-c lists all the secondary system qtrees, their corresponding primary system qtrees, maximum
speed of scheduled transfers, and maximum number of times SnapVault attempts to start a
scheduled transfer before skipping that transfer. This option can be run only from the secondary
system.
-l displays the long format of the output, which contains more detailed information.
-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.

For details on the snapvault status command output, refer to the Data ONTAP Data
Protection Online Backup and Recovery Guide.

Listing Snapshot Copies
Use the snap list q command to display all
Snapshot copies retained on the volume and
details of the qtrees contained in those Snapshot
copies
NY1> snap list -q vol1
Volume vol1 working...
qtree contents date source
-------- --------- -------- -------
sv_hourly.0 (Jan 22 15:00)
q1 Replica Jan 22 15:00 Dallas:/vol/vol1/q1
sv_hourly.1 (Jan 22 16:00)

LISTING SNAPSHOT COPIES
You use the snap list command to display a list of Snapshot copies to confirm what versions
of your primary qtree data have been backed up, or to locate by date or time a particular version
of a qtree to retrieve.
snap list [option] volume_name

-q lists all Snapshot copies retained on the volume you specified (not just SnapVault Snapshot
copies), and the details of the qtrees contained in those Snapshot copies.
-o lists the Snapshot copy timestamps, primary qtree origin (if applicable), and Snapshot copy
names stored for an individual qtree.
Example:
NY1> snap list -o /vol/vol1/q1
working...
Qtree /vol/vol1/q1
date source name
------------ -------- --------
Jan 22 15:00 Dallas:/vol/vol1/q1 hourly.0
Jan 22 16:00 Dallas:/vol/vol1/q1 hourly.1

For details on the snap list command output, refer to the Data ONTAP Data Protection
Online Backup and Recovery Guide.

Log Files
SnapVault logs are stored on the root volume, in the
/etc/log/snapmirror file
For example, on the primary
src Wed Jan 22 08:55:52 PDT Dallas:/vol/vol1/q1 NY1:/vol/vol1/q1 Request
(192.168.30.6)
slk Wed Jan 22 08:55:53 PDT state.qtree_softlock.vol1.000000ca.013.q1.src-
qt.NY1:/vol/vol1/q1.00000000.-01.1 Softlock_add (Transfer)
src Wed Jan 22 08:55:53 PDT Dallas:/vol/vol1/q1 NY1:/vol/vol1/q1 Start
src Wed Jan 22 08:57:31 PDT Dallas:/vol/vol1/q1 NY1:/vol/vol1/q1 End (36900 KB)
For example, on the secondary
dst Wed Jan 22 08:56:28 PDT Dallas:/vol/vol1/q1 NY1:/vol/vol1/q1 Request
(Initialize)
dst Wed Jan 22 08:56:30 PDT Dallas:/vol/vol1/q1 NY1:/vol/vol1/q1 Start
dst Wed Jan 22 08:58:08 PDT Dallas:/vol/vol1/q1 NY1:/vol/vol1/q1 End (36084 KB)

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.

Advanced Features

ADVANCED FEATURES

Single-File Restore with SnapVault
To restore a single file you can:
Copy the file from a Snapshot copy using
CIFS or NFS; or
Issue the Data ONTAP ndmpcopy command
from the primary system; or
Use NetApp Protection Manager.

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).
For information on the ndmpcopy command, refer to the Data ONTAP na_ndmpcopy manual
page.

\

Qtree Restore
To restore a backed-up qtree, use the
snapvault restore command
Administrators can restore the data to an
existing qtree on the primary system using:
Baseline restore
Incremental restore
Restores data in a nondisruptive way for data
sets containing LUNs

QTREE RESTORE
You use the snapvault restore command to restore a backed-up qtree saved to the
secondary system.
Starting with Data ONTAP 7.3, you can restore the data to an existing qtree on the primary
storage system using a baseline restore or incremental restore.
snapvault restore [option] -s snapname S
sec_system:/vol/volname/sec_qtree
pri_system:/vol/volname/pri_qtree

The -f option forces the command to proceed without first asking for confirmation from the
user.
The -k option sets the maximum transfer rate in kilobytes per second.
The -r option attempts an incremental restore. The incremental restore can be used to revert the
changes made to a primary system qtree since any backed-up version on the secondary system.
The -s option specifies that the restore operation must be from the Snapshot snapname on the
secondary system.
The -w option causes the command not to return after the baseline transfer starts. Instead, it waits
until the transfer completes (or fails). At that time, it prints the completion status and then returns.
Starting with Data ONTAP 7.3, the SCSI connectivity of applications to all LUNs within the
qtree being restored will be maintained throughout the restore process in order to make the restore
operation nondisruptive to applications. However, I/O operations will not be allowed during the
restore operation. Only baseline restores and incremental restores can be nondisruptive.

Baseline Restore
Baseline restore can be to an existing qtree or
to a nonexistent qtree
For an existing qtree, the restore operation
overwrites the qtree data
primary> snapvault restore S
sec:/vol/volname/sec_qtree /vol/volname/pri_qtree
Restore will overwrite existing data in
/vol/volname/pri_tree.
Are you sure you want to continue (yes/no)? Yes
Transfer started.
Monitor progress with 'snapvault status' or the
snapmirror log.

BASELINE RESTORE
The baseline restore can be to an existing qtree or to a nonexistent qtree.
In case of a baseline restore to an existing qtree, the restore operation overwrites the qtree data.
To protect from accidentally overwriting the primary qtree data, the user is prompted for
confirmation.
Example:
Primary> snapvault restore -S sec:/vol/volname/sec_qtree
/vol/volname/pri_qtree
Restore will overwrite existing data in /vol/volname/pri-qtree.
Transfer started.
Monitor progress with 'snapvault status' or the snapmirror log.

Use the -f flag to override the confirmation prompt and directly proceed with the restore.

Incremental Restore
Transfers only incremental changes from the
secondary qtree to the specified primary qtree
Primary> snapvault restore -r S
sec:/vol/volname/sec_qtree /vol/volname/pri_qtree
Restore will overwrite existing data in
Are you sure you want to continue (yes/no) ? Yes
Transfer started.
Monitor progress with 'snapvault status' or the
snapmirror log.
If the incremental restore fails due to a lack of
common Snapshot copies, attempt an in-place
baseline restore

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:
Primary> snapvault restore -r -S sec:/vol/volname/sec_qtree
Restore will overwrite existing data in /vol/volname/pri_qtree
Transfer started.
Monitor progress with 'snapvault status' or the snapmirror log.

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.

Nondisruptive Restore
SCSI connectivity to the LUNs is maintained
throughout the in-place baseline and
incremental restores
The LUNs attributes in the primary qtree are
reserved in a temporary staging area
Primary> lun show staging
/vol/san_vol1/Staging_19e45590-8948-11dc-
bb15-00a09802437a_199999999999999999/LUN1
100m (104857600) (r/w, online, mapped)
When the restore completed, the LUNs
attributes are applied to the restored LUNs

NONDISRUPTIVE RESTORE
SCSI connectivity to the 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 command 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>

Primary> lun show staging
/vol/san_vol1/Staging_19e45590-8948-11dc-bb15-
00a09802437a_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.

Resuming SnapVault
To resume backup operations after a
snapvault restore, resynchronize the
relationship with the snapvault start r
command
To cancel any further backups of the restored
qtree, release the relationship
The Snapshot copy created on the primary for
the restore is not deleted automatically
Do not delete this Snapshot copy, as it is
needed to resume SnapVault update transfers

RESUMING SNAPVAULT
After successfully restoring data with the snapvault restore command, if you wish to
resume the SnapVault relationship between the restored qtree and its backup qtree on the
secondary, you have to resynchronize the relationship using the snapvault start -r
command from the secondary system.
snapvault start -r -S pri_system:/vol/volname/pri_qtree
To discontinue the SnapVault relationship between the restored qtree and its backup qtree, enter
the following command on the primary system:
snapvault release /vol/volname/pri_qtree
Note that the Snapshot copy created on the primary for the restore is not deleted automatically.
Do not delete this Snapshot copy, as it is needed to perform the restart.

LUN Clone Backup
With Data ONTAP 7.3 release, SnapVault is able
to back up LUN clones in optimized mode using
SnapDrive for Windows
LUN clones are transferred as clones
Space savings with the parent LUN is preserved
Once the SnapVault relationship is handed off to
SnapDrive for Windows, update transfers must not
be run from the command-line interface
The backing Snapshot copy is locked on the
secondary after the backup Snapshot copy is
transferred

LUN CLONE BACKUP
When integrated with Data ONTAP, SnapDrive for Windows, or SnapDrive for Windows with
Microsofts Volume Shadow Copy Service creates two Snapshot copies upon LUN backup:
A backing Snapshot copy containing the LUN to be cloned
A backup Snapshot copy containing both the LUN and the clone
In versions of Data ONTAP earlier than 7.3 SnapVault backs up a LUN clone as a new LUN
during the initial baseline transfer. Therefore, the LUN clone and its backing LUN get replicated
as two separate LUNs on the secondary.
With the Data ONTAP 7.3 release, SnapVault is able to back up LUN clones in optimized mode
using SnapDrive for Windows. The LUN clones are transferred as clones and space savings with
the parent LUN is preserved. The SnapVault initial baseline transfer is performed at the
command-line interface but once the SnapVault relationship is handed off to SnapDrive for
Windows, transfers must not be run from the command-line interface.
On the secondary, the backing Snapshot copy is locked after the backup Snapshot copy is
transferred.

LIMITATIONS:
In optimized mode, the primary qtree must not contain LUN clones.
The transfer fails if the backing Snapshot copy is missing on the secondary.
A SnapVault restore will also fail if the backing Snapshot copy is missing on the primary.
Finally, in optimized mode, cascades from Volume SnapMirror destinations are not
supported.

SnapVault and
SnapMirror

SNAPVUALT AND SNAPMIRROR

Overview
The SnapVault and SnapMirror bundle
provides a consolidated data protection and
disaster-recovery solution
Fast and space-efficient disk-based backup
Recover from system disaster by making any
online backup copy writable
Rapid disaster recovery from hourly, nightly, or
weekly backup
Offsite disaster recovery by replicating backups
to remote sites

OVERVIEW
The SnapVault and SnapMirror bundle provides a consolidated data protection and disaster-
recovery solution. The solution provides:
Fast and space-efficient disk-based backup
Recovery from system disasters by making any online backup copy writable
Rapid disaster recovery from hourly, nightly, or weekly backup
Offsite disaster recovery by replicating backups to remote sites

Protecting SnapVault with SnapMirror
This solution consists of replicating SnapVault based
backup copies through SnapMirror to a disaster-
recovery site to provide:
Backup and standby service for SnapVault
Backup and restore protection for SnapVault
Data Center
DR site
Volume
SnapMirror
SnapVault
SnapVault
SV/SM
Bundle
Windows
SV/SM
Bundle
SV Primary
SV Primary
SV/SM
Bundle
SV/SM
Bundle

PROTECTING SNAPVAULT WITH SNAPMIRROR
By setting up a SnapMirror relationship between the SnapVault secondary and a SnapMirror
destination storage system, you can provide backup and standby service or backup and restore
protection for the SnapVault secondary data.
SnapMirror backup and standby service for SnapVault uses the SnapMirror destination
device as a standby device to be activated as an alternate SnapVault secondary system if the
original secondary system goes down.
SnapMirror backup and restore protection for SnapVault uses the SnapMirror destination
device as a source from which you can restore backup data to a SnapVault secondary that has
suffered data loss or corruption.
Under this configuration, SnapVault does not delete any Snapshot copy version on the primary
storage systems until that version has been successfully mirrored from the SnapVault secondary
to its SnapMirror destination. This guarantees that a Snapshot copy version will always be
retrievable even if the SnapVault secondary is disabled. By replicating the vaulted Snapshot
copies remotely, you can fail over to a desired Snapshot copy on the remote disaster recovery
storage.
The solution requires the purchase and the installation of the SnapVault and SnapMirror license
bundle.
For more information on the SnapMirror backup and standby service for SnapVault, refer to the
Data ONTAP Data Protection Online Backup and Recovery Guide.

Considerations
If a new SnapVault update is triggered before
the Volume SnapMirror transfer has
completed, then the ongoing transfer will abort
Transfers fail when the storage system
reaches the maximum simultaneous transfers
supported
In both cases, ensure that SnapMirror and
SnapVault schedules do not overlap and do
not stretch

CONSIDERATIONS
An ongoing Volume SnapMirror update transfer will abort if a SnapVault scheduled or manual
update is triggered before the Volume SnapMirror update transfer has completed on the
SnapMirror destination.
Transfers also fail when the storage system reaches the maximum simultaneous transfers
supported. To determine if the halfway storage system reaches that limit, you have to sum up all
active relationships scheduled at the same time.
Note that Protection Manager does not throttle requests to respect the limit. If a new data set is
created and many relationships must be established, they are all created at once. This leads to "too
many active transfers at once" errors on the storage system console, and to a large backlog of
running jobs on the Operations Manager server.
In all cases, ensure that the SnapMirror and the SnapVault update schedules do not overlap and
do not stretch.

SnapMirror and SnapVault for DR
Data Center
Standby DR site
In this solution, data at the production center is replicated at
the volume level to a SnapMirror destination system
Then the SnapMirror replicas are protected at the qtree
level to a tertiary appliance at the DR site using SnapVault
Nearby site
Volume
SnapMirror
SnapVault
SV/SM
Bundle
SV/SM
Bundle
SnapMirror
Source
SV/SM
Bundle
SnapMirror
Source
SV/SM
Bundle

SNAPMIRROR AND SNAPVAULT FOR DISASTER RECOVERY
In this data protection and disaster-recovery solution, data at the main production center is
replicated at the volume level to a SnapMirror destination system at a nearby site.
Then the SnapMirror replicas are protected at the qtree level to a tertiary appliance at the disaster-
recovery site using SnapVault.

This operation is possible because the SnapMirror source system, on which the SnapVault service
is also licensed, creates SnapVault Snapshot copies based on a SnapVault schedule. The
SnapVault Snapshot copies are transferred to the SnapMirror destination system during Volume
SnapMirror updates.

The solution requires the purchase and the installation of the SnapVault and SnapMirror license
bundle.

Recover from Site and Regional Disasters
In the event of a site disaster, you can fail over SnapMirror to the nearby
destination system and fail back without requiring a complete data
transfer
In the event of a regional disaster, you can fail over SnapVault to the
tertiary device and then resume vault operations after recovery
Data Center
Standby DR site Nearby site
Volume
SnapMirror
SnapVault
SV/SM
Bundle
SV/SM
Bundle
SnapMirror
Source
SV/SM
Bundle
SnapMirror
Source
SV/SM
Bundle

RECOVER FROM SITE AND REGIONAL DISASTERS
In case of a disaster at the main production center, the data replicated to a nearby site can be made
available to clients across the network, ensuring uninterrupted operation and data availability.
Once the damage is repaired at the production center, SnapMirror can be used to efficiently
transfer the data back to the primary site. After the production site takes over normal application
operation again, SnapMirror transfers to the destination storage system can resume without
requiring a complete data transfer.
If the entire region is affected by a disaster, you can fail over SnapVault to the tertiary device and
then resume vault operations after recovery.
LIMITATION
SnapVault updates from the Volume SnapMirror destination volume can only take place from the
latest base Volume SnapMirror Snapshot copy. This is an expected behavior, as by design
SnapVault from a Volume SnapMirror destination volume is hard coded to always ignore the
Snapshot copy requested by name, and instead transfer the most recent Volume SnapMirror base
Snapshot copy.

SnapVault for
NetBackup (SV-NBU)

SNAPVUALT FOR NETBACKUP (SV-NBU)

Overview
Backs up heterogeneous clients
Creates backup images online for immediate access
Optimizes space utilization
Allows recovery of files using NFS and CIFS
UNIX
Linux
NetBackup images
tar format
Windows
Data ONTAP native
format (WAFL)
User-initiated drag-
and-drop restores
Data ONTAP
deduplication
eliminates
redundant
data
L
A
N
NetBackup Clients NetBackup Server SnapVault Storage System
primary secondary

OVERVIEW
NetApp and Symantec bring years of collaboration and expertise to SnapVault for NetBackup.
SnapVault for NetBackup provides a unique disk-to-disk data protection solution integrating
Veritas NetBackup 6.0 with NetApp NearStore secondary storage and SnapVault software.
The SnapVault for NetBackup feature provides an optimized disk-based backup repository for
heterogeneous primary systems, using NetApp secondary storage system.
You can easily integrate SnapVault for NetBackup without changes to existing backup
topologies. Adding SnapVault for NetBackup is similar to adding a traditional NetBackup tape
unit or disk storage unit. This assumes you are using NetBackup 6.0 or later. It is best to use
NetBackup 6.0 MP5 or later.
The SnapVault for NetBackup feature provides the following benefits:

You can back up heterogeneous primary storage systems, such as UNIX, Linux, Novell,
Solaris, and Windows systems.
You can create a large number of backup images online for immediate access.
The feature creates point-in-time images of the primary file system in archival Snapshot
copies.
You can drag and drop files and directories to recover them over NFS

and CIFS protocols.
The feature optimizes space utilization by eliminating redundant data blocks between backup
images.
You can achieve high availability for SnapVault for NetBackup by directing backups to
storage systems in an active-active configuration.
You can configure a disaster-recovery solution for SnapVault for NetBackup using Volume
SnapMirror.

SnapVault for NetBackup Backup Streams
The NetBackup tar stream
Consists of header and data files
The Data ONTAP metadata stream
Describes the contents of the tar stream
Used to unpack the tar stream into the WAFL
file system in Data ONTAP
After all of the data is unpacked and written to
disk, the backup is captured to a Snapshot
copy

SNAPVAULT FOR NETBACKUP BACKUP
The NetBackup server controls the flow of data from the NetBackup client to the SnapVault
secondary system. Backups are initiated by the NetBackup server, are based on policies, and are
scheduled using the NetBackup Administration Console. NetBackup clients data is backed up in
a qtree on the SnapVault secondary.
Each backup data transfer to the SnapVault secondary consists of two streams: A standard
NetBackup tar stream that consists of header and file data and a Data ONTAP metadata stream
that describes the contents of the tar stream.
The tar data is written to the secondary system and stored on disk. Keeping the tar stream on
disk allows restores to be initiated by NetBackup from the NetBackup Administration
Console.
Using the metadata stream, the files and directories inside the tar stream are unpacked into
the WAFL file system in Data ONTAP. The file data in the unpacked file system does not
consume additional blocks because it shares all of the tar stream data blocks.
After all of the data is written to disk and all the data inside the tar stream is unpacked into an
active file system, the backup is captured to a Snapshot copy. In this way, backups of the
primary file system are captured to unique Snapshot copies that you can browse if you need to
restore a previous version of files or directories. The Snapshot copy is deleted only after all the
backups in a Snapshot copy are expired by NetBackup.

Backup Layout on the Secondary
The NetBackup qtree images stored on the SnapVault
secondary follow the default file system naming
convention
File Name Description
nbu_basename_policyname_suffix
Qtree naming convention where each
name is specific to NetBackup client and
policy settings.
nbu_online_data
Subdirectory of
nbu_basename_policyname_suffix
Directory in which data is unpacked.
You can view the backed up data in this
qtree.
nbu_image_data
Special qtree that contains information
specific to the tar images associated with
each qtree.

BACKUP LAYOUT ON THE SECONDARY
SnapVault for NetBackup qtree images stored on the SnapVault secondary follow the default file
system naming convention.
nbu_basename_policyname_suffix is the qtree naming convention where each name is
specific to NetBackup client and policy settings.

basename is the NetBackup client name
policyname is the NetBackup policy name
suffix is a four-digit number
nbu_online_data is the directory in which data is unpacked. It is a subdirectory of the
nbu_basename_policyname_suffix qtree. You can view the backed up data in this qtree.
nbu_image_data is a special qtree that contains information specific to the tar images
associated with each qtree.

Snapshot Copy Management
Archival Snapshot copies are managed
efficiently so that we consume as few
Snapshot copies as is necessary
Data ONTAP coalesces backups for different
polices into a single Snapshot copy
Redundant Snapshot copies are removed

SNAPSHOT COPY MANAGEMENT
The archival Snapshot copies are managed efficiently so that we consume as few Snapshot copies
as is necessary. Data ONTAP optimizes the number of Snapshot copies consumed by coalescing
backups for different polices into a single Snapshot copy. For example, if three backups for
different policies finish before the next update to any of the backups, Data ONTAP coalesces the
three backups into one Snapshot copy.

Space Savings
Context-based block sharing
Eliminates common blocks between the current tar
stream and all previous tar streams
Volume deduplication
Eliminates redundant data residing anywhere within
a SnapVault for NetBackup flexible volume
Runs as a scan in the background at the end of
every transfer
Initiated only if the number of changed blocks is
greater than 20%
In Data ONTAP 7.3, deduplication occurs before
writing the backup to disk

SPACE SAVINGS
CONTEXT-BASED BLOCK SHARING
As Data ONTAP unpacks file data, it performs a context-based block-sharing operation to
eliminate common blocks between the current tar stream and all previous tar streams; therefore,
only new or changed data blocks in the new tar stream are written to disk on the SnapVault
secondary system.
Data ONTAP volume deduplication eliminates redundant data residing anywhere within a
SnapVault for NetBackup flexible volume. SnapVault for NetBackup volume deduplication
eliminates redundancy:
Between multiple backups of same source data sets
Between multiple backups of different source sets
Within one backup (duplicate files and blocks)
Deduplication starts automatically once a particular SnapVault transfer completes and runs on
enabled SnapVault for NetBackup flexible volumes once a day at midnight by default. The
deduplication of blocks is initiated only if the number of changed blocks is greater than 20%. The
20% threshold is not configurable.
In Data ONTAP 7.3, data deduplication occurs before writing the backup to disk. This new
process saves a write operation and a block-free operation for each duplicate block and yields a
significant increase in performance.

Backup Modes
Determine the backup mode when configuring a
NearStore disk storage unit with the NetBackup
Administration Console
Three backup modes: Image, Space Optimized
Image (SOI), and File System Export (FSE)
Image SOI FSE
Data ONTAP block boundary alignment
Context-based block sharing
CIFS and NFS export
Archival Snapshot copies

BACKUP MODES
You determine the type of backup mode when configuring a NearStore disk storage unit using the
NetBackup Administration Console. You can choose three different backup modes.
Image mode: Backed up tar images that use the Image mode are not aligned on the Data
ONTAP block boundary, the file system is not exported using NFS or CIFS protocols, and no
archival Snapshot copies are made. You use the Image backup mode when you want to
perform a backup similar to a basic NetBackup disk backup.
Space Optimized Image mode (SOI): Backed-up tar images that use the Space Optimized
Image mode are aligned on the Data ONTAP block boundary for block sharing, but the file
system is not exported using NFS or CIFS protocols, and no archival Snapshot copies are
taken. Deduplication occurs on the volume after the backup is complete, which saves storage
space. You use the Space Optimized Image backup mode when backing up application data.
File System Export mode (FSE): Backed up tar images are aligned on the Data ONTAP
block boundary for block sharing. File System Export mode does not use volume
deduplication processing. However, blocks are shared through context-dependant block-
sharing during the backup process. The unpacked file system is exported using NFS and CIFS
protocols to allow drag-and-drop restore functionality, and the backups are captured in
archival Snapshot copies.

Backing up Applications
With Data ONTAP 7.3, SnapVault for
NetBackup backups support the following
applications
IBM
Lotus
Domino Server
Sybase
Adaptive Server Enterprise

Microsoft SQL Server
Oracle Database 10g
SnapVault for NetBackup application backup
uses Space Optimized Image (SOI) mode

BACKING UP APPLICATIONS
With Data ONTAP 7.3 and NetBackup 6.5 and later releases, SnapVault for NetBackup backups
support the following applications:
IBM Lotus Domino Server
Sybase Adaptive Server Enterprise
Microsoft SQL Server
Oracle Database 10g

For information about how to configure these applications to use NetBackup to manage backups,
refer to the appropriate NetBackup Database Administration Guide.
SnapVault for NetBackup application backup is achieved using the Space Optimized Image
(SOI) mode which is a two-step process:

1. The first step aligns the application data from the NetBackup agent on the Data ONTAP
block boundary and writes the data to disk.
2. After the entire backup is written to disk, the second step uses deduplication to eliminate
duplicate blocks on a volume to the blocks in the latest backup and then to achieve space
savings. Volume deduplication requires the a_sis license installed on the SnapVault
secondary.
As discussed previously, the SOI backup mode does not support CIFS shares and NFS exports.
The SOI backup mode also does not support archival Snapshot copies creation. Data cannot be
restored using drag-and-drop restore functionality. To restore data from the destination storage
system, follow the restore procedure in NetBackup documentation for the application.

Storage Systems and Volume Size
With Data ONTAP 7.3,
SnapVault for
NetBackup supports
the FAS3040,
FAS3070, FAS6030,
and FAS6070 platforms
Flexible volumes must
be 16 TB or smaller,
depending on platform
type
Platform Maximum Volume Size
FAS3020 1TB
FAS3050 2TB
FAS3040 3TB
R200 4TB
FAS3070 6TB
FAS6030 10TB
FAS6070 16TB
Maximum SnapVault for NetBackup
volume sizes
(including snap reserve space)

STORAGE SYSTEM AND VOLUME SIZE
In versions of Data ONTAP earlier than 7.3, SnapVault for NetBackup supported only FAS3020,
FAS3050, and NearStore R200 storage systems.
With Data ONTAP 7.3 or later, you can also enable SnapVault for NetBackup on the FAS3040,
FAS3070, FAS6030, and FAS6070 platforms.
Flexible volumes must be 16 TB or smaller, depending on platform type. The SnapVault for
NetBackup flexible volume size is a function of platform memory. With the introduction of
newly supported platforms, the maximum volume size is increased to 16 TB.

Configuring SnapVault for NetBackup on
the Secondary
1. Install the licenses
Required: sv_ontap_sec and sv_nbu_sec
Optional: nearstore_option and a_sis
2. Set SnapVault access permission
3. Enable and configure NDMP
4. Ensure TCP port 10571 is open
5. Configure deduplication (optional)

CONFIGURE SNAPVAULT FOR NETBACKUP ON THE SECONDARY
The SnapVault for NetBackup configuration on the secondary system consists of the following
five steps:
1. Install the sv_ontap_sec and sv_nbu_sec required licenses.
sv_nbu_sec is an additional new license required with Data ONTAP 7.3 to enable SnapVault
for NetBackup. If the secondary is not a NearStore system, install the nearstore_option
license. To run deduplication on SnapVault for NetBackup volume, you must also install the
a_sis license on the secondary.
2. Set SnapVault access by specifying the hostname of the NetBackup server:
options snapvault.access host=netbackup_server_hostname

3. Enable and configure NDMP.

3.1 Enable the NDMP service:
options ndmpd.enable on

3.2 Add a new backup user to the Backup Operators useradmin group list (optional):
useradmin useradd backupuser -g Backup Operators

3.3 Generate an NDMP password for the new user:

ndmpd password backupuser

3.4 Set NDMP access by specifying the host name of the NetBackup server:

options ndmpd.access host=netbackup_server_hostname

4. Ensure that TCP port 10571 is open. The NetBackup client connect requests are received on
that port.

5. Configure deduplication (optional) by specify the SnapVault for NetBackup volume on which
deduplication will run:
sis on /vol/volname

Monitoring SnapVault for NetBackup
Backup
Confirm that the secondary qtree was created
Secondary> qtree status
Volume Tree Style Oplocks Status
-------- -------- ----- -------- ---------
vol0 unix enabled normal
p3 mixed enabled normal
p3 .nbu_image_data mixed enabled snapvaulted
p3 nbu_client1_C1_F1.CLF_daily_0000 mixed enabled snapvaulted
p3 nbu_client1_C1_HDR.IMG_daily_0000 mixed enabled snapvaulted
Monitor transfer progress
Secondary> snapvault status
system1:daily client:/vol/p3/nbu_client_1_daily_0000
Snapvaulted 00:35:32 Idle

MONITORING SNAPVAULT FOR NETBACKUP BACKUP
To confirm that a destination qtree was created on the secondary system, use the qtree
status command.
Example:
Secondary> qtree status
Volume Tree Style Oplocks Status
-------- -------- ----- -------- ---------
vol0 unix enabled normal
p3 mixed enabled normal
p3 .nbu_image_data mixed enabled snapvaulted
p3 nbu_client1_C1_F1.CLF_daily_0000 mixed enabled snapvaulted
p3 nbu_client1_C1_HDR.IMG_daily_0000 mixed enabled snapvaulted
To check the status of a data transfer, use the snapvault status command. You can
use this display to view recent backup activity and confirm transfer status.
Example:
Secondary> snapvault status
system1:daily client:/vol/p3/nbu_client_1_daily_0000 Snapvaulted
00:35:32 Idle

Deduplication Overview
Deduplication reduces storage use by sharing
identical data blocks within a flexible volume
Works well with data sets that have duplicated
data (e.g. full backups)
Runs as a background process and is
transparent to any client
The space saving ratios vary between data sets
Frequent backup gain up to 20% savings
Non-backup scenarios gain up to 40%
To estimate your own savings, please visit
http://www.dedupecalc.com

DEDUPLICATION OVERVIEW
Deduplication is a software option in Data ONTAP that eliminates duplicate data blocks to reduce
the amount of storage space used to store data.
Deduplication can run on FlexVol volumes starting with Data ONTAP 7.3. To use deduplication,
you need to obtain and install the appropriate license.
The deduplication feature is integrated with SnapVault. This enables increased storage efficiency
in backing up data, and improved storage utilization on the secondary. Deduplication starts
automatically after a SnapVault completes when both SnapVault and Deducplication are licensed
and enabled.

presentation.ppt
Identical file
20 blocks
presentation.ppt
Original File
20 blocks
presentation.ppt
Edited file
10 blocks added
= Identical blocks
Deduplication in Action
Without NetApp deduplication
70 total blocks
With NetApp deduplication
30 total blocks

DEDUPLICATION IN ACTION
Deduplication works by removing duplicate WAFL blocks. The deduplication uses inodes and
the reference pointers that are part of the inode to create multiple pointers to the same blocks.
This is the same basic technology used for NetApp Snapshot copies.
Deduplication works with data from any sort of protocol such as CIFS, NFS, FCP, iSCSI, NDMP
or SnapVault and is application transparent.

Deduplication and SnapVault
Integrated with SnapVault
Starts automatically when both SnapVault and
Deduplication are licensed and enabled
Starts after a SnapVault completes
Does not use a schedule

DEDUPLICATION AND SNAPVAULT
Deduplication and SnapVault work together in the following ways:
Deduplication starts automatically after a SnapVault transfer completes.
NOTE: After every SnapVault transfer, deduplication checks the log of changes. The
deduplication of blocks is initiated only if the number of changed blocks is greater than 20
percent of the blocks in the volume.
Deduplication of a SnapVault volume cannot be run based on a schedule. Deduplication
internally synchronizes with the SnapVault schedule. Therefore, no external synchronization
is required between deduplication runs and the schedule of SnapVault transfers. However,
deduplication can be run manually.
The maximum number of deduplication operations allowed to run concurrently on a storage
system is eight. This includes the deduplication operations linked to SnapVault volumes and
those that are not linked to SnapVault volumes.

Monitoring Deduplication
Monitor deduplication process progress
secondary> sis status
Path State Status Progress
/vol/vol1 Enabled Idle Idle for 10:45:23
/vol/vol2 Enabled Active 25 GB Scanned
/vol/vol3 Enabled Active 25 MB Searched
/vol/vol4 Enabled Active 40 MB (20%) Done
Measure space savings
Secondary> snapvault status -b
Volume actual used saved %saved ratio
------ ------ ---- ----- ------ -----
vol1 478GB 226GB 251GB 53% 2.11:1
vol2 956GB 237GB 719GB 75% 4.02:1
vol3 21478MB 16623MB 4854MB 23% 1.29:1
vol3 62GB 20GB 42GB 68% 3.12:1

MONITORING DEDUPLICATION
You can use the Data ONTAP sis status command to monitor the deduplication process
progress.
In the above example, volume vol1 is Idle. Deduplication on the volume finished 10:45:23 ago.
Volume vol2 is Active. Deduplication is doing the whole volume scanning. So far, it has scanned
25 GB of data.
Volume vol3 is Active. The operation is searching for duplicated data. There are 25 MB of data
already searched.
Volume vol4 is also Active. The operation has saved 40 MB of data. This is 20% of the total
duplicate data found in the searching stage.

You can find out how much space you have saved with deduplication by using the Data ONTAP
snapvault status b command. Do not use the df s command.

Descriptions of the snapvault status -b command output fields:
actual - Total data sent from NetBackup and stored
used - Total disk space consumed on the volume
saved - Total storage savings on the volume
%saved - Percentage of storage saved
ratio - The effective compression ratio storage savings is providing

Restoring Data
You can restore data from FSE backups in one
of the following ways:
Use the NetBackup Administration Console
Access the exported file system and use drag-
and-drop technologies
Requires Data ONTAP 7.2 or later
The exported file system is in the
nbu_online_data subdirectory in the
backup qtree

RESTORING DATA
You can restore data from FSE backups in one of the following ways:
Use the NetBackup Administration Console.
For information about restoring data using the NetBackup Administration Console; see the
NetBackup documentation.
Access the SnapVault for NetBackup volume by mounting the volume (NFS) or creating a
share (CIFS), and either copy or drag the data.

The exported file system is in the subdirectory nbu_online_data in the backup qtree.

SnapVault for NetBackup and SnapMirror
for Disaster Recovery
In this solution, SnapVault for NetBackup volumes are
replicated to a disaster-recovery site using Volume
SnapMirror
Dense blocks are sent from the SnapMirror source to the
SnapMirror destination
Deduplication properties from the source are preserved on the
destination
DR Site
Data Center
Volume
SnapMirror
UNIX
Windows
L
A
N
NetBackup Clients NetBackup Server SnapVault for NetBackup
SV/SM
Bundle
FAS1
SV/SM
Bundle
FAS2
Destination
Storage System

SNAPVAULT FOR NETBACKUP AND SNAPMIRROR FOR DISASTER
RECOVERY
You can use NetBackup and Volume SnapMirror technology to provide a disaster-recovery
solution for NearStore disk storage units. SnapVault for NetBackup with Volume SnapMirror
provides disaster recovery in a very efficient manner. Dense blocks are sent only once over wire
from the SnapMirror source to the SnapMirror destination, and deduplication properties from the
source are preserved on the destination.
To provide failover support in a disaster recovery situation using the Volume SnapMirror feature
outside of the purview of NetBackup, you need to replicate the SnapVault for NetBackup
volumes to the SnapVault secondary storage system (FAS1 in the illustration), and then to a
SnapMirror destination storage system (FAS2).
In the case of a failure where the volumes on FAS1 are unrecoverable, you need to manually
break the SnapMirror relationship, which make the replicated volumes on FAS2 available for
read and write access.
After a few configuration adjustments in NetBackup, all future backups and restores to the
volumes that were replicated can now be served by FAS2. You can subsequently reconfigure
NetBackup to direct restores, verifications, deletions and backups back to FAS1. Your disaster-
recovery plan should include NetBackup catalog backup and restore procedures.
For more information regarding catalog backup and restore, see the NetBackup Administrators
Guide.

SnapVault for NetBackup and
Active-Active Configuration
Starting with Data ONTAP 7.3, SnapVault for
NetBackup supports full active-active configuration
SnapVault for NetBackup is able to connect to a taken
over node and get SnapVault for NetBackup requests
serviced
NetBackup images
tar format
vol1
vol2
FAS1
FAS2
UNIX
Windows
L
A
N
L
A
N
NetBackup Clients NetBackup Server SnapVault for NetBackup Disk Drives

SNAPVAULT FOR NETBACKUP AND ACTIVE-ACTIVE CONFIGURATION
Starting with Data ONTAP 7.3, SnapVault for NetBackup supports full active-active
configuration for the partner host in takeover mode. SnapVault for NetBackup is now able to
connect to a taken-over node and get SnapVault for NetBackup requests serviced. After takeover
or giveback, NetBackup reconnects and retries any SnapVault for NetBackup operation that was
interrupted by the takeover or the giveback.
For details on Data ONTAP active-active configurations, see the Data ONTAP Active-Active
Configuration Guide.
During takeover and giveback, all TCP/IP connections between NetBackup and the partner node
are interrupted. All backups and all restores to or from the former failed node get disrupted.
NetBackup needs to reestablish all of its connections to the node that was being taken over or
given back. The retry of a failed backup or restore must be reinitiated by the backup
administrator.
In takeover mode, context-based block sharing runs on both the local and partner nodes. Volume
deduplication works on the local node, but not on the partner node.
Note that SnapVault for NetBackup does not support Stretch and Fabric MetroCluster.
For more information on SnapVault for NetBackup and active-active configuration deployment,
refer to the Data ONTAP Data Protection Online Backup and Recovery Guide.

Data ONTAP Data Protection Online
Backup and Recovery Guide
SnapVault Deployment and Configuration
SnapVault Best Practices Guide

following:
MANUAL
TECHNICAL REPORTS
TR-3240: SnapVault Deployment and Configuration
TR-3487: SnapVault Best Practices Guide

Summary
How to configure and administer SnapVault
Perform advanced SnapVault operations
Deploy SnapVault for NetBackup
Explain how SnapVault for NetBackup
optimizes space utilization through the use
of block sharing and deduplication

SUMMARY

Exercise
Module 5: SnapVault

EXERCISES

6-1 NetApp Protection Software Administration Data ONTAP 7.3: Open Systems SnapVault
MODULE 6: OPEN SYSTEMS SNAPVAULT
Open Systems
SnapVault

Administration
Data ONTAP 7.3

INTRODUCTION
This module describes how to use the Open Systems SnapVault 2.6 software to back up Windows
and UNIX-based platforms to a SnapVault secondary storage system. The lecture includes major
features and enhancements, management options, and typical deployment.

Objectives
Describe how Open Systems SnapVault integrates
with Data ONTAP SnapVault
List Open Systems SnapVault advanced features
Configure and administer Open Systems
SnapVault
Perform Open Systems SnapVault backup and
restore operations
Explain how Open Systems SnapVault integrates
with virtualization
Troubleshoot and resolve Open Systems
SnapVault transfer failures

OBJECTIVES

Overview
The primary is a
Microsoft Windows or a
UNIX-based open
system
The Open Systems
SnapVault agent is
installed on the primary
and enables the system
to back up its data to the
secondary
The secondary backs up
the primary data using
the Data ONTAP
SnapVault technology
SnapVault
Secondary
Storage System
Primary Systems
running OSSV
Linux Server
Windows Server
UNIX Server
ESX Server

OVERVIEW
Open Systems SnapVault is a disk-to-disk data protection solution that takes advantage of the
NetApp SnapVault technology to protect data residing on the following platforms:
Microsoft Windows
Red Hat
Enterprise Linux
Novell
SUSE
Linux Enterprise Server

Sun
Solaris
IBM
AIX

HP HP-UX

VMware
ESX Server

For a complete list of currently supported versions of these platforms, refer to the Open Systems
SnapVault 2.6 Installation and Administration Guide on the NOW (NetApp on the Web) site.
The Open Systems SnapVault agent software module is installed on the primary and enables the
system to back up its data to the secondary.
The secondary system is a NetApp storage appliance, such as a NearStore

system. The secondary
backs up the primary data using the Data ONTAP SnapVault technology.

Theory of Operation
The directory is the basic unit of Open Systems
SnapVault backup
Incremental update is based on file modification time
If block-level incremental is enabled, only changed
blocks are transferred
Snapshot copy creation for archiving takes place on
the SnapVault secondary
UNIX
Server
Primary Systems
C:\data
Windows
server
/usr
SnapVault Secondary
Storage System
Read-only
qtrees replica
qtree_usr
Online/writable
volume
/vol/vol1
qtree_data

THEORY OF OPERATION
The directory is the basic unit of Open Systems SnapVault backup. Each directory, file, or drive
you want to back up from a primary is backed up to its own qtree on the SnapVault secondary
storage system.
For the first backup, you perform an initial baseline transfer of the identified directory or file.
This transfer establishes the SnapVault relationship between the Open Systems SnapVault
primary directory or file and its mapped SnapVault secondary qtree.
Subsequent transfers can either be initiated manually or configured for automatic scheduled
updates. You specify the schedules on the secondary using the Data ONTAP snapvault
command or using an NDMP-based management application such as Protection Manager or a
third-party NDMP-based supported application.
Upon an incremental update request, the Open Systems SnapVault primary determines whether
the directory or file has changed since the last successful transfer by examining the file
modification time. If block-level incremental (BLI) is enabled (for Windows platforms only),
Open Systems SnapVault determines which blocks data changed and sends only those modified
blocks to the secondary. After the secondary qtree is updated, SnapVault creates a Snapshot copy
of the volume for archiving.
If a directory or file data needs to be restored to the primary, SnapVault retrieves the data from
one specified Snapshot copy and transfers the data back to the primary system that requests it.

Central Management
Open Systems SnapVault backup schedules,
retention policies, backup control and
monitoring can be centrally managed by the
following NDMP-based applications:
NetApp Protection Manager
BakBone Software
, Inc. NetVault
SyncSort
Backup Express
CommVault
Galaxy

CENTRAL MANAGEMENT
Open Systems SnapVault can be managed from a variety of management applications. These
applications use the NDMP protocol, TCP port 10000, to communicate with the Open Systems
SnapVault clients and the storage systems over a TCP/IP network. Backup schedules, retention
policies, backup control, and monitoring are centrally configured on these applications.
The applications that you can use to manage Open Systems SnapVault are as follows.
NetApp Protection Manager
BakBone Software, Inc. NetVault
SyncSort Backup Express
CommVault Galaxy

Note that the NetApp Host Agent is required to manage Open Systems SnapVault using
Protection Manager and it is packaged with the Open Systems SnapVault software module.
For more information on central management using the NetApp Protection Manager, refer to the
Protection Manager module of this course.

Integrated Backup and DR Solution
SnapVault based backup copies are replicated through
SnapMirror to a disaster recovery, or DR site
If the SnapVault secondary becomes unusable, you
can redirect the subsequent Open Systems SnapVault
transfers to the tertiary storage system
Primary OSSV
Systems
Windows
Data Center
DR site
Volume
SnapMirror
SnapVault
SnapVault
SV/SM
Bundle
Windows
SV/SM
Bundle
SV/SM
Bundle
SV/SM
Bundle

INTEGRATED BACKUP AND DR SOLUTION
The Open Systems SnapVault primary systems have the same advantages as any other primary
systems in a data protection and disaster recovery scenario.
You can protect the SnapVault secondary system from disasters by using the SnapMirror feature.
The configuration involves setting up SnapMirror relationships from the volumes on the
SnapVault secondary system to volumes on a remote (tertiary) NetApp storage system, as shown
in the illustration.
If the SnapVault secondary becomes unusable because of a disaster, you can manually redirect
the subsequent Open Systems SnapVault transfers to the tertiary system. Effectively, the tertiary
system becomes the new SnapVault secondary, and the Open Systems SnapVault transfers
continue using the most recent Snapshot copy common to both the primary and tertiary storage
systems.

Advanced Features

ADVANCED FEATURES

Backing Up Open Files
Open File Manager (OFM)
Backs up open files on W2K platforms
Requires the sv_windows_ofm_pri license
Supports one active Snapshot copy per drive
Volume Shadow Snapshot Copy Service (VSS)
Backs up open files on W2K3 platforms
OFM and VSS
Are integrated with the Open Systems SnapVault agent
Tunable parameters using the Open Systems SnapVault
Configurator
Disable open files backup on the secondary:
snapvault modify o back_up_open_files=off

BACKING UP OPEN FILES
Open File Manager (OFM) allows Windows Server 2000 files that are open and in use to be
backed up with only a very short disruption to users or their current applications. OFM is
automatically installed at the same time the Open Systems SnapVault agent for Windows 2000
Server is installed. OFM is then enabled as soon as the Open Systems SnapVault agent
installation completes, the primary system is rebooted, and the OFM component,
sv_windows_ofm_pri is licensed on the secondary.
When an update is invoked, a Snapshot copy of the drive to be backed up is taken by OFM. To do
so, OFM produces a temporary drive letter, and the Open Systems SnapVault agent backs up the
files from that temporary drives Snapshot copy. OFM supports one active Snapshot copy per
disk volume letter. If multiple drives are backed up simultaneously, backups will proceed, but the
drives will be backed up sequentially.
Microsoft Windows Server 2003 provides a native Snapshot copy mechanism as part of the
Volume Shadow Copy Service (VSS). VSS Snapshot copy functionality is integrated with the
Open Systems SnapVault agent as a standard feature. Unlike the OFM implementation, it is
possible to have multiple copies of a shadow copy per drive.
OFM and VSS tunable parameters and drive exclusions can be configured using the Open
Systems SnapVault Configurator. OFM and VSS settings should be changed only for
troubleshooting. Open file backup can be disabled from the secondary using the snapvault
modify o back_up_open_files=off command.

Snapshot Copies Management
Open Systems SnapVault has the ability to retain Snapshot
copies
There are two possible configurations for common Snapshot
management:
MaxCPRestartWaitTime
Set the maximum waiting time a Snapshot copy is retained
after a transfer failure; default is 10 minutes
FailCPRestartOnNewSnapshot
If a Snapshot copy is not available during restart
When set to FALSE,the transfer to continues using a new
Snapshot copy
When set to TRUE the transfer is aborted
Use the svsetstanza command or edit the
snapvault.cfg file to change these values

SNAPSHOT COPIES MANAGEMENT
Common Snapshot copies management ensures that the same Snapshot copy is used for backup.
In releases earlier than Open Systems SnapVault 2.5, whenever the transfer of files failed,
the Snapshot copies were deleted and a new Snapshot copy was created during the
transfer restart.
Open Systems SnapVault 2.5 has the ability to retain old Snapshot copies and to use these
copies subsequently during transfer restarts. There are two possible configurations for
common Snapshot copies management:
MaxCPRestartWaitTime is the maximum waiting time (default is 10 minutes) a
Snapshot copy is retained after the transfer failure. If the transfer of files restarts after
the maximum waiting time, the Snapshot copy is lost and needs to be created again.
FailCPRestartOnNewSnapshot is the corresponding Snapshot copy is not available
during restart of a transfer due to a system restart, elapsed time, or Open Systems
SnapVault restart, either you allow the transfer to continue using a new Snapshot
copy or abort the transfer. When the value is set to TRUE, the transfer is aborted.
When the value is set to FALSE, a new Snapshot copy is created and the transfer continues.

Use the svsetstanza command or edit the snapvault.cfg file on the Open Systems
SnapVault primary system to set the FailCPRestartOnNewSnapshot value:

Checkpoints for Restart
Allows a failed transfer to resume from the last
valid recorded checkpoint
Not used to resynchronize a broken relationship
or to resume operations after a restore
Supports checkpoints at block levels inside
files
A failed transfer can restart even from the
middle of a file
Configure checkpoint interval
Default 300 seconds
Minimum 60 seconds

CHECKPOINTS FOR RESTART
When an Open Systems SnapVault backup process fails, checkpoint restart support allows the
backup transfer (baseline or update) to be resumed from the last valid recorded checkpoint.
Checkpoints are recorded by the Open Systems SnapVault primary when certain predetermined
conditions or periodic intervals are met. The Open Systems SnapVault primary records the
checkpoints and sends them to the SnapVault secondary system.
Checkpoint restarts are not used to resynchronize an Open Systems SnapVault relationship after a
restore or to re-establish an Open Systems SnapVault broken relationship.

In releases earlier than Open Systems SnapVault 2.5, checkpoints were taken either at five-
minute intervals or at the end of a file. This resulted in sending all the file data again, if there was
a transfer failure for a large file.

Open Systems SnapVault 2.5 and later releases support the following improvements in the
checkpoint mechanism:

Enabling checkpoints at block levels inside files
This enhancement is useful when the data set contains large files (greater than 100 MB).
Checkpoints are allowed inside files; therefore you can restart the transfer even from the
middle of a file.

Configuring checkpoint interval
You can configure the checkpoint interval by editing the snapvault.cfg file on the Open
Systems SnapVault primary system. The default value is set to 300 seconds (5 minutes), and
the minimum value is 60 seconds.

Block-Level Incremental
Block-level incremental (BLI) backup recognizes
that a file has changed based on timestamp and
checksum algorithm
BLI backup levels
OFF: No checksums computation
HIGH: Computes checksums on transfers and
incremental updates (default)
LOW: Computes checksums on first and
subsequent incremental updates
Name-based BLI
Addresses known issues on file modification

BLOCK-LEVEL INCREMENTAL
A block-level incremental (BLI) backup recognizes that a file has changed based on a timestamp
and checksum algorithm. It also determines exactly which blocks in the file have changed, and
then backs up only those blocks to the SnapVault secondary system.
Checksum database files are stored in the Open Systems SnapVault agent internal database
directory. Each Open Systems SnapVault relationship has its own checksum file directory. Disk
storage requirements to maintain the computed checksum values on the primary are expected to
be approximately 2% of the baseline backup size.

BLI can operate at three levels: OFF, HIGH, or LOW. Those values are configurable in the Open
Systems SnapVault Configurator.
OFF: No checksums are calculated. Full files are transferred once identified as being
changed files
HIGH (default): Always computes checksums (initial and incremental transfers)
LOW: Computes checksums on first incremental and subsequent transfers

Applications such as Microsoft Word, Microsoft Excel, and Microsoft PowerPoint (referred
to as name-based applications) modify files by inserting new data blocks in the file and rewriting
all subsequent data blocks in the file to new positions in the file. As the modified file is
considered new, a backup of all the rewritten blocks and a recalculation of checksum would be
required.
Open Systems SnapVault agents work around this issue by recognizing files by name in addition
to identifying the file by the file-system location. You can disable BLI backups for certain name-
based applications with the Open Systems SnapVault Configurator.

Exclude Lists and Encrypted Files
Exclude lists
Excludes specified files, directories, sub-
directories and paths from backups
Support for Encrypted File System (EFS) files
backup and restore
BLI does not support EFS files backup
Ensure that there is sufficient free space in the
target volume to restore EFS files

EXCLUDE LISTS AND ENCRYPTED FILES
Backup exclusion lists are used by the Open Systems SnapVault agent to exclude specified files,
directories, sub-directories, and entire paths from backups.
Open Systems SnapVault supports two types of exclusion lists:
File exclusion list entries consist of single-path elements. A file or directory is excluded if the
file name or any path element matches a file exclusion entry in the list. The file exclusion list
is in the install_dir/etc/file-exclude.txt file.
Path exclusion list entries consist of complete file system paths to either a directory or a file.
The path exclusion list is in the install_dir/etc/path-exclude.txt file.

Refer to the Open Systems SnapVault Installation and Administration Guide for details on
supported characters and wildcards for those file entries.
Open Systems SnapVault is capable of backing up and restoring Encrypted File System, or EFS
files, on Windows platforms. However, you cannot use block-level incremental backup to back
up EFS files. Any time an EFS file is modified, Open Systems SnapVault backs up the entire EFS
file.

The following are the requirements for backing up and restoring EFS files:
You cannot use block-level incremental backup to back up EFS files. Any time an EFS file is
modified, Open Systems SnapVault backs up the entire EFS file.
There must be a sufficient amount of free space in the target Windows volume. EFS-
encrypted file restore requires the Open Systems SnapVault agent to create a temporary file
that is equal or greater to the size of the EFS-encrypted file that is being replaced.

Open Systems SnapVault Database
Backup
Allows restoration of the Open Systems SnapVault
database without the need to initiate a baseline
transfer
On the Open Systems SnapVault primary, database
resides in
install_dir\snapvault\db\QsmDatabase
By default the Open Systems SnapVault database is
backed up upon each transfer
On the secondary, database backup is stored under
the qtree root as OSSV_DATABASE_BACKUP
Backup levels: BLI (default), DB only, and NONE
If between backup and restore the file system was
modified, you must resync the relationship

OPEN SYSTEMS SNAPVAULT DATABASE BACKUP
The Open Systems SnapVault database consists of a set of files that contain information about the
Open Systems SnapVault relationship between a primary and a secondary system:
History file
BLI checksums file (if BLI is enabled)
Checkpoint file (if a backup transfer had failed with a checkpoint)
If the Open Systems SnapVault database becomes corrupt or gets out-of-sync with the secondary,
data transfers fail and you will be forced to initiate a baseline transfer. However, if you have a
valid backup of the database, you can restore it and continue with subsequent transfers.
By default, backup of the Open Systems SnapVault database occurs automatically every time data
is transferred. A compressed file of the database is created and transferred to the secondary. The
file is named Open Systems SnapVault_DATABASE_BACKUP and stored in the root of the
destination qtree.

There are three backup levels of the Open Systems SnapVault database:
BLI (default): Backs up the history file and its corresponding BLI checksum file
DB only: Backs up only the history file
NONE: Disables the automatic database backup

To restore the database, issue the snapvault restore command from the Open Systems
SnapVault primary, including the file name Open Systems SnapVault_DATABASE_BACKUP
in the path.
After the database file is restored, Open Systems SnapVault decompresses it and places the files
where Open Systems SnapVault database files are located for the relationship. Data transfers can
be performed from this point onward. However, if between the backup and the restore operations
the file system was modified, you will have to resynchronize the relationship.

System State and Event Log Backup
Open Systems SnapVault supports W2K and
W2K3 system state backup and restore
Allows to restore a system to an earlier state
Subsequent backups use BLI when enabled
System state backup can include Windows Event
Log
Used for troubleshooting problems or capacity
planning
Application, Security, and System event log backup
are configurable options
Incremental updates of Windows Event Log files are
not supported

SYSTEM STATE AND EVENT LOG BACKUP
You can back up and restore various components of the Windows 2000 Server and Windows
Server 2003 system state. These components may include:
Registry
COM+ Class Registration database
System files and settings, including the boot files
Certificate Services database
IIS Metadirectory
System files that are under Windows file protection
Performance counters
System state data on domain controllers (Active Directory and SYSVOL data)

You can add backups of Windows system state data to existing Open Systems SnapVault backup
schedules and use the backups to restore a system to an earlier state. You can also use Open
Systems SnapVault system state data backup in conjunction with complete file system backups as
part of a disaster-recovery plan.
With Open Systems SnapVault support for Windows Event Log, you can maintain the records of
all the events that occur in the system. It is necessary to record the events to help you carry out
tasks such as troubleshooting problems or capacity planning.
You can enable or disable support for Windows Event Log as part of the system state backup
using the Open Systems SnapVault Configurator. Application, Security, and System event log
backup are configurable options.
Incremental updates of Event Log files are not supported. Every update does a full backup of
event logs.

Open Systems SnapVault Restore
Restoring a directory or a file
Copy file or directory using CIFS or NFS
Or use the snapvault restore command
Or use NetApp Operations Manager
Restoring an entire primary system
There must an operating system on the disk
Restoring files to a primary system from tape
First restore the data from the tape to the
secondary, and then restore from that
secondary to the Open Systems SnapVault
primary

OPEN SYSTEMS SNAPVAULT RESTORE
In the event of data loss or corruption on the Open Systems SnapVault primary system, the
administrator can restore a directory or a file, the entire system, or files from a tape device.
RESTORING A DIRECTORY OR A FILE

You can copy files from the secondary storage system to the Open Systems SnapVault primary
system using NFS or CIFS. Some Windows and UNIX attributes are not preserved using this
method, such as Windows sparse files, Windows EFS data, and UNIX access control lists.
You can also use the snapvault restore command from the Open Systems SnapVault
primary command-line interface.

snapvault restore s sv_snapshot S
sec_hostname:/vol/sec_vol/sec_qtree/file.doc
prim_hostname:dirpath
You can also use the NetApp Operations Manager restore wizard or supported NDMP
management software.

Restoring an entire primary system

You can restore an entire primary system from a SnapVault secondary, but there must be an
operating system on the Open Systems SnapVault primarys disk.
1. Reinstall the operating system on the primary.
2. Reformat the file system just as the original file system was formatted.
3. Install the Open Systems SnapVault agent.
4. (Optional) Restore the Windows system state data of the Open Systems SnapVault primary if
you backed it up.
5. Restore the backed-up directories using the snapvault restore command.
RESTORING TO A PRIMARY SYSTEM FROM TAPE

The process of restoring from tape to a primary system involves first restoring the data from the
tape to a secondary and then restoring from that secondary to the Open Systems SnapVault
primary.
1. Mount the tape that has the files that need to be restored on the secondary.
2. Use the Data ONTAP restore command to restore from the tape to the SnapVault
secondary.
3. Restore the files from the secondary to the NFS or CIFS primary using the snapvault
restore command.

Restore Limitations
When restoring using the snapvault
restore command, restoring files to a
directory that is part of a SnapVault
relationship is not allowed
You have to release the SnapVault backup
relationship from the primary before performing
the restore to the same location
Or you can restore the files to a new location
NTFS compressed files and directories lose
compressed attributes when restored

RESTORE LIMITATIONS
Restoring to a directory that is part of a SnapVault relationship
If you attempt to restore files to a directory involved in a SnapVault relationship using the
snapvault restore command, the attempt fails with the message:
Invalid Qtree/Snapshot requested
Directory in wrong phase
Error performing restore. Check snapvault log.
The following information is logged in the SnapVault log files:
Invalid Qtree/Snapshot requested
Directory in wrong phase

You can restore to such a directory by first releasing the SnapVault backup relationship using the
snapvault release command from the primary:
snapvault release pathname sec_hostname:/vol/sec_vol/sec_qtree

Alternatively, you can restore the files to a new location on the primary system.
RESTORING NTFS-COMPRESSED FILES AND DIRECTORIES
Open Systems SnapVault does not restore the compressed attribute on a Windows file if both the
following conditions are true:
The file has a compressed attribute set.
The file has a sparse or compressed alternate data stream attached.
In the case of compressed directories, the compressed attributes are lost when restored, regardless
of the alternate data streams.

Resynchronization
Resync a broken relationship
Use the snapvault start r command
Does not support resync of restored
subdirectories and single files
Resync after snapvault restore
1. Select the Enable restart/resync on restore
option on the primary before performing the
restore
2. Use the snapvault start r command to
resynchronize the relationship

RESYNCHRONIZATION
When the Open Systems SnapVault primary and the secondary systems become unsynchronized,
the relationship needs to be resynchronized to be able to continue incremental backups.
An Open Systems SnapVault relationship can get out of sync when:
An older version of the Open Systems SnapVault database is restored to the Open Systems
SnapVault primary system.
Data is restored using the snapvault restore command.
The state of the destination qtree in an Open Systems SnapVault relationship is changed to
read-writable, because such an operation breaks the Open Systems SnapVault relationship.

Open Systems SnapVault resynchronization is supported from Data ONTAP 7.2 and Open
Systems SnapVault 2.2 and later releases.

RESYNCHRONIZING A BROKEN RELATIONSHIP
To resynchronize a broken Open Systems SnapVault relationship, on the SnapVault secondary,
enter the following command:

Secondary> snapvault start -r -S prim_hostname:dirpath

NOTE: Open Systems SnapVault does not support resynchronizing restored subdirectories and
single files.

Resynchronizing after a snapvault restore
After data is restored using the snapvault restore command, if you want to perform
subsequent incremental backups from the restored location to the same qtree on the secondary
storage system, you must resynchronize the relationship.
Before restoring, enable the Enable restart/resync on restore check box in the
Open Systems SnapVault Configurator. By default this option is not selected.
If you selected this option before you performed the snapvault restore, you can
resynchronize the SnapVault backup relationship with the snapvault start r command
once the restore has completed.
If you did not select this option before performing the snapvault restore, you will have to
initialize the relationship after the restore using the snapvault start command from the
SnapVault secondary.

Logical Replication
Enables you to create a baseline relation between an
Open Systems SnapVault primary storage system and
a secondary using a portable device (for example, a
USB external drive)
2
5
3
6 7
USB Drive
lrep_reader
lrep_writer
1 4
Client1
Client2
connection Low-bandwidth
Data Center
Remote Office
SnapMirror
5
qtree1
qtree1
USB Drive
FAS2
FAS1

LOGICAL REPLICATION
Baseline transfers can have a crippling effect on the limited bandwidth wide area network (WAN)
connections of remote or branch offices. Using the LREP tool, no network bandwidth is used
because the initial baseline transfer is sent to a portable device belonging to a local system. For
instance, you can install LREP onto a local Microsoft Windows systems with a USB drive. The
administrator would then initiate SnapVault to transfer the data to the USB drive on the local
Microsoft Windows system.
Once the transfer is complete, the USB drive is physically sent to the remote site.
Then, the baseline data is transferred to the SnapVault secondary storage system using LREP
from a local Microsoft Windows systems with LREP installed. After the baseline data has been
transferred over to the secondary storage system, the relationship between the primary and
secondary storage systems is established for incremental transfers to occur directly.
1. Install the lrep_reader utility on Client1 at the data center.
2. Run the lrep_reader utility from Client1 to snapmirror initialize from the
source to the portable media; here a USB drive shared between sites.
3. The USB drive is then transferred to the remote office.
4. The lrep_writer utility is installed on Client 2 at the remote office.
5. Run lrep_writer utility from Client2 to reconstruct the replication streams by reading
from files, which were created by lrep_reader.
6. From the destination, run the snapmirror initialize command to read the
logical replication stream data from the lrep_writer.

The Qtree SnapMirror initial transfer completes. Edit the snapmirror.conf file to reflect the
correct source storage system

Logical Replication (Cont.)
Logical replication, or LREP, is used to initialize
Open Systems SnapVault data transfers over low-
bandwidth connections using a portable device
Two utilities: lrep_reader and lrep_writer
Supports Open Systems SnapVault data restore,
data compression and encryption
LREP 2.0 is packaged with Open Systems
SnapVault 2.5 and later releases and is also
downloadable from the NOW site

LOGICAL REPLICATION
Logical Replication Reader and Writer (LREP) is a tool used to initialize Open Systems
SnapVault data transfers using a portable device and without traversing the network.
You can then ship the portable device to the location where the SnapVault secondary is, and
move the data from the portable device to the secondary. Once the relationship between the
primary and secondary systems is established and modified, incremental transfers can occur
directly. You can also restore data from the secondary storage system to the primary
system using LREP.

The LREP tool consists of two utilities:
lrep_reader: Used at the remote office to write data from the Open Systems SnapVault primary system
to the portable device.
lrep_writer: Used at the location of the SnapVault secondary storage system to write
data from the portable device to the secondary storage system.

LREP enables the compression of data using a zlib library. Compression of LREP data is done in
the memory before the data is written to the disk.
The Advanced Encryption Standard algorithm is used to encrypt and decrypt the LREP data.
LREP 2.0 is packaged with Open Systems SnapVault 2.5 and later. You can also
download the LREP tool from the NOW site. The tool can be run on Windows 2000/2003,
Linux and UNIX-based platforms.

For details on how to back up and restore Open Systems SnapVault data using LREP, refer to
Logical Replication (LREP) Tool 2.0 User Guide on the NOW site.

Open Systems
SnapVault Deployment

OPEN SYSTEMS SNAPVAULT DEPLOYMENT

Installing Open Systems SnapVault
Install the Open Systems SnapVault agent on
Windows or UNIX-based systems
From the CD-ROM
Download from the NOW site
Automatic post-installation check
svinstallcheck
Unattended installation
Supported on all platforms on which Open Systems
SnapVault is supported
Use svconfigpackager to create install image
Open TCP ports 10000 and 10566 before install

INSTALLING OPEN SYSTEMS SNAPVAULT
The Open Systems SnapVault agent can be installed from the CD-ROM or from the Download
Software page on the NOW site. Refer to the Open Systems SnapVault Release Notes and the
Installation and Administration Guide for details on the installation process on Windows and
UNIX-based systems.
The Open Systems SnapVault agent installation will store the Open Systems SnapVault database
a set of executables, the logs file, and the Exclude Lists files on the primary. On a Windows
primary, the default installation path is the C:\Program Files directory. On UNIX systems, the
default installation location is the /usr directory. During the installation process, you will be
prompted to enter the NDMP account to connect to the primary system, the NDMP listening port,
and the host name or IP address of the secondary system. At the end of the installation routine,
the svinstallcheck utility will verify successful installation and make sure that the services
are running properly.
Unattended Installation

Unattended installation enables you to install or upgrade Open Systems SnapVault software over
a large number of Open Systems platforms with minimal user intervention. To perform an
unattended installation of Open Systems SnapVault, an installation script and other supporting
files are required. A utility called svconfigpackager is available in the Open Systems
SnapVault software. When run on an Open Systems SnapVault primary system, the utility saves
the current configuration settings to a file. In addition, this utility can create an installation script
that, in conjunction with the configuration settings file and other files, can be used to perform
unattended installations or upgrades.

Ensure that the TCP ports 10000 (for central management using NDMP) and 10566
(QSMSERVER) are open before Open Systems SnapVault is installed. For NetApp Host Agent,
HTTP port 4092 and HTTPS port 4093 must be open as well.

Configuring Open System SnapVault
Primary
Use the OSSV
Configurator
graphical user
interface (GUI) to
verify and modify
Open Systems
SnapVault
parameters
The svsetstanza
command is an
alternative to the
OSSV Configurator
utility

CONFIGURING OPEN SYSTEMS SNAPVAULT PRIMARY
You use the Open Systems SnapVault Configurator utility to verify and to modify the Open
Systems SnapVault configuration parameters.
The Configurator utility is automatically installed during the Open Systems SnapVault agent
installation and can be invoked from the Windows > Start > Programs menu or from the
command line. The svconfigurator.exe program is located in the Install_dir/bin
directory.

From the Configurator, you can perform the following actions:

The Machine tab displays information about the version of Open Systems SnapVault agent
software, and primary system machine information such as the IP address and OS version.
The Service tab allows you to stop and start the Open Systems SnapVault services.
The General tab enables you to generate debugging files and to modify the default db, tmp,
and trace directories locations.
The Trace Level tab is used to choose which process to take traces of and the trace level.
The Trace Level tab is used in conjunction with the General tab.
The SnapVault tab allows you to specify the SnapVault secondary hostname or IP address
and to modify some important parameters such as the BLI level, OFM, VSS, and NDMP
parameters.

Alternatively, you can use the svsetstanza utility from the primary for configuration
purposes instead of using the Configurator. The svsetstanza command is located in the
install_dir/util directory.

Licensing Open Systems SnapVault
The Open Systems SnapVault licenses are
installed on the SnapVault secondary to which
Open Systems are backed up
Open Systems SnapVault licenses
Not based on serial numbers but on platform
and on the number of hosts managed
Windows and UNIX licenses are not additive
Evaluation licenses available on NOW site
No limit on number of Open Systems
SnapVault nodes

LICENSING OPEN SYSTEMS SNAPVAULT
The Open Systems SnapVault licenses are installed on the secondary storage system to which
they are backed up. You will need to install the following licenses on the SnapVault secondary
storage system:
The SnapVault secondary sv_ontap_sec license.

The Open Systems SnapVault primary licenses for the platforms you want to back up to the
secondary storage system. The following is a list of the primary licenses:
sv_windows_ofm_pri (to use OFM for Windows 2000 Server)
sv_windows_pri (for Windows systems)
sv_unix_pri (for UNIX systems)
sv_linux_pri (for Linux systems)
sv_vmware_pri (for VMware ESX Server)

Licensing of the Open Systems SnapVault primary is based on the platform. Stored on the
secondary, these licenses are independent and do not tie in to the serial number of the secondary
system.
Open Systems SnapVault licenses are sold by platform (Windows and UNIX) and license
packages (sold in packs of 1, 5, 10, 25, 50, 100, and so on). Evaluation licenses are available on
the NOW site.

Configuring SnapVault Secondary
SnapVault secondary configuration steps are
identical to the ones used in a SnapVault
storage systems deployment:
1. Install the required licenses
2. Enable the NDMP service
3. Specify Open Systems SnapVault primary
systems to back up
4. Initialize the baseline transfer
5. Schedule updates

CONFIGURING SNAPVAULT SECONDARY
The SnapVault secondary configuration steps are identical to the ones used to configure
SnapVault in a NetApp storage systems environment.
1. Install the required licenses:
Secondary> license add <license_code>

2. Ensure that the NDMP service is enabled:
Secondary> options ndmpd.enable on

3. Specify the names or IP addresses of the Open Systems SnapVault primary systems to back
up and restore:
Secondary> options snapvault.access host=prim_hostname1,
prim_hostname2

4. For each Open Systems SnapVault platform directory or file to be backed up to the
SnapVault secondary, execute an initial baseline transfer:
Secondary>snapvault start -S prim_hostname:dirpath

5. Schedule incremental updates.
For example:
Secondary> snapvault snap sched -x vol1 sv_hourly 11@mon-
fri@7-18

The -x parameter causes SnapVault to copy new or modified files from the Open Systems
SnapVault system directory or file to their associated qtrees on the secondary. After all the
secondary qtrees on the specified volume have been updated, the SnapVault secondary then
creates a Snapshot copy of this volume for archiving.

Monitor Transfers
Use the snapvault status command to monitor
the transfer progress, status and lag
C:\> snapvault status -l c:\data
Source: W2K3-Client:c:\data
Destination: sec_FAS3050:/vol/vol1/backup-windows
Status: Transferring
State: Source
Lag: -
Mirror Timestamp: -
Base Snapshot: -
Current Transfer Type: -
Contents: -
Last Transfer Type: -
Last Transfer From: -
Bytes transferred so far: 18 MB
Transfer Time Elapsed: 00:00:21
Total files to transfer: 12
Total files transferred: 7
Current File Size: 8323815
Current File Progress: 2097152
Current File Name: c:\data\file1
Transfer Error ID: -
Transfer Error Message: -

MONITOR TRANSFERS
Use the snapvault status command to verify whether a transfer is in progress, the state of
the destination, and how long ago the last successful transfer took place.
If the -l option is given, the output displays more detailed information such as the total files to
transfer, how many were transferred, which file is currently transferring, and the transfer error ID,
if any error occurred.

For details on the snapvault status command output and options, refer to the Data
ONTAP Data Protection Online Backup and Recovery Guide.

Open Systems SnapVault Commands
The SnapVault commands available from the
Open Systems SnapVault primary command-
line interface are almost identical to the ones
supported on a SnapVault storage primary
system
C:\Program Files\netapp\snapvault\bin>snapvault
The following commands are available; for more
information type "snapvault help <command>"
abort destinations help release
restore status service diag
The service and diag commands are specific to
Open Systems SnapVault primary systems

OPEN SYSTEMS SNAPVAULT COMMANDS
The SnapVault commands available from the Open Systems SnapVault primary command-line
interface are identical to the ones supported on a SnapVault storage primary system. The
SnapVault commands are stored in the Install_dir/bin directory. Refer to the SnapVault
module of this course for details on the following SnapVault commands syntax:

Use the status command to monitor the status of an Open Systems SnapVault backup or
restore.
Issue the destinations command to list all the known destinations for this Open Systems
SnapVault primary system.
The abort command allows you to stop a restore transfer from the secondary to the primary
system.
The release command allows you to release relationships that have been stopped on the
secondary.
In the event of data loss or corruption on the primary system, use the restore command to
restore the affected file, directory, drive, or even the entire system.
Use the service command to manage the Open Systems SnapVault service.
Issue the diag command to display details of a given error number.
Note: the service and diag commands are specific to Open Systems SnapVault primary
systems.

Log Files
Open System SnapVault primary log files
Windows primary
C:\Program Files\netapp\snapvault\etc
UNIX-based primary
/usr/snapvault
A new file is created daily at midnight
File is named snapvault.yyyymmdd
No extension for the current file
SnapVault secondary log files
Root volume: /etc/log/snapmirror

LOG FILES
You can find the operational status and problem reports of the Open Systems SnapVault primary
system in the log file named snapvault.
On the Open Systems SnapVault primary, the log files are found:
On a Windows primary, in the C:\Program Files\netapp\snapvault\etc
directory
On a UNIX-based primary, in the /usr/snapvault directory

A new file is created daily at midnight or as soon after midnight as the first subsequent activity on
the system takes place; the existing file is not archived until a new one is created.
The current file has no extension. The archived files have the .yyyymmdd extension, where yyyy is
the year, mm is the month, and dd is the date when the file was created.

Note that the log file is created during the initial baseline transfer, not by the install process.
Therefore, if you search for the log file after completing the installation, but before you back up
data for the first time, you will not find the log file.

On the secondary storage system, the SnapVault log files are stored in the
/etc/log/snapmirror file in the root volume.

Open System
SnapVault Solution for
VMware

OPEN SYSTEM SNAPVAULT SOLUTION FOR VMWARE

VMware ESX Server Overview
VMware ESX Server allows multiple virtual
operating system instances or virtual machines to
run on a single powerful system
Virtual machine (VM) behaves like a physical
computer
Virtual Machine File System (VMFS) is the file
system used by ESX Servers to store VM files
The service console is the management interface
to the ESX Server
VMware VirtualCenter is used to manage a group
of ESX hosts and the associated VMs

VMWARE ESX SERVER OVERVIEW
VMware ESX Server software allows multiple virtual operating system instances or virtual
machines to run on a single and powerful multiprocessor system, substantially reducing the
deployment of physical servers.
A virtual machine, or VM, behaves like a physical computer and contains its own CPU, RAM
hard disk, and network interface card.

Virtual Machine File System, or VMFS, is a file system used by ESX Servers to store virtual
machine files.

The service console is a RHEL 3.0 operating system used as a management interface to the
ESX Server.

VMware VirtualCenter is used to manage a group of ESX hosts and the associated virtual
machines. VirtualCenter server is the backend and virtual infrastructure client is a user
interface.

Open System SnapVault for VMware ESX
Server
Open Systems SnapVault allows you to back
up data within a virtual machine
Open Systems SnapVault 2.6 has the ability to
back up the whole virtual machine
Runs in the service console of an ESX Server
Supports ESX Server 3.0, 3.01, and 3.02
Each VM is visible to Open Systems SnapVault as
a set of files
You can restore a VM to any of its previous
states

OPEN SYSTEMS SNAPVAULT FOR VMWARE ESX SERVER
Open Systems SnapVault allows you to back up data within a virtual machine. However, Open
Systems SnapVault 2.6 has the ability to back up the whole virtual machine.
Open Systems SnapVault 2.6 runs in the service console of an ESX Server and supports ESX
Server 3.0, 3.01 and 3.02. Each VM is visible to Open Systems SnapVault as a set of files;
therefore, a single Open Systems SnapVault agent can be used to back up and restore multiple
virtual machines.
Disaster recovery is possible as the entire VM is backed up. Because Open Systems SnapVault
supports update transfers, you can maintain multiple Snapshot copies on the secondary storage
system, which enables you to restore a VM to any of its previous states.

Backup and Restore of Virtual Machines
Backup process
1. Identifies the VM to be backed up by its UUID
2. Takes a Snapshot copy of the VM
3. Backs up .vmx, .vmdk, .nvram, and .log files
4. Releases the VM Snapshot copy
Restore process
1. Identifies the VM to be restored by UUID
2. Restores all backed up VM files
3. The restored VM registers to an ESX Server and
it is brought up

BACKUP AND RESTORE OF VIRTUAL MACHINES
Each virtual machine is represented as a collection of files under the VMFS volume. To back up a
virtual machine, Open Systems SnapVault backs up the following files:
.vmx file contains the references to all the components (CPU, memory disk, and so on) and
the configuration information of the VM.
.vmdk files are the disk descriptor and disk data files of the VM.
.nvram file contains the BIOS configuration of the VM.
.log files contain the activity logs of the VM.

When the virtual machine is running, its vmdk files are locked and not accessible for external
applications; however, taking a virtual machine Snapshot would freeze and release the lock on the
vmdk files, allowing Open Systems SnapVault to back up these files. As long as the virtual
machine Snapshot copy is active, changes to the virtual machine are tracked in a delta file. Open
Systems SnapVault deletes the virtual machine Snapshot copy once the transfer is completed.

Open Systems SnapVault backups and restores are integrated with the VMware environment and
uses VMware Infrastructure SDK to communicate with the VMware environment for activities
like creating Snapshot copies, registering, and powering on the virtual machine.

Backup Layout on the Secondary
The backed up files that comprise the VM are
organized according to the following directory structure
in the SnapVault secondary qtree:
Directory Content
CONFIG VMX and NVRAM files
LOGS Log files
DISK_x_y
Disk files for the hard disks at the
virtual device node SCSI (x:y)
OSSV_APP_CONFIG_
configuration file for a VM

BACKUP LAYOUT ON THE SECONDARY
After a virtual machine is backed up, different files that comprise the virtual machine are
organized according to a specific directory structure in the SnapVault secondary qtree as
illustrated in the above table. In addition, Open Systems SnapVault_DATABASE_BACKUP is
backed up at the root of the secondary qtree.

Solution Deployment
Install Open Systems SnapVault 2.6 for VMware
on the ESX Server
Same install procedure as for Open Systems
SnapVault on Linux
Additional inputs
VirtualCenter: Host name or IP, user name, and
password
HTTP or HTTPS connection
SnapVault secondary
Requires additional sv_vmware_pri license
You must specify the host name of the ESX Server
on which Open Systems SnapVault is running
options snapvault.access host=esx_server

SOLUTION DEPLOYMENT
INSTALLING OPEN SYSTEMS SNAPVAULT 2.6 ON THE ESX SERVER
The procedure to install Open Systems SnapVault 2.6 in the service console of ESX Server is
similar to the procedure to install Open Systems SnapVault 2.6 on the Linux platform. However,
when you run the install script, you will have to make a few additional inputs, such as the
following:
The host name or the IP address of the VirtualCenter host if ESX Server is not running
independently
The user name and password for the VirtualCenter host
Whether or not you want use HTTPS or HTTP to connect the VirtualCenter host (HTTPS is
the default value)

For more information about installing Open Systems SnapVault on the Linux platform, refer to
the Open Systems SnapVault Installation and Administration Guide.
CONFIGURING THE SNAPVAULT SECONDARY
On the SnapVault secondary system, an additional license named sv_vmware_pri must be
installed to support virtual machine backup and restore.
Note that when specifying the access list on the secondary system using the option
snapvault.access, you have to enter the ESX Server host name.

Configuring Open Systems SnapVault for
ESX Server
The Open Systems SnapVault Configurator utility cannot run in
the service console of ESX Server
Use the new svconfig command utility
svconfig [<option_key> [<option_value>]]
svconfig [<option_key_prefix>]
Example
# svconfig vmware
vmware.vchost 10.72.191.108
vmware.username Administrator
vmware.password
vmware.https.enable TRUE
vmware.poweroff_before_ss FALSE
vmware.backup_powered_down_vm TRUE
vmware.enable_remote_transfer 1
vmware.port.http 80
vmware.port.https 443

CONFIGURING OPEN SYSTEMS SNAPVAULT FOR ESX SERVER
The Configurator utility GUI (svconfigurator) cannot run in the service console of ESX Server
because of the nonavailability of the x-libraries. Therefore, a new command-line interface utility,
svconfig, has been introduced.
The svconfig command provides a way to configure all the options that are available through the
svconfigurator GUI and incorporated the VMware options for ESX Server.
Usage:

svconfig [<option_key> [<option_value>]]
svconfig [<option_key_prefix>]

option_key is the key name of the option that needs to be configured.
option_value is the value of the options key. If option_value is missing, then the value
of the option_key will be displayed along with the list of all possible values for this option,
wherever applicable. If option_key_prefix is specified, then all matching options with
their values will be displayed. In this case, the list of possible values will not be displayed.
For a complete list of the svconfig utility options and values, refer to refer to the Open
Systems Platform Administration and Installation Guide.

Initial Transfer
To initialize the first transfer, use the command:
snapvault start S
<esx_server>:app:vmware:<UUID>
<secondary_qtree>
esx_server is the host name of the ESX Server
on which Open Systems SnapVault is running
app:vmware is a keyword to specify that the
backup request is for a VM
UUID is the unique identifier of the VM
secondary_qtree is the path to the SnapVault
secondary qtree

INITIAL TRANSFER
To initialize the first transfer of a virtual machine, run the following command from the
SnapVault secondary system:
snapvault start S <esx_server>:app:vmware:<UUID>
<secondary_qtree>

esx_server is the hostname of the ESX Server on which Open Systems SnapVault is
running.
app:vmware is a keyword to specify that the backup request is for a VM.
UUID the universal unique identifier of 128-bit value used for identification of the individual
virtual machines.
secondary_qtree provides the path for the secondary qtree where the data files are to be
backed up.

Example:
snapvault start S ESX1:app:vmware:503f7bac-c758-3401-5613-
8482ed7f3451 /vol/vol1/VM1
To find the UUID of a particular VM, run the following command on the ESX Server console:

vcbVmName h esx_server or VC_server u username -p password -s
Any

-h esx_server or VC_server is the host name or IP address of the ESX host or the
VirtualCenter server.
-u username is the user name of the ESX host or the VirtualCenter server.
-p password is the password of the ESX host or the VirtualCenter server.
Any lists the details of all virtual machines.

Methods to Restore a VM
Three methods to restore a VM
snapvault restore S
sec_hostname:/vol/sec_vol/sec_qtree ...
Restore only VM data (vmdk files only)
... app:vmware:UUID:cfg=current
Restore VM data and all configuration files (vmdk,
vmx, nvram, and log files)
... app:vmware:UUID:cfg=original
Overwrites the current configuration settings
Restore VM files
... primary_path
Similar to the normal Open Systems SnapVault qtree
restore

METHODS TO RESTORE A VM
There are three methods to perform the restore operation of a virtual machine.
RESTORE ONLY THE VM DATA
Only vmdk files are restored. The configuration files (vmx, nvram and log files) will not be
restored and the virtual machine continues to use existing configuration. After the restore is
complete, the virtual machine will be powered on automatically.

snapvault restore S sec_hostname:/vol/sec_vol/sec_qtree
app:vmware:UUID:cfg=current
RESTORE THE VM DATA AND CONFIGURATION FILES
All the files that were backed up are restored. Hence this will overwrite the current configuration
settings of the virtual machine if it is already registered.

snapvault restore S Ssec_hostname:/vol/sec_vol/sec_qtree
app:vmware:UUID:cfg=original

RESTORE VM FILES
This type of restore is similar to the normal Open Systems SnapVault qtree restore.

snapvault restore S sec_hostname:/vol/sec_vol/sec_qtree
primary_path

When you run this command, virtual machine files are restored to the primary path specified in
the restore command with no additional functionality of integration with the VMware
environment.

Open Systems SnapVault Support for
VMotion
TM
VMotion is the process of live migration of VMs
from one ESX host to another
Open Server SnapVault 2.6 supports backup of
VMs during and after VMotion
Overlapping VMotion does not affect the backup
Block-level incremental (BLI) updates continue to
work even after the VM is moved to another ESX
host
Prerequisites
Open Systems SnapVault 2.6 must be installed and
running on the source and the target ESX hosts
TCP port 10555 (FILESERVER) must be open

OPEN SYSTEMS SNAPVAULT SUPPORT FOR VMOTION

VMotion is the process of live migration of virtual machines from one ESX host to another.
Open Systems SnapVault is designed so that it supports the backup of VM during and after
VMotion.
For example, overlapping VMotion does not affect the backup, and block-level incremental (BLI)
based updates continue to work even after the virtual machine is moved to another ESX host by
VMotion.

The prerequisite for VMotion support is that Open Systems SnapVault should be installed and
running on both the source and target ESX hosts that are involved in VMotion, and port 10555
should be open on the target ESX host.

Open Systems SnapVault support for VMotion is accomplished by the introduction in the Open
Systems SnapVault agent of a new component called file server. Basic functionality of this file
server is to serve files to its clients which are external Open Systems SnapVault agents running
on other ESX Servers. When Open Systems SnapVault detects that it has to back up a VM that is
registered with another ESX Server, it is going to contact the file server component of the Open
Systems SnapVault on the other ESX Server. The file server can access the vmdk files, read the
data and send it across to the Open Systems SnapVault agent that is doing the backup. This way,
backup can continue from the same Open Systems SnapVault agent even for those VMs that are
VMotioned out.

Limitations
Open Systems SnapVault on ESX Server does
not support:
Backup of VM with physical Raw Device
Mapping (RDM)
Backup of VM with an existing Snapshot copy
Checkpoint restart transfers after system reboot
or SnapVault service restarts
Resync after restore
File system backup
Open Systems SnapVault update transfers fail
after changing the UUID of the VM

LIMITATIONS
Open Systems SnapVault backup and restore of virtual machines has the following known
limitations:
Open Systems SnapVault cannot back up a VM which has physical Raw Device Mapping
(RDM); the disk is excluded from backup.
Open Systems SnapVault backup fails for VMs with an existing Snapshot copy.
Open Systems SnapVault does not support checkpoint restart transfers after the system
reboots or SnapVault service restarts.
Open Systems SnapVault on VMware ESX Server does not support resynchronization after
restore and file system backup.

Note that Open Systems SnapVault update transfers fail after changing the UUID of the VM.

Best Practices and
Troubleshooting

BEST PRACTICES AND TROUBLESHOOTING

Considerations
Open Systems SnapVault does not back up NFS
mountpoints and CIFS shares
Open Systems SnapVault built-in databases
require free space
Use the Free Space Estimator utility
OFM requires at least 15% disk free space in the
drive being backed up
Supports maximum 16 concurrent transfers
Large number of small files may impact
performance
Application database must be dismounted before
Open Systems SnapVault backups are initiated

CONSIDERATIONS
Open Systems SnapVault does not back up remote NFS or CIFS file systems that have been
mounted on or mapped to UNIX or Windows primary systems.

The Open Systems SnapVault database space requirements depend on the BLI level, the number
of files, average file size, and number of directories to back up. Use the Free Space Estimator
utility to ensure that there is sufficient space on the Open Systems SnapVault install drive to be
able to perform an incremental update. Note that if OFM (Windows 2000 Server) is used, the file
systems being backed up must have at least 15% disk space free in the drive being backed up. If
free space is not available, disable OFM for those drives.

Open Systems SnapVault supports a maximum of 16 simultaneous transfers from a primary
system. You should plan your backup schedules such that 16 or fewer transfers occur at the same
time.

When using Open Systems SnapVault, there is always some overhead to be transferred for files in
the Open Systems SnapVault relationship that have been modified. The Open Systems SnapVault
primary will send one 4 KB header for every file and directory that exists in the relationship. In
addition, for files and directories that are larger than 2 MB, an additional 4 KB header is
transferred for every 2 MB.

A large number of small files may degrade performance and also result in a large amount of
overhead data sent over the network. If a large number of files are not likely to be modified,
consider changing the BLI level to LOW.

Open Systems SnapVault is not integrated with any database backup APIs. The database files
need to be dismounted prior to using Open Systems SnapVault to back them up. If users want to
use the hot backup mode method, they will need to script it and test it themselves and ensure
that the procedure works reliably in their environment.

Error Messages
Collect error messages logged on the Open
Systems SnapVault primary and the SnapVault
secondary:
snapvault status l
/etc/log/snapmirror
Install_dir/snapvault
On the primary, use the snapvault diag
<err_num> to display details for a given error
number
Error messages, causes, and actions are listed in
the Open Systems SnapVault (current 2.6)
Installation and Administration Guide

ERROR MESSAGES
You can diagnose and troubleshoot Open Systems SnapVault issues by collecting and analyzing
the error messages logged on the Open Systems SnapVault primary
(Install_dir/snapvault) and on the SnapVault secondary (/etc/log/snapmirror)
systems.
On the Open Systems SnapVault primary command-line interface, use the snapvault diag
<err_num> command to display details for a given error code. The error code number is
displayed in the snapvault status l command output.

Example:
$ snapvault diag 3016
Type: Error
Message: A network error has occurred.
Possible cause: The network socket was closed unexpectedly or the
transfer was aborted by the user.
Possible action to take: Verify network connectivity between the
Open Systems SnapVault primary system and the secondary storage
system.

Error codes range:
1000-1999: Information messages
2000-2999: Warning messages
3000-3999: Errors causing an abort of the transfer

Note that not all the values in the range are used. A complete list of error codes, strings, causes
and action is available in the Open Systems SnapVault Installation and Administration Guide.

Data Collection
OSSVINFO tool
Collects a complete set of information, commands
outputs, and optionally ChangeLog and trace files
Packaged with the Open Systems SnapVault agent:
OSSVINFO.exe for W2K and W2K3
OSSVINFO.pl for Linux and UNIX
Generate debug information
Traces are compressed into a .bin file
Collect file server traces on the target ESX Server,
if any issues with VMotion support

DATA COLLECTION
When contacting NetApp Technical Support, you can either provide a set of files and command
outputs, or run the Open Systems SnapVaultINFO tool on the affected Open Systems
SnapVault primary to collect a complete set of information from the primary and the secondary
systems. The Open Systems SnapVaultINFO tool is packaged with Open Systems
SnapVault, and two versions are available:
Open Systems SnapVaultINFO.exe for Windows 2000 and 2003 Open Systems SnapVault
primary systems
Open Systems SnapVaultINFO.pl for Linux and UNIX-based Open Systems SnapVault
primary systems

The Open Systems SnapVaultINFO tool writes the data to the output directory as a text file in a
specific format. Also, it collects the ChangeLog and trace files to this output directory if either the
-q (for Windows) or -all (for all platforms) option is given as illustrated in this example:

Open Systems SnapVaultINFO.exe [ -s secondary ] [ -l
username:password ] [-q qtreeid]
[-all] Output_Dir

ChangeLog file captures duplicate inode issues and metadata corruption at run time. ChangeLog
capture is enabled by default in snapvault.cfg file.

NetApp Technical Support may ask you to enable Open Systems SnapVault
debugging to troubleshoot the issue.
The traces collected are automatically compressed into a .bin extension file.
When generating debug files, ensure the following:
Disable the generation of these files after you have sent a batch to Technical Support.
Delete the debug files from the system after you have sent them to Technical Support to
minimize the impact on performance.

Open Systems SnapVault Installation and
Administration Guide
Open Systems SnapVault Release Notes
Enabling Rapid Recovery with SnapVault
http://media.netapp.com/documents/tr-3252.pdf
Open Systems SnapVault Best Practices Guide
Open Systems SnapVault Best Practices Guide for
Protecting Virtual Infrastructure

DOCUMENTATION AND REFERENCES
You can obtain additional information about Open Systems SnapVault and related technologies
from the following:
MANUALS
Open Systems SnapVault Release Notes (current 2.6)
Open Systems SnapVault Installation and Administration Guide (current 2.6)
TECHNICAL REPORTS
TR-3252: Enhancing Heterogeneous Backup Environments with SnapVault
TR-3466: Open Systems SnapVault Best Practices Guide
TR-3653: Open Systems SnapVault Best Practices Guide for Protecting Virtual
Infrastructure

For the Open Systems SnapVault quick reference card or the frequently asked questions, see the
Data ONTAP Best Practices Guide on the NOW site.

Summary
Describe how Open Systems SnapVault integrates
with Data ONTAP SnapVault
List Open Systems SnapVault advanced features
Configure and administer Open Systems SnapVault
Perform Open Systems SnapVault backup and restore
operations
Explain how Open Systems SnapVault integrates with
virtualization
Troubleshoot and resolve Open Systems SnapVault
transfer failures

SUMMARY

Exercise
Module 6: Open Systems SnapVault

EXERCISE

7-1 NetApp Protection Software Administration Data ONTAP 7.3: SnapLock
MODULE 7: SNAPLOCK
SnapLock

Administration
Data ONTAP 7.3

INTRODUCTION
This module describes how to use SnapLock software to create volumes and aggregates that
provide WORM (write once, read many) storage.
SnapLock is supported in Data ONTAP on all releases later than 6.4.1 except for the following
releases:
Data ONTAP 7.2.2L1 and 7.2.4L1, which were released for only the FAS2020 and FAS 2050
platforms
Data ONTAP 7.3

Objectives
Describe the two types of SnapLock volumes
Explain how files are locked on SnapLock volumes
Manage and administer SnapLock volumes
Explain how SnapLock integrates with SnapMirror
Deploy LockVault to back up SnapLock volumes

OBJECTIVES

Overview
SnapLock is the NetApp WORM
implementation
Complies with SEC 240.17a-4 regulations
Available in two versions:
SnapLock Compliance, for strict regulatory
environments
SnapLock Enterprise, for more flexible
environments
Integrates with SnapMirror for data replication
Supports remote backup using LockVault

OVERVIEW
Some regulated environments require business records be archived on WORM media to maintain
a nonerasable and nonrewritable electronic audit trail that can be used for discovery or
investigation. An example of such an environment is a broker/dealer market regulated by SEC
240.17a-4.
Data ONTAP SnapLock software complies with the regulations of those markets. With
SnapLock, the media is rewritable but the integrated hardware and software controlling access to
the media prevents modification or deletion.
SnapLock is available in two versions: SnapLock Compliance for strict regulatory environments,
and SnapLock Enterprise, for more flexible environments.
SnapLock integrates with other NetApp products, such as SnapMirror and SnapVault.

SnapMirror allows SnapLock volumes to be replicated to another storage system.
LockVault backs up SnapLock volumes to a SnapVault secondary storage system to
ensure that if the original data is destroyed, it can be restored or accessed from
another location.

How SnapLock Works
Files are created on
SnapLock volumes and
committed to WORM
The retention date
applies immediately
Files cannot be altered
or deleted until they
reach the retention
date
Except for empty files
and directories
The retention date can
be extended
Windows
UNIX
SnapLock
Volumes
WORM
Snapshot
Copies
Storage System

HOW SNAPLOCK WORKS
WORM data resides on SnapLock volumes that are administered much like regular (nonWORM)
volumes.
Data on a SnapLock volume is created and committed to WORM state by transitioning the file
from a writable state to a read-only state. This commit process prevents the file from being
altered or deleted by applications, users, or administrators until the file retention date is reached.
The only exceptions are empty directories and files that are not committed to a WORM state.
Additionally, after directories are created, they cannot be renamed.

The retention date on a WORM file is set when the file is committed to WORM state, but it can
be extended at any time. The retention period can never be shortened for any WORM file.

SnapLock Compliance (SLC)
Used in strictly regulated environments
The administrator cannot modify or erase
retained WORM records
The secure compliance clock enforces retention
periods
Supports write verification for an additional
level of data integrity
snaplock.compliance.write_verify
Requires the snaplock license

SNAPLOCK COMPLIANCE
Use SnapLock Compliance in strictly regulated environments that require information to be
retained for specified lengths of time, such as those governed by SEC Rule 17a-4.
SnapLock Compliance provides WORM protection of files while also restricting the storage
administrators ability to perform any operations that might modify or erase retained WORM
records.
SnapLock Compliance uses a secure compliance clock called ComplianceClock to enforce
retention periods.
A secure time base ensures that retained data cannot be deleted prematurely by
changing the regular clock of the storage system.
A synchronized time source provides a time source for general operation that is
synchronized to a common reference time used inside your data center.

Data ONTAP provides a write-verification option for SnapLock Compliance volumes:
snaplock.compliance.write_verify.

When this option is enabled, an immediate read verification occurs after every disk write,
providing an additional level of data integrity.
SnapLock Compliance requires the snaplock license. This license enables basic functionality
and restricts administrative access to files.

SnapLock Enterprise (SLE)
Trusted administrator model
Allows the administrator to destroy SnapLock
Enterprise volumes before all files reach the
expiration date
However, users cannot modify or destroy
WORM records
Requires the snaplock_enterprise license
snaplock and snaplock_enterprise
licenses can be installed on the same storage
system from Data ONTAP 7.1 and later

SNAPLOCK ENTERPRISE
SnapLock Enterprise provides WORM protection of files with a trusted model of operation to
manage the systems.
SnapLock Enterprise allows the administrator to destroy SnapLock Enterprise volumes before all
locked files on the volume reach their expiration date. However, no one else can modify or
destroy WORM records.

SnapLock Enterprise requires the snaplock_enterprise license. This license enables
general functionality, and allows you to store and administer secure data.

Notes
From Data ONTAP 7.1 and later, SnapLock Compliance and SnapLock Enterprise licenses
can be installed at the same time on the same storage system. Earlier than Data ONTAP 7.1,
both licenses are mutually exclusive.
Uninstalling the SnapLock license (Compliance or Enterprise) does not undo the SnapLock
volume or the WORM file properties. When uninstalling the license, existing SnapLock
volumes are still accessible for general reading and writing, but wont allow new files to be
committed to WORM state on the SnapLock volume, or the creation of any new SnapLock
volumes.

SnapLock Deployment

SNAPLOCK DEPLOYMENT

Configuration Steps
1. Verify that the storage systems time zone,
time, and date are correct
2. License SnapLock
3. Initialize the ComplianceClock
4. Create SnapLock aggregate and volume
5. Set retention periods
6. Create files in the SnapLock volume
7. Commit files to a WORM state

CONFIGURATION STEPS

Initializing the ComplianceClock
Use the date c initialize command
The operation cannot be reverted
The ComplianceClock is checked when
determining or enforcing retention periods
ComplianceClock will get out of sync when:
Volume is taken offline/online
System is down/back up
Time alignment with the system clock depends
on the Data ONTAP release

INITIALIZING THE COMPLIANCECLOCK
The ComplianceClock is implemented in software and runs independently of the system clock.
Data ONTAP requires you to initialize the ComplianceClock before creating any SnapLock
Compliance volumes or aggregates.
Use the date c initialize command to initialize the ComplianceClock.

After ComplianceClock is initialized, it cannot be altered and WORM files, SnapLock
Compliance volumes, or aggregates cannot be destroyed.

The ComplianceClock is checked when determining or enforcing retention periods. For example,
the ComplianceClock is checked when determining if a file has expired; to enforce the volume
minimum, maximum, or default retention period when committed to the WORM state; or to
determine if a volumes destroy date has expired and therefore can be destroyed.

The ComplianceClock will get out of sync with the system clock when that volume has been
taken offline or the system has been shut down for an extended period of time. After the volume
has been brought back online, Data ONTAP will start to make up the time difference. The rate at
which the ComplianceClock catches up depends on the version of Data ONTAP your system is
running. For versions earlier than Data ONTAP 7.1, the rate is one day per year, for Data ONTAP
7.1 and later, the rate is seven days per year.

Creating SnapLock Volumes
SnapLock type, Compliance or Enterprise, is
determined by the installed license
Creating SnapLock traditional volumes
SnapLock is an attribute of the volume
vol create L vol_name <n disks>
Creating SnapLock flexible volumes
SnapLock is an attribute of the volumes
containing aggregate
1. aggr create L aggr_name <n disks>
2. vol create vol_name aggr_name <size>

CREATING SNAPLOCK VOLUMES
You can create SnapLock traditional volumes or SnapLock FlexVol volumes. The SnapLock
volume type, Compliance or Enterprise, is created using the enabled version. However, if both
SnapLock Compliance and SnapLock Enterprise licenses are enabled, you use either the
compliance or enterprise attribute to select the licensed features.
CREATING SNAPLOCK TRADITIONAL VOLUMES
SnapLock traditional volumes are created in the same way a standard traditional volume is
created. If both SnapLock Compliance and SnapLock Enterprise licenses are enabled, use the -L
<compliance | enterprise> option with the vol create command to specify a
compliance or enterprise attribute.
In this example, the L option indicates that the volume will be a SnapLock volume. No
SnapLock attribute is specified because only the SnapLock Compliance license is installed on the
storage system.

System> vol create slctrad L 14

Use the vol status command to verify the SnapLock volume attribute.
System> vol status slctrad
slctrad online raid4,trad
no_atime_update=on,snaplock_compliance
CREATING SNAPLOCK FLEXIBLE VOLUMES
Every flexible volume created inherits its aggregates SnapLock attributes. Thus before you
create a SnapLock flexible volume, you must create a SnapLock aggregate.

In this example, the L option indicates that the aggregate will be a SnapLock aggregate. No
SnapLock attribute is specified because only the SnapLock Compliance license is installed on the
storage system.
System> aggr create slcaggr L 3

Use the aggr status command to verify the SnapLock attribute of the newly created
aggregate.
System> aggr status slcaggr
Aggr State Status Options
slcaggr online raid_dp, aggr snaplock_compliance
Volumes: <none>
Plex /slcaggr/plex0: online, normal, active
RAID group /slcaggr/plex0/rg0: normal

Finally, create the SnapLock flexible volume in the same way a standard flexible volume is
created.

Example:
System> vol create slcflex slcaggr 100m

System> vol status slcflex
Slcflex online raid_dp,flex
no_atime_update=on,snaplock_compliance
Containing aggregate: 'slcaggr'

Volume Retention Periods
Retention periods are the volumes attribute
If you do not explicitly specify an expiration
date for a WORM file, the file inherits the
retention periods set at the volume level
Option SLE Default SLC Default
snaplock_default_period
Minimum
period
Maximum
period
snaplock_minimum_period 0 0
snaplock_maximum_period 30 years 30 years

VOLUME RETENTION PERIODS
The retention periods are the volumes attributes. If you do not explicitly specify an expiration
date for a WORM file, the file inherits the retention periods set at the volume level.
There are three retention periods per volume: a minimum, a maximum, and a default.

The default retention period specifies the retention period assigned to any WORM file on the
SnapLock volume that was not explicitly assigned a retention period.
The minimum retention period is the shortest amount of time a WORM file can be set in a
SnapLock volume.
The maximum retention period is the longest amount of time a WORM file can be set in a
SnapLock volume.
The maximum and the minimum retention periods take precedence over the default retention
period.

The retention periods values for a SnapLock Compliance volume and for a SnapLock Enterprise
volume are listed in the table:

Until you explicitly reconfigure it, the maximum retention period for all WORM files in a
SnapLock Compliance volume is 30 years.
If you change the maximum retention period on a SnapLock Compliance volume, you also
change the default retention period.
If you change the minimum retention period on a SnapLock Enterprise volume, you also
change the default retention period.

Setting Retention Periods
Use the vol options command to verify and set
the retention periods
Examples
vol options slcvol snaplock_minimum_period 1d
vol options slcvol snaplock_maximum_period 1d
vol options slcvol snaplock_default_period min
You can extend the retention date:
On the volume
For a WORM file
From Data ONTAP 7.1 and later, the maximum
retention period can be extended up to 70 years

SETTING RETENTION PERIODS
You use the vol options command to set the retention period values.
System> vol options vol_name snaplock_default_period [{period} |
min | max | infinite <count>d|m|y]
System> vol options vol_name snaplock_maximum_period [{period} |
infinite]
System> vol options vol_name snaplock_minimum_period [{period} |
infinite]

period is the retention period specified by count, followed by days (d), months (m), or years
(y).
min is the retention period specified by the snaplock_minimum_period option.
max is the retention period specified by the snaplock_maximum_period option.
infinite specifies that files committed to WORM state are retained forever.

The storage system checks the retention period values only when a file is initially committed to
the WORM state; therefore, you can extend the retention date set on the volume. For storage
systems using Data ONTAP 7.1 and later, the maximum retention period can be extended up to
70 years.

You can also extend the retention date for a WORM file before or after the file retention date has
expired by updating its last accessed timestamp. This will reenable WORM protection on the file
as if it were being committed for the first time. Once the retention date expires, you can reenable
the write permission on the file and then delete it. However the file contents still cannot be
modified.
NOTE: the SnapLock volume maximum retention period restrictions are not applied when
extending the retention date of a WORM file.

Committing Data to WORM
Consists of changing the file attributes from
writable to read-only while the file is in the
SnapLock volume
From a Windows client
Right-click on the file and select Properties
Check Read Only, and click OK
From a UNIX client
Change the access time (atime) of the file with
the touch command
Make the file read-only using the chmod
command

COMMITTING DATA TO WORM
After placing a file on a SnapLock volume, the file attributes must be explicitly changed to read-
only before it becomes a WORM file. This operation can be done interactively or
programmatically. The exact command or program required depends on the file access protocol
(CIFS, NFS, and so on) and client operating system being used.
The following commands could be used to commit the document.txt file to a WORM state, with a
retention date of November 21, 2020, using a UNIX shell:

touch -a -t 202011210600 document.txt
chmod -w document.txt

From a Windows client, to make a file read-only, right-click the file, select Properties, check the
Read Only checkbox, and then click OK.
The last accessed timestamp of the file at the time it is committed to WORM state becomes its
retention date unless it is limited by the minimum or maximum retention period of the SnapLock
volume. If the date was never set, the default retention period of the SnapLock volume is used.
If a file is initially copied read-only, it is not automatically committed to WORM state. The only
way to guarantee that a file is committed to WORM state is explicitly assign a read-only attribute
and optionally modify the last access time to set a retention date while the file is in the SnapLock
volume.

Auto-Committing Files
Automatically converts to WORM all files on
the SnapLock volume to WORM if they have
not changed during the delay period
Specify a delay with the
snaplock.autocommit_period option
Default is none
Minimum delay is two hours
Auto-commits are performed using a scanner
and can take some time

AUTO-COMMITTING FILES
A time-delay commit to WORM with an adjustable timer is available in Data ONTAP 7.2 or
later. If the file does not change during the delay period, the file is committed to WORM at the
end of the delay period. Auto-commit does not take place instantly when the delay period ends.
Auto-commits are performed using a scanner and can take some time. The retention date on the
committed file will be determined by the volumes default retention period.
To specify a time delay, set the global option snaplock.autocommit_period to a value
consisting of an integer count followed by an indicator of the time period: h for hours, d for
days, m for months, or y for years.
System> options snaplock.autocommit_period none | [count (h | d |
y)]

The default value is none and the minimum delay that can be specified is two hours.
The following example sets the auto-commit period to 24 days:

System> options snaplock.autocommit_period 24d

Appending WORM File
A WORM file can be appended by simply
creating an empty SnapLock file, appending
data to it, and then locking the file in place
again
Data is committed to WORM state in 256 Kb
chunks
The previous 256 Kb segment automatically
becomes immutable
Available from Data ONTAP 7.1 and later

APPENDING WORM FILE
There are times when it is useful to have a SnapLock file that will accept appended data. An
example would be a log file that you must retain. Rather than filling a log and copying it to a
SnapLock file, you can create the file as a SnapLock file, append data to it, then lock the file in
place. This procedure is available from Data ONTAP 7.1 and later.

To use this feature, proceed as follows:
1. Inside a WORM volume create a zero-length file with the desired retention date:
touch -a -t 202012150600 file

2. Update the file access time to indicate the files desired expiration.

3. Make the file read-only:
chmod 444 file

4. Make the file writable again:
chmod 755 file

5. Start writing data to the file:
echo test data > file

At this stage you have a WORM-appendable file. Data is committed to WORM in 256 Kb
chunks. Once data is written to byte n*256k+1 of the file, the previous 256 Kb segment is in
a WORM state and cannot be rewritten.

6. Make the file read-only again. The entire file is now in the WORM state and cannot be
overwritten or erased.
chmod 444 file

Deleting WORM Volumes and Aggregates
You cannot delete SnapLock Compliance
volumes that contain unexpired WORM data
You can delete the volume only when all the
WORM files have passed their retention dates
You can destroy Compliance aggregates if
they dont contain volumes
You can delete SnapLock Enterprise volumes
at any time

DELETING WORM VOLUMES AND AGGREGATES
SnapLock volumes constantly track the retention values of all retained WORM data.
Data ONTAP does not allow you to destroy any SnapLock Compliance volume that contains
unexpired WORM data. Data ONTAP does allow you to destroy SnapLock Compliance volumes
when all the WORM files on the volume have passed their retention dates.
NOTE: If a compliance volume cannot be destroyed, it remains offline. It should be immediately
brought online so that any retention period problem can be fixed and to keep the
ComplianceClock from falling behind.
You can destroy SnapLock Compliance aggregates only when they contain no volumes. The
volumes contained by a SnapLock Compliance aggregate must be destroyed first.
You can destroy SnapLock Enterprise volumes at any time, provided you have the appropriate
authority.

SnapLock and
SnapMirror

SNAPLOCK AND SNAPMIRROR

Solution Architecture
Destination
Storage System
Remote Site
WORM to WORM
SnapMirror
Windows
UNIX
Storage System
Data Center

SOLUTION ARCHITECTURE
You can replicate SnapLock volumes to another storage system using the SnapMirror feature of
Data ONTAP. If an original volume becomes disabled, SnapMirror ensures quick restoration of
data.

Support Matrix
You cannot replicate a non SnapLock volume or a
SnapLock Enterprise volume to a SnapLock
Compliance volume
SnapLock Compliance volumes do not support
synchronous replication
Non SnapLock SLE SLC
Non SnapLock

SLE

SLC

S
o
u
r
c
e

V
o
l
u
m
e

T
y
p
e
Destination Volume Type

SUPPORT MATRIX
You can initialize end-to-end WORM volumes replication in which both the source and
destination volumes are SnapLock volumes, but with the following restrictions:
You cannot replicate a non SnapLock volume or a SnapLock Enterprise volume to a
SnapLock Compliance volume. These limitations do not apply to Qtree-SnapMirror-to-
SnapLock-Compliance volumes.
SnapLock Compliance volumes do not support synchronous replication.

When replicating a non SnapLock volume to a SnapLock Enterprise volume, SnapMirror does
not automatically perform WORM commits for files transferred. To perform WORM commits,
you have to break the SnapMirror relationship and perform the WORM commits on all
transferred files, either manually or using a script.

Initializing a SnapLock-SnapMirror Transfer
For non SnapLock and SnapLock Enterprise
destination volumes, use regular SnapMirror
commands
For SnapLock Compliance destination
volumes
Destination volume must be a regular volume
Use the -L option
snapmirror initialize S
src_system:src_vol L dst_system:dst_vol
When the transfer completes, the destination
volume is converted to a SnapLock Compliance
volume

INITIALIZING A SNAPLOCK-SNAPMIRROR TRANSFER
To initialize the first SnapMirror transfer to a non SnapLock or a SnapLock Enterprise destination
volume, you use regular SnapMirror commands.
For information on SnapMirror configuration steps and snapmirror commands, refer to the
SnapMirror module of this course.
To establish a Volume SnapMirror relationship from a SnapLock Compliance source volume to a
SnapLock Compliance destination volume, the destination volume initially must be a non
SnapLock volume; that is a regular volume.
Then, to perform the initial baseline transfer, you use the L option in the snapmirror
command syntax to convert the destination volume to a SnapLock Compliance volume.
Example:

System> snapmirror initialize S src_system:src_vol L
dst_system:dst_vol
Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.
snapmirror: Destination volume system:dst_vol was converted to a
SnapLock Compliance volume.

Resynchronization
After breaking a Volume SnapMirror
relationship, you cannot resynchronize
replication to a SnapLock Compliance
destination volume
The relationship must be reinitialized to a new
destination volume
SLC
Volume
SLE Volume
Qtree SnapMirror
Resync

Volume SnapMirror
Resync

RESYNCHRONIZATION
You cannot use the SnapMirror resynchronization feature to reestablish a Volume SnapMirror
relationship to a SnapLock Compliance destination volume because data cannot be changed.
After breaking a Volume SnapMirror relationship, you have to rebaseline the relationship to a
new SnapLock Compliance destination volume.
This restriction only applies to Volume SnapMirror relationships and SnapLock Compliance
destination volumes. You can resync a broken Volume SnapMirror relationship as soon as the
destination volume is a SnapLock Enterprise volume. You can also resync a Qtree SnapMirror
broken relationship for either a SnapLock Compliance or Enterprise destination volume.
QTREE SNAPMIRROR RESYNC FOR SNAPLOCK COMPLIANCE VOLUMES
To support data integrity in a restrictive SnapLock Compliance environment, the SnapMirror
resync operation locates the most recent Snapshot copy, and saves any changes that occurred
prior to that Snapshot copy to an image and log file.
These files are stored in following directory on the SnapLock Compliance volume:
/etc/logs/snapmirror_resync_archive/volname_UUID_qtree

The image and log files are named dump_image_YYMMDD_HHMMSS, and
dump_log_YYMMDD_HHMMSS, respectively.

The retention period for image and log files is equal to the longest retention period of any data
file in the data set. This ensures that the image and log files will not be deleted before the
retention period has passed. If the save operation fails for any reason, the resync transfer
operation will not proceed.

SnapLock and
LockVault

SNAPLOCK AND LOCKVAULT

Solution Architecture
LockVault uses SnapVault technology to back up
WORM or nonWORM data to SnapLock
destination volumes
for Windows
for UNIX
SnapVault Secondary
Storage System
Storage System
LockVault
Log Volume
LockVault
Volumes LockVault
LockVault
LockVault

SOLUTION ARCHITECTURE
The LockVault feature of Data ONTAP uses SnapVault technology to back up WORM or
nonWORM data to SnapLock volumes, or LockVault volumes on a secondary storage system.
LockVault can be deployed on NetApp storage systems and open systems platforms.
On the secondary storage system, SnapVault uses a standard SnapLock volume in which the log
files are kept. This volume is called a LockVault log volume or the ComplianceJournal.
SnapVault uses an append-only write to write to the log files. This allows accurate record keeping
but does not allow previous events to be overwritten.
For added data protection, you can replicate the LockVault backup to a tertiary storage system
using volume SnapMirror.

Planning Capacity
Plan secondary volumes capacities to be able
to back up the data and log files
Limit the number of qtree replicas per
secondary volume
Maximum of 16 primary qtrees backed up to a
single secondary volume
Ensure that transfer frequency does not
overload the primary or the network

PLANNING CAPACITY
It is important to plan the destination volume capacity to be able back up the data and log files.
For sizing examples refer to the Data ONTAP Data Retention Online Backup and Recovery
Guide.
Because of performance constraints, a maximum of 16 primary qtrees should be backed up to a
single secondary volume. If you are backing up volumes to qtrees using SnapVault, a maximum
of 16 volumes should be backed up to a volume.
The only guideline for scheduling SnapVault transfers is to avoid overloading the primary storage
system or the network. You must consider the overall load and time to complete all transfers.

Configuring LockVault
1. Configure SnapVault
2. License SnapLock and initialize the
ComplianceClock
3. Create and configure the SnapLock volume
and the LockVault log volume
4. Initialize the first transfer
5. Schedule SnapVault backups and Snapshot
copies creation

CONFIGURING LOCKVAULT
The LockVault configuration steps are almost identical to those for non SnapLock volumes.
1. First, configure SnapVault on the primary and the secondary storage systems as described in
the SnapVault module of this course.

2. Then, license SnapLock, and initialize the ComplianceClock as described previously in this
module.

3. Create and configure the SnapLock volume and the LockVault log volume on the SnapVault
secondary system.
The LockVault log volume must be a SnapLock volume. All SnapVault log entries will be
created in this log volume. Once the volume is created, use the following option to specify
the LockVault log volume name:
Secondary> options snapvault.lockvault_log_volume volume_name
volume_name is the lockvault log volume.

4. Initialize the first transfer for each primary qtree
For example, to start a baseline copy of qtree: (tree_a) to a SnapLock Compliance volume
called sv_vol, use the command:
Secondary> snapvault start -S primary/vol/vol1/tree_a
secondary/vol/sv_vol/tree_a

5. Finally, schedule SnapVault updates on the secondary and Snapshot copies creation on
the primary. Before scheduling SnapVault Snapshot copies, ensure that the SnapLock
default retention period is set correctly or that you explicitly set the retention period when
you schedule SnapVault Snapshot copies.

SnapVault Log Files
Reside in the LockVault log volumes /etc/log
directory
Inherit the retention periods set at the volume
level
Two types of log files:
Operations log files
snapvault.yyyymmdd_zzz
Files-transferred log files
snapvault_filelog.yyyymmdd_hhmmss_zzz
One file per transfer attempt
Separate file for rollback

SNAPVAULT LOG FILES
Log files are kept in the LockVault log volumes /etc/log directory and inherit the default
retention periods of the log volume; thus they cannot be deleted from the volume until their
retention periods have expired. Since SnapVault does not remove expired log files automatically,
you will have to delete them manually once their retention period has expired.
SnapVault uses two types of log files to record events: SnapVault operations log files and
SnapVault files-transferred log files.

Operations log files contain SnapVault operations information and have a weekly rotation
policy; SnapVault creates a new log file every Sunday morning at midnight based on the
ComplianceClock.
File names consist of the word snapvault followed by a timestamp denoting when the file was
created: snapvault.yyyymmdd_zzz.
Files-transferred log files are kept in the following directory structure:
/etc/logs/snapvault secondary vol/secondary qtree name/month/log
file.
Log file names include the timestamp of the transfer similar to the operation log file name plus
the time zone to ensure uniqueness: snapvault_filelog.yyyymmdd_hhmmss_zzz.
SnapVault creates a new files-transferred log file at the beginning of each SnapVault transfer.
A transfer log contains a header that describes the transfer, and zero or more entries that describe
the contents of the transfer. A log file contains only a header and zero entries in two instances:
when no data on the primary had changed since the last SnapVault update, or for a rollback
transfer.

SnapVault WORM Snapshot Copies
SnapVault Snapshot copies for SnapLock
volumes are WORM Snapshot copies and
inherit the retention periods set at the volume
level
They can be deleted only once their retention
period has expired
They are not automatically deleted
Snapshot copies names are specified in the
snapvault snap sched command
snapname.yyyymmdd_hhmmss_zzz

SNAPVAULT WORM SNAPSHOT COPIES
When you configure a SnapVault Snapshot schedule for a SnapLock volume on the secondary,
the Snapshot copies created for that volume are WORM Snapshot copies and inherit the retention
periods set at the volume level. WORM Snapshot copies are not deleted automatically, and
cannot be deleted until their retention period has expired. This rule overwrites the Snapshot
retention count that you specified in the snapvault snap sched command.
Snapshot copies names created by SnapVault on SnapLock volumes are specified in the
snapvault snap sched command.
Snapshot names for SnapLock volumes use the time and date of the Snapshot copy creation as a
suffix. The time and date are generated based on the ComplianceClock:
snapname.yyyymmdd_hhmmss_zzz
snapname is the Snapshot copy name specified in the schedule
yyyymmdd is the year, month, and day
hhmmss is the hour, minute, and second
zzz is the current time zone setting

Example:
svhourly.20080822_120502_GMT
The SnapVault Snapshot copy svhouly was created on August 22, 2008, at 12:05:02 GMT.

Managing WORM Snapshot Copies
Use the retention_period option in the
snapvault snap sched command to specify a
retention period for WORM Snapshot copies
Use the snapvault snap retain command to
extend the retention period
Display WORM Snapshot copies and retention
dates:
Secondary> snap list -l sec_vol
Volume sec_vol
snapshot date retention date name
--------------------- -------------------- -----
Aug 22 19:56:50 2008 +0000 May 13 19:59:42 2009
+0000 sv_hourly.20080822_195442_GMT

MANAGING WORM SNAPSHOT COPIES
You can configure the schedules on the secondary to create WORM Snapshot copies with a
retention period that you specify, using the command:
Secondary> snapvault snap sched -x -o retention_period=period
sec_vol snapname count@day_list@hour_list

Period is the retention period in count followed by days (d), months (m), or years (y).
You can extend the retention period of a WORM Snapshot copy using the command:
Secondary> snapvault snap retain sec_vol snapname period

To display WORM Snapshot copies and their retention dates, use the snap list -l
command.

Example:
Secondary> snap list -l sec_vol
Volume sec_vol
working...
snapshot date retention date name
-------------------------- --------------------------
Aug 22 19:56:50 2008 +0000 May 13 19:59:42 2009 +0000
sv_hourly.20080822_195442_GMT
Aug 22 19:51:07 2008 +0000 May 13 19:55:08 2009 +0000
sv_hourly.20080822_195006_GMT

Resynchronizing Compliance Volumes
Use snapvault start r to resynchronize
a broken SnapVault relationship
Resync saves data written after the common
Snapshot copy to an image and log file on the
volume
Path:
/etc/logs/snapmirror_resync_archive
/volname_UUID_qtree
Image name: dump_image_YYMMDD_HHMMSS
Log files name: dump_log_YYMMDD_HHMMSS

RESYNCHRONIZING COMPLIANCE VOLUMES
The snapvault start -r command enables you to reestablish a broken SnapVault
relationship without a lengthy baseline transfer. Typically, this command locates the most recent
common Snapshot copy, discards any data written to the destination after that Snapshot copy, and
begins to resynchronize content using the common Snapshot copies.
To support data integrity in a restrictive SnapLock Compliance environment, the snapvault
start -r operation saves all data that was written after the common Snapshot copy to an
image and log file in a directory on the volume.
These files are then stored in the following directory on the SnapLock Compliance volume:
/etc/logs/snapmirror_resync_archive/volname_UUID_qtree
The image and log files are named dump_image_YYMMDD_HHMMSS, and
dump_log_YYMMDD_HHMMSS, respectively.
The retention period for image and log files is equal to the longest retention period of any data
file in the data set.

Data ONTAP Data Protection Online Backup
and Recovery Guide
WORM Storage on Magnetic Disks Using
SnapLock Compliance and SnapLock
Enterprise
Understanding SnapLock ComplianceClock

following:
MANUAL
TECHNICAL REPORTS
TR-3263: WORM Storage on Magnetic Disks Using SnapLock Compliance and
SnapLock Enterprise
TR-3618: Understanding SnapLock Compliance Clock

Summary
Explain the difference between SnapLock
Compliance and Enterprise volumes
Configure SnapLock
Commit data to a WORM state
Manage a WORM Snapshot copy
Replicate SnapLock volumes using volume
SnapMirror
Back up WORM and nonWORM data using
LockVault

SUMMARY

Exercise
Module 7: SnapLock

EXERCISES

8-1 NetApp Protection Software Administration Data ONTAP 7.3: Protection Manager
MODULE 8: PROTECTION MANAGER AND PROVISIONING MANAGER
Protection Manager
and Provisioning
Manager
Administration
Data ONTAP 7.3

PROTECTION MANAGER AND PROVISIONING MANAGER

Objectives
At the end of this module, you will be able to:
List Protection Manager features and components
Enable and install Protection Manager and
Provisioning Manager
Configure hosts and storages systems
Configure resource pools, schedules, policies, and
data sets
Explain Thin Provisioning
Perform backup and restore operations
Manage backup and mirror relationships

OBJECTIVES

Operations Manager Overview
SnapMirror
SnapVault
Protection
Manager
Operations
Manager Server
Management
Console
Primary Storage
SnapVault
SnapVault
OSSV + NetApp Host Agent
Primary Storage
Secondary Storage
Secondary Storage

OPERATIONS MANAGER OVERVIEW
Operations Manager automates and simplifies the management of heterogeneous data and
application backup and recovery. It provides data protection by proactively identifying
unprotected data, and provides and error diagnostic capability for hosts, as well as detailed status
reporting.
OPERATIONS MANAGER SERVER
Use Operations Manager to perform the following actions:
Group devices, vFiler units, host agents, volumes, qtrees, and LUNs into meaningful groups for
ease of management.
Configure role-based access control (RBAC) settings.
Define group configuration management templates and apply those templates to one or more
systems.
Edit volume, qtree, or user quotas.
Run Data ONTAP CLI commands simultaneously on multiple systems.
PROTECTION MANAGER AND PERFORMANCE ADVISOR
Protection Manager can be downloaded from Operations Manager (formerly DataFabric
Manager). Protection Manager is part of the NetApp Management Console and can be installed
on either a UNIX or Windows server.
Protection Manager enhances disaster-recovery protection by providing capabilities for disaster-
recovery verification, testing, and simple failover processes.
Protection Manager integrates with SnapVault and SnapMirror to automate backups and mirrors
for primary-to-secondary relationships.

Protection Manager uses the information stored in the Operations Manager database to be aware
of primary and secondary storage systems, Open Systems SnapVault clients, and existing
SnapVault and SnapMirror relationships.
NETAPP HOST AGENT
The Operations Manager server can automatically discover SAN hosts. The special-purpose
NetApp Host Agent software discovers, monitors, and manages SANs on SAN hosts. You
must install the NetApp Host Agent software on each SAN host that you want to
monitor and manage with the Operations Manager server.

After the NetApp Host Agent software is installed on a client host and you have
installed the DataFabric Manager server with the Operations Manager license,
you can perform a variety of tasks:
Monitor basic system information for SAN clients and related devices
Perform management functions such as creating, modifying, or expanding a LUN
View detailed HBA and LUN information.

OPEN SYSTEMS SNAPVAULT
Allows users to monitor and manage SnapVault and Open Systems
SnapVault disk-to-disk backups.

Protection Manager Components
Protection Manager manages primary data in
data sets and secondary storage systems in
Resource Pools
Data protection is based on Schedule and
Policy
Protection Manager monitors whether the data
conforms to the policy

PROTECTION MANAGER COMPONENTS
Protection Manager helps you manage your backup and mirror relationships and perform failover
operations easily and efficiently by eliminating repetitive tasks and automating some tasks.
Typically, data and resource management is time consuming because it involves manual analysis
and management of storage capacity, network bandwidth, schedules, retention policies, and other
infrastructure variables. Protection Manager simplifies this work by employing configuration
policies, convenient wizards, and automated verification of certain aspects of the data protection
configuration. It lets you launch a backup, restore, or failover operation with a single click.

The protection application can perform the following actions:
Use policies to manage primary data, storage, and backup and mirror relationships
Manage local and remote backups and mirror copies
Provision the secondary storage for backups and mirrored copies based on policies you assign
Enable disaster-recovery capability if you install the licensed disaster-recovery option
Automatically validate your backup and disaster-recovery configuration with a conformance
checker.

Data Protection Types
Local backup
Snapshot
TM
copy protection of the data on the storage
system
Fast restore using the most recent Snapshot copy
Remote backup
Backs up data from a primary system to a secondary
system
Based on SnapVault and Qtree SnapMirror technologies
Mirror
Mirrors all volume data from a primary system to a
secondary storage system
Based on Volume SnapMirror replication technology
Does not support SnapMirror Sync and Semi-Sync

DATA PROTECTION TYPES
Local backup protection is based on NetApp Snapshot copy technology. Local backup protection
is the periodic capture of active data on a NetApp storage system in backup images. Local backup
operations are typically employed on primary storage systems where data is being actively
updated and where, in event of accidental data loss, data can be restored using the most recent
and locally stored Snapshot copy.
Remote backup protection is the periodic capture and copying of active data from a source
storage system to a remote secondary or tertiary storage system. If data in the source system is
lost and unrecoverable, then data can be quickly restored from the remote backup site. Remote
backup protection is based on SnapVault and Qtree SnapMirror technologies.

Mirror protection is the periodic exact mirroring of all volume data from a source storage system
to a destination storage system. If data in the source system is lost or made unavailable, then that
same data can quickly be made available from the destination mirror site. Mirror protection is
based on Volume SnapMirror technology. Protection Manager as part of Operations Manager 3.6
does not support SnapMirror Sync and Semi-Sync replications.

Policy-Based Data Protection
Policies are the sets of data protection rules
that are assigned to data sets
A data protection policy defines
The method of protection: local backup, remote
backup, or mirror
The backup copy retention duration
The backup schedule
Lag threshold configurations
Scripts to be run

POLICY-BASED DATA PROTECTION
Protection policies are the data protection instructions that you assign to your data sets. These
policies describe the method of protection to carry out, the backup copy retention duration, the
backup or mirror operation schedules, the backup and mirroring lag times to allow, and the scripts
to execute.
A policy is a set of rules that specifies the intended management of data set members. You can
apply the same policy to multiple data sets, leveraging your configuration of the policy across the
data sets. If you update a policy, the update is propagated across all the data sets to which the
policy is applied.

From the NetApp Management Console, you can use the following policies to quickly implement
changes across an entire organization:
PROTECTION POLICIES
A protection policy defines when data copies used for backups and mirror copies are created on
the primary storage, when to transfer the copies, and the maximum amount of data to transfer at
scheduled times. The protection policy settings define how long to retain copies at each backup
location and the warning and error thresholds for lag time. You cannot override a policy for
specific members of a data set; if some members of a data set require different policy parameters,
you need to move those members to a different data set.

DISASTER-RECOVERY POLICIES
A protection policy that supports failover from a primary to a secondary node is considered to be
capable of disaster recovery. The disaster-recovery node is always directly connected to the
primary node, and its storage is made available after a disaster.
PROVISIONING POLICIES
A provisioning policy defines how you want to have storage provisioned, exported, and managed,
and what your space requirements are. For example, a provisioning policy might specify that
when a storage container reaches the Nearly Full or Full threshold, an event message is sent or the
size of the volume is increased (which provides more space for all the qtrees in the volume).

A provisioning policy applies to all volumes, qtrees, or LUNs in a data set node. You cannot
assign different provisioning policies to individual members within a data set.
If you also have the protection license and the data set has a mirror or backup node, you can
create and assign a different policy that defines provisioning and storage management on a
secondary and tertiary node.

Examples of Policy
Backup, then mirror
Local Snapshot copy
SnapVault backup to
secondary host
SnapMirror replication
to tertiary host
Mirror
Local Snapshot copies
SnapMirror replication to destination
host
Backup
Local Snapshot copies
SnapVault backup to secondary host
Primary
Data
Mirror
Primary
Data
Backup
Primary
Data
Mirror Backup

EXAMPLES OF POLICY
MIRROR
Performs a local Snapshot copy on the primary host, and then uses SnapMirror to back up the
primary host to a secondary host.
BACKUP
Performs a local Snapshot copy on the primary host, and then uses SnapVault to back up the
primary host to a secondary host.
BACKUP AND THEN MIRROR
Performs a local Snapshot copy on the primary host, and then uses SnapVault to back up the
primary host to a secondary host, which in turn is backed up with SnapMirror to a tertiary host.

Resource Pools
A collection of physical resources from which
secondary storage is provisioned
Created from entire storage systems or from
aggregates
When adding a storage system to a resource
pool, all aggregates on the storage system are
available for provisioning
To prevent conflicts, physical storage assigned
to one resource pool cannot be assigned to
another resource pool

RESOURCE POOLS
A resource pool is a collection of unused physical storage (such as storage systems or aggregates)
from which new volumes or LUNs can be provisioned to contain data. If you assign a storage
system to a resource pool, all aggregates on that storage system become available for
provisioning.
Any unused physical resource in a resource pool is potentially eligible for provisioning. You can
organize physical resources into resource pools by location, performance, or other important
factors.

The protection and provisioning applications apply NetApp best practices in provisioning storage,
so automatically provisioned volumes or LUNs meet the necessary requirements for compatible
software version, licensing, and available space.

In the licensed protection application, you assign a resource pool to the backup and mirror
destinations of a data set. The protection application can then automatically provision volumes
out of the physical resources in the resource pool to contain backups and mirror copies. To
prevent conflicts, physical storage assigned to one resource pool cannot be assigned to a second
resource pool.

With the licensed provisioning application, you can use resource pools to fulfill requests for
storage space for the primary or secondary data of a data set. By applying a provisioning policy to
a data set node, the provisioning application applies the resiliency characteristics and space
settings in the policy to automatically select the resources needed to fulfill a provisioning request.

Provisioning Resource Pools
Mirrors
You can only select entire storage systems to
include in resource pools
Backups
Protection Manager cannot provision resources
for backup jobs
You must manually create the volumes to add to
the data sets secondary node
When assigning resources to a data set, only the
volumes are available for selection

PROVISIONING RESOURCE POOLS
MIRRORS
If you are mirroring data, you can only select entire storage systems to include in resource pools.
Protection Manager uses the spare disks on the storage systems to provision traditional volumes
for the mirrors.
BACKUPS
Protection Manager cannot provision resources for backup jobs. You must manually create the
volumes to add to the data sets secondary node. When you assign resources to a data set, only the
volumes are available for selection.

Data Sets
A collection of physical resources, such as
storage systems, flexible volumes, qtrees, and
copies of backed-up data
You can associate a policy with a data set to
automate tasks
Apply consistent policies to primary data
Propagate policy changes
Provision new volumes

DATA SETS
In the simplest terms, a data set is a collection of user data you manage as a single unit, plus all
the replicas of that data. The data is identified by the volume, qtree, or directory in which it is
located.
Because you manage a data set as a single unit, its members should have common management
requirements. In Protection Manager, members of a data set should share the same data protection
requirements. In Provisioning Manager, each node in a data set might not share the same
provisioning requirements, but all members of each node should share the same provisioning
requirements.

For example, different types of data supporting the same application would probably share the
protection requirements of the application. You would want to collect that data in the same data
set, even if the data was stored in different volumes or qtrees. By configuring protection
appropriate for the application that the data supports and applying that protection to the data set,
you apply it to all the data set members.

Data Set Creation
When a data set is created, Protection
Manager performs the following:
1. Provisions volumes and qtrees on the
destination node
2. Creates a backup relationship
3. Runs the data protection schedules
4. Checks that the data set conforms to its data
protection policy

DATA SET CREATION
Protection Manager uses the information in a data set to create Snapshot copies used for backups
and mirrors, to provision storage as needed for the copies, and to transfer the copies to destination
nodes. After you set up a data set for protection, Protection Manager performs the following
operations:
Protection Manager provisions volumes and qtrees on the destination node in several ways. For
storage systems that run Data ONTAP 7.0 or later, Protection Manager automatically provisions
flexible volumes and qtrees when the resource pool contains an aggregate. For storage systems
that run Data ONTAP 6.5 or earlier, you manually add secondary storage to the destination node.
If you manually select storage without using resource pools for a SnapMirror destination node,
Protection Manager provisions traditional volumes assigned to that destination node.
Protection Manager creates a backup relationship (either SnapVault or SnapMirror) between each
volume and qtree in the data set with the newly provisioned secondary storage.
Protection Manager runs the data protection schedules, making Snapshot copies of the primary
data and initiating SnapVault and SnapMirror baseline transfers at the scheduled times.
Protection Manager periodically checks that the data set conforms to its data protection policy. If
either the data set membership or the policy changes, Protection Manager tries to bring the data
set back into conformance or it notifies you that the conformance status changed to
nonconformant.

Conformance Checker
Check the actual behavior of the system
against policy
Data sets are marked as either in conformance
or out of conformance
Administrator can be notified of important
changes
The Conformance Engine makes changes to
bring data sets into compliance automatically
or with the Administrators guidance

CONFORMANCE CHECKER
The Protection Manager conformance monitor regularly checks for a data sets conformance to its
policy. When it detects a change in the data sets membership or policy definition, the
conformance monitor does one of three things:
Automatically performs corrective steps to bring a data set back into conformance
Presents you with a list of actions for your approval prior to correction
Lists conditions that it cannot resolve
For example, if the conformance monitor detects that a data sets assigned secondary resources do
not offer appropriate backup space, it requires that you reconfigure the resource pool membership
so that Protection Manager can successfully continue data protection.

Enable and Install

ENABLE AND INSTALL

Setup Overview
Setting up Protection Manager consists of:
Downloading the NetApp Management Console
Licensing Protection Manager
Then, to configure data protection:
Configure the storage systems
Add the storage systems and set credentials
Create resource pools, schedules, and policy
Create data sets and monitor job status

SETUP OVERVIEW

Install NetApp Management Console
Connect to and log in to Operations Manager
http://<Operations_Manager_IP_Address>:8080/dfm/welcome
Download the NetApp Management Console
Setup > Download Management Console

INSTALL NETAPP MANAGEMENT CONSOLE

Licensing Protection Manager
To enable Protection Manager, you need to
purchase and install the dataprotection license on
the Operations Manager Server
Using the Operations Manager Web Interface:
Setup > Options > Licensed Features

LICENSING PROTECTION MANAGER
The NetApp Management Console is installed by each user on his or her workstation by
downloading an installation program from Operations Manager Control Center page.
The links for downloading this installer are located by selecting the Download Management
Console item in the Setup drop-down menu of the Control Center.

Management Console

MANAGEMENT CONSOLE
The above screen shot is an example of what the NetApp Management Console looks like when
licensed with Protection Manager.
The screen shown is the Dashboard. From this screen you can easily see how many protected
data sets, volumes, qtrees, and directories you have. You can also see what is not protected. You
can see the top five events, including critical and cautionary events. You can see lag warnings,
which tell you if a SnapVault update was not successful, as well as utilization of Resource Pools
to let you know if you have to add disks to aggregates that are being used by Resource Pools.

Data ONTAP Configuration
1. Install the SnapMirror license
license add <code>
2. Specify the host names of destination systems
allowed to mirror data from the source
options snapmirror.access host=<dst_hostname>
3. Set SnapMirror access on the destination
options snapmirror.access host=<src_hostname>
4. Enable the NDMP service
options ndmpd.enable
5. Set NDMP access
options ndmpd.access

DATA ONTAP CONFIGURATION
To prepare the source and the destination storage systems to be managed by Protection Manager,
complete the following steps:
1. Install the SnapMirror license:
src/dst> license add <code>

2. Specify the host name of the destination system allowed to mirror data from the source:
src> options snapmirror.access host=<dst_hostname>

3. Set SnapMirror access on the destination:
dst> options snapmirror.access host=<src_hostname>

4. Enable the NDMP service:
src/dst> options ndmpd.enable on

5. Set NDMP access:
src/dst> options ndmpd.access all

The default value is all, which permits NDMP sessions with any host.
If you want to specify a restricted set of hosts that can connect to the storage system, you can set
one of the following values:
host=hosts allows a specified host or a comma-separated list of hosts to run NDMP sessions on
this storage system; the hosts can be specified by either host name or IP address.
if=interfaces allows NDMP sessions through a specified interface or a comma-separated list of
interfaces on this storage system.

Data ONTAP Configuration (cont.)
6. Set NDMP authorization method
options ndmpd.authtype
7. Create local account (optional)
useradmin useradd <backupuser> -g
Backup Operators
8. Set NDMP password length (optional)
ndmpd.password_length { 8 | 16 }
9. Generate encoded NDMP password (optional)
ndmpd password <backupuser>

DATA ONTAP CONFIGURATION (CONT.)
6. Set NDMP authorization method:
src/dst> options ndmpd.authtype
The challenge authentication method is generally the preferred and more secure authentication
method. Challenge is the default type; SnapVault and SnapMirror management require challenge.

7. Create local account (optional):
If you do not want the operator to access the storage systems with root privileges,
add a new backup user to the Backup Operators useradmin group list:
src/dst> useradmin useradd <backupuser> -g Backup
Operators

8. Set NDMP password length (optional):
Specify an 8-character or 16-character NDMP password length (the default value is 16):
src/dst> ndmpd.password_length { 8 | 16 }
By default, ONTAP generates 16 character passwords.

9. Generate an encoded NDMP password for the new user (optional):
src/dst> ndmpd password <backupuser>

Configure Hosts and Storage Systems
Hosts or storage systems can be added
directly to the Operations Manager database
and then configured for use with Protection
Manager
Add Host Wizard guides the user through the
steps required to configure a new host
The Diagnose Wizard section describes how to
configure existing storage systems for
mirroring

CONFIGURE HOSTS AND STORAGE SYSTEMS
This includes setting the login and NDMP credentials for the hosts and ensuring that the
appropriate licenses are enabled on each host according to the purpose you assign to the host in
your protection strategy.

Login Credentials
Set Up > Hosts > Select a Storage System > Diagnose

LOGIN CREDENTIALS
In order for Protection Manager to execute data protection commands, Operations Manager must
be able to log in to the storage system with system administrators credentials.
The user name and password is usually the root account and password for the storage system.
You can display user names and accounts information by issuing the Data ONTAP useradmin
user list command on the storage system on which you are trying to establish credential
authentication.
Example:
NetApp> useradmin user list
Name: root
Info: Default system administrator.
Rid: 0
Groups:
Name: administrator
Info: Built-in account for administering the filer
Rid: 500
Groups: Administrators
Name: rootrb
Info:
Rid: 131072
Groups: Administrators

Licenses and Access Control

LICENSES AND ACCESS CONTROL

NDMP Credentials

NDMP CREDENTIALS
Protection Manager uses NDMP to communicate with NetApp storage systems.
The NDMP account used is the built-in account for administering the storage system (default is
administrator).

You must log in to the storage system to obtain the NDMP password set for the administrator
account.

Example:
System> ndmpd password administrator
password ********

Protection Manager Administration Guide For
Use with Operations Manager Server 3.6
Role-Based Access Controls in Data ONTAP:
Granular Administration of Capabilities
NetApp Protection Manager Protecting Your
Data: Policy-Driven Data Management
NetApp Protection Manager: Scenario Setup

following:
MANUAL
Protection Manager Administration Guide for Use with Operations Manager Server 3.6
TECHNICAL REPORTS
TR-3358: Role-Based Access Controls in Data ONTAP: Granular Administration of
Capabilities
TR-3524: NetApp Protection Manager Protecting Your Data: Policy-Driven Data
Management
TR-3560: NetApp Protection Manager: Scenario Setup

Summary
List Protection Manager features and components
Enable and install Protection Manager and
Provisioning Manager
Configure hosts and storage systems
Configure resource pools, schedules, policies, and
data sets
Explain Thin Provisioning
Perform backup and restore operations
Manage backup and mirror relationships

SUMMARY

Exercise
Module 8: Protection Manager
Estimated Time: 1.5 hours

EXERCISE

Data Protection STRSW Ilt Dataprot Rev3 SG - Studentguide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Data Protection STRSW Ilt Dataprot Rev3 SG - Studentguide

Uploaded by

Copyright:

Available Formats

NetApp University

Replicate data using SnapMirror

for storage systems and open

, SnapMirror, SnapVault, SnapRestore, FlexClone

NetApp Protection Software

Describe the effects of SnapRestore on backup

NetApp Protection Software

Schedule SnapMirror updates at times when

NetApp Protection Software

Adaptive Server Enterprise

NetApp Protection Software

Linux Enterprise Server

NetApp Protection Software

You might also like