13 DataProtectionB&DR SG

Module 13
Data Protection: Backups and

Disaster Recovery
NetApp Confidential 1
MODULE 13: DATA PROTECTION: BACKUPS AND DISASTER RECOVERY
13-1 Clustered Data ONTAP Administration: Data Protection: Backups and Disaster Recovery
© 2013 NetApp, Inc. This material is intended only for training. Reproduction is not authorized.
Module Objectives
After this module, you should be able to:

 Configure and replicate to SnapVault backups
 Answer questions about NDMP backup
 Discuss disaster recovery in a clustered
environment
MODULE OBJECTIVES
Lesson 1
LESSON 1
SnapVault Software for Clusters
SNAPVAULT SOFTWARE FOR CLUSTERS

SnapVault software leverages block-level incremental replication for a reliable, low-overhead backup
solution. It provides efficient data protection by copying only the data blocks that have changed since the last
backup, instead of entire files. As a result, you can back up more often while reducing your storage footprint
because no redundant data is moved or stored. With direct backups between NetApp systems, disk-to-disk
vault backups minimize the need for external infrastructure and appliances. By default, vault transfers retain
storage efficiency on disk and over the network, further reducing network traffic. You can also configure
additional deduplication, compression, or both on the destination volume. However, if additional compression
is configured on the destination volume, storage efficiencies from source to destination are not retained over
the network.
The key advantages of vault backups for clusters include reduction of backup times from hours or days to
minutes, 100% success rates for backup reliability, reduction of disk capacity requirements by 90% or more,
simplified management across enterprise applications, and minimized network traffic.
For more information about backing up FlexVol volumes to a backup vault, see the Clustered Data ONTAP
Data Protection Guide.
SnapVault Benefits
 Reduction of backup times from hours to days

or minutes
 100% success rates for backup reliability
 Reduction of disk capacity requirements by
90% or more
 Simplified management across enterprise
applications
 Minimized network traffic
SNAPVAULT BENEFITS
Use SnapMirror Commands
 SnapVault was added to the SnapMirror

architecture and UI.
 SnapVault functions are accomplished with
SnapMirror commands.
 SnapVault is specified with transfer type
“XDP.”
cluster1::> snapmirror create
-source-path vs7:vs7_vol1
-destination-path vs8:vs8_vol1
-type XDP
-schedule 5min -policy vs7-vs8-vspolicy
USE SNAPMIRROR COMMANDS

Because SnapVault was added to the new SnapMirror architecture and UI, there are no SnapVault commands.
SnapVault functions are accomplished with SnapMirror commands. SnapVault is specified with the transfer
type “XDP.” Architecture, UI, and various behaviors were changed to accommodate scalability and server
virtualization.
SnapMirror Types
 DP: asynchronous data protection mirror

relationships
 LS: load-sharing mirror relationships
 XDP: backup vault relationships
 TDP: transition relationships
 RST: transient restore operations
relationships
SNAPMIRROR TYPES
In clustered Data ONTAP, SnapMirror technology is organized to include several types of replication
relationships.
 “DP” is for asynchronous data protection mirror relationships.
 “LS” is for load-sharing mirror relationships.
 “XDP” is for backup vault relationships.
 “TDP” is for transition relationships from Data ONTAP running in 7-Mode to clustered Data ONTAP.
 “RST” is a transient relationship for restore operations.
SnapMirror Commands for SnapVault
snapmirror create
snapmirror initialize
snapmirror modify
snapmirror policy -type XDP
snapmirror show
snapmirror update
snapmirror restore
SNAPMIRROR COMMANDS FOR SNAPVAULT

SnapMirror commands, with the “–type XDP” [pronunciation tip: dash type X.D.P.] option, are used to
configure SnapVault. The basic SnapMirror commands include snapmirror create, snapmirror
initialize, snapmirror modify, snapmirror policy, snapmirror show,
snapmirror update, and snapmirror restore.
Snapshot Policy on the Source Volume
cluster1::> snapshot policy show
Vserver: cluster1
Number of Is
Policy Name Schedules Enabled Comment
------------------------ --------- ------- ---------------------------------
default 3 true Default policy with hourly, daily
& weekly schedules.
Schedule Count Prefix SnapMirror Label
---------------------- ----- ---------------------- ----------------
hourly 6 hourly -
daily 2 daily daily
weekly 2 weekly weekly
default-1weekly 3 true Default policy with 6 hourly, 2

daily & 1 weekly schedule.
Schedule Count Prefix SnapMirror Label
---------------------- ----- ---------------------- ----------------
hourly 6 hourly -
daily 2 daily -
weekly 1 weekly -
Cron Schedules
SNAPSHOT POLICY ON THE SOURCE VOLUME

On the primary volume, you must configure a Snapshot policy that specifies what copies to create and when
to create them by using cron schedules, and assign labels to specify which copies should be transferred by
SnapVault. Notice that in the output of the snapshot policy show command, the last column shows
the SnapMirror label. This parameter is used by the SnapVault secondary volume to locate the matching
Snapshot copy name to transfer to the secondary volume.
On the secondary, create a SnapMirror policy that specifies the labels of Snapshot copies to be transferred and
how copies should be retained on the secondary. A flow chart describing these steps and detailed setup
instructions are available in the SnapVault Express Guide and the Data Protection Guide.
Steps for Creating a SnapVault
Relationship on the Destination Cluster
1. Create a destination data aggregate.
2. Create a SnapVault Vserver.
3. Create a destination volume.
4. Create a SnapMirror policy (type -XDP).
5. Create the SnapVault relationship.
6. Initialize the SnapVault relationship.
STEPS FOR CREATING A SNAPVAULT RELATIONSHIP ON THE DESTINATION

CLUSTER
After setting up the primary volume, follow these steps on the destination node to set up the SnapVault
relationship:
1. Create a data aggregate in the destination cluster;
2. Create a SnapVault destination Vserver;
3. Create a destination volume;
4. Create a SnapMirror policy specifying type –XDP for SnapVault relationships;
5. Create the SnapVault relationship with the Snapmirror create command, again, specifying type
–XDP for SnapVault relationships; and then
6. Initialize the SnapVault relationship with the snapmirror initialize, type –XDP, command.
Fan-In Deployments
 Multiple clusters/Vservers backing up to single cluster or
Vserver
 Affected by cluster peer limit (7:1 cluster fan-in limit in 8.2)
FAN-IN DEPLOYMENTS
Clustered Data ONTAP supports system level Fan-in. Since replication is now done at the volume level, you
cannon have multiple source volumes backing up to the same destination volume. Similar to the way you
could have multiple source Qtrees backing up to one volume with 7-Mode SnapVault, you can have volumes
from different Vservers and different clusters backing up to volumes on the same vserver. To configure Fan-
in, you must set up cluster peers. Note that in 8.2 the number of cluster peers is limited to 8, so volumes from
a maximum of 8 clusters can back up to a single cluster. Because the current limit in Data ONTAP is 8 cluster
peers, this means that volumes from a maximum of 7 different clusters can back up to a single destination
cluster.
Fan-Out Deployments
 SnapMirror and SnapVault of single primary volume
 1:4 fan-out possible (Can be any combination of
SnapMirror and SnapVault)
FAN-OUT DEPLOYMENTS
Up to four SnapVault destination volumes can be replicated from the same source volume. The limit of four
destination volumes is shared between SnapMirror and SnapVault, therefore the 1:4 ratio applies to the total
number of SnapMirror and SnapVault relationships of any combination.
Cascades
 SnapMirror  SnapVault
 SnapVault  SnapMirror
 Only one SnapVault replication supported in a cascade
 Cascade configuration transfers the SnapMirror base
Snapshot copy to SnapVault destination
SnapMirror to SnapVault SnapVault to SnapMirror
CASCADES
Supported cascade relationships include SnapMirror to SnapVault and SnapVault to SnapMirror.
Cascade relationships can contain only one instance of a SnapVault relationship; however, you can include as
many mirror copies as you require.
The cascade function is designed to guarantee that all volumes in a cascade chain have a common Snapshot
copy. The common Snapshot copy makes it possible for any pair of end points in a cascade to establish a
direct relationship.
The snapmirror restore Command
Using the snapmirror restore command you:

 Specify the destination and the source paths.
 Restore the latest Snapshot copy.
cluster1::> snapmirror restore

-destination-path vs7:vs7_vol1
-source-path vs8:vs8_vol1
THE SNAPMIRROR RESTORE COMMAND

Using the snapmirror restore command you specify the destination and then the source. You can
restore the latest Snapshot copy either from the source volume or the SnapVault secondary volume.
Comparing SnapVault to SnapMirror
SnapMirror Functions SnapVault Functions
SnapMirror provides data protection SnapVault accumulates copies of the

for disaster recovery. source volume for archival purposes.
SnapMirror can asynchronously copy If the source FlexVol volume is lost,

the source FlexVol volume to a clients can restore data from the
disaster recovery replica. secondary to primary storage.
If the source FlexVol volume is lost The read-only SnapVault copy can
or destroyed, clients can connect to be rendered writable only by creating
the mirror image of the source data. a FlexClone volume copy.
COMPARING SNAPVAULT TO SNAPMIRROR

SnapMirror and SnapVault are data-protection replications. SnapMirror is used for disaster recovery and
maintains only one read-only replica of the source volume. If a disaster occurs at your data center, you break
the SnapMirror relationship to render the copy writable and quickly connect your client servers to the now
writable SnapMirror replica. SnapVault is used for creating read-only archival copies of your source volume.
If a disaster occurs at your data center, you can select one of the read-only backup versions and restore the
data from secondary to primary storage. The read-only SnapVault copy can be rendered writable only by
creating a FlexClone volume copy of the SnapVault copy and splitting the cloned volume away from the
parent Snapshot copy.
SMTape to Seed Baselines
SnapMirror
Resync SMTape
SMTape
SMTAPE TO SEED BASELINES

In clustered Data ONTAP, you can attach a tape device to the source node and use SMTape in a process that
is called “tape seeding.” By using SMTape commands and a tape device, you can establish mirror and vault
relationships for large source volumes without sending the initial baseline transfer from the source node to the
destination node over the network.
For more information on using vault backups, enroll in the web-based course Technical Overview of
SnapVault on Clustered Data ONTAP.
Lesson 2
LESSON 2
Backup and Restoration with NDMP
 You can perform local NDMP, remote NDMP, and
three-way NDMP backups.
– NDMPv4
– Direct Access Recovery (DAR)
 A clustered Data ONTAP system does not
provide native NDMP backup and restoration,
only NDMP through third-party software.
 Backups do not traverse junctions; you must list
every volume to be backed up.
 You should not back up directly through NFS
or CIFS.
BACKUP AND RESTORATION WITH NDMP

Backups can be performed across a cluster by using three-way NDMP, provided that the third-party backup
application is given access to the cluster network.
A backup of a source volume does not include all of the volumes that are mounted to the source volume.
NDMP backups do not traverse junctions. Therefore, every volume that is to be backed up must be listed
explicitly. However, if the backup vendor software supports automatic discovery of file systems or the use of
wildcards, not every volume must be specified.
Although backing up through an NFS or CIFS client is possible, doing so uses all of the cluster resources that
are meant to serve data and fill the network module caches with data that most clients aren’t actually using.
You should send the data through a dedicated FC connection to the tape device or devices by using NDMP,
which doesn’t use the resources of the network module, data network, or cluster network.
Vserver-aware NDMP
CAB* Enabled Remote NDMP
DMA Server
Control
Control Connection
Data or Intercluster LIF Connection
Data or Intercluster LIF

Data
Connection
Target
Volume
*CAB: Cluster-Aware Backup
VSERVER-AWARE NDMP
Clustered Data ONTAP now enables NDMP to function at the Vserver level. Resources, including FlexVol
volumes, can be backed up, restored, and scoped. Vserver-aware backups are critical for implementing multi-
tenancy.
For NDMP to be aware of a Vserver, the NDMP data management application software must be enabled with
cluster-aware backup (CAB) extensions, and the NDMP service must be enabled on the Vserver. After the
feature is enabled, you can back up and restore all volumes that are hosted across all nodes in the Vserver. An
NDMP control connection can be established on different LIF types. An NDMP control connection can be
established on any data or intercluster LIF that is owned by a Vserver that is enabled for NDMP and owns the
target volume. If a volume and tape device share the same affinity, and if the data-management application
supports the cluster-aware backup extensions, then the backup application can perform a local backup or
restore operation and, therefore, you do not need to perform a three-way backup or restore operation.
Vserver-aware NDMP user authentication is integrated with the role-based access control mechanism. For
more information about Vserver-aware NDMP and cluster-aware backup extensions, see the Clustered Data
ONTAP Data Protection Tape Backup and Recovery Guide.
Configuring for NDMP
1. Enable and configure NDMP on the node or nodes:
cluster1::> system services ndmp modify
2. Identify tape and library attachments:
cluster1::> system node hardware tape drive
show
cluster1::>system node hardware tape library
show
3. Configure the data management application (such as
Symantec NetBackup) for NDMP.
NOTE: The smallest backup level is the volume.
CONFIGURING FOR NDMP

Enabling or disabling NDMP on a node is simple. You must enable NDMP on each node in the cluster that
will be used for backups (probably all of them). The NDMP data management application uses the NDMP
user name and password that you choose during this configuration.
You must know the tape drive and library paths to configure the data management application.
Clustered Data ONTAP and NDMP
 Clustered Data ONTAP supports the Symantec
NetBackup and IBM Tivoli Storage Manager (TSM)
data management applications, and more are being
added.
 Clustered Data ONTAP supports local NDMP, remote
NDMP, and three-way NDMP backup.
 A data management application with DAR can restore
selected files without sequentially reading entire
tapes.
CLUSTERED DATA ONTAP AND NDMP

Forms of NDMP backup:
 Local NDMP: Data is backed up directly from the storage system (a node, in this case, not a cluster) to a
locally attached (or SAN-attached) tape device.
 Remote NDMP: Data is transported from the storage system to the data management application server.
The server is attached to a tape device and backs up the data to the tape device.
 Three-way NDMP: Data is transported from the storage system to another storage system that has a
locally attached (or SAN-attached) tape device.
Direct Access Recovery (DAR) is the ability of a data management application to restore a selected file or
selected files without the need to sequentially read the entire tape or tapes that are involved in a backup. For
example, if a large backup spans four 100-GB tapes, and the one file that you want to restore is on the fourth
tape, a non-DAR restoration reads the first three tapes in their entirety and then all of the fourth tape up to the
point that it finds the target file. With DAR, the data management application reads some information from
the first tape and then goes directly to the appropriate spot on the fourth tape.
Local, Remote, and Three-Way NDMP
LAN
Remote NDMP
NDMP Backup
Hosts
VERITAS
NetBackup
Server
Local Three-Way
Backup Backup
Tape Drive
Automated Automated
Tape Library Tape Library
LOCAL, REMOTE, AND THREE-WAY NDMP
A Six-Node Cluster with Data-Protection
Mirror Backups
Cluster Network
Compute Farm
SATA Storage
and
Data-Protection
Mirror Copies
Data Network
Tape Library
A SIX-NODE CLUSTER WITH DATA-PROTECTION MIRROR BACKUPS

If a customer can afford to dedicate some nodes to data protection (rather than to serving data to clients), the
customer has an excellent way to protect data. Data-protection nodes are members of the cluster, but their
aggregates consist of slower and denser disks. Data can be mirrored from the other nodes to these nodes and
then backed up from these nodes by using local NDMP, which alleviates the need for tape devices to be
connected to the other nodes. Benefits of this technique include the following:
 Data-protection mirror copies don’t need to move (or need to move only rarely), which alleviates one
source of headaches for backup administrators.
 Fewer NDMP licenses are needed, which can result in considerable cost savings.
 Fewer nodes must be backed up, which helps backup administrators.
 Nonbackup nodes can use their CPUs and resources for client access.
If these “disaster-recovery” nodes are not used for client access, they don’t need data LIFs and can reassign
those data network ports to be used for cluster network ports for a larger cluster “pipe.”
Lesson 3
LESSON 3
SnapMirror Data Protection
Create
Intracluster or intercluster replication (TR-4015)
Primary Disaster Recovery

Data Center Data Center
R WAN
R
A B B
dp
Create Volume for Mirror (on disaster recovery Vserver):

volume create –vserver vserver -volume datavolume_dp -aggr <aggrname>
-size <equal to datavolume_A size> -type dp
Create Mirror (from disaster recovery site):
snapmirror create -destination-path DR://vserver/datavolume_dp
-source-path PRI://vserver/datavolume_A
NOTE: A cluster peer relationship must be created for intercluster replication.
SNAPMIRROR DATA PROTECTION: CREATE

The -type dp argument automatically puts the volume in restricted mode and is required. You cannot
modify an RW volume type (default) to a DP type. The slides work with either intracluster or intercluster
relationships. The peer relationship, intercluster LIFs (and intercluster ports, if required) must also be created
for intercluster SnapMirror.
Mirrors can be intracluster (within the cluster) or intercluster (to a peer cluster). No replication is currently
available between clustered Data ONTAP and Data ONTAP 7-Mode.
No support for:
 Cascading
 Vserver level management
 Vserver disaster recovery
All data-protection mirrors require licenses on source and destination clusters.
Intercluster SnapMirror requires a peer cluster relations configuration.
Scheduling must also be configured. This is part of the SnapMirror creation wizard when you use System
Manager (recommended).
You can find more details in TR-4015 and the Data Protection Guide.
Because intercluster LIFs are node scoped, intercluster LIFs cannot fail over to other nodes in the cluster. If
you use intercluster ports, then intercluster LIFs can fail over to other intercluster ports on the same node. If
intercluster LIFs are assigned to data ports, then intercluster LIFs can fail over to any data port on the same
node.
Initialize and Update
Primary DR
R WAN R
A B dp B
Initialize Mirror – Baseline Transfer (from DR site):

snapmirror initialize -destination-path
DR://vserver/datavolume_dp -source-path
PRI://vserver/datavolume_A
Update Mirror – Incremental Transfers (from DR site):
snapmirror update -destination-path
DR://vserver/datavolume_dp -source-path
SNAPMIRROR DATA PROTECTION: INITIALIZE AND UPDATE

Create, initialize, and update separately with data-protection mirrors. Using the initialize command on
a data-protection mirror before creating the mirror will result in a “mirror has not been created” error.
With LS mirrors, using an update command alone creates the mirror, initializes the mirror (creates a
baseline) and updates the mirror incrementally. Using the initialize command on LS mirrors also
creates the mirror and then initializes it.
The initialize and update commands work differently in LS and data protection. A data-protection
mirror must be created before it can be initialized or updated. The initialize and update commands
must be run from the destination cluster.
Failover Considerations
 SnapMirror does not replicate the Vserver namespace
junction path information.
 Because the NAS volumes have no junction path,
they will not be accessible after a SnapMirror break
occurs unless they are premounted before failover, or
until they are mounted after failover.
 The security style and permissions on the destination
Vserver root volume must be set correctly or the
namespace might be inaccessible after failover.
 Use the Cluster Config Dump Tool to collect and
replicate system configuration settings to a disaster
recovery site.
FAILOVER CONSIDERATIONS
Currently, failover is a manual task. If there are multiple volumes in the namespace, failover will have to
repeated for each volume.
The Cluster Config Dump Tool (http://communities.netapp.com/thread/17921) is a Java-based
Windows/Linux/Mac utility that collects configuration information.
The tool stores information that is needed in a disaster recovery scenario:
 Volume junction paths
 NFS export policies, CIFS shares information
 Snapshot and storage efficiency policies
 LUN mapping information
Run the tool locally and replicate, or run it remotely.
The tool does not restore a configuration.
Disaster
Primary DR
R
WAN
B R
A B
dp
Break Mirror (from DR) – Make destination writeable:

snapmirror break -destination-path
DR://vserver/datavolume_dp
NOTE: Admin must redirect the clients (or host) of the source
volume on the primary site to the new source volume at the DR
site in a disaster situation.
SNAPMIRROR DATA PROTECTION: DISASTER

Breaking the mirror relationship does not delete the relationship; it only stops the updates to the mirror and
makes the mirrored volume writable. You can then redirect the clients to access the disaster-recovery site
mirrored volume.
Disaster Considerations
 LUNs should be mapped after failover.

 CIFs shares or NFS exports must be created
(or verified).
 Assign Snapshot schedules.
 Assign storage efficiency policies.
DISASTER CONSIDERATIONS
Currently, breaking the mirror relationship and redirecting clients this is a manual task. If there are multiple
volumes in the namespace, the steps are repeated for each volume.
Recovery Scenario A―Dev/Test Recovery
Primary DR
R
WAN
R
A B B
dp
Resync Mirror (From DR) – Resume relationship:

snapmirror resync -destination-path
NOTE: All “new” data written to the destination after the break will
be deleted.
SNAPMIRROR DATA PROTECTION:

RECOVERY SCENARIO A―DEV/TEST RECOVERY
Recovery Scenario B―Source Is Recoverable
Primary DR
R
WAN
R
A B B
dp
Delete Mirror (From DR) – Remove Relationship:

snapmirror delete -destination-path
NOTE: You must delete the mirror to change source to

destination for resync.

RECOVERY SCENARIO B―SOURCE IS RECOVERABLE
Volumes in clustered Data ONTAP can be only a source or a destination, not both. A source can be a source
for many destinations (fan out), but can not cascade. If the data in the source volume is recoverable, and the
data is still intact, you might have a considerable amount of new data on the destination that you do not want
deleted. To prevent a complete rebaseline (deletion of new data), you must delete the mirror relationship first.
Recovery Scenario B―Change Relationship
Primary DR
R
WAN
R
A B B
dp
Create a new relationship with DR as source:

snapmirror create -destination-path
-source-path DR://vserver/datavolume_dp
Resync the mirror (From DR) – Copy new data to Primary (no re-
baseline):
snapmirror resync -destination-path
PRI://vserver/datavolume_A -source-path

RECOVERY SCENARIO B―CHANGE RELATIONSHIP
In this scenario, no baseline would be required because a common snapshot is available. Only changed blocks
would be sent. To go back to the original relationship, follow steps on the previous slide.
After deleting the original SnapMirror relationship, you can create a new relationship (switching the roles).
The disaster recovery version will now be the source, and the primary will now be the destination. To prevent
a complete baseline, use the resync command instead of the initialize command. This will find the
common snapshot and copy to the primary site only the changes that were made to the disaster-recovery site.
You can keep this relationship if desired. Otherwise, you will need to follow steps outlined in the Data
Protection Guide.
Recovery Scenario C―Source Is Unrecoverable
Primary DR
R
WAN
R
A B B
dp
 Create a new volume on the source

 Create a new relationship with disaster recovery as the source
 Initialize the mirror (rebaseline required)

RECOVERY SCENARIO C―SOURCE IS UNRECOVERABLE
If the volume is corrupted or unrecoverable, you must create a new volume and relationship. You must re-
initialize the mirror, which will require a complete rebaseline.
As with Scenario B, you can keep this relationship if desired. Otherwise, follow the steps outlined in the Data
Protection Guide.
RDB Disaster Recovery
 The replicated database (RDB) cannot be

backed up.
 As long as one node survives, a copy of the
RDB is available and propagates itself to
reconstructed nodes.
 If all nodes are destroyed, the RDB data is
destroyed.
RDB DISASTER RECOVERY
Module Summary
Now that you have completed this module, you

should be able to:
 Configure and replicate to SnapVault backups
 Answer questions about NDMP backup
 Discuss disaster recovery in a clustered
environment
MODULE SUMMARY
Exercise
Module 13: Data Protection:
Backups and Disaster Recovery
Time Estimate: 30 minutes
EXERCISE
Please refer to your exercise guide.

13 DataProtectionB&DR SG

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

13 DataProtectionB&DR SG

Uploaded by

Copyright:

Available Formats

Module 13

Data Protection: Backups and

MODULE 13: DATA PROTECTION: BACKUPS AND DISASTER RECOVERY

After this module, you should be able to:

SNAPVAULT SOFTWARE FOR CLUSTERS

 Reduction of backup times from hours to days

 SnapVault was added to the SnapMirror

USE SNAPMIRROR COMMANDS

 DP: asynchronous data protection mirror

SNAPMIRROR COMMANDS FOR SNAPVAULT

default-1weekly 3 true Default policy with 6 hourly, 2

SNAPSHOT POLICY ON THE SOURCE VOLUME

STEPS FOR CREATING A SNAPVAULT RELATIONSHIP ON THE DESTINATION

SnapMirror to SnapVault SnapVault to SnapMirror

Using the snapmirror restore command you:

cluster1::> snapmirror restore

THE SNAPMIRROR RESTORE COMMAND

SnapMirror Functions SnapVault Functions

SnapMirror provides data protection SnapVault accumulates copies of the

SnapMirror can asynchronously copy If the source FlexVol volume is lost,

COMPARING SNAPVAULT TO SNAPMIRROR

SMTAPE TO SEED BASELINES

BACKUP AND RESTORATION WITH NDMP

Data or Intercluster LIF

*CAB: Cluster-Aware Backup

NOTE: The smallest backup level is the volume.

CONFIGURING FOR NDMP

CLUSTERED DATA ONTAP AND NDMP

LOCAL, REMOTE, AND THREE-WAY NDMP

A SIX-NODE CLUSTER WITH DATA-PROTECTION MIRROR BACKUPS

Primary Disaster Recovery

Create Volume for Mirror (on disaster recovery Vserver):

NOTE: A cluster peer relationship must be created for intercluster replication.

SNAPMIRROR DATA PROTECTION: CREATE

Initialize Mirror – Baseline Transfer (from DR site):

SNAPMIRROR DATA PROTECTION: INITIALIZE AND UPDATE

Break Mirror (from DR) – Make destination writeable:

SNAPMIRROR DATA PROTECTION: DISASTER

 LUNs should be mapped after failover.

Resync Mirror (From DR) – Resume relationship:

SNAPMIRROR DATA PROTECTION:

Delete Mirror (From DR) – Remove Relationship:

NOTE: You must delete the mirror to change source to

SNAPMIRROR DATA PROTECTION:

Create a new relationship with DR as source:

SNAPMIRROR DATA PROTECTION:

 Create a new volume on the source

SNAPMIRROR DATA PROTECTION:

 The replicated database (RDB) cannot be

RDB DISASTER RECOVERY

Now that you have completed this module, you

You might also like