Cloning: Emc Networker

EMC® NetWorker®
Cloning
Release 7.6 Service Pack 2
Integration Guide
P/N 300-012-451
REV A01
EMC Corporation
Corporate Headquarters:
Hopkinton, MA 01748-9103
1-508-435-1000
www.EMC.com
Copyright © 2011 EMC Corporation. All rights reserved.
Published May, 2011
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO
REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION,
AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
For the most up-to-date regulatory document for your product line, go to the Technical Documentation and Advisories section
on EMC Powerlink.
For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.
2 EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide

Contents
Preface
Chapter 1 Introduction
Revision history ...................................................................................................... 12
Cloning integration feature ................................................................................... 12
Staging integration feature .................................................................................... 13
Benefits of cloning and staging............................................................................. 13
Additional data protection.............................................................................. 14
Performance ...................................................................................................... 14
Storage optimization ........................................................................................ 14
Licensing .................................................................................................................. 15
Version requirements.............................................................................................. 15
NetWorker components ......................................................................................... 16
NetWorker server ............................................................................................. 16
NetWorker clients............................................................................................. 16
Storage node...................................................................................................... 16
NetWorker Management Console ................................................................. 17
Volumes ............................................................................................................. 17
Pools ................................................................................................................... 17
Save sets ............................................................................................................. 17
NetWorker repositories ................................................................................... 18
Cloning example ..................................................................................................... 19
Staging data example ............................................................................................. 20
Chapter 2 Planning and Practices

Cloning requirements............................................................................................. 22
Cloning policy ......................................................................................................... 22
Deciding when to clone ................................................................................... 22
About clone pools............................................................................................. 23
Save sets ............................................................................................................. 24
Clone attributes................................................................................................. 24
Multiplexed backups........................................................................................ 24
Consider the application........................................................................................ 27
Consider the recovery scenario............................................................................. 27
Consider the browse and retention policies........................................................ 27
Browse policy .................................................................................................... 28
Retention policy ................................................................................................ 29
EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide 3

Contents
Chapter 3 Cloning Procedures

Cloning data............................................................................................................. 32
NetWorker release 7.6 SP1 and later .............................................................. 32
NetWorker releases prior to 7.6 SP1............................................................... 32
Cloning options ....................................................................................................... 32
Automated cloning ................................................................................................. 33
Configuring auto-clone .................................................................................... 33
Schedule cloning ..................................................................................................... 35
Scheduling clone operations............................................................................ 36
Starting scheduled clone operations manually ............................................ 38
Monitoring scheduled clone operations ........................................................ 39
Viewing the clone status of a save set............................................................ 39
Volume cloning ........................................................................................................ 39
Save set cloning ....................................................................................................... 39
Scripted cloning....................................................................................................... 41
NetWorker 7.6 Service Pack 1 enhancements ............................................... 41
NetWorker 7.5 enhancements ......................................................................... 42
nsrclone option descriptions ........................................................................... 42
Using the nsrclone options .............................................................................. 43
Using the nsrclone command to specify a browse and retention policy .. 43
Cloning archived data ............................................................................................ 44
Scheduling a clone session for archive data.................................................. 44
Cloning an archive volume manually............................................................ 44
Considerations to improve cloning performance............................................... 45
Cloning validation .................................................................................................. 45
Displaying the backup versions in the GUI ........................................................ 46
Chapter 4 Software Configuration

Filesystem configuration ........................................................................................ 48
Storage nodes........................................................................................................... 49
Determining the read and write source......................................................... 50
Criteria for reading the clone data.................................................................. 51
Criteria for writing the clone........................................................................... 51
Directing a clone from one storage node to another storage node............ 52
Directing clones from all storage nodes to a single storage node.............. 52
Criteria for recovering cloned data ................................................................ 52
Cloning with tape devices ............................................................................... 53
Cloning with file type and AFTD devices..................................................... 54
Differences in the cloning process .................................................................. 54
Manual cloning with advanced file type device .......................................... 54
Cloning with EMC Avamar (deduplication node) ............................................. 55
Backup-to-tape for Avamar deduplication clients....................................... 55
Cloning with Data Domain (DD Boost) ............................................................... 56
Clone formats .................................................................................................... 56
Clone requirements .......................................................................................... 57
Cloning by pools ............................................................................................... 58
Cloning with EMC Disk Library using an embedded storage node ............... 58
Storage node selection...................................................................................... 61
Environments with multiple storage nodes.................................................. 61
Cloning node affinity for all disk library virtual tape libraries.................. 61
Production storage node cloning of data to physical tape ................................ 62

Contents
Chapter 5 NetWorker Module for Microsoft Applications

Cloning with NetWorker Module for Microsoft Applications......................... 64
NMM media database records ....................................................................... 65
NMM client file index ...................................................................................... 65
NMM save sets........................................................................................................ 65
Cover save set ................................................................................................... 66
Rollover save set ............................................................................................... 66
Metadata save set.............................................................................................. 67
Display save set................................................................................................. 67
Dummy save set for Microsoft Exchange 2007 and Microsoft Exchange 2010
only ..................................................................................................................... 67
Snap session ID ................................................................................................. 68
Examples of NMM save sets ................................................................................. 68
A single NetWorker client resource in the NetWorker group................... 68
NMM save set example with a NetWorker group ...................................... 70
Identifying NMM save sets ................................................................................... 72
Cloning using NMM .............................................................................................. 72
Automated cloning........................................................................................... 72
Save set cloning................................................................................................. 73
Scheduled clone ................................................................................................ 74
Volume cloning................................................................................................. 76
Scripted cloning ................................................................................................ 77
Validating a clone operation.................................................................................. 79
Recovering cloned save sets .................................................................................. 80
Recovery scenarios ........................................................................................... 80
Required save sets and volumes for recovery of cloned data.................... 82
Save set requirements ...................................................................................... 87
Configuration considerations ......................................................................... 91
Recovery tasks................................................................................................... 96
Restoring save sets that are not in the media database............................. 101
Troubleshooting NMM clone operations .......................................................... 108
Rollover save set restore fails with error..................................................... 108
Validate rollover and cover save sets .......................................................... 108
Unable to read metadata save set................................................................. 109
Unable to restore rollover save set............................................................... 109
Failure to restore cover save sets.................................................................. 110
Chapter 6 NetWorker Module for Databases and Applications

NMDA save set bundling .................................................................................... 112
NetWorker staging restrictions .................................................................... 113
Save set bundling with NMDA .................................................................... 113
Save set bundling information in the media database.............................. 114
NMDA policy uniformity.................................................................................... 115

Contents
Chapter 7 Recovering Data from Clones

Clones recovery ..................................................................................................... 118
Recovery scenarios................................................................................................ 118
Browse and retention periods ....................................................................... 118
Required save sets and volumes for recovery of cloned data ........................ 120
Generating a media database listing of all of the save sets....................... 120
Determining the status of a save set in the media database ..................... 121
Save set requirements..................................................................................... 121
Selecting clone volumes to recover data from ............................................ 123
Recovery tasks ....................................................................................................... 124
Restoring cloned data that is browsable in the client file index............... 124
Restoring recoverable save sets to the client file index ............................. 126
Restoring recyclable save sets to the client file index ................................ 128
Restoring save sets that are not in the media database ............................. 130
Chapter 8 Staging
Staging overview................................................................................................... 136
Staging example .............................................................................................. 136
The destination ...................................................................................................... 137
Working with staging policies............................................................................. 137
Creating a staging policy ............................................................................... 137
Editing a staging policy.................................................................................. 139
Copying a staging resource ........................................................................... 139
Deleting a staging policy................................................................................ 140
Staging from the NetWorker Management Console ........................................ 140
Staging from the command line .......................................................................... 140
Finding the clone ID of a save set ................................................................. 140
Glossary

Preface
As part of an effort to improve and enhance the performance and capabilities of its product
lines, EMC periodically releases revisions of its hardware and software. Therefore, some
functions described in this document may not be supported by all versions of the software or
hardware currently in use. For the most up-to-date information on product features, refer to
your product release notes.
If a product does not function properly or does not function as described in this document,
please contact your EMC representative.
Note: This document was accurate as of the time of publication. However, as information is
added, new versions of this document may be released to the EMC Powerlink website. Check
the Powerlink website to ensure that you are using the latest version of this document.
Audience This document is part of the EMC NetWorker documentation set, and is intended for
use by system administrators. It contains planning, practices, and configuration
information for using the NetWorker cloning feature.
Readers of this document should be able to perform the following tasks:
◆ Identify the different hardware and software components that comprise the
NetWorker datazone.
◆ Follow procedures to configure storage management operations.
◆ Follow guidelines to locate problems and implement solutions.
This guide has been written for NetWorker release 7.6.2 unless specified otherwise.
NetWorker product documentation

Documentation related to the use of NetWorker software can be found at the EMC
Powerlink website, http://Powerlink.EMC.com, including:
◆ EMC NetWorker Release 7.6 Service Pack 2 Installation Guide provides instructions
for installing or updating the NetWorker software for clients, console, and server
on all supported platforms.
◆ EMC NetWorker Release 7.6 Service Pack 2 Cluster Installation Guide contains
information related to installation of the NetWorker software on cluster servers
and clients.
◆ EMC NetWorker Release 7.6 Service Pack 2 Administration Guide describes how to
configure and maintain the NetWorker software.

Preface
◆ EMC NetWorker Release 7.6 Service Pack 2 Release Notes contain information on new
features and changes, fixed problems, known limitations, environment, and
system requirements for the latest NetWorker software release.
◆ EMC NetWorker Licensing Guide provides information about licensing NetWorker
products and features.
◆ EMC NetWorker License Manager 9th Edition Installation and Administration Guide
provides installation, setup, and configuration information for the NetWorker
License Manager product.
◆ EMC NetWorker 7.6 Service Pack 2 Error Message Guide provides information on
common NetWorker error messages.
◆ EMC NetWorker 7.6 Service Pack 2 Command Reference Guide provides reference
information for NetWorker commands and options.
◆ EMC NetWorker Management Console Online Help describes how to perform the
day-to-day administration tasks in the NetWorker Management Console and the
NetWorker Administration window.
◆ EMC NetWorker User Online Help describes how to use the NetWorker User
program, which is the Microsoft Windows client interface for the NetWorker
server, to back up, recover, archive, and retrieve files over a network.
NetWorker related documentation

The following documentation resources provide more information about NetWorker
software:
◆ EMC Information Protection Software Compatibility Guide provides a list of client,
server, and storage node operating systems supported by the EMC information
protection software versions.
◆ EMC E-Lab™ Issue Tracker database offers online queries of NetWorker known
problems and fixed bugs that are searchable by such details as issue number,
product feature, host operating system, and fixed version.
◆ NetWorker Procedure Generator (NPG) is a downloadable Microsoft Windows
application with periodic updates that are available to NetWorker customers and
support staff. By means of user-selectable prompts, NPG tailors single-focused
documents from high-demand information drawn from the NetWorker product
guides and the latest advice supplied by expert users.
◆ Technical notes and white papers provide in-depth technical reviews of products
regarding business requirements, applied technologies, and best practices.
These resources are available at http://Powerlink.EMC.com. You must have a service
agreement to use the Powerlink website.

Preface
Conventions used in this document

This document uses the following conventions for special notices.
Note: A note presents information that is important, but is not hazard-related.
IMPORTANT
An important notice contains information essential to software or hardware
operation.
Typographical conventions
EMC uses the following type style conventions in this document:
Normal Used in running (nonprocedural) text for:

• Names of interface elements (such as names of windows, dialog boxes,
buttons, fields, and menus)
• Names of resources, attributes, pools, Boolean expressions, buttons, DQL
statements, keywords, clauses, environment variables, functions, utilities
• URLs, pathnames, filenames, directory names, computer names, links, groups,
service keys, filesystems, notifications
Bold Used in running (nonprocedural) text for:

• Names of commands, daemons, options, programs, processes, services,
applications, utilities, kernels, notifications, system calls, man pages
Used in procedures for:

• Names of interface elements (such as names of windows, dialog boxes,
buttons, fields, and menus)
• What user specifically selects, clicks, presses, or types
Italic Used in all text (including procedures) for:

• Full titles of publications referenced in text
• Emphasis (for example a new term)
• Variables
Courier Used for:

• System output, such as an error message or script
• URLs, complete paths, filenames, prompts, and syntax when shown outside of
running text
Courier bold Used for:

• Specific user input (such as commands)
Courier italic Used in procedures for:

• Variables on command line
• User input variables
<> Angle brackets enclose parameter or variable values supplied by the user
[] Square brackets enclose optional values
| Vertical bar indicates alternate selections - the bar means “or”
{} Braces indicate content that you must specify (that is, x or y or z)
... Ellipses indicate nonessential information omitted from the example

Preface
Where to get help EMC support, product, and licensing information can be obtained as follows.
Product information — For documentation, release notes, software updates, or for
information about EMC products, licensing, and service, go to the EMC Powerlink
website (registration required) at:
http://Powerlink.EMC.com
Technical support — For technical support, go to Powerlink and select Support. On

the Support page, you will see several options, including one for making a service
request. Note that to open a service request, you must have a valid support
agreement. Please contact your EMC sales representative for details about obtaining a
valid support agreement or with questions about your account.
Your comments Your suggestions will help us continue to improve the accuracy, organization, and
overall quality of the user publications. Please send your feedback to:
BSGdocumentation@emc.com
If you have issues, comments, or questions about specific information or procedures,
please include the title and, if available, the part number, the revision (for example,
A01), the page numbers, and any other details that will help us locate the subject that
you are addressing.

1
Introduction
This chapter includes the following sections:

◆ Revision history............................................................................................................. 12
◆ Cloning integration feature.......................................................................................... 12
◆ Staging integration feature .......................................................................................... 13
◆ Benefits of cloning and staging ................................................................................... 13
◆ Licensing......................................................................................................................... 15
◆ Version requirements .................................................................................................... 15
◆ NetWorker components ............................................................................................... 16
◆ Cloning example ........................................................................................................... 19
◆ Staging data example.................................................................................................... 20
Introduction 11
Introduction
Revision history
The following table lists the revision history of this document.
Revision Date Description of added or changed sections
A01 May 16, 2011 Initial publication of this document.
Cloning integration feature

Cloning is a feature of the EMC® NetWorker® software that allows for secure offsite
storage and the transfer of data from one location to another. It provides the ability to
create a copy of a save set from one volume to another volume.
A NetWorker clone operation can be performed at the following levels:
◆ Save set
◆ Volume
◆ Pool
Further selection criteria can also be used to specify particular types of data or clients.
Although the clone operation creates a copy of the original backup data, it is not an
exact copy since only the data within the backup is an exact copy. Some metadata is
changed so that the clone copy can be managed as a separate and independent copy
from the original. This capability allows the clone copy to be used for subsequent
operations without any dependency to the original.
Multiple clone copies can be created so that a backup can be protected against
corruption, local damage, site disaster, or loss. Cloning also provides a mechanism
that can be used to move data from one storage type to another. For example, for
offsite storage you can move data from disk to tape.
Clone operations can be configured to be run by:
◆ Automatic start (auto-clone)
◆ A schedule
◆ A customized script
Information about the volumes, status, and history of cloning operations can be
viewed and monitored from the NetWorker Administration window. Clone-related
messages are also logged to the NetWorker message file and the savegrp log file,
which are located in the NetWorker_install_dir\logs directory.

Introduction
Staging integration feature

NetWorker staging is a separate process but it relies on the cloning mechanism. Save
set staging is the process of transferring data from one storage medium to another
medium, and then removing the data from its original location. Staging is only
supported for data that resides on disk-type devices.
A save set can be staged from one disk to another as many times as required. For
example, a save set can be staged from disk 1, to disk 2, to disk 3, and finally to a
remote tape device or cloud device. Once the save set is staged to a tape or cloud
device, it cannot be staged again. However, you can clone the tape or cloud volume.
Staging can be driven by any of the following processes:
◆ Calendar-based process, such as keeping the save set for 30 days on the staging
device before moving the data to the next device.
◆ Event-based process, such as when available space in the staging pool drops
below a set threshold. When this happens, the oldest save sets are moved until
available space reaches a preset upper threshold.
◆ Administrator-based process, such as allowing the administrator to either reset
the threshold or manually select save sets to stage.
Staging does not affect the retention policy of backup data. Therefore, staged data is
still available for recovery.
When the stage process encounters an error after successfully cloning specified save
sets, it deletes only those successful save sets from the source volume before the
program is stopped. This ensures that after staging, only a single set of save sets exists
in either the source volumes or clone volumes.
Benefits of cloning and staging

While there may be multiple reasons to choose to clone or stage data, in most cases it
is usually driven by the following main objectives:
◆ Additional data protection
◆ Performance
◆ Storage optimization
A NetWorker cloning operation is performed only after a successful backup which
provides the following benefits:
◆ Allows the backup process to complete at maximum performance without any
impact to speed due to multiple write acknowledgements, delays, or retries on
one or more devices. Cloning limits the impact to the client, while providing data
protection as quickly as possible.
◆ Ensures that the backup is successful, that the data is valid, and that the clone
operation will complete successfully.
◆ Ensures that the storage requirements have been determined and that the
appropriate storage is made available.
Staging integration feature 13

Introduction
◆ Allows cloning to be scheduled and prioritized outside of the backup window

when resources are less constrained.
◆ Reduces the load on the backup infrastructure.
◆ Allows for recoveries to be initiated easily because the backup operation has
already completed.
Note: You cannot use the NetWorker software to create an instant clone by writing to two
devices simultaneously. This operation is also referred to as parallel cloning, twinning, or inline
copy. Where parallel cloning or twinning is required, consider using the NetWorker cloning
feature. Using cloning will help ensure that the initial backup completes successfully.
Additional data protection can also be implemented by using the optimum devices and
bandwidth available for the backup environment.
Additional data protection

By creating a clone of the backup data you can achieve the following two goals:
◆ Validate that the original backup data can be read successfully which provides
additional assurance that the data can be recovered. It also validates that the
media where the backup resides is intact.
◆ With cloning, multiple copies of the data are available. One copy can be shipped
offsite for vaulting which provides faster data rates than backing up directly to
tape. This copy can be made available for recovery at the original site or offsite.
Performance
Performance is one benefit of staging. Data is backed up to near-line storage which is
usually a backup-to-disk. The data can then be migrated to tape later based on
staging policy settings for the disk device.
Storage optimization
The storage device that is used for the initial backup is often a compromise between a
number of factors which include the following:
◆ Location
◆ Availability
◆ Capacity
◆ Speed
◆ Cost
As a result, the backup data on the initial storage device is unlikely to be on the ideal
or optimum storage for the entire duration of the data’s retention period.
Cloning and staging can help to use the storage devices more effectively by moving
data between different types of devices. This ability provides the following benefits:
◆ Backups that are stored on local tape devices can be copied to other devices in
remote locations without impact to the initial backup performance.
◆ Backups from disk devices can be copied to tape to facilitate offsite or long term
storage.

Introduction
By moving data from disk to tape, you can use the storage capacity more effectively.
The use of a deduplicated disk allows the initial storage space to be reclaimed for new
backups.
Once backups have been cloned to other storage devices, the original backups can be
deleted. This allows for the following:
◆ New backups can be written to the disk device since the initial storage space can
be reclaimed for new backups.
◆ Multiple service levels can be accommodated:
• The most recent backups may remain on one storage device for fast recovery.
• Other backups may be moved to more cost effective, slower storage for less
demanding recovery needs.
Tape
Tape is still the most commonly used backup storage medium and the following
issues might be encountered when using it:
◆ Difficulty in accessing the data
◆ Reliability of the tape device
◆ Reliability of the robotic changing mechanisms
◆ Requirement of a long backup window
Note: Use backup-to-disk where high performance backups are required within a short backup
window. The data can be staged to tape for longer term retention.
Disk devices
Disk devices are becoming more cost effective and offer advantages when
deduplicating and replicating data. However, disk devices have limited capacity and
can sometimes require considerable effort.
Licensing
In most cases, the functionality used for cloning or staging is incorporated into the
existing NetWorker base product and requires no additional licenses or enablers.
However, there are some devices that offer additional functionality and these might
require additional licenses and enablers in order for this functionality to be used for
cloning or staging, or for additional capacity to be made available.
To ensure that the appropriate capacity and functionality licensing is applied and
enabled for the devices that are being used, refer to the EMC NetWorker Licensing
Guide.
Version requirements
NetWorker client and servers that support cloning should meet the following version
requirements:
◆ NetWorker server must be installed with NetWorker 7.6 Service Pack 1 (SP1) or
later software.
◆ NetWorker Management Console (NMC) must be release 7.6 SP1 or later.
Licensing 15
Introduction
NetWorker components
The NetWorker software has a number of components that allow for flexibility in the
deployment of NetWorker datazone configurations. It allows for the scaling of data
and the number of clients it supports.
The section includes the following topics:
◆ “NetWorker server” on page 16
◆ “NetWorker clients” on page 16
◆ “Storage node” on page 16
◆ “NetWorker Management Console” on page 17
◆ “Volumes” on page 17
◆ “Pools” on page 17
◆ “Save sets” on page 17
◆ “NetWorker repositories” on page 18
NetWorker server
The NetWorker server is the main component that manages the other components
that comprise the backup infrastructure.
A datazone is comprised of a NetWorker server and the group of components and
client data that the server manages. A customer site may have one or multiple
datazones depending on the size, distribution, and departmental organization.
NetWorker clients
NetWorker clients are computers, workstations, or files servers whose data can be
backed up and restored with the NetWorker software. Each NetWorker client requires
that the NetWorker software be installed and that the client is configured on the
NetWorker server. The software also enables interaction with the NetWorker
Application Modules.
In some cases, additional software is also installed that allows for local storage
devices and dedicated storage nodes.
Storage node
The NetWorker storage node is a system that has a NetWorker storage device
attached and is able to store backup data.
The storage node can be one of two types:
◆ Shared storage node (standard)
The shared storage node is able to receive data from multiple sources and to share
its storage capabilities.

Introduction
◆ Dedicated storage node

A dedicated storage node is restricted or dedicated to a single client and does not
allow its storage to be used by other clients. In most cases, shared storage nodes
should use dedicated systems so that the IO capabilities can be fully used.
However, it is possible for the storage node to reside on systems that have other
duties.
By default, the NetWorker server must be a storage node to secure its own
backups. In certain small environments, you can use the NetWorker server as a
shared storage node for all backup client data.
Note: Use dedicated systems for shared storage nodes and to direct all client data to the
dedicated storage node.
NetWorker Management Console

NetWorker Management Console (NMC) provides the graphical user interface and
services necessary to manage the administration of the NetWorker software, monitor
backup and restore activities, and report backup events. This separate software
package is able to communicate with the NetWorker server.
In small environments, it is typically installed together with the NetWorker server.
Although for larger environments, NMC may be installed on its own or on a separate
system.
With the NMC, you can configure, monitor, and report on activities in real time.
Volumes
NetWorker devices use data volumes to store and manage the backup data.
Every volume must belong to a pool which allows multiple volumes to be used. In
the case of tape cartridges, this procedure ensures that the correct volume and the
storage node are always used.
Pools
A pool can be used to group the backups together so that data of a similar type or
profile can be stored together. For example, you can create a pool for Sunday Full
backups.
Pools also allow data to be directed to specific storage nodes or locations which help
to organize the data for optimum storage and recovery and are used during cloning
sessions.
Save sets
The backup data consists of one of more save sets in a single session or thread of data
that has been generated by a NetWorker client of a NetWorker module. A save set
contains at least one file which is located on a NetWorker volume.
NetWorker components 17
Introduction
Save set attributes provide the following information:

◆ Where the data originated
◆ Type of backup the save set contains
◆ Type of save set it is
◆ Date the save set was created
◆ Date the save set will expire
◆ Date the associated index will expire (browse expiration)
◆ Location of the data
These attributes allow the NetWorker software to ensure that the data is managed
according to the policies and configuration settings applied. You can determine the
status and type of the save set.
These attributes also allow you to determine:
◆ What has been cloned
◆ What needs to be cloned
◆ Status of the clone operation
◆ Status of the backup
NetWorker repositories
NetWorker software uses two separate repositories to manage data that has been
backed up by using the save command. The following repositories record metadata
irrespective of NetWorker client, NetWorker module, or data type:
◆ Media database
◆ Client file index
Media database
Information on the save set is stored in the media database. This database contains all
of the records for all of the save sets that are currently under the control of the
NetWorker software, and that have the potential to be used for recovery purposes.
The media database provides the following information:
◆ Location (volume) of the save set
◆ Size of the save set
◆ Offset within the volume
The media database contains limited details on what is inside the save set. The names
and attributes of the files within the save set are stored in separate client indexes.
Unlike client indexes, media database entries are relatively small and require only a
small amount of space for each save set. As such, the disk space requirements for the
media database are generally small and disk size is dependent on the number of
volumes and save sets.
Client index
There is a separate client index repository for each unique NetWorker client
configured with the NetWorker software. The client indexes contain references to the
save set IDs and record each file that was included in the backup of a given
NetWorker client.

Introduction
The entries in the client file index record the following information for filesystem
backups:
◆ Filename
◆ Attributes of the file
◆ Location of the file within the file structure
◆ Position of the file within the save set
Note: For NetWorker module backups, the client file index includes metadata about the
individual application objects.
As some save sets might contain many files (100,000 or more) the information stored
in the client indexes can grow. This growth impacts the amount of disk space required
to store them. The save set browse retention policy allows customers to manage index
space for save sets.
Cloning example
In this example, three save sets are created by a backup of a client with three data
drives. These save sets are stored on a volume that is accessible through Storage
Node A. Once a cloning action occurs, the copies of these save sets are sent to a clone
pool on Storage Node B. Figure 1 on page 19 illustrates a cloning environment.
Figure 1 Cloning example
Cloning example 19
Introduction
Staging data example

For example, the initial backup data can be directed to a high performance file type or
advanced file type device. In this way, the backup time is reduced by taking
advantage of a file or advanced file type device. At a later time, outside of the regular
backup period, the data can be moved to a less expensive but more permanent
storage medium, such as magnetic tape. After the backup data is moved, the initial
backup data can be deleted from the file or advanced file type device so that sufficient
disk space is available for the next backup.
In Figure 2 on page 20, the staging action will result in the deletion of the original
save sets on the Volume A1, once they had been successfully staged (cloned) to
volume B1. The Xs indicate that once a successful clone copy has completed, the
original save sets are deleted. This is the difference between a clone and a stage
operation. The save sets appear to move from one storage to another. The resulting
save set is identical to that of the first, but in a different location.
Figure 2 Staging example

2
Planning and
Practices

◆ Cloning requirements ................................................................................................... 22
◆ Cloning policy................................................................................................................ 22
◆ Consider the application .............................................................................................. 27
◆ Consider the recovery scenario ................................................................................... 27
◆ Consider the browse and retention policies .............................................................. 27
Planning and Practices 21

Planning and Practices
Cloning requirements
The following requirements apply when performing clone operations:
◆ A minimum of two storage devices mustbe enabled. One to read the existing data
and one to write the cloned data:
• If libraries with multiple devices are used, the NetWorker server automatically
mounts the volumes required for cloning.
• If stand-alone devices are used, mount the volumes manually. A message
displays in the Alert tab of the Monitoring option that indicates which
volumes to mount.
◆ The destination volume must be a different volume from the source volume, and
must belong to a clone pool.
◆ You must be a NetWorker administrator. The EMC NetWorker Administration
Guide provides detailed information.
Note: Only one clone of a particular save set can reside on a single volume. If three clones of the
same save set are specified, the NetWorker software will ensure that each clone is written to a
separate volume.
Cloning policy
Cloning data has many benefits and can be used to protect and maximize the data
protection infrastructure.
The following section lists some of these benefit, describes common scenarios, and
provides advice on data selection.
Note: Ensure that all target volumes do not already contain the same clone save sets. Volumes
that contain failed clone save sets might prevent additional clone sessions from completing.
Deciding when to clone

In most situations, the backup window is limited and usually all available resources
are required to secure the client data in the required time period. Adding cloning
requirements to this backup window impacts the amount of resources that are
available for backups. Cloning should be avoided for all but the most important data
or where a dedicated cloning infrastructure is available.
The need to clone data is normally driven by a requirement for additional protection
or the need to move data to a specific media type or location. In both cases, the
priority is to secure the data as quickly as possible so that data protection can begin.
There is a high probability that any restore request within the first 48-hours will be
due to local failure or corruption and that the original backup copy is the most likely
source for that recovery.
In the case of a local disaster recovery or site loss, the recovery actions and objectives
are likely to be very different. Selected systems and services will be given specific
priorities, recovery point objective (RPO) values, and recovery time objective (RTO)
values.

The decision on when to clone depends on specific circumstances. However, in most

cases the clone operation can be separated and delayed from the initial backup
operation. This combined with the requirement to use infrastructure outside of the
backup window allows a cloning window to be created. Most or all of the cloning
operations should occur within the cloning window.
With the NetWorker 7.6 SP1 scheduled cloning feature and the nsrclone command,
cloning can be configured and scheduled independently of the backup window. It is
important that, as with backup, sufficient planning and resources are made available
to allow for successful clone operations to be completed.
IMPORTANT
Do not schedule more than 30 clone sessions to start at the same time. Scheduling
30 or more clone sessions to occur simultaneously may result in timed-out and
incomplete cloning sessions.
About clone pools

The cloning operation reads a save set from a volume within a backup pool and
writes it to a target volume.
Consider the following to ensure that the clones are easy to manage:
◆ Ensure that target volume belongs to a clone pool.
◆ Ensure that the volume that is used for cloning does not already contain a copy of
the save set. Only one instance of a save set can exist on the same volume or pool.
As with backup pools, there can be multiple clone pools. Clone pools can be used to
sort data by type, retention period, or location.
A clone pool can also be associated with one or more devices to limit the number or
type of devices that are used. By using clone pools, you can expire the original save
sets and reclaim the space on the initial or primary storage device while also
maintaining the data for future recoveries. This extends the retention periods within
clone storage pools and devices.
Save set clones have their own retention and browse periods which allow them to be
managed independently from the original backup.
Note: The retention policy specified in a clone pool will be overwritten if a retention policy is
specified in a scheduled clone operation or through the nsrclone command.
Specifying a retention policy for a clone pool

You can specify a retention policy only for cloned data in a Pool resource.
To specify a retention policy for a clone pool:
1. In the clone pool to which clone backups will be directed, click the Configuration
tab.
2. From the Retention policy list, select a retention policy.
3. Click OK. The EMC NetWorker Administration Guide provides information about
editing or creating a pool.
Note: The retention policy that is specified in a clone pool will be overridden if any retention
policy is specified in a scheduled clone operation.
Cloning policy 23
Save sets
NetWorker save sets have various status conditions that allow you to determine:
◆ Current status of the save set
◆ History of the save set
◆ Validity of the save set for recovery or clone operations
Clone attributes
Clone attributes include the following:
◆ Browsable: Select if the save set still has an entry in the client file index.
◆ Recyclable: Select if all save sets have passed both the browse and retention
policy time periods. The volume might be available for automatic relabeling and
overwriting provided that all of the save sets on the volume are recyclable.
◆ Recoverable: Select if the entry for the save set has been removed from the client
file index, but is still available for recovery from the media. That is, the volume
has not passed its retention policy.
◆ In-progress: Select if the save set is currently in the process of being backed up.
IMPORTANT
In-progress save sets cannot be cloned.
◆ Aborted: Select if the save set was either aborted manually by the administrator
during a backup, or because the computer crashed.
IMPORTANT
Aborted save sets cannot be cloned.
◆ Suspect: Select if a previous attempt to recover the save set failed.
IMPORTANT
Suspect save sets are not cloned. The following error message appears:
nsrclone: skipping suspect save set <ssid> cloneid <cloneid> nsrclone: error,
no complete save sets to clone.
Multiplexed backups
Multiplexed save sets can be cloned. Clone copies of multiplexed save sets are written
as a single contiguous data stream on the target media (demultiplexed). This
behavior can be an advantage since multiplex backups have a read and recovery
overhead. By cloning multiplexed save sets, you remove this overhead which allows
recoveries from the clone to be read faster than the original backup.
When cloning multiplex save sets, note that only one save set will be cloned to the
same target at the same time. However, multiple clone sessions can be started at the
same time from the same source provided that they all have separate target volumes.

Save set spanning

Some devices support save set spanning where a save set spans across multiple
volumes. When a save set is selected for cloning, it might start on one volume but will
continue to one or more additional volumes.
When using devices that support save set spanning, it is important to:
◆ Identify save sets that span multiple volumes.
◆ Ensure that the number of continued save sets is kept to a minimum.
◆ Use separate pools and larger or alternative devices.
◆ Use the EMC Data Domain® backup-to-disk and optimized cloning feature with
Data Domain devices.
◆ Plan ahead to ensure that the volumes are available and that they are read in an
optimum sequence.
A custom, scripted solution that uses the nsrclone command can be created and used
to manage save set spanning.
Moving from or to different devices

The devices that are used for the initial backup might not be ideal for the entire data
policy.
Often the devices that are used for the initial backup are chosen for their speed or
cost. These devices are usually local to the clients that are being protected and are
subject to the same situations or scenarios that the clients are trying to be protected
from. These include, power or cooling failures or site loss through natural disaster.
With NetWorker cloning, you can copy or move the data to an alternate or additional
device.
When data is cloned, the data is read from the source media in its native form similar
to a restore operation. Cloned data is not copied on a bit-by-bit basis. As such, data
can be re-written to another device. The destination device does not need to be the
same as the source device. Cloning or moving save sets from tape to disk or from disk
to Virtual Tape Library (VTL) is no different than cloning data from like devices. This
allows devices to be used efficiently and effectively in the right places.
Example
Advanced file type device (AFTD) disk devices can used for the initial backups
because of their speed and versatility.
Tape devices can be used to clone the data. This allows for an extended retention
period without increasing the disk space requirements.
The use of deduplication can also provide efficient use of storage. Cloning to or from
deduplication devices can ensure that these devices are used effectively.
Considerations for scheduled clone sessions

Note the following considerations when setting up scheduled clone sessions:
◆ “Scheduling multiple clone sessions to start at the same time” on page 26
◆ “Mixing save sets from different source devices” on page 26
◆ “Unmounted clone source volumes on remote storage nodes” on page 26
◆ “Clone resources that are created with the nsradmin program” on page 26
Cloning policy 25
Scheduling multiple clone sessions to start at the same time

Do not schedule more than 30 clone sessions to start at the same time. Scheduling 30
or more clone sessions to occur simultaneously may result in timed-out and
incomplete cloning sessions.
Mixing save sets from different source devices

Consider the following:
◆ Clone operations that mix save sets from different source devices, such as Data
Domain devices, AFTD devices, or Network Data Management Protocol (NDMP)
devices, may be written to different cloning target volumes. The full set of clone
volumes should be shipped offsite.
Note: Although this behavior is by design and is recommended as a best practice, it is

possible to write all save sets in the clone operation to the same clone volume.
◆ It is a best practice to not mix normal data and NDMP data because of the way in
which the data is written to tape differs. The number of filemarks and positioning
is different for NDMP data.
◆ If the clone operation includes save sets from different devices, and you want all
of the save sets to be written to the same volume, include only one volume in the
clone target pool.
Unmounted clone source volumes on remote storage nodes

Ensure that the source clone volume is mounted prior to cloning. The source clone
volume contains the copy of data that is to be cloned. The EMC NetWorker
Administration Guide provides detailed information on how to mount a volume.
If the clone source volume is on a remote storage node and is unmounted, a regular
volume clone operation will not complete successfully; even if the source volume is
mounted after the clone operation attempts to start.
The nsrclone program will stop responding with the following message:
Server server_name busy, wait 30 second and retry
This issue does not occur when the storage node is on the NetWorker server. The
storage node is not remote.
Clone resources that are created with the nsradmin program

Clone resources (known as NSR clone resources) that are created with the nsradmin
command line program cannot be edited as scheduled clone resources in the
NetWorker Administration user interface.
To avoid this issue, perform either of the following:
◆ In the Administration GUI, create scheduled clone resources.
or
◆ In the nsradmin program:
a. Create a NSR clone resource.
b. Create a corresponding NSR task resource.
You can use these resources to edit the clone item as a scheduled clone resource in the
GUI. The corresponding NSR task resource must have its name and action attributes
specified as follows:
name: "clone.nsrclone_resource_name"
action: "NSR clone:nsrclone_resource_name"

For example, if the NSR clone resource was named TestClone1, the name and action
attributes of the NSR task resource would be:
◆ name: clone.TestClone1
◆ action: NSR clone: TestClone1
These entries are case-sensitive.
Consider the application

When implementing a cloning policy for backup data, consider:
1. What NetWorker Module was used to create the original backup.
2. Consult the appropriate chapter for any special considerations:
• “NetWorker Module for Microsoft Applications” on page 63
• “NetWorker Module for Databases and Applications” on page 111
Consider the recovery scenario

When implementing a cloning policy for backup data, consider the recovery
scenarios.
Cloning data provides a second or alternative source for the recovery. This can
protect against media loss or corruption. However, if the media is located in one of
the following locations, then the second copy of the data is still vulnerable to major
disasters that can impact the entire site:
◆ On the same tape library
◆ On a deduplication device within the same data center (within a Data Domain
environment)
◆ In a safe on the site
In some cases:
◆ More copies may be required to ensure that all of the recovery scenarios can be
accommodated while maintaining the expected return on investment. This
requirement may not apply to all clients and all data or be practical. However,
consider the reasons why cloning is being used to ensure that the actions that are
being proposed or performed meet the requirements or expectations.
◆ Additional protection can also be achieved by changing the target or moving
tapes to a second location once the cloning operation is complete.
Consider the browse and retention policies

The NetWorker software uses browse and retention policies and applies them to
every write operation:
◆ The retention policy determines the length of time that the data remains available
for recovery on the NetWorker media database.
◆ The browse policy determines how long the details of the data remain available
for browsing and selection on the NetWorker client index.
Consider the application 27

Both the browse and retention polices impact the amount of disk space required by
the NetWorker server. The recovery procedure is likely to be different if one or both of
these polices has elapsed. The browse and retention polices should be equal to or
greater than the client or data requirements and allow for the expected recovery
conditions.
The NetWorker software is very versatile when recovering data because of how it
handles the data on the media. When determining data recovery options, consider:
◆ The data is written in a format that is self-describing. This allows data to be read
and recovered by using different NetWorker instances or versions.
◆ The data remains on the media until the save set data has expired. The media is
relabeled or staged in the case of an AFTD.
◆ Up until the point when the media is relabeled, recoveries are still possible,
regardless of the browse policy, expiration status, or even if the volume is known
to the NetWorker software in the media database entry.
While this versatility can be relied upon when unexpected events occur, it does not
replace the requirement to plan and manage the data appropriately. Care and
consideration should be given when selecting browse and retention polices. Also
consider the location and number of copies of volumes and save sets. This ensures
that the data is available at the most likely time by using the simplest procedures.
Browse policy
For every backup that is created by using the NetWorker software, you must assign
two policies to determine how long data should be maintained and be available after
the recovery. The most important policy from an ease of recovery perspective is the
browse policy.
The browse policy determines how long the backup will be browsable, so that the
ability to review and select data for recovery is possible. This policy determines how
long index data is maintained in the respective client index, so that a browse policy of
seven days will remove data from the client index after seven days has elapsed. This
allows different clients, or different data types, or even different groups of clients to
have browse periods that differ.
Once the browse policy for a save set has expired, it is possible regenerate the index
for a given save set. “Restoring save sets that are not in the media database” on
page 130 provides details.
Note: The browse policy is limited by the retention policy. The browse period cannot exceed
the time set for retention policy.

Retention policy
As with the browse policy, the retention policy is also assigned for every NetWorker
backup, regardless of its source or type. The policy lets the NetWorker software know
how long the data within a save set is expected to be maintained for recovery.
By having separate browse and retention policies, the user is not bound by the
retention period for client index information. This is useful as the recovery of data is
more likely to occur within a short period of time from when the backup was made.
However, the need to retain the information for business or regulatory reasons is
likely to exceed this period by some period. It is therefore possible to have a browse
period which is long enough to accommodate the most likely recovery scenario, but
maintain a retention period to satisfy the business or regulatory criteria. This
approach allows the disk space required by the client index to be maintained at a
more acceptable level without the overhead of large disk space requirements and the
performance and scaling concerns that would be associated with this.
Example
Figure 3 on page 29 shows how browse and retention policies can be used to maintain
the data available for recovery while minimizing the disk space required for client
indexes and maximizing the storage space available. By having this cascading
retention period, you can free the space on the immediate or high performance
devices, and still maintain the recovery options from the less costly, lower
performance devices.
Figure 3 Browse and retention policies
Consider the browse and retention policies 29


3
Cloning Procedures

◆ Cloning data................................................................................................................... 32
◆ Cloning options ............................................................................................................. 32
◆ Automated cloning ....................................................................................................... 33
◆ Schedule cloning ........................................................................................................... 35
◆ Volume cloning.............................................................................................................. 39
◆ Save set cloning ............................................................................................................. 39
◆ Scripted cloning............................................................................................................. 41
◆ Cloning archived data .................................................................................................. 44
◆ Considerations to improve cloning performance..................................................... 45
◆ Cloning validation ........................................................................................................ 45
◆ Displaying the backup versions in the GUI .............................................................. 46
Cloning Procedures 31
Cloning Procedures
Cloning data
NetWorker clone operations can be configured by using several different methods.
Each method is suited to different environments and storage needs. You may need to
use multiple or mixed cloning approaches to achieve the required control and
flexibility.
Clone operations can be configured to be run by:
◆ Automatic start (auto-clone)
◆ A schedule
◆ A customized script
NetWorker release 7.6 SP1 and later

In NetWorker release 7.6 SP1 and later, a clone user interface option was introduced
for scheduled clone operations, and provides the following benefits:
◆ Combines the flexibility of using the nsrclone command and avoids some of the
performance limitations that were often associated with the legacy automatic
cloning method.
◆ Eliminates the requirement to create scripted solutions.
NetWorker releases prior to 7.6 SP1

For NetWorker releases prior to 7.6 SP1, the following cloning options are available:
◆ Automated clone operations. These are linked to regular backup group
operations and are enabled through the Backup Group resource.
◆ The nsrclone command combined with a scripted solution.
Cloning options
Table 1 on page 32 lists the cloning options and describes how and when they are
typically used.
Table 1 Cloning options (1 of 2)
Cloning option Description
Automated Automated cloning is configured through the NMC at the NetWorker group level. The
cloning runs immediately after the group completes, so it might interfere with the
backup window. “Automated cloning” on page 33 provides details.
Scheduled Scheduled cloning, introduced with NetWorker 7.6.1, overcomes limitations in group
cloning by providing the ability to set clone schedules and more flexible options on
save set selection and clone pools. “Schedule cloning” on page 35 provides details.

Cloning Procedures
Table 1 Cloning options (2 of 2)
Cloning option Description
Volume Volume cloning is performed through the NMC Media window.

The clone of the individual volume runs immediately. “Volume cloning” on page 39
provides details.
Save Set Save set cloning is performed through the NMC Media window:
• To build a list of save sets, use the save set query feature.
• To clone individual or multiple save sets, review the query results.
“Save set cloning” on page 39 provides details.
Scripted Cloning scripts are written by customers.

These scripts use the NetWorker CLI to list and clone save sets. “Scripted cloning” on
Automated cloning
Note: Use the scheduled cloning GUI instead of using the auto-clone option.
Save sets can be automatically cloned when the backup group that contains them is
completed. Because the cloning occurs immediately after the group completes, this
clone method is suitable for smaller environments, or a small number of clients,
where the clone operations need to be completed quickly and immediately within the
backup window.
Unlike scheduled cloning, automated cloning runs immediately after the backup
group completes. This ensures that the backup data is cloned as quickly as possible.
However, it also means that the cloning operation is likely to interfere with the
backup window and might vary in start and end times.
Configuring auto-clone
To configure auto-cloning:
1. In the NetWorker Administration window, select Configuration.
2. Create a Group resource and then select Properties.
3. Specify the Clones option.
4. Select the clone pool that will be used to direct the backup.
The EMC NetWorker Administration Guide provides details on creating a clone pool.
Figure 4 on page 34 displays the auto-clone action. Once the backup of the three save
sets has completed, the clone of the save sets automatically starts. This action
provides two copies of the backup on completion of the savegroup.
Automated cloning 33
Cloning Procedures
Figure 4 Auto-clone action
A savegroup that has the auto-clone attribute enabled starts a cloning session after
the backup is complete. If the savegroup is aborted or stopped after the backup is
complete, the auto-clone session does not take place and the following occurs:
◆ Status icon in NMC displays as successful.
◆ Message appears in the logs to indicate that the save set cloning session failed.
Since the group is marked as successful in the NMC, the restart option is not enabled
on the savegroup.
To start the savegroup again, in NMC select start on the savegroup. The backup
session begins with auto-clone enabled.

Cloning Procedures
Schedule cloning
NetWorker scheduled clone operations can be configured and run in NMC according
to a schedule for predetermined clients, pools, save sets, and devices.
This method is suitable for environments where copies of save sets need to be
regularly provided. Such an environment is typically part of a well-defined
maintenance cloning window, which runs independent of the main backup
operation.
Figure 5 on page 35 shows the schedule pane for a clone session.
Figure 5 Setting up a scheduled clone session
Schedule cloning 35
Cloning Procedures
Scheduling clone operations

To set up a scheduled clone operation:
1. From the Administration window, click Configuration.
2. In the expanded left pane, select Clones.
3. From the File menu, select New.
4. In the Name attribute:
a. Type a unique name to identify the scheduled clone resource.
b. Type additional information in the Comment attribute, if required.
5. To override the save set's original browse and retention policies:
a. Select New policies in the Browse attribute.
b. Select New policies in the Retention attribute.
6. To specify the storage node that will write data during the clone operation, select
a storage node from the Storage node to WRITE save sets attribute.
The Storage node to WRITE save sets attribute is used primarily in conjunction
with the Storage node to READ save sets attribute. This joint usage balances the
access to storage node media across different storage nodes.
Note: If a selection is made in the Storage node to WRITE save sets attribute, it will
override any selection that is described in “Criteria for writing the clone” on page 51.
7. To specify the storage node that will read the data during the clone operation:
a. Select a storage node value from the Storage node to READ save sets
attribute. This attribute is visible only when Diagnostic mode is selected.
b. Ensure that the selected storage node is included in at least one of the
following:
– The Recover storage nodes or Storage nodes attribute of the NetWorker
server’s Client resource.
– A storage node list in the Read Hostname attribute for the Library
resource, if a library is being used.
– A storage node on which any device in the library is configured, if a library
is being used.
Note: The Storage node to READ save sets attribute is not intended for use with
stand-alone devices such as AFTDs, file type devices, and Data Domain devices.
8. To specify the clone media pool to write data to during a clone operation, select a
clone type media pool from the Write clone data to pool attribute.
Note: If no selection is made, clones will be written to the default clone pool.
9. Use the Pool attribute to ensure that only certain media types are used to hold
clone data. Pools direct backups to specific media volumes.

Cloning Procedures
For example, to ensure that this clone session replicates only to:
• A certain type of disk, such as a Data Domain type disk, select a clone pool
that uses only Data Domain type disks.
• Tape (tape out), select a clone pool that uses only tape devices.
10. Select Continue on save set error to force the NetWorker software to skip invalid
save sets and to continue the clone operation.
If this option is not selected (default setting), an error message results and the
clone operation stops if an invalid save set or invalid volume identifier is
encountered.
11. To restrict the number of clone instances that can be created for any save set that is
included in the particular scheduled clone operation:
a. Type a value in the Limit number of save set clones attribute.
A value of zero (0) means that an unlimited number of clones might be created
for this scheduled clone operation. The NetWorker software allows one copy
of a save set on any given volume since a clone is created for each volume in
the pool. Only one clone is created for each run of a scheduled clone operation.
b. Consider limiting the number of save set clones in cases where the clone
operation has not completed and is being retried.
For example, if you type a value of 1 in this attribute and then retry a partially
completed clone operation, only the save sets that were not successfully
cloned the first time will be eligible for cloning. In this way, unnecessary clone
instances will not be created.
Regardless of the value in this attribute, the NetWorker software always limits
the number of save set clone instances to one per volume. A clone pool can
have multiple volumes. This attribute limits the number of save set clone
instances that can be created for a clone pool in a particular scheduled clone
operation.
12. Select Enable to allow the clone session to run at its scheduled time.
13. In the Start Time attribute, perform either of the following:
• Click the up and down arrows to select the time to start the clone session.
or
• Type the time directly into the attribute fields.
14. From the Schedule Period attribute:
a. Select Weekly by day or Monthly by day depending on how you want to
schedule the clone session.
b. Select the days of the week or month on which the scheduled clone is to occur.
15. To repeat the clone session within a day, specify an Interval time in hours.
For example, if the start time is 6 a.m., and the interval is 6 hours, then the clone
session will run at 6 a.m., 12 p.m., and 6 p.m.
16. If the Limit the number of save set clones value is set, then the repeat clone
session skips those save sets in the pool for which the specified number of clones
already exists.
17. Click the Save Set Filters tab to specify the save sets to be included in this
scheduled clone session.
Schedule cloning 37
Cloning Procedures
To limit save sets by various filter criteria, perform either of the following:
• Select the clone save sets that match selections.
or
• Select the clone specific save sets to explicitly identify the save sets to be
cloned.
18. Click OK to save the scheduled clone session.
Displaying a list of the save sets that will be cloned based on the filter criteria
To display a list of the save sets that will be cloned based on the filter criteria that you
specified, select Preview Save Set Selection.
Cloning save sets that match selection criteria

To clone save sets that match selection criteria, specify selection criteria to limit the
save sets that will be included in this scheduled session. You can select the following
criteria:
◆ Groups (savegroups)
◆ Clients (client resources)
◆ Pools (backup pools)
◆ Filter save sets by level (backup level)
◆ Filter save sets by name (save set name as specified in the Client resource)
◆ Include save sets from the previous (save sets from the past number of days,
weeks, months, or years)
Cloning specific save sets

To clone specific save sets:
1. Type the specific save set ID/clone ID (SSID/clonid) identifiers in the Clone
specific save sets list box.
2. Type each SSID/cloneid value on a separate line.
3. You can query save set IDs/clone IDs by using one of the following methods:
• Selecting the Administration > Media user interface
or
• Using the mminfo command
Starting scheduled clone operations manually

You can start a scheduled clone session at any time without affecting the regularly
scheduled start time.
To start a scheduled clone session manually:
1. From the Administration window, click Configuration.
2. In the expanded left pane, select Clones.
3. Right-click a clone resource in the right pane.
4. Click Start.
You can also start a scheduled clone from the NetWorker Monitoring feature.

Cloning Procedures
Monitoring scheduled clone operations

In the Monitoring window of the Administration GUI, you can view the following:
◆ Status of scheduled clone sessions
◆ Scheduled clone's last start and end time
◆ Completion status of each save set that is included in the scheduled clone
Viewing the clone status of a save set

To determine whether save set on a volume is a clone, or was cloned, check the
window on the Query Save Set tab on a volume that has been cloned, or is a clone.
Volume cloning
Volume cloning is the process of reproducing complete save sets from a storage
volume to a clone volume. You can clone save set data from backup or archive
volumes.
Volume cloning uses nsrclone. However, it uses the volume name as an argument.
Cloning in the NetWorker software operates at the save set level and does not
specifically duplicate tape volume. This might result in multiple volumes being used.
The following describes the volume cloning process:
1. Instructs nsrclone to clone all of the save sets that exist on a particular volume.
2. When volumes are cloned, a list of all of the save sets that reside on them is
created, and these in turn are then cloned.
3. Save sets that begin (header sections of continued save sets) on a specified
volume will be completely copied:
• Volumes may be requested during the cloning operation in addition to those
specified on the command line.
• Save sets that reside on the specified volumes that begin elsewhere (middle
sections or tail sections of continued save sets) are not cloned.
Save set cloning

To manually clone a save set:
1. From the Administration window, click Media.
2. In the expanded left pane, select Save Sets.
3. In the right pane:
a. Click the Query Save Set tab.
b. Use the Query Save Set tab to specify options to limit the range of save sets
displayed.
c. All query options are optional except for the date. A date range must be
selected.
Note: The text boxes in the Query Save Set tab are case-sensitive.
Volume cloning 39
Cloning Procedures
4. Type values in any of these attributes to limit the search:

• Client Name
• Save Set
• Save Set ID
• Volume
• Pool
5. Use the Copies attribute to limit the search to only those save sets that have
already been cloned:
a. Select a boolean value from the list:
– Greater than (>)
– Equal to (=)
– Less than (<)
b. Type the number of clones to complete the search criteria for the Copies
attribute.
For example, to search for only those save sets that have been cloned at least
twice, select greater than (>) and then type 1 as the number of copies.
6. Use the Save Time attribute to limit the search to a period of time in which the
save set was created.
By default, yesterday is used for the start date, and today is used for the end date.
This means that save sets backed up between yesterday at 12:01 a.m. and the
current time will be displayed.
For the From and To date fields, any of these formats are acceptable:
• Written out completely (for example, November 1, 2009)
• Numerically as mm/dd/yy (for example, 11/01/09)
• Date and time selection from the list
Note: A long date range might result in too many selected save sets. This can increase
response time or even require that you close and reopen the browser connection to the
NetWorker Console.
7. Use the Status attribute to limit the search to save sets that have a particular
status.
The values that can be selected include the following:
• All
• Browsable
• Recyclable
• Scanned-in
• Recoverable
• Suspect

Cloning Procedures
8. Use the Maximum Level attribute to limit the search to save sets of a particular
backup level.
The level All is specified by default. All the levels up to and including the
selected level are displayed. For example:
• If you select level 5, save sets backed up at levels full, 1, 2, 3, 4, and 5 are
displayed.
• If you select level Full, only those save sets backed up at level full are
displayed.
• If you select All, save sets for all levels are displayed.
9. Click the Save Set List tab. The save sets that fit the criteria appear in the Save
Sets list.
10. From the Save Set list, select the save sets to clone.
11. From the Media menu, select Clone.
12. From the Target Clone Media Pool list, select a clone pool.
13. Click OK, then click Yes on the confirmation screen.
Scripted cloning
As of NetWorker 7.6 SP1, most of the functionality provided in the nsrclone.exe
command is now provided in the NMC Clone resource user interface.
However, for some situations or circumstances, the use of the nsrclone.exe command
within a script can still have advantages. For example, a scripted cloning solution
could be used for any of the following scenarios:
◆ To control the conditions before cloning occurs. For example, following a specific
event or test, or as part of a workflow.
◆ To control the actions after cloning has been successful. For example, deleting
files, or moving data as part of a workflow.
◆ To control the cloning as part of an enterprise management scheduler that is
independent of NetWorker scheduling or NMC.
◆ To create multiple clones. For example, clone 1 on disk, clone 2 to tape, each with
specific dependencies, timing, and logic.
Note: When using the scripted cloning feature, use the latest versions of NetWorker software.
This will minimize the complexity of the logic in the cloning script.
NetWorker 7.6 Service Pack 1 enhancements

As of NetWorker 7.6 SP1, most of the functionality provided in the nsrclone
command is now provided in the NMC Clone resource user interface. The updated
nsrclone command also contains a number of enhancements that can significantly
reduce the size and complexity of any script.
Table 2 on page 42 provides the descriptions of the options that can be used with the
nsrclone command.
Scripted cloning 41
Cloning Procedures
NetWorker 7.5 enhancements

As of NetWorker 7.5, the nsrclone command has been enhanced to provide greater
flexibility when selecting save sets for cloning by:
◆ Clients
◆ Groups
◆ Save set names
◆ Save set levels
◆ The number of valid copies
◆ The number of clones not yet created in the target pool
nsrclone option descriptions

Table 2 on page 42 provides the descriptions of the options that can be used with the
nsrclone command.
Table 2 Descriptions of nsrclone options
Options Description
-C less than copies in target pool Specifies the upper non-inclusive integer limit such that only save sets with a lesser number of
clone copies in the target clone pool are considered for cloning. This option is useful when
retrying aborted clone operations. Because the target is a clone pool, each save set's original
copy or clone is never considered when counting the number of copies of the save set. Likewise,
any AFTD read-only mirror clone is not considered because its read or write master clone is
counted and there is only one physical clone copy between the related clone pair. Recyclable,
aborted, incomplete and unusable save set or clones are excluded in the counting. This option
can be used only with the -t or -e option.
-l level or range Specifies the level or n1-n2 integer range from 0 to 9 for save sets that are considered for
cloning. Manual for ad-hoc or client-initiated save sets, full for level full save sets, incr for level
incremental save sets, and integers 0 through 9, where save set0 also means full, can be used.
More than one level can be specified by using multiple -l options and the -l n1 to n2 range
format. This option can be used only with the -t or -e option.
-N save set name Specifies the save set name for save sets that are considered for cloning. More than one save
set name can be specified by using multiple -N options. This option can be used only with the -t
or -e option.
-c client name Specifies the save sets in the particular client. More than one client name can be specified by
using multiple -c options. This option can be used only with the -t or -e option.
-g group name Specifies the save sets in the particular group. More than one group name can be specified by
using multiple -g options. This option can be used only with the -t or -e option.

Cloning Procedures
Using the nsrclone options

The following examples show how various options can be used with the nsrclone
command:
1. Copy all save sets created in the last twenty-four hours for the clients Mars and
Jupiter with save set names /data1 and /data2 for only backup level full:
nsrclone -S -e now -c mars -c jupiter -N /data1 -N /data2 -l full
2. Copy all save sets that were not copied to the default clone pool in a prior
partially aborted nsrclone session:
nsrclone -S -e now -C 1
3. Copy all save sets that were not copied to the default clone pool in a previous
partially aborted nsrclone session and with extended retention and browse
periods:
nsrclone -S -e now -C 1 -y 12/12/2010 -w 12/12/2009
Using the nsrclone command to specify a browse and retention policy

When using nsrclone you are able to specify a browse and retention policy from the
command prompt.
Specifying a retention policy

To specify a retention policy from the command prompt, perform one of the
following:
◆ Use the nsrclone command with the -y option when creating a clone save set.
◆ Specify a retention policy for an existing clone save set by using the nsrmm -e
command.
Specifying a browse policy

To specify a browse policy from the command prompt, use the nsrclone command
with the -w option when creating a clone save set.
Note: Be aware that this will also change the browse policy of the original save set instance if
the original save set's browse time has not passed and is earlier than the new browse time for
the clone.
Scripted cloning 43
Cloning Procedures
NSR clone resources

Clone resources that are created with the nsradmin program’s NSR clone resources
cannot be edited as scheduled clone resources in the NetWorker Administration
graphical user interface GUI.
To avoid this issue, perform one of the following:
◆ Create scheduled clone resources in the Administration interface. “Scheduling
clone operations” on page 36 provides more information.
◆ Create a NSR clone resource, if required with the nsradmin program:
a. Create a corresponding NSR task resource with the nsradmin program.
Together, these resources will enable you to edit the clone item as a scheduled
clone resource in the GUI.
b. The corresponding NSR task resource must have its Name and Action
attributes specified as follows:
name: "clone.nsrclone_resource_name"
action: "NSR clone:nsrclone_resource_name"
Cloning archived data

You can schedule a clone session to clone archive data or clone archive data manually.
Scheduling a clone session for archive data

To set up a scheduled clone session for archive data:
1. Follow the steps in “Scheduling clone operations” on page 36.
2. Select an archive pool as one of your save set filter criteria.
Cloning an archive volume manually

To clone an archive volume manually:
1. From the Administration window, click Media.
2. In the expanded left pane, select Save Sets.
3. In the right pane, click the Query Save Set tab.
4. In the Pool attribute:
a. Select an archive pool from the list.
b. Make other selections, as appropriate, to limit the save set search criteria.
“Starting scheduled clone operations manually” on page 38 provides more
information.
5. Click the Save Set List tab.
6. Select the archive save sets to clone from the Save Set list.
7. From the Media menu, select Clone.
8. From the Target Clone Media Pool list, select an archive clone pool.
9. Click OK.
10. Click Yes on the confirmation screen.

Cloning Procedures
Considerations to improve cloning performance

Cloning can be performed in parallel so that multiple clone sessions can be active at
the same time. However, the number and speed of this will depend on the devices
that are being used and the method that is employed to start the cloning operation.
◆ Automatic cloning is based on a savegroup and is a single-threaded process.
◆ For a given group, the NetWorker software runs only one clone at a time,
regardless of the parallelism setting.
◆ Other groups that have auto-clone configured are able to run in parallel.
However, they will also run only one clone at a time, assuming that there is no
contention for volumes or devices.
Cloning validation
Clone data does not require validation because the data is read from the source in its
native and self-describing form and then it is written to the target. The action of
creating a clone validates the ability to read the source data from the media.
Therefore, subsequent clone operations based on the clone will also be validated as
further copies are created.
If there are actions that are expected after a clone operation, then it is likely that some
form of validation is used. This is important if the follow-on action has a destructive
or irreversible nature, such as the deletion of the source data through expiration or
relabeling.
For individual save sets, use the mminfo command to check that the clone save set is
valid and not in an aborted or error state.
Additional clone copies can also be used to:
◆ Validate that the save set is able to be read
◆ Provide additional assurance and protection.
Although a check of individual save sets may help confirm a successful clone
operation, it does not confirm that recovery is possible:
◆ Additional save sets may also be required as part of the recovery.
◆ Always ensure that all save sets have been identified and cloned successfully.
◆ Application-based backups are a particular example where multiple save sets
may be required.
Considerations to improve cloning performance 45

Cloning Procedures
Displaying the backup versions in the GUI

After the scanning the data is complete, you can display the backup in the NetWorker
User program.
You can display the data by using one of the following methods:
◆ If the application object is present in the most recent backup, you can view
versions for that application object. The versions are not cached, so a newly
scanned version should be detected if present:
a. From the View Versions pane, look for the savetime that the data was
scanned.
b. If the savetime is found, choose this savetime as the new browse time to
proceed.
c. Use the Change Browse Time attribute to set the time slightly ahead of the
most recent save set that was scanned.
◆ If you are restoring from an incremental backup:
a. Validate that the prior full and all incremental backups are also visible as
backup versions.
b. Run View Versions for the application object.
◆ If the scanned backup version does not appear in the NetWorker User program,
validate the rollover save set.

4
Software
Configuration

◆ Filesystem configuration.............................................................................................. 48
◆ Storage nodes................................................................................................................. 49
◆ Cloning with EMC Avamar (deduplication node) ................................................... 55
◆ Cloning with Data Domain (DD Boost) ..................................................................... 56
◆ Cloning with EMC Disk Library using an embedded storage node ..................... 58
◆ Production storage node cloning of data to physical tape...................................... 62
Software Configuration 47
Software Configuration
Filesystem configuration
Before you start to configure cloning, you must consider the type of data that is being
cloned. This section describes a basic cloning operation that uses a standard
filesystem backup where a client, pool, or volume that has one or more filesystem
save sets is required to be cloned to a second device. This device is typically located in
a different location.
For specific application data cloning considerations, see:
◆ Chapter 5, “NetWorker Module for Microsoft Applications”
◆ Chapter 6, “NetWorker Module for Databases and Applications”
Figure 6 on page 48 illustrates the principle for all cloning operations.
Figure 6 Filesystem cloning

In this figure:
◆ A client performs a backup to a storage node.
◆ The clone operation takes the copy from the storage node or another storage node
that has access to the same volumes and reads the data from the volume, storage
node A.
◆ Data is then directed to a different device. The data can be accessed in one of three
ways:
• Through the same storage node
• From a storage node in a different location
• By using a different device (storage node B)
Most of the configuration principles in this section apply to all cloning operations.
Storage nodes
When performing clone operations, you can select the storage node that is used for
the source and target.
This section describes the criteria that you can use to determine:
◆ The storage node from which the clone data is read (read source).
◆ The storage node to which the clone data is written (write source).
Figure 7 on page 49 illustrates a typical NetWorker environment where a number of
storage nodes and devices are available. The ability to determine the storage node
and device used for both the read and the write source of any cloning operation is an
important element in configuring cloning.
Figure 7 Cloning with storage nodes
Storage nodes 49
Determining the read and write source

By selecting the appropriate read and write sources, you can ensure that:
◆ The clone copies are created from and reside in the appropriate locations or media
formats.
◆ The resources are available for other backup or recovery operations.
Figure 8 on page 50 illustrates the storage node selection criteria for reading the clone
data.
Figure 8 Storage node selection criteria for reading the clone data

Criteria for reading the clone data

Use the following criteria to determine the storage node from which the clone data
will be read (read source):
◆ If the source volume is mounted, then the storage node of the device on which the
volume is mounted is used as the read source.
If the FORCE_REC_AFFINITY environment variable is set to Yes:
• The selection criteria in step a on page 51 are ignored.
• The selection criteria behaves as though the volume is not mounted as
described in step a on page 51.
◆ If the volume is not mounted or if the FORCE_REC_AFFINITY environment
variable is set to Yes, a list of eligible storage nodes is created.
The list is based on the storage nodes that meet the following criteria:
a. Storage nodes are listed in the Recover Storage Nodes attribute of the Client
resource of the NetWorker server. If this attribute is empty, the Storage Nodes
attribute of the NetWorker server is used.
b. If the requested volume is in a media library, the storage nodes on which the
volume can be mounted is determined in the following manner:
– The storage node listed in the Read Hostname attribute for the library
resource is used.
– If the Read Hostname attribute for the library resource is not set, then all of
the storage nodes on which any device in the library is configured are
added to the list of Eligible Storage Nodes.
– If the volume is not in a media library, then the list of Storage Nodes is
based on step a on page 51 only.
Criteria for writing the clone

Use the following criteria to determine the storage node to which the clone data will
be written (write source):
◆ The Clone Storage Node attribute of the Client resource of the read source
storage node is used as the write source.
◆ If the read source host does not have a Client resource:
• The Clone Storage Node attribute of the NetWorker server is used as the write
source.
• The Storage Nodes attribute of the NetWorker server is used as the write
source.
No matter where the cloned data is directed, the client file index and the media
database entries for the cloned save sets still reside on the NetWorker server. This
ensures that the browse and retention policies are handled consistently regardless of
where the clone data is directed.
Storage nodes 51
Directing a clone from one storage node to another storage node

To direct a clone from one storage node to another:
1. Open the Client resource for the read source storage node. The EMC NetWorker
Administration Guide provides detailed information on how to edit a client.
2. Click the Globals (2 of 2) tab.
3. In the Clone Storage Nodes attribute, add the hostname of the storage node to
which the clone data will be written.
The first entry in the list contains the functional, enabled device that receives the
cloned data from the read source storage node.
4. The Clone Storage Nodes attribute applies only to NetWorker servers and
storage nodes.
Note: Leave this attribute blank for NetWorker clients that are not also NetWorker servers
or storage nodes.
Directing clones from all storage nodes to a single storage node

To direct clones from all storage nodes to a single storage node:
1. On the Client resource for each storage node, leave the Clone Storage Nodes
attribute blank.
2. Open the Client resource for the NetWorker server. The EMC NetWorker
Administration Guide provides detailed information on how to edit a client.
3. Click the Globals (2 of 2) tab.
4. In the Clone Storage Nodes attribute, add the hostname of the storage node to
which all cloned data is to be written.
Criteria for recovering cloned data

Use the following criteria to determine the storage node from which the clone data
will be recovered:
◆ If the source volume is mounted, then the storage node of the device on which the
volume is mounted is used as the read source:
• If the FORCE_REC_AFFINITY environment variable is set to Yes:
– The selection criteria in step a on page 51 are ignored.
– The selection criteria behave as though the volume is not mounted as
described in step a on page 51.
• When cloning is used in a VTL environment such as an EMC CLARiiON®
Disk Library (CDL), the NetWorker software behaves as if the
FORCE_REC_AFFINITY environment variable is set to Yes.
◆ If the volume is not mounted or if the FORCE_REC_AFFINITY environment
variable is set to Yes, a list of eligible storage nodes is created. The list is based on
the storage nodes that meet the following criteria:
• The storage nodes listed in the Recover Storage Nodes attribute of the
NetWorker client resource that is being recovered. If this attribute is empty, the
NetWorker client's Storage Nodes attribute is used.

• If the requested volume is in a media library, the storage nodes on which the
volume can be mounted are determined in the following manner:
– The storage node listed in the Read Hostname attribute for the library
resource is used.
– If the Read Hostname attribute for the library resource is not set, then all
storage nodes on which any device in the library is configured are added to
the list of eligible storage nodes.
– If the volume is not in a media library, then the list of storage nodes is
based on step a on page 51 only.
Cloning with tape devices

There are a number of reasons why tape devices are used as part of the cloning
process:
◆ In cases where tape is used as a secondary storage tier where selected data is
cloned to tape for offsite storage or for extended data retention periods. This
allows disk devices to be used for the initial backup where their speed and
flexibility can be most effectively used for fast backup and recovery performance.
◆ In cases where tape is used as the primary backup media, there are still benefits in
creating clone copies, including:
• Secondary copy at different location or for offsite storage
• Data validation
• Verification of the ability to read data from the media
• Added protection of multiple copies across multiple volumes
• De-multiplexing of multiplex backups for faster recovery
Cloning with tape devices provides two benefits which should be considered for
every clone created:
◆ Unlike disk-based devices, tape devices read data in a serial format. This means
that while multiplexing is beneficial from a backup streaming perspective, not so
when it comes to recovery.
◆ If recovery speed is important, the use of clone copies as the source is likely to
result in faster recovery throughput.
◆ Tape clone copies are often the preferred method to read data in disaster recovery
situation. The ability to acquire, install, and configure a tape unit to read data is
often the first task on a disaster recovery plan.
By creating a copy of the backup on tape, you can eliminate the need for appliances
such as VTLs or disk systems to be in place. This often takes longer to acquire, install,
and configure. However, ensure that the tape copy is a full and complete copy,
without the dependence on other backups or deduplication appliances to complete
the restore operation.
Storage nodes 53
Cloning with file type and AFTD devices

The use of the disk backup devices such as file type and AFTD devices are ideal for
cloning operations because they provide high speed, random access, and flexibility.
In many cases, the disk devices are used as the initial target device for backups,
especially in situations where slower clients are unable to match the speeds expected
for modern tape devices. In these situations, the ability to clone or stage data to tape
often provides extended retention and data protection while maximizing the disk use
and benefits.
Data can remain on the disk devices for short periods, typically 3 to 14 days which
allows for:
◆ Adequate time for immediate and urgent restore operations to occur.
◆ Plenty of time to create further copies to tape or other disk-based devices for
longer term retention.
Differences in the cloning process

There are differences in the cloning process for the two types of devices:
◆ For file type devices, automatic and manual cloning begins only after all the save
sets in a savegroup have been backed up.
◆ For AFTD, automatic cloning begins only after all the save sets in a savegroup
have been backed up.
Note: You can begin manually cloning a save set as soon as it has finished its backup.
◆ AFTD devices allow a maximum of two concurrent clone operations. One clone
operation can use the writable device and the other clone operation can use the
read-only device.
◆ AFTD devices allow recoveries during cloning operations (Read(source) or
Write(target). This assumes that the recover operation is not from the active save
set and that only one clone operation is running at-a-time.
Manual cloning with advanced file type device

Consider a situation where there are three save sets:
◆ Save set A has a size of 10 KB.
◆ Save set B has a size of 10 MB.
◆ Save set C has a size of 10 GB.
When save set A has completed its backup, you can:
◆ Begin the manual cloning process while the other two larger save sets are still
being backed up.
◆ Launch the cloning process for that save set as each save set is backed up.
◆ Clone only one save set at a time.

Cloning with EMC Avamar (deduplication node)

EMC Avamar® deduplication technology decreases the amount of time, network
bandwidth, and disk capacity required to back up client data.
The cloning of Avamar deduplication backups is somewhat different from the cloning
of other NetWorker backups. Only the metadata (hash information) is stored on a
NetWorker storage node. This metadata is not deduplicated. However, it can be
cloned in the usual manner. “Scheduling clone operations” on page 36 provides
information on how to set up cloning operations. Cloning this hash metadata is
highly recommended.
The backed-up data from an Avamar deduplication client, however, is stored on an
Avamar deduplication node and cannot be cloned to a NetWorker storage node. This
backed-up data can be replicated on another Avamar deduplication node if such a
replication host has been configured. The NetWorker software does not initiate
replication. A replication host (an Avamar server) must be configured by EMC
Customer Support before a deduplication backup can be replicated. The EMC
NetWorker Administration Guide provides more information. You can also output the
backup data of Avamar deduplication nodes to tape volumes. “Backup-to-tape for
Avamar deduplication clients” on page 55 provides more information.
IMPORTANT
For disaster recovery, you must replicate the client data to another Avamar
deduplication node. You must also clone the metadata. Both the metadata and the
client data are required to recover backed-up client data.
Backup-to-tape for Avamar deduplication clients

There is an alternate method to using a replication node to ensure that additional
copies of Avamar deduplication data are available for recovery. Create a second
instance of the client to be backed up, but do not configure the second instance as a
deduplication client. The second client instance is treated as a regular NetWorker
client and its data is backed up to tape.
Example
Clients mars, venus, and jupiter have been configured as deduplication clients and
assigned to a backup group named Dedupe backups. This group is scheduled for a
daily level full backup.
To get a monthly tape backup of these clients:
1. Create another instance of the mars, venus, and jupiter clients.
IMPORTANT
Do not select the Deduplication backup checkbox on the Apps & Modules tab
of the Create Client resource.
2. On the General tab of the Create Client resource, assign mars, venus, and jupiter to
a backup group named Tape backups.
3. Schedule this group for a monthly full backup on one day of the month. Skip
every other day of the month.
Note: The Avamar documentation describes the tape out options that are available for Avamar.
Cloning with EMC Avamar (deduplication node) 55

Cloning with Data Domain (DD Boost)

As with other NetWorker devices, Data Domain device types can also be used to
perform clone operations. Single save sets or the entire volume of a Data Domain
device may be cloned as a source or target.
Clone formats
Data stored on a Data Domain device may be cloned by the NetWorker software in
one of two formats, depending on the type of media on which the clone copy will be
stored:
◆ Clone-controlled replication format
◆ Regular clone format
Clone-controlled replication format

Data that is cloned to a target Data Domain device, typically at a remote location,
retains its deduplication format and is known as clone-controlled replication or an
optimized clone.
Clone-controlled replication uses the native Data Domain replication feature to copy
data from one Data Domain system to another. The NetWorker control ensures that
clone-controlled replication will not begin until after the related backup group at the
source has finished its backup.
The storage node for the target device reviews the incoming clone for data that is
already stored on the target device and transfers only unique data and reference
pointers to be stored on the device.
Clone-controlled replication uses a special Data Domain API command. Do not
confuse this clone-controlled replication with standard directory level replication,
which is also supported. The clone is created quickly and uses low bandwidth and
low storage capacity.
A clone created in this format may be used for data recovery or to create further
copies, for example, to traditional disk or tape storage. This method results in
minimal impact on production or primary backup and recovery operations.
Regular clone format

When data on the Data Domain device is cloned to a traditional disk or tape, it is
reverted to its native non-deduplicated format, known as "regular clone" format.
Regular clone format is necessary for the data on traditional disk or tape storage to be
completely recoverable, for example for disaster recovery, without the need of a Data
Domain system.
The process that takes data that has been deduplicated and then reverts it to normal
or regular data is called rehydration.

Clone requirements
To clone data from one Data Domain device to another by NetWorker
clone-controlled replication (optimized cloning), ensure that requirements are met.
The following eight requirements assume that the previous creation of a clone target
pool named, for example, as newclonepool:
1. Ensure that both the source and target storage nodes are clients of the same
NetWorker server.
2. Ensure that the Data Domain systems are properly licensed, including a
replication license, which is required to create optimized clones.
3. Ensure that the Client resource for the NetWorker server and both storage nodes
specify, in their Aliases attribute, all of their names in use.
For example:
• Fully-qualified name
• Short name
• Aliases
• IP address
Note: If an nsrclone command or script is used to perform an optimized clone from a host
that is not the NetWorker server, then this command must specify the NetWorker server by
its primary hostname as listed in the NMC Enterprise view. Otherwise, a regular clone
might be produced instead of an optimized clone.
4. Ensure that a target pool (for example, newclonepool) has been created for
Backup Clone type with the Media type required attribute set to Data Domain.
With this setting, if a Data Domain device is not available for a clone operation in
the specified target pool, then NMC displays a "Media waiting" message.
Note: The Default Clone pool does not allow any modification. The required media type
cannot be set in that pool.
5. Ensure that the Client resource for the source storage node specifies, in its Clone
Storage Node attribute, the target storage node hostname:
• If the Clone storage node attribute is not specified, then the NetWorker server
becomes the storage node for the clone operation.
• If the Clone storage node attribute lists a storage node for a volume that is not
Data Domain, and media type required is not set to Data Domain in the target
clone pool, then only regular clones may be stored on those volumes.
Note: This setting is not required if the target storage node is on the NetWorker server.
6. Ensure that the source Data Domain device is mounted and available on the
source storage node.
If the source device is not mounted, then a regular, non-deduplicated clone will
be performed, except if the specified target pool is of Backup Clone type with the
Media type required attribute set to Data Domain.
Cloning with Data Domain (DD Boost) 57

7. Ensure that the target Data Domain device is labeled and mounted on the target
storage node. The pool selected for the device label operation (for example,
newclonepool) must be of Backup Clone pool type.
8. Verify that the target clone pool (for example, newclonepool) is properly specified
or selected:
• For CLI clone operations, use the nsrclone -b newclonepool command.
• For scheduled clone operations, in the Write clone data to pool attribute of the
Clone resource, select newclonepool.
• For auto-clone operations for a group, in the Clone pool attribute of the Group
resource, select newclonepool.
• For clones of entire volumes, “Cloning by pools” on page 58 provides details.
Cloning by pools
In order to copy save sets from Data Domain storage to a device, a special pool must
be specified. This pool is known as a "clone pool." A clone pool must be assigned to a
device on the target Data Domain system, where it will be available for use.
There are two main purposes for a clone pool:
◆ To copy existing deduplicated VTL or CIFS/NFS AFTD save sets to a Data
Domain device.
◆ To copy the existing save sets from one Data Domain device to another Data
Domain device, typically at a remote location for disaster recovery purposes.
Cloning with EMC Disk Library using an embedded storage node

The storage node cloning capability within the EMC Disk Library® (EDL) requires a
NetWorker storage node. This means that the EDL with the embedded storage node
cloning capability must be configured in a NetWorker datazone. All standard
NetWorker configuration rules and restrictions apply.
The embedded storage node software feature automatically starts when the EDL
NetWorker Storage Node enabler license is installed. The storage node software also
automatically restarts after an EDL reboot, as long as the enabler license remains
installed. If the EDL NetWorker Storage Node enabler license is removed, the storage
node software is stopped and will remain stopped until the EDL reboot.
Activating the EDL embedded NetWorker Storage Node enabler license also enables
a menu option within the EDL Console that checks the status of the storage node and
enables starting and stopping of storage node services. The EMC Disk Library online
help provides more details.

Embedded storage node use cases

The embedded storage node feature supports all standard NetWorker cloning
operations, including these six use cases:
1. Cloning save sets from virtual tape with the disk library to Fibre
Channel-connected target libraries on the back end of a disk library:
• The disk library embedded storage node reads save sets from the virtual tape
library that are used by the production storage node, and writes to the target
tape devices that are attached to the back-end Fibre Channel ports of the disk
library.
• A different retention policy can be applied to the cloned copy of the save set.
• Setting different retention policies can enable the copy on the virtual media to
be retained for a relatively short period of time. For example, one week where
as a longer retention policy can be applied to the clone copy on tape for
longer-term storage.
2. Cloning save sets from virtual tape to a second Fibre Channel-connected disk
library on the back end of the disk library. This cloning operation has the
advantage of maintaining a second copy of data on disk, while freeing space on
the primary backup target.
3. Cloning of save sets from virtual tape to a remote disk library through extended
back-end Fibre Channel SAN connectivity:
• This allows electronic cloning of a save set or distance, where the remote tape
device is written to by the local disk library storage node.
• Recovery of the save set can also be accomplished over that same distance if
necessary.
4. Cloning of the save sets from virtual tape to a second disk library with embedded
storage node over IP:
• This provides the ability to:
– Clone over a relatively low-cost infrastructure including one that may be
already be in place.
– Keep the remote data on disk library disk.
• This is particularly useful when a limited amount of data needs to be moved (1
to 2 TB per day depending on the distance).
• Performance limitations of the existing IP infrastructure will impact the
amount of data that can be cloned with this solution.
5. Cloning of the save sets from virtual tape to a different or separate NetWorker
storage node over IP:
• This provides the ability to clone over a relatively low-cost infrastructure. One
that may be already in place without requiring a second disk library at the
remote site.
• This is particularly useful when a limited amount of data needs to be moved (1
to 2 TB per day depending on the distance).
• Performance limitations of the existing IP infrastructure will impact the
amount of data that can be cloned with this solution.
Cloning with EMC Disk Library using an embedded storage node 59

6. Cloning of save sets in virtual tape libraries on either disk library engine from one
disk library engine addresses these points:
• Allows a single embedded storage node to clone from VTLs in either disk
library engine.
• Allows a single embedded storage node to clone from other virtual tapes if the
other disk library engine is down.
Cloning operations with embedded storage nodes

The environment that supports this use case provides an additional level of
availability for embedded storage node cloning operations. An embedded storage
node is similar to any other storage node in that the node can use the devices that it
can see such as:
◆ Virtual tape library on its own disk library engine
◆ Target tape library (PTL) connected to the same disk library engine
However, it cannot see the virtual tape library in the other disk library engine. But it
can:
◆ Treat engine A, which functions as a Fibre Channel initiator, as a SAN client of
engine B that functions as a Fibre Channel target.
◆ Engine B provides the same VTL used by the production node to engine A.
Each disk library engine becomes a SAN client of the other, just like any other
SAN-connected NetWorker storage node. This requires each embedded storage node
to have this capacity.
In the previous scenarios, one or more virtual tape libraries were created within the
disk library and assigned to the NetWorker storage nodes. These virtual tape libraries
can be used by a single or multiple production storage nodes, or by the embedded
storage node.
For the embedded storage node to access these virtual tape libraries for cloning
operations, the virtual tape libraries must also be assigned to the NetWorker storage
node which is the SAN client in the Disk Library Console program. This allows the
embedded storage node to:
◆ Read from the virtual tapes that were created by the production storage nodes.
◆ Write to either virtual or physical tape devices that are attached to the disk library
or to a second or remote storage node.
The NetWorker software allows a tape library to be shared by two or more storage
nodes. This can occur in two instances both of which are supported by the embedded
storage node cloning capability:
◆ Dynamic Drive Sharing (DDS), where one or more of the tape drives in a tape
library are shared by two or more storage nodes.
◆ Without DDS, where one or more of the tape drives are dedicated (not shared) by
two or more storage nodes.

Storage node selection

The purpose of the embedded disk library storage node is to provide a highly
efficient cloning process. A NetWorker datazone has one NetWorker server, one or
more storage nodes, and one or more clients.
Environments with multiple storage nodes

In environments with multiple storage nodes, configure the NetWorker environment
so that the NetWorker software uses the disk library embedded storage node, and not
the production storage nodes to perform the cloning operations.
If not properly configured, it is possible that the NetWorker software will
automatically select a production storage node in place of the embedded storage
node. As a result, cloning might occur between storage nodes over an IP or Ethernet
connection.
Cloning node affinity for all disk library virtual tape libraries
By default, the NetWorker software determines which storage node will read a source
volume in a clone operation by first considering if the source volume is already
mounted. While this is an efficient choice for many situations, it is not preferred for
environments where clone operations are to be performed by the disk library
embedded storage node.
NetWorker version 7.4 SP1 and later incorporates a feature where the mounted status
of a source volume is ignored when determining the read source for virtual tape
libraries.
Note: Use this feature when performing any cloning operation that involves the disk library
embedded storage node. Note that this feature is applied to the NetWorker server, not the
embedded storage node that is running inside the disk library.
The NetWorker software also automatically activates a feature that ignores the
mounted tape status when determining cloning node affinity for all disk library VTLs
have the virtual jukebox attribute set to Yes in the Jukebox resource. This same
functionality is available, but not automatically enabled for all other non-VTL
jukeboxes.
To enable this feature on non-VTL jukeboxes on the NetWorker server:
1. Set the environment variable FORCE_REC_AFFINITY to Yes.
2. Restart the NetWorker processes.
Cloning with EMC Disk Library using an embedded storage node 61

Production storage node cloning of data to physical tape

This section outlines the advantages and disadvantages of cloning data to physical
tapes:
◆ The NetWorker software can clone from virtual tape in the disk library through a
production storage node to a SAN-attached tape library to produce copies of save
sets. This operation is a standard NetWorker cloning procedure.
◆ For the disk library, a virtual tape drive works in conjunction with a
SAN-attached target tape device to complete the cloning process.
◆ Cloning from a production storage node to a second storage node can also be
performed over IP.
IMPORTANT
Do not use a production storage node to perform cloning operations when the
embedded storage node cloning capability is present.
Advantages
The advantages of cloning data to physical tapes include the following:
◆ Cloning can occur with the disk libraries under NetWorker control with standard
NetWorker policy support. Multiple retentions policies for different cloned copies
of data can be used.
◆ Cloning can occur at the save set level.
Note: An entire save set can be cloned.
◆ Copying can occur from one tape type (virtual) to another tape type (target tape
library), also known as tape conversion.
◆ Copying can occur from multiple virtual tapes to a single tape, also known as
tape stacking.
Disadvantages
The disadvantages of cloning data to physical tapes include the following:
◆ Requires storage node licenses.
◆ Requires maintenance of front-end SAN infrastructure to a target tape library as
well as the virtual tape library.
◆ Consumes SAN bandwidth as data must be from virtual tape over the SAN to a
target device on the SAN.

5
NetWorker Module
for Microsoft
Applications

◆ Cloning with NetWorker Module for Microsoft Applications ............................... 64
◆ NMM save sets .............................................................................................................. 65
◆ Examples of NMM save sets........................................................................................ 68
◆ Identifying NMM save sets.......................................................................................... 72
◆ Cloning using NMM..................................................................................................... 72
◆ Validating a clone operation ........................................................................................ 79
◆ Recovering cloned save sets ........................................................................................ 80
◆ Troubleshooting NMM clone operations................................................................. 108
NetWorker Module for Microsoft Applications 63

NetWorker Module for Microsoft Applications
Cloning with NetWorker Module for Microsoft Applications

Cloning is used to replicate backups to a longer-term retention media pool. Cloning
allows for secure offsite storage, that is, the transfer of data from one location to
another and verification of backups.
Unlike filesystem backups where one filesystem results in one save set, the
NetWorker Module for Microsoft Applications (NMM) software uses Volume
Shadow Copy Service (VSS) snapshot technology to create a point-in-time copy of an
application. This results in multiple save sets regardless of the filesystems or clients
involved. Because the NMM software creates multiple save sets during a run of a
NetWorker backup group, care must be taken to ensure that all save sets that were
created during an NMM backup are included in the cloning process. Failing to clone
all these save set may result in an inability to perform a full and consistent restore
from the clone copy.
When deploying a cloning solution for the NMM software, ensure that:
◆ NetWorker server and storage node software and patches have been installed
correctly and that those versions support NMM cloning. Table 3 on page 64
provides more details.
IMPORTANT
The following NetWorker server versions are required for successful NMM
cloning and recovery. Quick and effective recovery of NMM data from expired
or cloned data cannot be assured if the versions detailed are not used and the
recommendations and practices outlined in this guide and in the NetWorker
Procedure Generator are not followed.
◆ All of the NMM save sets are properly cloned.
Table 3 NetWorker server support matrix
NetWorker server and storage node version Required hotfix or version
NetWorker server 7.6.2 None
NetWorker server 7.6.1 Cumulative build NetWorker server 7.6.1.5a or later
NetWorker server 7.6.0 Cumulative build NetWorker server 7.6.1.5b or later
NetWorker server 7.5.4 Cumulative build NetWorker server 7.5.4.2 or later
NetWorker server 7.5.3 and earlier Cumulative build NetWorker server 7.5.4.2 or later
a. Data Domain to Data Domain cloning requires 7.6.1.5 or later. If Data Domain to Data Domain cloning is not used, then
NW 7.6.1.1 or higher can be used.
b. Data Domain to Data Domain cloning requires 7.6.1.5 or later. If Data Domain to Data Domain cloning is not used, then
NW 7.6.1.1 or higher can be used.

NMM media database records

The NetWorker media database contains a record of every save set that the
NetWorker software creates. It is important to ensure that the media database records
for NMM based backups are used so that the correct list of save sets is obtained.
Use the information in the media database to:
◆ Determine which save sets are part of the NMM backup.
◆ Identify and confirm the save sets that are required to be cloned.
◆ Identify and confirm the save sets that are required to be recovered.
Establish the following media database retention policies:
◆ Set the retention policy in the NMM client resources to insure that you maintain
all of the media database entries for all of the save sets that are expected to be
used for data recovery. Media database entries are removed only when a volume
that contains the save sets is recycled.
◆ Remove or delete the NetWorker media database entries only under the following
circumstances:
• The recovery of the save sets on a particular volume is no longer expected.
• All of the save sets have been successfully cloned to other volumes.
◆ Maintain all bootstrap backups for all of the periods that the media database
entries have been removed.
Note: The media database record is separate to the file index records.
NMM client file index

The client file index records are valid only for the browse period and occupy more
disk space than the NMM media database entries.
The removal or purging of the NMM client index entries is not as critical as the
removal of media database entries.
NMM save sets

The NMM software presents challenges for cloning. Unlike traditional NetWorker
client backups where a single save set is produced, a single NMM backup creates
multiple save sets with different purposes. These save sets are all linked to the
backup data and must be treated as a set to ensure that recovery can be performed.
Depending on the type of cloning that you are performing, you need to be able to:
◆ Identify the number and name of these save sets.
◆ Ensure that these save sets are all copied and retained when creating clones,
extending the data retention of clones, or recovering clones.
NMM save sets 65

The following topics provide an overview of the save sets created during a single
backup group:
◆ “Cover save set” on page 66
◆ “Rollover save set” on page 66
◆ “Metadata save set” on page 67
◆ “Display save set” on page 67
◆ “Dummy save set for Microsoft Exchange 2007 and Microsoft Exchange 2010
only” on page 67
◆ “Snap session ID” on page 68
Cover save set

A cover save set is a special save set that was introduced for snapshot management:
◆ The cover save set is a placeholder save set that was first created in the backup
workflow. The cover save set does not contain the actual backup data (rollover),
but is essential to the recovery of that data.
◆ The cover save set is a hidden save set. Media database utilities and reporting do
not typically display this save set by default. There are forms of the media
database query CLI that will display the save set.
◆ Multiple cover save sets are created when multiple filesystems are backed up.
Backup optimization logic splits the backup into multiple save sets by filesystem
so that the backup can be performed in parallel. A separate cover save set is
created for each of these filesystem save sets.
◆ The save set name for the cover save set is the same as the save set name for the
application or filesystem being backed up. For example, if the save set name from
the client resource was APPLICATIONS:\Microsoft Exchange 2007\First Storage
Group, the cover save set would have this same name.
◆ The browse and retention period for the cover save set is recorded in the media
database as having no browse or retention expiration. The cover inherits the
browse and retention of its rollover save set pairing.
Rollover save set

A rollover save set is the save set that contains the data:
◆ A rollover save set is associated with a cover save set to form a cover-rollover
pairing. A rollover save set is fully visible with the media database CLI and
reporting interfaces.
◆ The backup optimization logic splits the backup into multiple save sets based on
the filesystems that are being backed up. For environments where multiple
filesystems are backed up, there will be multiple rollover save sets created for a
single run of the NetWorker group. Each of these rollover save sets is associated
with its own cover save set.
◆ The save set name for the rollover save set is the same as the save set name for the
application or filesystem that is being backed up. For example, if the save set
name from the client resource is APPLICATIONS:\Microsoft Exchange 2007\First
Storage Group, then the rollover save set would have this same name.
◆ The browse and retention period for a rollover save set follows standard
NetWorker behavior, and is set based on the client resource or other overrides.

Metadata save set

A metadata save set is a special save set that contains additional metadata that is
required by the NMM software to perform restore operations, including:
◆ VSS documents which records the VSS components that were used during the
backup process.
◆ File history and other information.
Consider:
◆ A metadata save set is fully visible with the media database CLI and reporting
interfaces.
◆ The save set name for the metadata save set is the same name of the metadata file
that was created and backed up from disk. For example,
C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT1192235146.xml
◆ The browse and retention period for a metadata save set follows standard
NetWorker behavior, and is set based on the client resource or other overrides.
Display save set

A display save set contains no backup data. It only contains index records that are
used to display the backup in the NetWorker User program.
Consider:
◆ The display save set is a special type of cover save set that has no associated
rollover save set pairing.
◆ The display save set is not associated with a cover save set. It is a special type of
cover save set that has no rollover.
◆ Unlike the cover save sets associated with rollover data save sets, the display save
set is fully visible with the Media Database Query utilities.
◆ The save set name for the display save set is always VSS:/.
◆ The browse and retention period for the display save set is recorded in the media
database as having no browse or retention expiration. This save set inherits the
browse and retention of other save sets for the same backup.
Dummy save set for Microsoft Exchange 2007 and Microsoft Exchange 2010 only
A dummy save set is specific to passive node backups for Microsoft Exchange Server.
The dummy save set does not contain any data and is used as part of the NetWorker
scheduling workflow to manage index entries for the passive and active nodes. The
save set is not required as part of the recovery process and there is no requirement to
clone this save set.
NMM save sets 67

Snap session ID
The snap session ID is a unique identifier that can be used to identify save sets that
belong to a single backup instance.
The *snap_sessionid attribute provides additional information on the media database
record that aids the NetWorker server and the NMM software in determining the
relationship among save sets. This information is stored in the Media Database
Record Attributes field. The *snap_sessionid attribute appears on all save sets created
by the NMM software.
The *snap_sessionid attribute has the following characteristics:
◆ Is filled in with a unique number that is generated at the start of running the
backup on the client. If multiple clients are in the group, each client will be
assigned its own *snap_sessionid value.
◆ Provides a grouping of save sets created for a single backup.
◆ Is used internally by the NMM and the NetWorker software.
◆ Can be used to inspect the media database query results to identify the group of
save sets for a single backup.
Examples of NMM save sets

This section describes the following examples:
◆ Figure 9 on page 69 illustrates the NMM save sets that were created by a single
run of a backup group and how they are linked.
◆ Figure 10 on page 71 illustrates a single group that contains three clients which
generate a total of 18 save sets.
A single NetWorker client resource in the NetWorker group

Figure 9 on page 69 illustrates an example that is based on the Microsoft Exchange
Server. However, the same principles can be applied to all scheduled NMM
application backups.
In this example:
◆ There is one cover-rollover save set pair for each filesystem per save set on a per
client basis.
◆ There is one metadata and display save set per client resource.
◆ The snapshot session ID will be unique for each client.
◆ The number of save sets is likely to consist of multiple groups of save sets as
several clients and data sets are included.

Figure 9 NMM Microsoft Exchange Server save sets that were created during a single run
Table 4 on page 69 provides a summary of the save sets within the media database
and was created by using the output from the following command:
mminfo -S -s NetWorker_server_name -q group=group_name
Note: To display the cover save sets, use -S in combination with the -q group=group_name
command. When used in combination with certain -r flags, the cover save sets are not
displayed.
Table 4 NMM Microsoft Exchange Server save sets
Save set name Description SSID Flags Media database attributes
APPLICATIONS:\Microsoft Exchange 2007\ Rollover (data) save set for the 4239685367 vF coverid:4256462581;
ThirdStorageGroup files of E:\ or F:\. *snap_sessionid:1286895022;
APPLICATIONS:\Microsoft Exchange 2007\ Rollover (data) save set for the 4206130936 vF *coverid:4222908151;
ThirdStorageGroup files of E:\ or F:\. *snap_sessionid:1286895022;
C:\ProgramData\EMC\NetWorker\LG_VSS_CLIE Metadata save set 4189353746 vrF *snap_sessionid:1286895022;
NT1275155189.xml *stream_metadata:Yes;
VSS:/ Display save set 4172576538 vKF *snap_sessionid:1286895022;
Examples of NMM save sets 69


◆ The relationship between the other save sets is held in the *snap_sessionid
attribute.
◆ All save sets have the same *snap_sessionid value for this client within this group
at this backup time. Other clients and other groups that occur during the same
backup time will have different session_ids.
◆ Clients and groups that are run at different backup times will have different and
unique session IDs.
NMM save set example with a NetWorker group

Figure 10 on page 71 illustrates a single group that contains three clients which
generate a total of 24 save sets. Most of these save sets will be required for the cloning
and recovery operations. The ability to determine the appropriate session IDs and
save sets is critical to successful cloning and recovery operations. This example is
based on Microsoft Exchange. However, the same principles can be applied to all
scheduled NMM application backups.
In this example:
◆ There is one rollover save set pair for each filesystem per save set on a per client
basis.
◆ There is one metadata and display save set per Client resource.
◆ The snapshot session ID will be unique for each client.
◆ Two pairs of save sets (four in total) with the name APPLICATIONS:\Microsoft
Exchange 2007\ThirdStorageGroup. These are the cover rollover save set pairs.
◆ The *connected save sets and coverid attributes are used to link the two pairs of
save sets:
• The K flag indicates the cover save sets.
• One pair is for the files on the E:\ drive.
• The other pair is for the files on the F:\ drive.
The relationship between the other save sets is held in the *snap_sessionid attribute.
All save sets have the same *snap_sessionid value for this client within this group at
this backup time. Other backup groups, clients, or even the same groups and clients,
which are run at different times will have different and unique session IDs.

Figure 10 NMM save sets that were created from a single group
Examples of NMM save sets 71

Identifying NMM save sets

You can use the following mminfo command to identify NMM save sets:
Note: Use the mminfo -S -s NetWorker_server_name -q group=group_name to identify all the

roll over save sets together with their associated cover save sets. There is no other way to
perform this task.
Other flags can be added to this command to limit the save sets that are displayed.
Cloning using NMM

Once the save sets that are to be cloned have been identified, you can use one of the
following options to initiate the clone operation:
◆ “Automated cloning” on page 72
◆ “Save set cloning” on page 73
◆ “Scheduled clone” on page 74
◆ “Volume cloning” on page 76
◆ “Scripted cloning” on page 77
Note: The schedule cloning feature is supported in NetWorker release 7.5.x and later.
Automated cloning
Save sets can be automatically cloned when the backup group that contains the save
set has completed. Because the cloning occurs immediately after the group completes
this clone method is suitable for smaller environments, or a small number of clients
where the clone operations are required to be completed quickly and automatically as
part of the backup window:
To configure automated cloning:
1. Connect to the NetWorker server in NMC.
2. In the NetWorker Administration window, select Configuration.
3. Right-click the NMM group resource and then select Properties.
4. Specify the Clones option.
5. Select the clone pool that will be used to direct the NMM backups.
Note: Automated cloning identifies all of the NMM save sets without any further required
action.

Save set cloning

When using the NMC save set cloning feature, ensure that all save sets that were
generated in the NMM backup are included in the clone.
To verify that all save sets that were generated in the backup are included in the
clone:
1. Connect to the NetWorker server by using NMC.
2. Click Media.
3. In the left navigation tree, select Save sets.
4. Determine the list of save sets to be cloned by building a required save set query.
Table 5 on page 73 lists the supported query options.
Table 5 NMM supported query options
Save set query Supported

option by NMM Considerations
Client name Yes Use the client name for the NMM host whose save sets will be cloned.
Note: The index backup will not be cloned if this option is selected.If the save set expires then indexes cannot be
recovered to make the save set browsable, but would require to run scanner.
Save set No Do not use this feature. There are multiple save set names for each backup.
Save set ID No Do not use this feature.
Volume Yes When a query is performed by volume:

• Always determine if multiple volumes were used during the backup.
• Include all of these volumes in the query.
If using a snapshot pool, include that volume.
Pool Yes This feature should not be used in combination with the group query option.
When a query is performed by media pool:
• Always determine if a separate snapshot pool was used.
• Include this pool in the query
Checkpoint ID No Do not use this feature.
Copies Yes The copies value will be:

• 2 for save sets residing on any advanced file type device.
• 1 for all other device types.
• Higher values indicate that the save set has been cloned previously.
Savetime range Yes Always observe the run times for the backup groups that are being cloned to ensure that the time range is sufficient.
Status No Do not use this feature.
Type No Do not use this feature.
Maximum level No Do not use this feature.
5. Select Save Set List to generate the save set list based on the query specifications.
6. Select all of the required save sets that are to be cloned:
a. Right-click an item in the save set list and then click Clone.
b. In the Target Clone Media Pool list, select the appropriate clone pool and then
click OK.
Cloning using NMM 73

Scheduled clone
Clone sessions can be run according to a schedule.
This method is suitable for environments where copies of the save sets are required to
be regularly provided as part of a well-defined maintenance cloning window. This
cloning window runs independent of the main backup operation.
Note: The schedule cloning feature is supported in NetWorker release 7.5.x and later.
Configuring a scheduled clone operation

To configure a scheduled clone operation for either a regular or optimized clone, use
the NMC. For example:
1. From the NetWorker Administration window, select Configuration.
2. In the browser tree, select Clones.
3. From the File menu, select New to open the Create Clone window.
4. In the Name attribute:
a. Create a unique name to identify the scheduled Clone resource.
b. For the Comment attribute, type any additional information.
5. If the clones are to use policies that are different than the original backup policies:
a. Set the Browse Policy attribute.
b. Set the Retention Policy attribute.
6. In the Write clone data to pool attribute, specify the clone pool that targets the
devices on which the clones will be stored.
7. To skip invalid save sets, select Continue on the save set error checkbox.
Note: If the skip invalid save sets attribute is not selected, which is the default setting, an
invalid save set will stop the clone operation and generate an error message.
8. In the Limit number of save set clones attribute, specify a value to limit the
number of clones for each save set that might be produced in the clone pool for a
scheduled clone operation:
• Value of 1 allows only one clone to be made to the target pool for each save set.
For example, use this default value of 1 to manually restart an interrupted
clone operation. This creates only the missed clones, but does not reproduce
clones that were already successfully created.
• Value of 0 (zero) setting allows an unlimited number of duplicate clones.
Note: The NetWorker software allows only one unique save set clone to be stored on a
single volume. If duplicate or multiple clones of the same save set are created, each is
stored on a different volume in the pool.

9. Configure the schedule for the clone session:
Note: To reduce the use of resources, schedule clone operations to be performed after the
backup window have completed.
a. Select Enable to enable the clone session to run at its scheduled times.
b. In the Start Time attribute:
– Set the start time.
– Click the spin arrows or type values.
c. For the Calendar:
– Select either Weekly by day or Monthly by day.
– Select the days on which the clone session is to run.
– To repeat the clone session within a day, specify an Interval Time in hours.
For example:
– If the Start Time is 6 a.m., and the Interval Time is 6 hours, then the clone
session will run at the following times: 6 a.m., 12 p.m., and 6 p.m.
– If the Limit the number of save set clones value is set, then the repeat
clone session will fail after the limit is reached.
10. Select Save Set Filters and then specify the source save sets to include in the
scheduled clone session.
There are two main options:
• Select the clone save sets that match the selections and then limit the save sets
that are to be cloned.
IMPORTANT
When cloning NMM save sets, do not use this option as it is prone to error.
The metadata save set will have a different save set name for each backup.
Specify the following details:

– Savegroups
– NetWorker clients
– Pools (in the case of NMM save sets, always consider if a separate snapshot
pool was used and include this pool)
– Save set levels (this setting can be problematic as backup levels can be
different than expected)
– Save set name, as specified in the NetWorker Client resource
– Save sets from the past number of days, weeks, months, or years
• Select clone-specific save sets and type the names of the source save sets to be
cloned:
a. Use either the save set ID (SSID) or the clone ID (clonid).
b. Use a separate line for each save set name.

To find save set and clone IDs, use either of the following methods:
– In the NetWorker Administration window, click Media and then select
Save Sets in the browser tree. Specify values for the search.
or
– Use the NetWorker mminfo command. The EMC NetWorker Administration
Guide provides details.
11. To review save set filter settings, click Preview Save Set Selection.
12. Click OK to save the scheduled clone session.
Volume cloning
When using the NMC volume cloning feature, ensure that all of the volumes that
were used in the NMM backup are included in the clone.
The NetWorker User program provides the required volumes report that will assist
you in determining the set of volumes to clone for a single NMM backup. The
following examples lists the procedures that should be used for an NMM backup of
Microsoft Exchange. The NetWorker Module Administration Guide for details on how to
obtain the required volumes report for other application types.
To verify that all of the volumes that were used in the NMM backup of Microsoft
Exchange are included in the clone:
1. On the NMM client, launch the NetWorker User for Microsoft Applications
program.
2. In the Client list, select the NMM client. From the left pane:
Note: If the NMM client is part of a cluster, select the virtual client.
a. For NMM 2.2.x, select Recover > Exchange Recover Session > Database.
b. For NMM 2.3, select:
– Recover > Exchange Recover Session > Database for Microsoft Exchange
2007 systems
– Recover > Exchange 2010 Recover Session > Database for Microsoft
Exchange 2010 systems
3. To change the backup time:
a. Click the Calendar icon.
b. Select the required date and time.
c. In the Browse window, select all of the backups that will be cloned.
4. To ensure that the correct full and all associated incremental or differential
backups have been selected:
a. Select one of the marked items.
b. Select Version.
c. Click Cancel.

5. To ensure that the correct volume has been selected:

a. Right-click one of the marked items.
b. Select Required Volumes.
Note: NetWorker volumes are not associated with a snapshot backup until the
snapshot has been rolled over to a NetWorker server. If you select to view the required
volumes for a system component or application data snapshot that has not been rolled
over, no volumes will be displayed.
c. Make note of all the listed volumes.

d. Click OK.
The EMC NetWorker Module for Microsoft Applications Administration Guide
provides detailed information about how to use the NetWorker User required
volumes feature.
6. Close the NetWorker User for Microsoft Applications program.
7. Connect to the NetWorker server by using the NMC.
8. Click the Media button.
9. In the left navigation pane, select either of the following:
• Disk volumes
or
• Tape volumes
10. Select each volume that is displayed in the Required Volumes list:
a. Right-click in the Volume list window and then select Clone.
b. In the Target Clone Media Pool list, select the appropriate clone pool.
c. Click OK.
Scripted cloning
Custom cloning scripts can be used for clone operation. However, custom cloning
scripts cannot be generated by the NetWorker software and require an experienced
administrator to create them. EMC Professional Services can assist with the creation
and testing of custom scripting solutions.
Custom cloning scripts use the NetWorker mminfo and nsrclone commands:
◆ The mminfo command is used to generate the list of save sets to clone.
◆ The nsrclone command is used to perform the clone operation and is given the
save set or the list of save sets to clone.
The EMC NetWorker Command Reference Guide provides detailed information about all
of the query specifications that are supported with the mminfo and nsrclone
commands.

mminfo -q
When using the mminfo -q command to generate the list of save sets to clone, you
can specify a number of attributes to constrain the save sets that are queried in the
media database.
commands.
Table 6 on page 78 lists the following information:
◆ Attributes that are commonly used to specify a query.
◆ Considerations to ensure that all NMM save sets are cloned.
Table 6 Attributes for cloning
Attributes Considerations
Pool Query by pool is supported, but should not be used in combination with the group query option.
When a query is performed by media pool, always consider if a separate snapshot pool was used and include this pool in the
query.
Volume Query by volume is supported.

When a query is performed by volume, always consider if multiple volumes were used during the backup and include all of these
volumes in the query.
If using a snapshot pool, include that volume.
Name Query by save set name is not recommended and is prone to error.
The metadata save set will have a different save set name for each backup.
Savetime Query by time range in conjunction with other parameters is supported.

Always observe the run times for the backup groups that are being cloned to ensure that the time range is sufficient.
Client Query by client name is supported.

When cloning Microsoft Exchange Server 2007 CCR Passive Node backups, always use the NetWorker client name for the
Microsoft Exchange 2007 Virtual Server. Backups are recorded against the Microsoft Exchange 2007 Virtual Server.
When cloning Exchange 2010 Database Availability Group (DAG) backups, always use the NetWorker client name for the
Microsoft Exchange 2010 DAG. Backups are recorded against the Microsoft Exchange 2010 DAG.
Group Query by group name is supported but should not be used in combination with the pool query option.
mminfo -r
When using the mminfo command with the -r option to generate the list of save sets
to clone, there are a number of attributes that can be specified to limit the reported
save set information based on the query used.
IMPORTANT
When using the -r option, do not use sumflags, pool, or volume.
To validate any extended reporting queries, compare the output to the output of the
following command:
This validation ensures that all of the save sets are reported.
commands.

nsrclone
When using the nsrclone command to clone NMM save sets, there are a number of
options that can be specified.
Table 7 on page 79 lists the following information:
◆ Attributes that are commonly used to specify a query.
◆ Considerations to ensure that all NMM save sets are cloned.
Table 7 Options of nsrclone save sets
nsrclone Supported Considerations
-S [ssid [, ssid …] yes Scripts must ensure that all NMM save sets are listed.
-V [volid, [, volid …] yes Scripts must ensure that all volumes written to by an NMM
backup are supported.
-g [group-name] yes This option is supported by NMM.
-t, -e yes Scripts must ensure that all NMM save sets are included in
the time range.
-N [saveset-name] no Do not use this option.

Save set names cannot be predicted ahead of time for the
NMM software.
-l [level spec] no Do not use this option.

Backup levels might be different than expected.
All other options yes All other nsrclone options are supported.
commands.
Validating a clone operation

You must validate that all NMM save sets that are cloned at the start of deployment.
To validate that all the NMM save sets are cloned, use the following mminfo
command:
mminfo -v -ot -q "group=[my-group],savetime>[t1],savetime<[t2] "
-r "ssid,copies,nsavetime,ssflags,savetime(22),name,client"

◆ This query returns all of the save sets for the group in the time range specified
with [t1] and [t2]. Use the MM/DD/YY HH:mm:SS format.
◆ The -ot flag sorts the save sets by time.
◆ The copies value indicates the number of copies.
◆ In order for this command to succeed on UNIX systems:
• The options following -r must be enclosed in quotes.
or
• The (22) following the savetime option must be enclosed in quotes.
Validating a clone operation 79

◆ A save set with a copy count of 1 does not have a clone.

◆ If the backup was done to AFTD, the number of copies for save sets is reported as
2 prior to cloning.
◆ For AFTD/DDBOOST devices, ensure that the copy count is greater than 2.
Compare the output to the original list to ensure that all save sets have been
cloned successfully.
of the query specifications that are supported with the mminfo command.
Recovering cloned save sets

When using cloning, ensure that you can recover the cloned save sets for all of the
recovery scenarios that are expected to occur. These recovery scenarios and the steps
to recover the cloned save sets are likely to be specific to the application and your
specific situation. “Recovery scenarios” on page 80 provides details.
To ensure the recovery of cloned data:
◆ Verify that all relevant recovery scenarios have been accounted for as described in
“Recovery scenarios” on page 80. For example, if you expect to rely on the clone
copy for recovery, then you must ensure that the recovered save sets come from
the clone copy and not from the original volume. This is important for situations
where both or all copies are available, as well as when the original is not.
“Selecting clone volumes to recover data from” on page 90 provides details.
◆ Ensure that all the required save sets and volumes are available for recovery.
“Required save sets and volumes for recovery of cloned data” on page 82
provides detailed information.
◆ Review the application specific recovery considerations. “Configuration
considerations” on page 91 provides details for:
• “Microsoft DPM” on page 91
• “Microsoft Exchange Server 2007 and 2010” on page 92
• “Microsoft Hyper-V” on page 94
• “Microsoft SharePoint 2007 and 2010” on page 94
◆ Ensure that recovery procedures are in place and have been regularly tested as
described in “Recovery tasks” on page 96.
To ensure data consistency when recovering data, ensure that the recovery
procedures are aligned with the application in use. The NetWorker Procedure
Generator provides detailed NMM application specific recovery procedures.
Recovery scenarios
When a recovery operation is initiated, there are two common assumptions about
recovery operation:
◆ That the recovery will be performed within a short period of time after the
backup (hours or days).
◆ That the recovery will use the original data volumes and that the backup server
will be fully operational. You can use the standard NetWorker recovery procedure
because the NMM backups are present in both the client file indexes and the
media database. “Required save sets and volumes for recovery of cloned data” on

However, if the recovery operation occurs after the NetWorker browse or retention
periods have expired or following a site or building loss, then the metadata or
volumes may not be readily available and additional actions might be required. For
NMM application backups, a recovery can be successfully performed only if all of the
relevant save sets and associated metadata are available. Table 8 on page 81 details
the recovery scenarios and necessary actions.
Browse and retention periods

In many restore operations, the request to restore the data arrives soon after the
backup has completed. In these circumstances the browse and retention periods are
likely to be still valid and recovery is simple. “Required save sets and volumes for
recovery of cloned data” on page 82 provides details on how to restore cloned data in
this scenario.
In cases where the browse and retention periods have expired, additional effort might
be required to perform a restore operation. It is important to consider this when
determining the browse and retention periods for the backup and the clone copies.
“Consider the browse and retention policies” on page 27 provides more information
on how to restore cloned data in this scenario.
Identifying the recovery options

If the recovery is not readily available, perform the following:
1. Identify the backup or clone save sets that are required.
2. Investigate the cause and attempt to remedy the situation. Table 8 on page 81
provides details.
3. Seek alternative recovery options if required. “Recovery tasks” on page 96
provides details.
The NetWorker software has various log files that contain information about the
volumes, status, and history of cloning operations. These can be viewed and
monitored from the NetWorker Administration window or recovered from previous
server backups.
Clone-related messages are also logged to the NetWorker message file and the
savegrp log file, which are located in the NetWorker_install_dir\logs directory.
Review the recovery scenarios

If the recovery is not immediately available or successful, review the following list of
recovery scenarios to help determine the cause and the resolution if available.
Table 8 NMM restore scenarios(1 of 2)
Restore scenario Description Section
Recovering original or clone data The NMM backups are present and browsable in both the client file indexes “Restoring cloned data that is
that is browsable. The save sets and in the media database. browsable in the client file index”
appear in both the client file index on page 96
and in the media database.
The browse period has elapsed and The client index information has been purged because the browse period “Restoring recyclable save sets to
the client file index entries have has elapsed. the client file index” on page 97
been purged. Although you can use the media database to identify the volumes and the
save sets, you cannot perform a partial or item-level recovery operation.
If the browse policy has elapsed, you can:
• Use the nsrck -L7 -t command to recover the client file index entries.
or
• Use the scanner command to recreate the client file index entries.
Recovering cloned save sets 81

Table 8 NMM restore scenarios(2 of 2)
The browse and retention periods The media database entries have been marked as expired but the volume “Restoring recyclable save sets to
have both elapsed but the volume has not been recycled (relabeled). the client file index” on page 97
has not been recycled since the If the volume has not been recycled, then the media database entries will
data that is still within the retention still exist. You must mark the media database entries in the media database
period. as eligible for recovery.
The browse and retention periods If the volume has been recycled, then the media entries have been purged. “Selecting clone volumes to
have both expired and the volume In this case the data is longer available to recover from and alternative recover data from” on page 90
has been recycled. recovery sources will need to be used.
One or more volumes are missing Some or all of the original backup volumes are no longer available for • The EMC NetWorker
or are offline. restore: Administration Guide provides
• If the volumes are offsite or in storage, then they can be easily recalled detailed information.
and made available to the online NetWorker server so that the recovery • “Restoring save sets that are
operation can continue. In this situation the media database entries are not in the media database” on
still available and valid. A mount operation or library inventory may also page 101
be required to make the volumes available.
• If the media database entries are not available or are invalid, use the
scanner command to repopulate the media entries so that the
NetWorker server knows what data is on that volume.
The clone volume does not contain If the clone volumes do not contain all of the necessary data for the • “Restoring recoverable save
all of the save sets that are required recovery, then the number of available recovery options might be limited. sets to the client file index” on
to be recovered. Data might be able to be recovered, if: page 99
• The original bootstrap (media and client index) information is available. • “Restoring save sets that are
• The original volumes still exist and can be used for recovery. not in the media database” on
page 101
A recovery of that data might not be possible in cases where:
• No bootstrap backups exist for the period of time where the recovery is
requested.
• The original data volumes are missing or have been recycled.
The NetWorker server does not The NetWorker server has been rebuilt or has been recently recovered and The EMC NetWorker Disaster
have knowledge or any database all or most records of the previous backups are missing. Recovery Guide provides detailed
records of the backup. A full recovery of the media database and client file indexes is required information.
before any client recovery operation can be initiated. The recovery should
include media and client index entries for all the volumes, clients, and dates
available. This relies on the NetWorker server bootstrap backups.
Required save sets and volumes for recovery of cloned data

Before initiating a recovery it is important to ensure that all the required save sets and
volumes are available for recovery:
◆ Since VSS-based backups consist of multiple save sets, ensure that all of these
save sets are available for recovery. The following sections provide details:
• “Generating a media database listing of all of the NMM save sets” on page 83
• “Determining the status of a save set in the media database” on page 86
• “Save set requirements” on page 87
◆ When clone volumes are being used, ensure that all the clone save sets are
available for recovery. “Selecting clone volumes to recover data from” on page 90
provides details.
“Troubleshooting NMM clone operations” on page 108 provides information to assist
if issues are encountered during the restore operation.

Generating a media database listing of all of the NMM save sets

To generate a media database listing of all of the required NMM save sets:
1. At command line prompt on the NetWorker server, type the following command
to generate a list of the NMM cloned save sets in the media database:
mminfo -S -s NetWorker_server_name -c NMM_client_name
-q "group= group_name, savetime>date1, savetime<date2"
-ot 1>output.txt 2>&1
where:
• NetWorker_server_name is the name of the NetWorker server host.
• NMM_client_name is the name of the NMM client host.
• group_name is the name of the group which contained the NMM client when
the backup occurred.
• date1 is at least one day before the date range of the NMM clone to be restored.
• date2 is at least one day after the date range of the NMM clone to be restored.
For example, to list the save set details which reside on a NetWorker server called
krkr-pdc.krkr.local, an NMM client named krkr8x64.krkr.local in a group called
grupa2 on dates Dec 14 13:48:00 2010 and Dec 15 13:57:00 2010, use the command:
mminfo -S -s krkr-pdc.krkr.local -c krkr8x64.krkr.local -q
"group=grupa2,savetime>12/14/2010 13:48:00,savetime<12/15/2010
13:57:00" > out3.txt
2. Edit the output.txt file, which resides in the same directory where the mminfo
command was run.
If the output file contains the following message, the media database does not
contain the NMM save sets for the client or query options specified:
mminfo: no matches found for the query
• Make adjustments to the query options specified in the mminfo command.

or
• Restore the media database. “Restoring save sets that are not in the media
database” on page 101 provides details.
Identifying the Rollover save set

To identify the rollover save set:
1. Identify the most recent full backup for the filesystem or application save set in
the output.txt file.
This save set will:
• Not have a K value in the sflags attribute.
• List full in the level attribute.
For example, a rollover save set for a full backup of APPLICATIONS:\Microsoft
Office SharePoint Services would be:
ssid=4060555534 savetime=14.12.2010 09:21:33 (1292314893)
krkr8x64.krkr.local:APPLICATIONS:\Microsoft Office SharePoint
Services
level=full sflags=vF size=344 files=1
insert=14.12.2010
create=14.12.2010 complete=14.12.2010 browse=14.01.2011 23:59:59
retent=14.12.2011 23:59:59
clientid=bae80470-00000004-4d01e902-4d01e9d7-00500c00-ff26eb29

*ACTUAL_HOST: krkr8x64.krkr.local;
*ACTUAL_PATH: "E:";
*appid: 1;
*coverid: 4094109964;
*snap_sessionid: 1292314809;
group: Default;
Clone #1: cloneid=1292317204 time=14.12.2010 10:00:04
retent=14.12.2011 flags=F
frag@ 0 volid=2332165333 file/rec=4060555534/0 rn=0
last=14.12.2010
2. From this full rollover save set backup, record the following:
• ssid
• All unique cloneid values
• coverid
• *snap_sessionid
For example, for the full backup of "APPLICATIONS:\Microsoft Office
SharePoint Services" on krkr8x64 the values appear as follows:
• ssid =4060555534
• cloneid=1292317204
• *snap_sessionid=1292314809
• *coverid: 4094109964
Identifying the cover save set

To identify the cover save set:
1. Search the mminfo output for the cover save set associated with the full backup
by using the *coverid.
For example, searching for ssid=4094109964 reveals the following save set
information:
ssid=4094109964 savetime=14.12.2010 09:21:30 (1292314890)
krkr8x64.krkr.local:APPLICATIONS:\Microsoft Office SharePoint
Services
level=full sflags=vKF size=4 files=0
insert=14.12.2010
retent=19.01.2038 04:13:59
*connected savesets: 4060555534;
*coverset: Yes;
group: Default;
last=14.12.2010;
Note: The K in the sflags attribute confirms this is a cover save set.
2. Record the SSID and all unique cloneid values. For example, for the cover set of
full backup of "APPLICATIONS:\Microsoft Office SharePoint Services on
krkr8x64" the ssid=4094109964 appears as follows:
• ssid=3523700721
• cloneid=1292330993
• cloneid=1292332326

Identifying additional cover and rollover save sets

To identify additional cover and rollover save sets, use the *snap_sessionid recorded
for the full backup to:
1. Search for other rollover and cover save sets with the same *snap_sessionid that
matches the name of the save set that are being restored.
2. Record the following values for each of these additional cover and rollover save
sets:
• SSID
• All unique cloneid values
For example, search the output.txt file for 1292314809 and a save set name of
APPLICATIONS:\Microsoft Office SharePoint Services reveals the following two
save sets:
◆ ssid=1976609844 (rollover save set)
◆ ssid=2077273033 (cover save set)
Identifying the VSS: save set

To identify the VSS: save set:
1. Search the output.txt file for the save set VSS: that has the same *snap_sessionid
as the rollover save set.
For example, searching for the VSS: save set with the *snap_sessionid 1292314809
reveals the following save set information:
ssid=3859228981 savetime=14.12.2010 09:22:11 (1292314931)
krkr8x64.krkr.local:VSS:/
level=full sflags=vKF size=14572 files=14
insert=14.12.2010
retent=19.01.2038 04:13:59
*coverset: Yes;
group: Default;
last=14.12.2010
2. Make note of the following values for the VSS: save set:
• ssid
• All cloneid values
In this example, the values appear as follows:
• ssid =3859228981
• cloneid=1292317204

Identifying the metadata save set

To identify the metadata save set:
1. Search the output.txt file for the metadata save set that has the same
*snap_sessionid as the rollover save set.
This save set will have a different name for each backup. It can be recognized as a
filename of the form "LG_VSS_CLIENTxxxxxxxxxx.xml".
For example, a search for the XML save set with the *snap_sessionid=1292314809
reveals the following save set information:
ssid=3892783398 savetime=14.12.2010 09:21:58 (1292314918)
krkr8x64.krkr.local:C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT1492
044633.xml
level=full sflags=vrF size=1296680 files=1
insert=14.12.2010
retent=14.12.2011 23:59:59
*ACTUAL_HOST: krkr8x64.krkr.local;
*appid: 1;
*stream_metadata: Yes;
group: Default;
last=14.12.2010
2. Make note of the following values for the XML save set:
• SSID
• Unique cloneid values
In this example the values are as follows:
• ssid=3456591868
• cloneid=1292331004
• cloneid=1292332326
Determining the status of a save set in the media database

To determine the status of a save set in the media database, use the mminfo
command. You can use the ssflags attribute to provide a summary of the status of
each save set.
When generating a report of the ssflags summary of save sets:
◆ An r in the ssflags output denotes that a save set is recoverable and that it has
exceeded its defined browse policy.
◆ An E in the ssflags output denotes a save set that is eligible for recycling and that
it has exceeded its defined retention policy. This is also referred to as an expired
save set.
In the case of incremental or differential save sets, the ssflags value will contain an E
only when all dependent incremental, differential, or full backups have also exceeded
their defined retention policy period.
When all save sets on a volume are eligible for recycling, the volume can be
overwritten.

Save set requirements
Note: Do not use the procedures until you are familiar with all of the NMM save set
requirements.
Recovering data from media that has either expired or is recyclable requires that you
identify the NMM save sets for the backup:
◆ If you are know the list of required save sets that are to be recovered, perform the
steps outlined in “Using the backup time to list all of the cover save sets” on
page 87.
◆ If you do not know all of the required save sets that are to be recovered, perform
the steps outlined in“Using savetime to determine the full set of save sets to
recover” on page 87.
Using the backup time to list all of the cover save sets
If you are familiar with the required save set for the NMM software, you can use the
backup time to ensure that all of the cover save sets are displayed:
mminfo -v -ot -q "group=group_name,saveset>date1,saveset<date2"
-r "ssid, cloneid, nsavetime, ssflags, level, savetime(22), ssbrowse,
ssretent, name, client, volume" 1>output.txt 2>&1
where:
◆ group_name is the name of the group which contained the NMM client when the
backup occurred.
◆ date1 is at least one day before the date range of the NMM clone to be restored.
◆ date2 is at least one day after the date range of the NMM clone to be restored.
This query will return all of the save sets for the group in the time range specified.
The -ot flag sorts the save sets by time and the information is stored in a file called
output.txt. This file resides in the same directory from which the mminfo command
was run.
Note: If you experience restore issues using this easier method, use the procedures in
“Generating a media database listing of all of the NMM save sets” on page 83 to validate the
output.
Using savetime to determine the full set of save sets to recover

You can use the mminfo command to identify the required savetime range for the
backup version that is being restored by querying the media database. The savetime
range is used to query the media database.
The savetime range is the day before (date1) and the day after (date2) the date of the
backup which is to be restored.
IMPORTANT
If the backup that is to be restored was an incremental level backup or a
differential level backup, you must increase the savetime range to include the
sequence of the full and the level backups.

To determine the full set of save sets to recover:

1. For the version of the backup that is being restored, identify the required
savetime range.
If you are restoring filesystem or Microsoft Exchange data, you might need to:
a. Expand the savetime range to include the sequence of full and incremental
backups.
b. Adjust the savetime range accordingly.
2. Identify the save set name that was used to backup for the filesystem or
application data that is being restored.
3. Use the savetime range to generate the media database listing for the backup:
mminfo -S -s server -c client -q
"group=group, savetime>date1, savetime<date2"
For example, use the following command to restore a backup that occurred on
4/28/2010:
mminfo -S -s bv-nwsvr-1 -c bv-exch-1 -q
"group=BV-EXCH-1_Group,savetime>4/27/2010,savetime<4/29/2010"
where:
• bv-exch-1 is the NMM client.
• bv-nwsvr-1 is the NetWorker server.
• BV-EXCH-1_Group is the group.
4. Identify the most recent full backup for the filesystem or application save set in
the mminfo report.
The full backup should be identified by using a rollover save set:
• Save set name of the application or filesystem.
• Save set name does not have the K in the sflags.
For example, a rollover save set for a full backup of APPLICATIONS:\Microsoft
Exchange 2007\ThirdStorageGroup would be:
ssid=4239685367 savetime=10/12/2010 7:55:51 AM (1286895351)
mb-mbox-2.mb2.emc.com:APPLICATIONS:\Microsoft Exchange
2007\ThirdStorageGroup
level=full
sflags=vF
size=14695900
files=16
insert=10/19/2010
create=10/12/2010 complete=10/12/2010 browse=11/20/2010 1:48:36 AM
retent=10/20/2011 1:49:25 AM
clientid=1db239da-00000004-4cb3dee0-4cb3dedc-00045000-a134ae56
*ACTUAL_HOST: mb-mbox-2.mb2.emc.com;
*ACTUAL_PATH: \
C:\\Program
Files\\Legato\\nsr\\tmp\\SnapshotMountPoint\\3776-1286895116-1";
*appid: 1;
*coverid: 4256462581;
group: MB-MBOX-2_Exchange;
Clone #1: cloneid=1286895351 time=10/12/2010 7:55:51 AM
retent=10/20/2011 flags=F
frag@0 volid=4273201045 file/rec=4239685367/0 rn=0 last=10/19/2010

5. Obtain the *snap_sessionid from the full backup.

For example, from the full rollover save set found in step 4 on page 88, the
*snap_sessionid is 1286895022.
6. For the rollover save set found in step 4 on page 88:
a. Use the *coverid parameter to find the cover save set associated with the
rollover save set.
b. Make note of the cover save set ID for later.
For example, in step 4 on page 88 search for the 4256462581 save set ID because
the coverid is listed as *coverid: 4256462581:
ssid=4256462581 savetime=10/12/2010 7:55:47 AM (1286895347)
bv-exch-1.mb2.emc.com:APPLICATIONS:\Microsoft Exchange
2007\ThirdStorageGroup
level=full
sflags=vKF
size=420
files=1
insert=10/19/2010
create=10/12/2010 complete=10/12/2010 browse=1/25/2038 9:01:06 PM
retent=1/25/2038 9:03:24 PM
*connected savesets: 4239685367;
*coverset: Yes;
group: bv-exch-1_Exchange;
7. Find the additional cover save sets and their associated rollover save sets:
a. Use the *snap_sessionid found in step 4 on page 88 to search for other covers
and rollover save sets that match the save set name that is being restored.
b. Make note of the rollover and cover save set IDs for later.
8. Identify the display (VSS:/) save set:
a. Search for the save set name for the following:
– VSS:/
– *snap_sessionid
b. Make note of the save set ID for later.
For example, the matching VSS:/ save set appears as follows:
ssid=4172576538 savetime=10/12/2010 7:56:26 AM (1286895386)
bv-exch-1:VSS:/
level=full sflags=vKF
size=6868
files=6
insert=10/19/2010
create=10/12/2010 complete=10/12/2010 browse=1/25/2038 9:00:41 PM
retent=1/25/2038 9:02:59 PM
*coverset: Yes;
group: BV-EXCH-1_Group;
Clone #2: cloneid=1287511204 time=10/19/2010 11:00:04 AM
retent=1/25/2038
flags=F
frag@0 volid=4273851359 file/rec=4172576538/0
rn=0 last=10/19/2010

9. Search for the *snap_sessionid to find the metadata save set:

a. Although this save set will have a different name for each backup, it can be
recognized as a filename of the form LG_VSS_CLIENTxxxxxxxxxx.xml.
b. Make note of the save set ID for later.
For example, the matching metadata save set appears as follows:
ssid=4189353746 savetime=10/12/2010 7:56:19 AM (1286895379)
bv-exch-1.mb2.emc.com:C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT12
75155189.xml
level=full sflags=vrF size=1348668 files=1
insert=10/19/2010
create=10/12/2010 complete=10/12/2010 browse=11/20/2010 1:48:20 AM
retent=10/20/2011 1:49:08 AM
*ACTUAL_HOST: bv-exch-1.mb2.emc.com;
*appid: 1;
*stream_metadata: Yes;
group: bv-exch-1_Exchange;
Selecting clone volumes to recover data from

Review the following procedure to ensure that the recovery comes from the clone
copy and not the original in situations where both or all of the copies are available.
The volume, either a clone or original volume, that is selected for a recovery
operation is determined as follows:
1. The highest priority is given to the volume (clone or original volume) that has a
complete, non-suspect, save set status. A complete save set that is suspect has a
higher priority than an incomplete non-suspect save set.
The EMC NetWorker Administration Guide provides information about changing
the status of a save set.
2. If the volumes still have equal priority, then priority is given to the mounted
volume.
3. If the volumes are mounted, then priority is based on the media type. The media
types from highest-to-lowest priority are:
a. Advanced file type device
b. File type device
c. Other (such as tape or optical)
4. If the volumes are not mounted, then priority is based on the media location. The
media locations from highest-to-lowest priority are:
a. Volumes in a library
b. Volumes in an EMC AlphaStor® or SmartMedia controlled library
c. Volumes that are not in a library but are onsite (offsite flag is not set)
d. Volumes that are offsite (offsite flag is set)
5. Use the nsrmm command to specify that a volume is offsite. For example:
nsrmm -o offsite -V volume_id

The volumes required for recovery appear in the Required Volumes window of the
NetWorker User program. The EMC NetWorker Administration Guide provides
information on viewing volumes that are required for data recovery.
You can also run the scanner program on a clone volume to rebuild entries in the
client file index, the media database, or both. After you re-create the entries, normal
recovery is available. The EMC NetWorker Administration Guide provides information
on restoring a save set entry in the online indexes.
Configuration considerations
The configuration considerations differ for each application that is supported by the
NMM software:
◆ “Microsoft DPM” on page 91
◆ “Microsoft Exchange Server 2007 and 2010” on page 92
◆ “Microsoft Hyper-V” on page 94
◆ “Microsoft SharePoint 2007 and 2010” on page 94
◆ “Microsoft SQL 2005 SP4, 2008 SP2, and 2008 R2” on page 95
Microsoft DPM
When restoring Microsoft DPM data from clone save sets, consider the following.
Serialized rollover
The NMM software will serialize rollovers for individual Microsoft DPM save sets.
For larger Microsoft DPM configurations, the NetWorker group may take more than
24-hours to complete.
When performing the cloning restore procedures to identify volumes and save sets,
consider the backup window for the original backup might have spanned a 24-hour
period.
Microsoft DPM replica save sets

If you are restoring an individual Microsoft DPM replica, determine the save set of
the Microsoft DPM replica that you are going to restore. This will save time when
identifying save sets regardless of whether you are repairing media that has been
marked recycled or when scanning volumes to regenerate save sets.
Snapshot session per Microsoft DPM replica save set

The NMM software will create one snapshot per Microsoft DPM replica save set as
required by the Microsoft DPM Writer. The save sets described in the “NMM save
sets” on page 65 will exist for each individual Microsoft DPM replica save set that is
backed up as part of the NetWorker group.
When identifying required save sets for restore, for each Microsoft DPM replica save
set that is being restored, you must also identify the associated metadata and display
save set. The snapshot session ID media database attribute will allow you to make
this association.

Determining the rollover save set name

The rollover save set is the backup save set that contains the backup of the NMM
data.
When inspecting the media database, there are two ways to determine the name of
the save sets:
◆ Use NMC to inspect the save set field for the NMM client configured on the
NetWorker server.
◆ On the NMM client, type the following command:
nsrsnap_vss_save -?
Microsoft Exchange Server 2007 and 2010

When restoring Microsoft Exchange 2007 and 2010 data from clone save sets, consider
the following.
Typical configurations
Table 9 on page 92 lists factors to consider for a typical NMM configuration for
Microsoft Exchange Server 2007 and Microsoft Exchange Server 2010 when selecting
clone save sets.
Note: Microsoft Exchange Server 2010 is supported in only NMM 2.3 and later.
Table 9 Typical NMM configurations
Factor Description
Multiple NetWorker groups Multiple NetWorker groups are deployed for a single Microsoft Exchange Server
according to the configuration requirements of the NMM software.
Microsoft Exchange storage group save The Microsoft Exchange Storage Group save sets are listed in the Client resource
sets according to the configuration requirements of the NMM software. There may be one or
many storage group save sets per NMM client.
Frequent backup failures Backup failures might occur in Microsoft Exchange Server environments and this may
cause multiple retries within a 24-hour period. Failures might result in partially
successful backups that should be included in the restore process.
Note: Although Microsoft currently supports 50 Exchange storage groups per Microsoft
Exchange Server, the NetWorker software supports a maximum of 16 Exchange storage groups
per Exchange Server in a single NetWorker backup group.
Exchange 2007 Storage Group save sets

If you schedule multiple Microsoft Exchange Storage Groups as individual save sets
of a single NetWorker Group, determine the save set of the Microsoft Exchange 2007
Storage Group that you are going to restore. This will save time when identifying
save sets regardless of whether you are repairing recycled media or scanning to
regenerate save sets.
Exchange 2010 Database save sets

If you schedule multiple Microsoft Exchange 2010 Databases as individual save sets
of a single NetWorker Group, determine the save set of the Microsoft Exchange 2010
Database that you are going to restore. This will save time when identifying save sets
regardless of whether you are repairing media that has been marked recycled or
when scanning volumes to regenerate save sets.
When repairing media that has been marked recycled or when scanning volumes,
always include all of the writer-level save sets in the backup.

Writer save set

If you are using a writer-level save set, include all writer save sets for a single backup
in the repairing recycled media or scanning process.
Log chain
If you are restoring to an incremental backup, restore the full set of backups from the
time of the full backup to the time of the incremental backup.
Backup Group Retry

If NetWorker groups are retried after backup failures, multiple backups for an
individual Microsoft Exchange Storage Group will have taken place within a 24-hour
window.
Depending on the cause of the original backup failure, there might be multiple valid
backups for the Microsoft Exchange Storage Group that you are restoring.
If you are cloning Microsoft Exchange incremental backups, include these retry
backups in the recovery process if they fall in the time range between the full backup
and the required recovery time.

data.
There are two ways to inspect in the media database to determine the name of the
save sets:
NetWorker server.
◆ On the NMM client:
• If the Microsoft Exchange 2007 server is a stand-alone node or Local
Continuous Replication (LCR) active node, type:
nsrsnap_vss_save -?
• If the Microsoft Exchange 2007 server is on an Exchange 2007 Single Copy

Cluster (SCC) node, type:
nsrsnap_vss_save -c virtual_server_name -?
Note: If the application server is on a virtual host, run this command from the physical
node that is currently hosting the application server.
• In an Exchange 2007 CCR environment, type the following on both the active
and passive nodes as one line:
nsrsnap_vss_save -c physical_server_name -A
NSR_VIRT_SERV=virtual_server_name -?
where:
– physical_server_name is the name of the physical NetWorker server in the
environment.
– virtual_server_name is the name of the virtual NetWorker server in the
environment.
• If the Microsoft Exchange 2010 server is a stand-alone node, type:
nsrsnap_vss_save -?

Microsoft Hyper-V
When restoring Microsoft Hyper-V data from clone save sets, consider the following.
Microsoft Hyper-V Virtual Machine save sets

If you schedule multiple Microsoft Hyper-V Virtual Machines as individual save sets
of a single NetWorker group, determine the save set of the Microsoft Hyper-V Virtual
Machine that you are going to restore. This will save time when identifying save sets
regardless of whether you are repairing recycled media or scanning to regenerate
save sets.
Writer save set

When repairing media that has been marked recycled or when scanning volumes to
regenerate save sets, always include all of the writer-level save sets in the backup.

data.
the save sets:
NetWorker server.
◆ On the NMM client, run the following command:
nsrsnap_vss_save -?
Microsoft SharePoint 2007 and 2010

When restoring Microsoft SharePoint 2007 and 2010 data from clone save sets,
consider the following.
Microsoft SharePoint farm-level restore

If you are performing a Microsoft SharePoint farm-level restore, you must include all
farm clients that were backed up in the restore procedures.
If your backup configuration performed backup of individual Microsoft SharePoint
content databases under different backup schedule that the Microsoft SharePoint
farm-level backup, determine if both backup types are required for the backup time
that you are recovering from.
For example, if your Microsoft SharePoint farm-level backup runs only on Sunday,
and your Microsoft SharePoint content database backup runs Monday through
Saturday, if you are restoring to a backup that occurred on Tuesday, you will need to
identify:
◆ The previous Sunday's Microsoft SharePoint farm-level backup.
◆ The Tuesday Microsoft SharePoint content database-level backup.
Microsoft SharePoint content database-level restore

If you are performing a Microsoft SharePoint content database-level restore, you
must include the following:
◆ Farm clients that were backed up in the backup procedures
◆ The Microsoft SharePoint Web Front End where the backups were taken
◆ The Microsoft SQL Server host

Writer save set

regenerate save sets, always include all of the writer-level save sets in the backup.

data.
the save sets:
NetWorker server.
◆ On the NMM client for each host in the SharePoint farm, type the following
commands:
• If the Microsoft SharePoint host is one of the following, type the following
command:
nsrsnap_vss_save -?
– Stand-alone Microsoft SharePoint system

– Microsoft SharePoint Web Front End where the backups are run
– Microsoft SharePoint Search/Index host
– Microsoft SQL Server host that is not clustered
• If the Microsoft SQL Server host is a SQL clustered instance, type the following
command:
• If the application server is on a virtual host, type the following command from
the physical node that is currently hosting the application server:
Microsoft SQL 2005 SP4, 2008 SP2, and 2008 R2

When restoring Microsoft SQL data from clone save sets, consider the following.
Microsoft SQL Database save sets

If you schedule multiple Microsoft SQL databases as individual save sets of a single
NetWorker Group, determine the save set of the Microsoft SQL database that you are
going to restore.
This will save time when identifying save sets regardless of whether you are
repairing recycled media or scanning to regenerate save sets.
SQL Writer save set or SQL Instance save set

regenerate save sets, always include all of the following save sets in the backup:
◆ All SQL writer-level save sets
◆ All SQL instance-level save sets


data.
There are two ways to determine the name of the save sets to inspect in the media
database:
NetWorker server.
◆ On the NMM client, type the following commands:
• If the Microsoft SQL Server host is not a SQL clustered instance, type:
nsrsnap_vss_save -?
• If the Microsoft SQL Server host is a SQL clustered instance, type:

• If the application server is on a virtual host, type the following command from
the physical node that is currently hosting the application server.
Recovery tasks
This section discusses recovery from cloned save sets to help you identify what save
sets are required, and ensure that these save sets are in a state that can be used for
recovery:
◆ “Restoring cloned data that is browsable in the client file index” on page 96
◆ “Restoring recyclable save sets to the client file index” on page 97
◆ “Restoring recoverable save sets to the client file index” on page 99
◆ “Restoring save sets that are not in the media database” on page 101
To restore the data from full and incremental backups:
◆ For each backup, repeat the tasks listed in this section until all of the incremental
backups that occurred after the full backups have been recorded.
◆ To restore multiple clients, repeat the recovery tasks for each client.
Restoring cloned data that is browsable in the client file index

Recover cloned data that is browsable by using the standard NetWorker recovery
procedure since the NMM backups are present in both the client file indexes and are
in the media database.
No special operation is required to recover cloned data. The EMC NetWorker Module
for Microsoft Applications Guide provides detailed information.
To perform an NMM restore operation:
1. On the NMM client, launch the NetWorker Module for Microsoft Applications
program.
2. In the Client list, select the NMM client.
Note: If the NMM client is part of a cluster, select the virtual client.

3. In the left pane:

• For NMM 2.2.x, select Recovery > Recover Session.
• For NMM 2.3, select Recover > SharePoint Recovery.
4. To change the backup time:
a. Click the Calendar icon.
b. Select the required date and time of the NMM backup.
5. In the Browse window, select all of the required NMM items in the backup.
6. To ensure that the correct full and all of the associated incremental or differential
backups have been selected:
a. Right-click on one of the marked items.
b. Select Version.
c. Click Cancel.
7. To ensure that the correct volume has been selected:
a. Right-click one of the marked items.
b. Select Required Volumes.
c. Make note of all the listed volumes.
d. Click OK.
The EMC NetWorker Module for Microsoft Applications Administration Guide provides
information about how to use the Required Volumes feature.
7. Start the recover operation. The EMC NetWorker Module for Microsoft Applications
Guide provides detailed information.
Restoring recyclable save sets to the client file index

For each save set, if the backup has expired but its save sets are still listed as
recyclable in the mminfo output, you must restore the online client file indexes.
To restore the online client file indexes:
1. For each save set, reset the browse and retention time:
nsrmm -e time1 -w time2 -S SSID/cloneid
where
• time1 is the required retention time.
• time2 is the required browse time.
• SSID is the save set value recorded for each display and cover save set from
the output of the mminfo command.
If the cloneid is not identified with the -S option, the following error message
appears:
Save set ssid cannot be marked as notrecyclable. Please specify the
ssid/cloneid of the particular clone instance.

2. For each save set, use its associated SSID and cloneid that is recorded in “NMM
save sets” on page 65, to reset the save set to expired/recoverable:
nsrmm -o notrecyclable -S SSID/cloneid
3. Repopulate the client file index with the save set information:
nsrck -L 7 -t date client 1>nsrck.txt 2>&1
where:
• date is a date after the completion of the latest save set that will be restored.
• client is the name of the NMM client.
Note: Ensure that the volume containing the index backup is available for mounting.
4. Review the output in nsrck.txt for errors once the command has completed:
• If the following messages are reported, type the following command:
nsrck -L 2 client
where client is the name of the NMM client.

Messages:
19779:nsrck: Please run ``nsrck clientname''
9348:nsrck: The index recovery for ' clientname ' failed.
39078:nsrck: SYSTEM error: The operation completed successfully.
• File attribute messages such as the following will not impact the NMM restore
and can be safely ignored:
32222:uasm: Warning: Some file attributes were not recovered:
C:\Program
Files\Legato\nsr\index\clientname\db6\tmprecov\C\Program
Files\Legato\nsr\index\clientname\db6\
• If the nsrck command fails with the error "xxxxx", the index backup might no
longer be referenced in the media database. Use the following command to
scan all SSIDs recorded for the cover, display, metadata and rollover save sets:
scanner -i -S SSID device
where:
– SSID is the save set id of the save set that will be restored.
– device is the device containing the volume for the save set to be restored.
5. Ensure that the NetWorker User program is closed on the NMM clients before
running the scanner command. If the program is open while scanner is run, the
scanner command may fail with the following errors:
• For NetWorker 7.6.1 and earlier:
"Index error, flush Failed"
• For NetWorker 7.6.2 and later:

"8829:scanner: (ssid 2772567781) index error, store failed"
"39077:scanner: error, Cannot unlink the existing key file

C:\Program"
"Files\Legato\nsr\index\bv-e2007sp3-ccr\db6\4d420000\4d4206e1.k
0 before re-creating it. Error 'Permission denied"

6. For each metadata and rollover save set, modify the browse times of the existing
save sets, if browse and retention times set by scanner are not a long enough
duration to complete recovery procedures:
nsrmm -s NetWorker_server_name -w time2 -S SSID
where:
• NetWorker_server_name is the name of the NetWorker server.
• time2 is the new browse time.
• SSID is the save set value recorded for each metadata or rollover save set.
Note: Ensure that the new browse dates for the save sets are far enough in the future to
allow sufficient time for the restore to complete.
7. Restore the data. “Restoring cloned data that is browsable in the client file index”
on page 96 provides detailed information.
Restoring recoverable save sets to the client file index

If the backup save sets for the rollover, display, metadata and cover save set that are
recoverable, they can be made browsable for the required length of time to perform
the restore operation. For example sflags=vrF.
To recover recoverable save sets to the client file index:
1. For each display, metadata and rollover save set, modify the browse and retention
times of the existing save sets:
nsrmm -s NetWorker_server_name -e time1 -S SSID
where:
• time1 is the new retention time.
• SSID is the save set value recorded for each metadata or rollover save set in
“NMM save sets” on page 65.
Note: Ensure that the new browse and retention dates for the save sets are far enough in
the future to allow sufficient time for the restore operation to complete.
2. Repopulate the client file index on the NetWorker server with the save set
information:
where:

3. Review the output in nsrck.txt for errors once the command has completed.
• If the following messages are reported, run the following command:
nsrck -L 2 client
where client is the name of the NMM client.

Messages:
• File attribute messages such as the following will not impact the NMM restore
and can be safely ignored:
C:\Program
scan all SSIDs recorded for the cover, display, metadata and rollover save sets:
where:


C:\Program"
5. For each metadata and rollover save set, modify the browse times of the existing
save sets. If browse and retention times set by scanner are not a long enough
duration to complete recovery procedures:
where:
• time2 is the new desired browse time.
• SSID is the save set value recorded for each metadata or rollover save set.
6. Restore the data. “Restoring cloned data that is browsable in the client file index”
on page 96 provides detailed information.
Restoring save sets that are not in the media database

If the clones are no longer in the media database, you must scan the clone volumes to
regenerate the media database and the client file index database for these save sets.
The following procedures are used to perform this task:
◆ “Task 1: Identify the roll over save set name” on page 101
◆ “Task 2: Identify the clone volumes that are required for scanning” on page 101
◆ “Task 3: Disable the Idle Device Timeout attribute” on page 102
◆ “Task 4: Recover the clone save sets that do not exist in the media database” on
page 102
◆ “Task 5: Determine SSID of the required save sets” on page 104
◆ “Task 6: Scan the required save sets into the media database and the client file
index” on page 105
◆ “Task 7: Validate that the save sets are in the client file index” on page 107
◆ “Task 8: How to generate a media database listing of all of the save sets” on
page 107
◆ “Task 9: Validate that the metadata save sets are in the media database” on
page 107
◆ “Task 10: Restore the data” on page 107
Task 1: Identify the roll over save set name

The rollover save set contains the backup of the NMM data. If you know the name of
this save set, you can reduce the number of save sets to repair or scan during
recovery.
To determine the name of the rollover save sets in the media database:
NetWorker server.
◆ On the NMM client for each host, run the nsrsnap_vss_save command.
If the NetWorker backup configuration is not available, consult the EMC NetWorker
Module for Microsoft Applications Guide for assistance to determine the save set name.
Task 2: Identify the clone volumes that are required for scanning
The scanning procedure is used to rebuild index and media database entries:
◆ When restoring from a full backup, the volumes from the date of the full backup
are required to recover the data from.
◆ When restoring from an incremental backup, the volumes from the day of the
incremental backup to the most recent full backup are required to recover the data
from.

“Selecting clone volumes to recover data from” on page 90 provides information on

how to ensure that the recovery comes from the clone copy and not the original in
situations where both or all of the copies that are available.
Note: If other volumes are required to be scanned, review “Selecting clone volumes to recover
data from” on page 90 to identify what save sets are missing so that the additional volumes can
be retrieved.
Task 3: Disable the Idle Device Timeout attribute

To prevent devices from being unloaded from the drives while scanner is in use, you
must temporarily disable the Idle Device Timeout attribute, if it was configured.
To disable temporarily the Idle Device Timeout attribute:
1. Connect to the NetWorker server through NMC.
2. Click Devices.
3. Right-click the device that is to be used.
4. Select Properties.
5. Click the Advanced tab.
6. Set the Idle Device Timeout value to 0.
7. Click OK.
Task 4: Recover the clone save sets that do not exist in the media database
If the NMM clone save sets that are required for a restore operation are no longer in
the media database, you must scan the clone volumes to regenerate the media and
index database for these save sets. You can use the scanner command to scan the
volumes.
To scan the required volume:
1. Mount the volume containing the clone save sets into the drive.
Note: If the volume itself is no longer in the NetWorker media database, choose the option
load without mount while loading the tape.
2. From a command prompt on the NetWorker server, obtain a listing of the save
sets on the clone volume to generate a report of the save sets on the volume. Use
the following command:
scanner -v device 1>scanner_output.txt 2>&1
where device is the name of the device containing the volume.

For example:
scanner -v C:\device\clone 1>C:\output1\5\scanner_output.txt 2>&1
or
scanner -v \\.\Tape0 1>scanner_output.txt 2>&1


C:\Program"
4. Open the scanner_output.txt file, which resides in the same directory the scanner
command was run from.
5. If the scanner_output.txt file displays only the following message:
scanner: SYSTEM error: Cannot stat <device_name>: No such file or
directory
a. Check the device name specified in the scanner command for errors.
b. Retry the scanner command with the correct device name.
Considerations for identifying required save sets

◆ For application backups, there will be multiple rollover save sets with the same
name.
◆ If the save set was an application save set of an individual application object, for
example, an individual content database used by SharePoint server, there may be
multiple rollover save sets. For example, the content database is configured to
have data files and logs files on separate volumes. There will be one save set for
each filesystem that contained application data.
◆ For an application writer-level save set, there will also be one rollover save set for
each filesystem that contained application data.
◆ Anticipate a larger number of save sets if the application data involved more
filesystems.
◆ If a backup retry occurred in the backup window, there might be multiple
occurrences of the following:
• VSS:/save set
• Metadata save set
• Rollover save set
Note: Since you might not be able to determine what happened, include redundant save
sets in the list to scan.
◆ All of these save sets must be scanned even when restoring only an individual
application object. This is because it is not possible to determine which rollover
save sets are needed without scanning them in first.

◆ When using the scanner command, the cover save sets must be scanned in before
the rollover save sets. This allows for any repair of the *coverid and the
*connected save sets attributes if required. You can distinguish the rollover save
sets from their covers by save set size:
• Cover save sets are approximately 1 MB or less.
• Rollover save sets are the size of the data backed up.
Task 5: Determine SSID of the required save sets

To determine the SSID of the required save sets:
1. Inspect the scanner_output.txt file to determine the SSIDs of the required save
sets. These can be identified by using the following attribute values for each save
set in the output file:
• Client name
• Save time
• Level
• Save set name
2. To perform the restore, including all dependent full and incremental save sets,
determine the following information for all of the rollover and cover save sets:
• SSID
• Savetime
• Save set name (the rollover and cover save sets will have the same save set
name)
Note: The SSID values will be used later in the procedure to scan the save sets back into
the media database and the savetime will be used to validate that the repopulation of
the client file index was successful.
For example, the rollover/cover set save set name for client krkr8x64
(SharePoint webfront server) is APPLICATIONS:\Microsoft Office SharePoint
Services. The date of the point in time restore to be performed is December 14,
2010:
Searching for the string "APPLICATIONS:\Microsoft Office
SharePoint Services 12/14/2010" provides the following entries
in the file for client krkr8x64:
client name save set save time level size files ssid
S
krkr8x64.krk APPLICATIONS:\Microsoft Office SharePoint Services
12/14/10 9:21 f 4 0 4094109964 E
krkr8x64.krk APPLICATIONS:\Microsoft Office SharePoint Services
12/14/10 9:21 f 344 1 4060555534 E
• Based on this output, the backup performed on December 14 was a full

backup, the following SSIDs are recorded:
"Cover save set(s): 4094109964, with a savetime of 12/14/10
9:21
"Rollover save set(s): 4060555534, with a savetime of 12/14/10
9:21
Note: In some instances, there may be multiple cover-rollover save set pairs reported.
IMPORTANT
If the date of the point-in-time restore was an incremental or differential
backup level as denoted by the value in the level column, all save sets from the
point-in-time restore to the last full level restore must be identified. In some
cases, the associated full backup might be on a different volume.
3. Determine the following for the VSS save set for the client:
• SSID
• Savetime
For example, searching for VSS: reveals the following save set for client krkr8x64
on December 14, 2010:
client name save set save time level size files ssid S
krkr8x64.krk VSS:/ 12/14/10 9:22 f 14572 14 3859228981 E
Based on this output, the backup performed on December 14 was a full backup
and SSID 3859228981 with a savetime of 12/14/10 9:22 is recorded.
IMPORTANT
If the date of the point-in-time restore was an incremental or differential
backup level as denoted by the value in the level column, all save sets from the
point-in-time restore to the last full must be identified. In some cases, the
associated full backup might be on a different volume.
4. Determine the SSID for the metadata save set for the client.
For example, searching for LG_VSS_Client reveals the following save set for client
krkr8x64.krk on Dec 14, 2010:
client name save set save time level size files ssid S
krkr8x64.krk
C:\ProgramData\EMC\NetWorker\LG_VSS_CLIENT1492044633.xml 12/14/10
9:21 f 1296680 1 3892783398 E
Based on this output, the backup performed on December 14 was a full backup
and SSID 3892783398 is recorded.
IMPORTANT
If the date of the point-in-time restore was an incremental or differential backup
level as denoted by the value in the level column, all save sets from the
point-in-time restore to the last full must be identified. In some cases, the
associated full backup might be on a different volume.
Task 6: Scan the required save sets into the media database and the client file index
Depending on your IT procedures and urgency of the restore request, you might
choose to scan individual save sets from the clone volumes. Scanning should be run
to regenerate both the media database and client file index entries.
Consider:
◆ The cover save sets must be scanned into the media database and client file
indexes before the metadata and rollover save sets are scanned in.
◆ It is not possible to specify the scanning order when save sets are supplied
through the -S parameter to scanner.

◆ Save sets are scanned based on their order on the volume. As such, it may be
necessary to scan the rollover save sets twice. The rollovers are initially identified
from the scanner save set report by using the save set size.
◆ When scanning the metadata and rollover save sets the -y option is used to
establish a new retention policy for the save set. Once these save sets have been
scanned back into the media database, the browse time will be reset with the
nsrmm command.
The end-to-end process of recovering from scanned clones might take several
days, so resetting the browse and retention times to a sufficient point-in-time in
the future will help to ensure that the scanned save sets do not prematurely expire
before you are finished restoring the data.
To scan the required save sets into the media database and the client file index:
1. Use the following command to scan cover save sets:
scanner -i -S SSID device 1>scanneri.txt 2>&1
where:
• SSID is the SSID recorded for save set.
• device is the device with media that contains the save set.


C:\Program"
IMPORTANT
It is critical that the cover save sets be scanned first.
3. Review the output of the scanneri.txt file for errors.

• If a cover save set was not scanned before the metadata or rollover save sets,
the scanner output will report a message similar to the following:
scanner: Coverset xxxxxxxx not found in the Media DB, which must
exist in order to make use of this saveset (yyyyyyyy). Please be
sure to scan in all volumes relevant to this backup.
• If this message is encountered:

a. Use the scanner -i command to scan in the referenced cover save set.
b. Rescan the metadata or rollover save set.
Task 7: Validate that the save sets are in the client file index
For each save set that was scanned, you can use the nsrinfo command to validate that
the data has been repopulated in the client file index.
To validate that the save sets are in the client file index:
1. During the inspection of the scanner output, review the savetime recorded for
each of the following save sets:
• Cover
• Display
• Rollover
2. Run the nsrinfo command against each savetime to confirm that the client file
index was populated with the necessary save set details:
nsrinfo -t exact_savetime client
where:
• exact_savetime is the savetime recorded from the scanner output.
For example:
nsrinfo -t 1292314893 krkr8x64
scanning client `krkr8x64' for savetime 1292314893(14.12.2010
09:21:33) from the backup namespace
C:\LG_PLACEHOLDER_1492021383
1 objects found
3. For all recorded savetimes, run the nsrinfo command against each savetime to
confirm that the client file index was populated with the necessary save set
details:
where:
Task 8: How to generate a media database listing of all of the save sets
“Generating a media database listing of all of the NMM save sets” on page 83
Task 9: Validate that the metadata save sets are in the media database
For each metadata save set that was scanned, inspect the output.txt output to ensure
that the XML files are present.
Note: Metadata save sets do not have index entries, as result the ssflags value for the save set
will never be browsable.
Task 10: Restore the data

Restore the data. “Restoring cloned data that is browsable in the client file index” on
page 96 provides detailed information.

Troubleshooting NMM clone operations

Table 10 on page 108 provides detailed instructions for typical problems that are
encountered. If the issue that is encountered falls into one of these categories under
the Problem column, go to the associated Troubleshooting section in the table.
Contact EMC Support if you are unable to determine the cause of the problem or
resolve the problem by using these instructions.
Table 10 Troubleshooting scenarios
Problem Probable cause Troubleshooting resource
Backup version does not display in the NetWorker • Missing VSS:/ save set. “Displaying the backup versions in the GUI” on
User GUI • Missing VSS:/ indexes. page 46
• Missing coverset and rollover save set.
Restore fails when recovering metadata save set Missing metadata save set. “Unable to read metadata save set” on page 109
Restore fails when restoring the files • Missing coverset and rollover save set. • “Cover save set” on page 66
• Missing rollover save set indexes. • “Failure to restore cover save sets” on
page 110
Rollover save set restore fails with error

If the rollover save sets are not browsable, the data recovery process fails with an
error similar to the following:
◆ For Hyper-V:
NMM Hyper-V: Operation unit failed with error
'G:\SC2ATARIDES\SCVAtariDes.vhd not in index
◆ For DPM:
NMM DPM: Operation unit failed with error APPLICATIONS:\Microsoft
DPM\ <DPM replica> not in index
Validate rollover and cover save sets

The NetWorker User program (NetWorker Module for Microsoft Applications)
includes logic to validate that a rollover or snapshot exists for an item and is
browsable before it can be displayed. The *snap_sessionid attribute is used to
perform this validation:
◆ If a rollover save set is not found with the same *snap_sessionid as the cover save
set, the NetWorker User program will not display the backup version.
◆ If the backup version does not display in the GUI, you must validate that the
rollover save set and the cover save sets are in the media database and browsable
for the savetimes.
◆ If the save sets are not in the media database, you must identify what additional
clone volumes are required and repeat the process. “Restoring save sets that are
not in the media database” on page 101 provides details.
◆ If it is determined that the sets are recyclable, refer to “Restoring recyclable save
sets to the client file index” on page 97.
◆ If it is determined that the save sets are recoverable, refer to “Restoring
recoverable save sets to the client file index” on page 99.
Unable to read metadata save set

Assuming the backup versions are displayed in NetWorker software, one of the first
save sets that will be read during the restore is the metadata save set. The metadata
save set is identified by the data in the index and its SSID is used during the restore. If
the metadata save set is not in the media database, the restore operation will fail.
Note: The metadata save set contains a single XML document. This XML document is a file
mapping section and consists of information regarding the files to restore and their
corresponding cover save set times.
With NetWorker Module for Microsoft Applications 2.2 SP1, the failure to restore the
metadata save set will be indicated in nsr\applogs\nmm.raw. The last line of the log
file will be:
NMM start restore of metadata key for savetime xxxxx.
If a failure occurs, perform the following steps:

1. Review the output.txt file. The file resides in the same directory where the
mminfo command was run.
2. The metadata save set can be recognized as a filename of the form:
LG_VSS_CLIENTxxxxxxxxxx.xml
3. Confirm that the value in the savetime column matches the savetime reported in
the nmm.raw file.
Note: Metadata save sets do not have client file index entries so it is not necessary to make
these save sets browsable.
4. If the metadata save set with the savetime reported in the nmm.raw file is not
found in the mminfo output, run the procedure in “Restoring save sets that are
not in the media database” on page 101.
Unable to restore rollover save set

If the rollover save sets are not browsable, the data recovery process fails with an
error similar to the following:
NMM Hyper-V: Operation unit failed with error
'G:\SC2ATARIDES\SCVAtariDes.vhd not in index
To validate this:
1. Run the mminfo command against the SSIDs noted during the restore procedures
for the rollover save sets.
2. Ensure that the rollover save sets are browsable.
Troubleshooting NMM clone operations 109

Failure to restore cover save sets

Once the metadata is read, the NMM software starts the recovery process. This is
when the cover save set and the rollover save sets are used by the NMM recover
logic. The metadata save set contains a single XML document. This XML document
contains information on the files to restore and their cover save set times. This section
is named file mapping. The restore request consists of the files that are required to be
restored and their cover savetimes. If the cover save sets do not exist, the restore fails.
If the restore fails:
1. Inspect the logs under nsr\logs. A message to the following might appear:
Error [BROptimizer.cpp 2174] init()::No Saveset found in NSR
server[mb-misc-1.MB2.EMC.COM] with
key[server=mb-misc-1.MB2.EMC.COM, clnt=MB-MBOX-2.MB2.EMC.COM,
time=Tue Oct 12 07:55:52 2010
Note: The savetime listed in the message, for example Tue Oct 12 07:55:52 2010, is the
savetime for the missing cover save set.
2. Locate the clone tape that contains the save set.

3. Generate a scanner report for the clone volume to find the matching save set and
the savetime.
4. Scan the cover save set and its rollover save set. “Restoring save sets that are not
in the media database” on page 101 provides details.
6
NetWorker Module
for Databases and
Applications

◆ NMDA save set bundling ........................................................................................... 112
◆ NMDA policy uniformity ........................................................................................... 115
IMPORTANT
NMDA does not support save set bundling for regular manual backups or EMC
PowerSnap™ snapshot backups. NMDA performs save set bundling for regular
scheduled Oracle backups only.
NetWorker Module for Databases and Applications 111

NetWorker Module for Databases and Applications
NMDA save set bundling

If the NetWorker Module for Databases and Applications (NMDA) save set bundling
is configured, NMDA automatically creates a save set bundle to group all dependent
save sets from the same backup cycle. Save sets are dependent when two or more
save sets are required to restore a database object.
A backup cycle includes the following:
◆ A level 0 incremental backup of the database object.
◆ All subsequent level 1 incremental backups that are dependent on the level 0
backup.
The EMC NetWorker Module for Databases and Applications Administration Guide
provides details on NMDA support of full and incremental Oracle backups.
IMPORTANT
NMDA does not support save set bundling for regular manual backups or EMC
PowerSnap snapshot backups. NMDA performs save set bundling for regular
scheduled Oracle backups only.
Save set bundling automatically enables the following for Oracle:

◆ Improved staging
Oracle-aware staging causes NMDA Oracle save sets that have a dependency on
each other to be staged together:
• During automatic staging, if the staging criteria determine that a particular
NMDA save set should be staged and the save set is part of a save set bundle,
the NetWorker server stages the entire save set bundle.
• During manual staging with the nsrstage command, if one or more save sets
being staged are from a save set bundle, all the save sets in the bundle are
staged.
◆ Policy uniformity
Policy uniformity is enabled automatically whenever you enable save set
bundling. If you do not want to use save set bundling, you can still enable policy
uniformity separately. “NMDA policy uniformity” on page 115 provides more
details.
Note: After a staging operation during which all the save sets in a bundle are staged, the
resulting available space on the staging device might exceed the lower-water mark specified in
the staging policy.
The EMC NetWorker Administration Guide provides details on how to work with
staging policies and perform automatic and manual staging operations through the
NetWorker server.
provides information on how to configure save set bundling for NMDA scheduled
backups.
If an error occurs during save set bundling, the bundling operation fails but the
scheduled backup can finish successfully. Information about the bundling failure is
printed to the savegrp output and to the NMDA debug file.
NetWorker staging restrictions

When planning the strategy for NMDA save set bundling, consider the following
NetWorker staging restrictions:
◆ The NetWorker server cannot simultaneously stage all the save sets from a save
set bundle if some of the save sets were backed up to separate volumes. The
server simultaneously stages save sets only if they are located on the same staging
volume. Example 3 on page 114 provides more information.
To ensure the proper staging of all the save sets from a save set bundle, do not
split the backup between different staging volumes. If required, split the backup
into different backup cycles, with each cycle going to a separate volume.
◆ NetWorker staging policies must not cause the save sets of an NMDA backup
cycle to be staged before the cycle is complete. For example, if a 1-week NMDA
cycle starts on Sunday, the staging policy must not cause the partially complete
save set bundle to be staged before the final backup of the cycle occurs on
Saturday.
To prevent a staging operation from splitting an NMDA backup cycle, adjust the
NetWorker staging policy accordingly. For example, adjust the policy so that
older save sets are staged before new ones, or adjust the high-water and
low-water marks.
The EMC NetWorker Administration Guide provides details on how to work with
staging policies and perform automatic and manual staging operations through the
NetWorker server.
Save set bundling with NMDA

The NMDA program nsrdasv automatically places save sets into a save set bundle at
the end of a scheduled backup.
To perform save set bundling:
◆ Operate NetWorker privileges are required.
◆ The nsrdasv program connects to the Oracle database by attempting to use the
login and password from the RMAN script.
◆ If a login and password are not available from the script, the program uses the
ORACLE_SID value from the NMDA configuration file to search the nwora.res
file for the NSR_ORACLE_CONNECT_FILE parameter, and uses the connection
strings from the specified connection file.
◆ After connecting to the Oracle database, the nsrdasv program obtains all the
required information about the backups by using the V$ views. The EMC
NetWorker Module for Databases and Applications Administration Guide provides
more details on the nwora.res file and the requirements of save set bundling.
◆ The nsrdasv program creates a save set bundle for each incremental level 0
backup.
◆ The program adds the save sets from subsequent incremental backups to the
bundles of the level 0 backups they are dependent on. Example 1 on page 114 and
Example 2 on page 114 illustrate different scenarios for how the save set bundle is
formed.
NMDA save set bundling 113

◆ The name that the nsrdasv program assigns to a save set bundle is the save time
of the oldest save set in the bundle.
◆ After a scheduled backup, the NetWorker server stores the save set bundle name
and the list of save sets it contains in the media database.
You can view the bundle information by using the mminfo command, as described in
“Save set bundling information in the media database” on page 114.
Example 1 Save set bundling for a 1-week scheduled backup cycle of a tablespace
A 1-week scheduled backup cycle of a tablespace includes a level 0 backup of the

tablespace on Sunday and a level 1 backup every other day of the week. The save set
bundle for the cycle is created during the Sunday backup. Save sets from each level 1
backup are added into the same bundle. The complete bundle contains the save sets
from the seven daily backups of the tablespace. A new bundle is created for the next
backup cycle during the following week.
Example 2 Save set bundle join
This example illustrates a scenario where NMDA combines existing bundles into a
new save set bundle.
Two save set bundles are created by separate level 0 backups of files A and B. Then a
new backup set is created by a level 1 backup of both files A and B. As the new backup
set is dependent on both of the preceding level 0 backups, NMDA combines all three
backups into the same save set bundle.
Example 3 Splitting a save set bundle across volumes
In this example, a save set bundle is split across multiple volumes. A level 0 backup
of file A is performed to volume A. An incremental backup of file A is then
performed to volume B. Although both backups are recorded as belonging to the
same save set bundle, the save set bundle is split across volumes. During staging,
only the save sets on the same volume can be staged together.
Save set bundling information in the media database

The NMDA software stores information about each save set bundle in the NetWorker
media database.
Query the media database by using the NetWorker command, mminfo, with the
appropriate options:
◆ The mminfo -r command can display the name of the bundle associated with a
save set. For example, the following command displays a list of all save sets and
their bundles:
mminfo -a -r "ssid,ssbundle"
◆ The mminfo -q command can display all the save sets in a specific bundle. For
example, the following command displays all the save sets in the bundle named
12983479182:
mminfo -a -q "ssbundle=12983479182"
The EMC NetWorker Command Reference Guide and the UNIX man pages provide more
information on the mminfo command and its available options.
NMDA policy uniformity

If policy uniformity is enabled, NMDA automatically enforces the uniformity of the
browse and retention policies between all the dependent save sets in a scheduled
Oracle backup cycle (whether or not save set bundling is enabled).
After NMDA performs an incremental Oracle scheduled backup, if the browse and
retention policies of the save sets in the backup are longer than the policies of
preceding dependent save sets in the same backup cycle, NMDA changes the policies
of all save sets in the cycle to match the longest policy of the new incremental save
sets. NMDA modifies the policies recorded in the NetWorker media database. As a
result, backups cannot expire and become recyclable before other dependent backups
from the same backup cycle.
Note: NMDA does not support policy uniformity for regular manual backups and PowerSnap
snapshot backups. NMDA supports policy uniformity for regular scheduled backups only.
Policy uniformity does not depend on whether save sets are stored on separate
volumes. For example, if parts of a save set bundle are split onto separate volumes, all
the save sets in the bundle still receive the same browse and retention policies.
provides information on how to configure policy uniformity for NMDA backups.
NMDA policy uniformity 115

7
Recovering Data
from Clones

◆ Clones recovery ............................................................................................................ 118
◆ Recovery scenarios....................................................................................................... 118
◆ Required save sets and volumes for recovery of cloned data .............................. 120
◆ Recovery tasks ............................................................................................................. 124
Recovering Data from Clones 117

Recovering Data from Clones
Clones recovery
When using cloning, ensure that you can recover the cloned save sets for all of the
recovery scenarios that are expected to occur. These recovery scenarios and the steps
to recover the cloned save sets are likely to be specific to the situation. “Recovery
scenarios” on page 118 provides details.
To ensure that the recovery of cloned data:
◆ Verify that all relevant recovery scenarios have been accounted for as described in
“Recovery scenarios” on page 118. For example, if you expect to rely on the clone
copy for recovery, then you must ensure that the recovered save sets come from
the clone copy and not from the original volume. This is important for situations
where both or all copies are available, as well as when the original is not.
“Selecting clone volumes to recover data from” on page 123 provides details.
◆ Ensure that all the required save sets and volumes are available for recovery.
“Required save sets and volumes for recovery of cloned data” on page 120
◆ Ensure that recovery procedures are in place and have been regularly tested as
described in “Recovery tasks” on page 124.
Recovery scenarios
When a recovery operation is initiated, there are two common assumptions about
recovery operation:
◆ That the recovery will be performed within a short period of time after the
backup (hours or days).
◆ That the recovery will use the original data volumes and that the backup server
will be fully operational. You can use the standard NetWorker recovery
procedure because the backups are present in both the client file indexes and the
media database. “Required save sets and volumes for recovery of cloned data” on
However, if the recovery operation occurs after the NetWorker browse or retention
periods have expired or following a site or building loss, then the volumes may not
be readily available and additional actions might be required. Table 11 on page 119
details the recovery scenarios and necessary actions.
Browse and retention periods

In many restore operations, the request to restore the data arrives soon after the
backup has completed. In these circumstances the browse and retention periods are
likely to be still valid and recovery is simple. “Required save sets and volumes for
recovery of cloned data” on page 120 provides details on how to restore cloned data
in this scenario.
In cases where the browse and retention periods have expired, additional effort might
be required to perform a restore operation. It is important to consider this when
determining the browse and retention periods for the backup and the clone copies.
“Consider the browse and retention policies” on page 27 provides more information
on how to restore cloned data in this scenario.
Identifying the recovery options

If the recovery is not readily available, perform the following:
1. Identify the backup or clone save sets that are required.
2. Investigate the cause and attempt to remedy the situation. Table 11 on page 119
provides details.
3. Seek alternative recovery options if required. “Recovery tasks” on page 124
provides details.
The NetWorker software has various log files that contain information about the
volumes, status, and history of cloning operations. These can be viewed and
monitored from the NetWorker Administration window or recovered from previous
server backups.
Clone-related messages are also logged to the NetWorker message file and the
savegrp log file, which are located in the NetWorker_install_dir\logs directory.
Review the recovery scenarios

If the recovery is not immediately available or successful, review the following list of
recovery scenarios to help determine the cause and the resolution if available.
Table 11 NetWorker restore scenarios (1 of 2)
Recovering original or clone data The backups are present and browsable in both the client file indexes and “Restoring cloned data that is
that is browsable. The save sets in the media database. browsable in the client file index”
appear in both the client file index on page 124
and in the media database.
The browse period has elapsed and The client index information has been purged because the browse period “Restoring recyclable save sets to
the client file index entries have has elapsed. the client file index” on page 128
been purged. Although you can use the media database to identify the volumes and the
save sets, you cannot perform a partial or item-level recovery operation.
If the browse policy has elapsed, you can:
• Use the nsrck -L7 -t command to recover the client file index entries.
or
• Use the scanner command to recreate the client file index entries.
The browse and retention periods The media database entries have been marked as expired but the volume “Restoring recyclable save sets to
have both elapsed but the volume has not been recycled (relabeled). the client file index” on page 128
has not been recycled since the If the volume has not been recycled, then the media database entries will
data that is still within the retention still exist. You must mark the media database entries in the media database
period. as eligible for recovery.
The browse and retention periods If the volume has been recycled, then the media entries have been purged. “Selecting clone volumes to
have both expired and the volume In this case the data is longer available to recover from and alternative recover data from” on page 123
has been recycled. recovery sources will need to be used.
One or more volumes are missing Some or all of the original backup volumes are no longer available for • The EMC NetWorker
or are offline. restore: Administration Guide provides
• If the volumes are offsite or in storage, then they can be easily recalled detailed information.
and made available to the online NetWorker server so that the recovery • “Restoring save sets that are
operation can continue. In this situation the media database entries are not in the media database” on
still available and valid. A mount operation or library inventory may also page 130
be required to make the volumes available.
• If the media database entries are not available or are invalid, use the
scanner command to repopulate the media entries so that the
NetWorker server knows what data is on that volume.
Recovery scenarios 119

Table 11 NetWorker restore scenarios (2 of 2)
The clone volume does not contain If the clone volumes do not contain all of the necessary data for the • “Restoring recoverable save
all of the save sets that are required recovery, then the number of available recovery options might be limited. sets to the client file index” on
to be recovered. Data might be able to be recovered, if: page 126
• The original bootstrap (media and client index) information is available. • “Restoring save sets that are
• The original volumes still exist and can be used for recovery. not in the media database” on
page 130
A recovery of that data might not be possible in cases where:
• No bootstrap backups exist for the period of time where the recovery is
requested.
• The original data volumes are missing or have been recycled.
The NetWorker server does not The NetWorker server has been rebuilt or has been recently recovered and The EMC NetWorker Disaster
have knowledge or any database all or most records of the previous backups are missing. Recovery Guide provides detailed
records of the backup. A full recovery of the media database and client file indexes is required information.
before any client recovery operation can be initiated. The recovery should
include media and client index entries for all the volumes, clients, and dates
available. This relies on the NetWorker server bootstrap backups.
Required save sets and volumes for recovery of cloned data

Before initiating a recovery it is important to ensure that all the required save sets and
volumes are available for recovery:
◆ “Generating a media database listing of all of the save sets” on page 120
◆ “Determining the status of a save set in the media database” on page 121
◆ “Save set requirements” on page 121
When clone volumes are being used, ensure that all the clone save sets are available
for recovery. “Selecting clone volumes to recover data from” on page 123 provides
details.
Generating a media database listing of all of the save sets

To generate a media database listing of all of the required save sets:
1. At command line prompt on the NetWorker server, type the following command
to generate a list of the cloned save sets in the media database:
mminfo -S -s NW_server_name -c NW_client_name
-q "group= group_name, savetime>date1, savetime<date2"
-ot 1>output.txt 2>&1
where:
• NW_server_name is the name of the NetWorker server host.
• NW_client_name is the name of the NetWorker client host.
• group_name is the name of the group which contained the NetWorker client
when the backup occurred.
• date1 is at least one day before the date range of the NetWorker clone to be
restored.
• date2 is at least one day after the date range of the NetWorker clone to be
restored.
For example, to list the save set details which reside on a NetWorker server called
krkr-pdc.krkr.local, an NMM client named krkr8x64.krkr.local in a group called
grupa2 on dates Dec 14 13:48:00 2010 and Dec 15 13:57:00 2010, use the command:
mminfo -S -s krkr-pdc.krkr.local -c krkr8x64.krkr.local -q
"group=grupa2,savetime>12/14/2010 13:48:00,savetime<12/15/2010
13:57:00" > out3.txt
2. Edit the output.txt file, which resides in the same directory where the mminfo
command was run.
If the output file contains the following message, the media database does not
contain the NetWorker save sets for the client or query options specified:
mminfo: no matches found for the query
• Make adjustments to the query options specified in the mminfo command.

or
• Restore the media database. “Restoring save sets that are not in the media
database” on page 130 provides details.
Determining the status of a save set in the media database

To determine the status of a save set in the media database, use the mminfo
command. You can use the ssflags attribute to provide a summary of the status of
each save set.
When generating a report of the ssflags summary of save sets:
◆ An r in the ssflags output denotes that a save set is recoverable and that it has
exceeded its defined browse policy.
◆ An E in the ssflags output denotes a save set that is eligible for recycling and that
it has exceeded its defined retention policy. This is also referred to as an expired
save set.
In the case of incremental or differential save sets, the ssflags value will contain an E
only when all dependent incremental, differential, or full backups have also exceeded
their defined retention policy period.
When all save sets on a volume are eligible for recycling, the volume can be
overwritten.
Save set requirements
Note: Do not use the procedures until you are familiar with all of the save set requirements.
Recovering data from media that has either expired or is recyclable requires that you
identify the save sets for the backup:
◆ If you are know the list of required save sets that are to be recovered, perform the
steps outlined in “Using the backup time to list all of the save sets” on page 122.
◆ If you do not know all of the required save sets that are to be recovered, perform
the steps outlined in “Using savetime to determine the full set of save sets to
recover” on page 122.
Required save sets and volumes for recovery of cloned data 121
Using the backup time to list all of the save sets

If you are familiar with the required save set for the NetWorker software, you can use
the backup time to ensure that all of the cover save sets are displayed:
mminfo -v -ot -q "group=group_name,saveset>date1,saveset<date2"
-r "ssid, cloneid, nsavetime, ssflags, level, savetime(22), ssbrowse,
ssretent, name, client, volume" 1>output.txt 2>&1
where:
◆ group_name is the name of the group which contained the NetWorker client when
the backup occurred.
◆ date1 is at least one day before the date range of the NetWorker clone to be
restored.
◆ date2 is at least one day after the date range of the NetWorker clone to be restored.
This query will return all of the save sets for the group in the time range specified.
The -ot flag sorts the save sets by time and the information is stored in a file called
output.txt. This file resides in the same directory from which the mminfo command
was run.
Note: If you experience restore issues using this easier method, use the procedures in
“Generating a media database listing of all of the save sets” on page 120 to validate the output.
Using savetime to determine the full set of save sets to recover

You can use the mminfo command to identify the required savetime range for the
backup version that is being restored by querying the media database. The savetime
range is used to query the media database.
The savetime range is the day before (date1) and the day after (date2) the date of the
backup which is to be restored.
! IMPORTANT
If the backup that is to be restored was an incremental level backup or a
differential level backup, you must increase the savetime range to include the
sequence of the full and the level backups.
To determine the full set of save sets to recover:

1. For the version of the backup that is being restored, identify the required
savetime range.
If you are restoring a filesystem, you might need to:
a. Expand the savetime range to include the sequence of full and incremental
backups.
b. Adjust the savetime range accordingly.
2. Identify the save set name that was used to backup for the filesystem that is being
restored.
3. Use the savetime range to generate the media database listing for the backup:
mminfo -S -s server -c client -q
"group=group, savetime>date1, savetime<date2"
For example, use the following command to restore a backup that occurred on
4/28/2010:
mminfo -S -s bv-nwsvr-1 -c bv-accounting-1 -q
"group=BV-accounting-1_Group,savetime>4/27/2010,savetime<4/29/2
010"
where:
• bv-accounting-1 is the NetWorker client.
• bv-nwsvr-1 is the NetWorker server.
• BV-accounting-1_Group is the group.
4. Identify the most recent full backup for the filesystem save set in the mminfo
report.
The full backup should be identified by using a rollover save set:
• Save set name of the filesystem.
• Save set name does not have the K in the sflags.
5. Obtain the *snap_sessionid from the full backup.
Selecting clone volumes to recover data from

Review the following procedure to ensure that the recovery comes from the clone
copy and not the original in situations where both or all of the copies are available.
The volume, either a clone or original volume, that is selected for a recovery
operation is determined as follows:
1. The highest priority is given to the volume (clone or original volume) that has a
complete, non-suspect, save set status. A complete save set that is suspect has a
higher priority than an incomplete non-suspect save set.
The EMC NetWorker Administration Guide provides information about changing
the status of a save set.
2. If the volumes still have equal priority, then priority is given to the mounted
volume.
3. If the volumes are mounted, then priority is based on the media type. The media
types from highest-to-lowest priority are:
a. Advanced file type device
b. File type device
c. Other (such as tape or optical)
4. If the volumes are not mounted, then priority is based on the media location. The
media locations from highest-to-lowest priority are:
a. Volumes in a library
b. Volumes in an AlphaStor or SmartMedia controlled library
c. Volumes that are not in a library but are onsite (offsite flag is not set)
d. Volumes that are offsite (offsite flag is set)
5. Use the nsrmm command to specify that a volume is offsite. For example:
nsrmm -o offsite -V volume_id
Required save sets and volumes for recovery of cloned data 123
The volumes required for recovery appear in the Required Volumes window of the
NetWorker User program. The EMC NetWorker Administration Guide provides
information on viewing volumes that are required for data recovery.
You can also run the scanner program on a clone volume to rebuild entries in the
client file index, the media database, or both. After you re-create the entries, normal
recovery is available. The EMC NetWorker Administration Guide provides information
on restoring a save set entry in the online indexes.
Recovery tasks
This section discusses recovery from cloned save sets to help you identify what save
sets are required, and ensure that these save sets are in a state that can be used for
recovery:
◆ “Restoring cloned data that is browsable in the client file index” on page 124
◆ “Restoring recoverable save sets to the client file index” on page 126
◆ “Restoring recyclable save sets to the client file index” on page 128
◆ “Restoring save sets that are not in the media database” on page 130
To restore the data from full and incremental backups:
◆ For each backup, repeat the tasks listed in this section until all of the incremental
backups that occurred after the full backups have been recorded.
◆ To restore multiple clients, repeat the recovery tasks for each client.
Restoring cloned data that is browsable in the client file index

Recover cloned data that is browsable by using the standard NetWorker recovery
procedure since the backups are present in both the client file indexes and are in the
media database.
No special operation is required to recover cloned data. The EMC NetWorker
Administration Guide provides detailed information.
where
• SSID is the save set value recorded for each save set from the output of the
mminfo command.
appears:
2. For each save set, use its associated SSID and cloneid that is recorded in the List
Required Save sets section to reset the save set to expired/recoverable:
where:
• client is the name of the NetWorker client.
nsrck -L 2 client
where client is the name of the NetWorker client.

Messages:
• File attribute messages such as the following will not impact the restore and
can be safely ignored:
C:\Program
longer be referenced in the media database.
Use the following command to scan all SSIDs recorded for each save set:
where:


C:\Program"
Recovery tasks 125

6. For each save set, modify the browse times of the existing save sets, if browse and
retention times set by scanner are not a long enough duration to complete
recovery procedures:
where:
• SSID is the save set value recorded for each save set.
7. Ensure that the new browse dates for the save sets are far enough in the future to
8. Restore the data. The EMC NetWorker Administration Guide provides detailed
information.
Restoring recoverable save sets to the client file index

If the backup save sets for the rollover, display, metadata and cover save set that are
recoverable, they can be made browsable for the required length of time to perform
the restore operation. For example sflags=vrF.
To recover recoverable save sets to the client file index:
1. For each display, metadata and rollover save set, modify the browse and retention
times of the existing save sets:
nsrmm -s NetWorker_server_name -e time1 -S SSID
where:
• time1 is the new retention time.
• SSID is the save set value recorded for save set.
Note: Ensure that the new browse and retention dates for the save sets are far enough in
the future to allow sufficient time for the restore operation to complete.
2. Repopulate the client file index on the NetWorker server with the save set
information:
where:
3. Review the output in nsrck.txt for errors once the command has completed.
• If the following messages are reported, run the following command:
nsrck -L 2 client
Messages:
• File attribute messages such as the following will not impact the NetWorker
restore and can be safely ignored:
C:\Program
scan all SSIDs recorded for each save set:
where:


C:\Program"
5. For each save set, modify the browse times of the existing save sets. If browse and
retention times set by scanner are not a long enough duration to complete
recovery procedures:
where:
• time2 is the new desired browse time.
information.
Recovery tasks 127

Restoring recyclable save sets to the client file index

where:
• SSID is the save set value recorded for each save set from the output of the
mminfo command.
appears:
2. For each save set, use its associated SSID and cloneid that is recorded in the List
Required Save sets section to reset the save set to expired/recoverable:
where:
nsrck -L 2 client

Messages:
• File attribute messages such as the following will not impact the NetWorker
restore and can be safely ignored:
C:\Program
scan all SSIDs recorded for the save sets:
where:


C:\Program"
6. Modify the browse times of the existing save sets, if browse and retention times
set by scanner are not a long enough duration to complete recovery procedures:
where:
information.
Recovery tasks 129

Restoring save sets that are not in the media database

If the clones are no longer in the media database, you must scan the clone volumes to
regenerate the media database and the client file index database for these save sets.
The following procedures are used to perform this task:
◆ “Task 1: Identify the clone volumes that are required for scanning” on page 130
◆ “Task 2: Disable the Idle Device Timeout attribute” on page 130
◆ “Task 3: Recover the clone save sets that do not exist in the media database” on
page 131
◆ “Task 4: Determine SSID of the required save sets” on page 132
◆ “Task 5: Scan the required save sets into the media database and the client file
index” on page 132
◆ “Task 6: Validate that the save sets are in the client file index” on page 133
◆ “Task 7: Generate a media database listing of all of the save sets” on page 134
◆ “Task 8: Restore the data” on page 134
Task 1: Identify the clone volumes that are required for scanning
The scanning procedure is used to rebuild index and media database entries:
◆ When restoring from a full backup, the volumes from the date of the full backup
are required to recover the data from.
◆ When restoring from an incremental backup, the volumes from the day of the
incremental backup to the most recent full backup are required to recover the data
from.
“Selecting clone volumes to recover data from” on page 123 provides information on
how to ensure that the recovery comes from the clone copy and not the original in
situations where both or all of the copies that are available.
Note: If other volumes are required to be scanned, review “Selecting clone volumes to recover
data from” on page 123 to identify what save sets are missing so that the additional volumes
can be retrieved.
Task 2: Disable the Idle Device Timeout attribute

To prevent devices from being unloaded from the drives while scanner is in use, you
must temporarily disable the Idle Device Timeout attribute, if it was configured.
To disable temporarily the Idle Device Timeout attribute:
1. Connect to the NetWorker server through NMC.
2. Click Devices.
3. Right-click the device that is to be used.
4. Select Properties.
5. Click the Advanced tab.
6. Set the Idle Device Timeout value to 0.
7. Click OK.
Task 3: Recover the clone save sets that do not exist in the media database
If the NetWorker clone save sets that are required for a restore operation are no longer
in the media database, you must scan the clone volumes to regenerate the media and
index database for these save sets. You can use the scanner command to scan the
volumes.
To scan the required volume:
1. Mount the volume containing the clone save sets into the drive.
Note: If the volume itself is no longer in the NetWorker media database, choose the option
load without mount while loading the tape.
2. From a command prompt on the NetWorker server, obtain a listing of the save
sets on the clone volume to generate a report of the save sets on the volume. Use
the following command:
scanner -v device 1>scanner_output.txt 2>&1
where device is the name of the device containing the volume.

For example:
scanner -v C:\device\clone 1>C:\output1\5\scanner_output.txt 2>&1
or
scanner -v \\.\Tape0 1>scanner_output.txt 2>&1


C:\Program"
4. Open the scanner_output.txt file, which resides in the same directory the scanner
command was run from.
5. If the scanner_output.txt file displays only the following message:
scanner: SYSTEM error: Cannot stat <device_name>: No such file or
directory
a. Check the device name specified in the scanner command for errors.
b. Retry the scanner command with the correct device name.
Recovery tasks 131

Task 4: Determine SSID of the required save sets

To determine the SSID of the required save sets:
1. Inspect the scanner_output.txt file to determine the SSIDs of the required save
sets. These can be identified by using the following attribute values for each save
set in the output file:
• Client name
• Save time
• Level
• Save set name
2. To perform the restore, including all dependent full and incremental save sets,
determine the following information for all of the save sets:
• SSID
• Savetime
• Save set name
Note: The SSID values will be used later in the procedure to scan the save sets back into the
media database and the savetime will be used to validate that the repopulation of the client
file index was successful.
! IMPORTANT
If the date of the point-in-time restore was an incremental or differential backup
level as denoted by the value in the level column, all save sets from the
point-in-time restore to the last full level restore must be identified. In some cases,
the associated full backup might be on a different volume.
Task 5: Scan the required save sets into the media database and the client file index
Depending on your IT procedures and urgency of the restore request, you might
choose to scan individual save sets from the clone volumes. Scanning should be run
to regenerate both the media database and client file index entries.
Consider:
◆ It is not possible to specify the scanning order when save sets are supplied
through the -S parameter to scanner.
◆ The end-to-end process of recovering from scanned clones might take several
days, so resetting the browse and retention times to a sufficient point-in-time in
the future will help to ensure that the scanned save sets do not prematurely expire
before you are finished restoring the data.
To scan the required save sets into the media database and the client file index:
1. Use the following command to scan the save sets:
scanner -i -S SSID device 1>scanneri.txt 2>&1
where:
• SSID is the SSID recorded for save set.
• device is the device with media that contains the save set.


C:\Program"
! IMPORTANT
It is critical that the cover save sets be scanned first.
3. Review the output of the scanneri.txt file for errors.
Task 6: Validate that the save sets are in the client file index
For each save set that was scanned, you can use the nsrinfo command to validate that
the data has been repopulated in the client file index.
To validate that the save sets are in the client file index:
1. During the inspection of the scanner output, review the savetime recorded for the
save sets:
2. Run the nsrinfo command against each savetime to confirm that the client file
index was populated with the necessary save set details:
where:
For example:
nsrinfo -t 1292314893 krkr8x64
scanning client `krkr8x64' for savetime 1292314893(14.12.2010
09:21:33) from the backup namespace
C:\LG_PLACEHOLDER_1492021383
1 objects found
3. For all recorded savetimes, run the nsrinfo command against each savetime to
confirm that the client file index was populated with the necessary save set
details:
where:
Recovery tasks 133

Task 7: Generate a media database listing of all of the save sets

“Generating a media database listing of all of the save sets” on page 120 provides
detailed information.
Task 8: Restore the data

Restore the data. The EMC NetWorker Administration Guide provides detailed
information.
8
Staging

◆ Staging overview......................................................................................................... 136
◆ The destination ............................................................................................................ 137
◆ Working with staging policies................................................................................... 137
◆ Staging from the NetWorker Management Console .............................................. 140
◆ Staging from the command line................................................................................ 140
Staging 135
Staging
Staging overview
NetWorker staging is a separate process but relies on the cloning mechanism.
Save set staging is the process of transferring data from one storage medium to
another medium, and then removing the data from its original location. For example,
the initial backup data can be directed to a high performance file type or advanced
file type device. In this way, the backup time is reduced by taking advantage of a file
or advanced file type device. At a later time, outside of the regular backup period, the
data can be moved to a less expensive but more permanent storage medium, such as
magnetic tape. After the backup data is moved, the initial backup data can be deleted
from the file or advanced file type device so that sufficient disk space is available for
the next backup.
Staging example
In Figure 11 on page 136, the staging action will result in the deletion of the original
save sets on the Volume A1, once they had been successfully staged (cloned) to
volume B1. The Xs indicate that once a successful clone copy has completed, the
original save sets are deleted. This is the difference between a clone and a stage
operation. The save sets appear to move from one storage to another. The resulting
save set is identical to that of the first, but in a different location.
Figure 11 Staging
Staging
The destination
A save set can be staged from one disk to another as many times as required. For
example, a save set could staged from disk 1, to disk 2, to disk 3, and finally to a
remote tape device or cloud device. Once the save set is staged to a tape or cloud
device, it cannot be staged again. However, you could still clone the tape or cloud
volume.
Staging can be driven by any of the following:
◆ Calendar-based process, such as keeping the save set for 30 days on the staging
device before moving the data to the next device.
◆ Event-based process, such as when available space in the staging pool drops
below a set threshold. When this happens, the oldest save sets are moved until
available space reaches a preset upper threshold.
◆ Administrator-based process, such as allowing the administrator to either reset
the threshold or manually select save sets to stage.
Staging does not affect the retention policy of backup data. Therefore, staged data is
still available for recovery.
When the stage process encounters an error after successfully cloning specified save
sets, it deletes only those successful save sets from the source volume before the
program is aborted. This ensures that after staging only a single set of save sets exists
in either the source volumes or clone volumes.
Working with staging policies

This section describes how to work with staging policies:
◆ “Creating a staging policy” on page 137
◆ “Editing a staging policy” on page 139
◆ “Copying a staging resource” on page 139
◆ “Deleting a staging policy” on page 140
◆ “Finding the clone ID of a save set” on page 140
The EMC NetWorker Administration Guide provides information on file type device
(FTD) and advanced file type device (AFTD) configuration.
Creating a staging policy

Before creating a staging policy configure all appropriate devices. Otherwise, no
devices will be listed in the Devices attribute.
To prevent an AFTD from becoming full during backup, the staging policy must be
set up so that save sets are automatically moved to another medium to make disk
space available in the AFTD.
To create a staging policy:
1. In the Administration window, click Configuration.
2. In the left pane, select Staging.
3. From the File menu, select New.
4. In the Name attribute, type a name for the staging policy.
The destination 137

Staging
5. In the Comment attribute, type a description of the staging policy.

6. To enable staging to begin immediately or to be invoked automatically at a later
time, set the Enabled attribute to Yes.
Note: You can enable or disable staging at any time.
7. In the Devices attribute, select the file type and adv_file type devices as the
source device for staging.
Note: The adv_file device and its corresponding _AF_readonly device will both be selected
automatically, even if only one device was selected as the source of staging.
You can assign multiple devices to the staging policy, but a given device cannot be
controlled by more than one staging policy.
8. For the Destination Pool attribute, select the destination pool for the staged data.
Note: The Default volume can only be staged to the Default or Default Clone pool.
Similarly, the Default Clone volume can only be staged to the Default or Default Clone
pool and Archive data can only be staged to the Archive Clone pool. The other volume
types can be staged to any pool. If the Clone pool you have selected is restricted to storage
node devices, you will also need to modify Clone Storage Node attribute of the Client
resource for the NetWorker server to include the storage node name.
9. In the High-Water Mark (%) attribute, type or select a number.

This value is the point at which save sets should be staged, measured as the
percentage of available space used on the filesystem partition that the file device
is on. Staging continues until the low-water mark is reached (see step 10).
Note: The high-water mark must be greater than the low-water mark.
10. In the Low-Water Mark (%) attribute, type or select a number. This is the point at
which the staging process will stop, measured as the percentage of available
space on the filesystem partition that the file device is on.
11. From the Save Set Selection attribute, select from the list to determine the save
set selection criteria for staging.
12. In the Max Storage Period attribute, type the number of hours or days for a save
set to be in a volume before it is staged to a different storage medium.
Note: The Max Storage Period attribute is used in conjunction with the filesystem Check
Interval attribute. Once the Max Storage Period value is reached, staging does not begin
until the next filesystem check.
13. In the Max Storage Period Unit attribute, select Hours or Days.
14. In the Recover Space Interval attribute, type the number of minutes or hours
between recover space operations for save sets with no entries in the media
database from file or advanced file type devices.
15. In the Recover Space Interval Unit attribute, select Minutes or Hours.
Staging
16. In the File System Check Interval attribute, type the number of minutes or hours
between filesystem checks.
Note: At every File System Check interval, if either the High-Water Mark or Max Storage
Period has been reached, a staging operation is initiated.
17. In the File System Check Interval Unit attribute, select Minutes or Hours.
18. To invoke the staging policy immediately, complete this step. Otherwise, skip this
step:
a. Click the Operations tab.
b. In the Start Now attribute, select one of these operations:
– Recover space — Recovers space for save sets that have no entries in the
media database and deletes all recycled save sets.
– Check file system — Checks filesystem and stage data, if necessary.
– Stage all save sets — Stages all save sets to the destination pool.
The selected operation applies to all devices associated with this policy.
Note: The choice you make takes effect immediately after clicking OK. After the staging
operation is complete, this attribute returns to the default setting (blank).
19. When all the staging attributes are configured, click OK.
Editing a staging policy

To edit a staging policy:
3. In the right pane, select the Staging policy to edit.
Note: You cannot edit the name of an existing staging policy.
4. From the File menu, select Properties.

5. Make any necessary changes and click OK.
Copying a staging resource

To copy a staging resource:
3. In the right pane, select the Staging resource to copy.
4. From the Edit menu, select Copy. The Create Staging dialog box appears,
containing the same information as the staging resource that was copied, except
for the Name attribute.
5. Type the name for the new Staging resource in the Name attribute, edit any other
attributes as appropriate.
6. Click OK.
Working with staging policies 139

Staging
Deleting a staging policy
Note: The Default staging policy cannot be deleted.
To delete a staging policy:

3. Remove all devices from the Staging policy:
a. In the right pane, select the Staging policy to be deleted.
b. From the File menu, select Properties.
c. In the Devices attribute, ensure that all listed devices are unselected.
d. Click OK.
4. In the right pane, select the Staging policy to be deleted.
5. From the File menu, select Delete.
6. When prompted, click Yes to confirm the deletion.
Staging from the NetWorker Management Console

Staging a save set from the command prompt works differently than staging a save
set from the NetWorker Management Console (NetWorker Console).
When a save set is cloned, the cloned save sets are given the same save set ID as the
original save set with a new clone ID.
When staging from the NetWorker Console, select save sets that belong to a single
device.
Staging from the command line

When staging from the command prompt, specify the save set IDs to be staged.
The NetWorker software stages all the save sets with the specified save set ID and
then removes those save sets. That means any cloned versions of the save set are
removed when the original is removed.
To ensure that all clones are not removed, specify a clone ID with the save set ID to
indicate the source volume of the staging. For example:
nsrstage -m -S ssid/cloneid
Finding the clone ID of a save set

To find the clone ID of a save set, use the mminfo command. For example:
mminfo -avot -r "volume,ssid,cloneid,name"
The EMC NetWorker Command Reference Guide or the UNIX man pages provide
information about nsrstage or mminfo commands.
Glossary
This glossary provides definitions for terms used in this guide.
A
administrator Person who normally installs, configures, and maintains software on network
computers, and who adds users and defines user privileges.
attribute Feature of a NetWorker resource. It is a setting or information that the resource

provides.
B
backup 1. Duplicate of database or application data, or entire computer system, stored
separately from the original, which can be used to recover the original if it is
destroyed or damaged.
2. Operation that saves data to a volume for use as a backup.
backup group See “group.”
backup volume See “volume.”
bootstrap Save set that is essential for NetWorker disaster recovery procedures with the
NetWorker server. The bootstrap consists of three components that reside on the
NetWorker server: the media database, the resource database, and a server index.
browse policy NetWorker policy that specifies the period of time during which backup entries are
retained in the client file index. The index makes the associated backed-up data
readily accessible for recovery by desktop users. See “retention policy.”
C
client Computer, workstation, or fileserver whose data can be backed up and restored with
NetWorker software.
client file index Database maintained by the NetWorker server that tracks every database object, file,
or filesystem backed up. The NetWorker server maintains a single index file for each
client computer. The tracking information is purged from the index after the browse
time of each backup expires.
Glossary
Client resource NetWorker server resource that identifies the save sets to be backed up on a client.
The Client resource also specifies information about the backup, such as the schedule,
browse policy, and retention policy for the save sets.
clone Duplicate copy of backed-up data, which is indexed and tracked by the NetWorker
server. Single save sets or entire volumes can be cloned.
clone-controlled Creation of a replica of deduplicated data copied from one Data Domain device to
replication another, which is scheduled by the NMC clone feature and is indexed and tracked by
the NetWorker server.
clone volume Exact duplicate of a backup or archive volume. NetWorker software can track four
types of volumes (backup, archive, backup clone, and archive clone). Save sets of
these different types may not be intermixed on one volume. Clone volumes may be
used in exactly the same way as the original backup or archive volume.
Console server See “NetWorker Management Console.”
D
database 1. A collection of data arranged for ease and speed of update, search, and retrieval by
computer software.
2. An instance of a database management system (DBMS), which in a simple case
might be a single file containing many records, each of which contains the same set of
fields.
datazone Group of computers administered by a NetWorker server.
DD Boost An optimized library and communication framework with a special Data Domain
API that allows the NetWorker software to define and interact with storage devices
on the Data Domain system.
DD device A logical storage device created on a Data Domain server, which is used to store
deduplicated NetWorker backups. Each device appears as a folder on the Data
Domain system and is listed with a storage volume name in NMC.
DD OS Data Domain Operating System.
deduplication Process of detecting and identifying the redundant variable-length blocks (data
segments) within a given set of data to eliminate redundancy.
deduplication Type of backup in which redundant data blocks are replaced by metadata pointers
backup and only unique blocks of data are stored. When the deduplicated data is restored,
the data is returned to its original native format.
deduplication ratio Reduction in storage space required to store data as a result of deduplication
technology, usually combined with data compression, for example, a 20:1 space
reduction.
device 1. Storage unit that can contain a backup volume. A storage unit can be a tape
device, optical drive, autochanger, or disk connected to the server or storage
node.
2. Access path to the physical drive, when dynamic drive sharing (DDS) is enabled.
3. General term that refers to storage hardware.
Glossary
disaster recovery Recovery from any disruptive situation, such as hardware failure or software
corruption, in which ordinary data recovery procedures are not sufficient to restore a
system and its data to normal day-to-day operations.
distributed segment Part of the DD Boost interface, which enables data deduplication to be performed on
processing a host before the data is sent to the Data Domain system for storage.
E
enabler code Special code that activates the software. The enabler code that unlocks the base
features for software is called a base enabler. Enabler codes for additional features or
products (for example, library support) are called add-on enablers.
G
group Client computer or group of clients that are configured to back up files during a
NetWorker scheduled backup, according to a single designated schedule or set of
conditions.
H
host Computer on a network.
L
label Electronic header on a volume used for identification by NetWorker or other data
mover application.
license enabler See “enabler code.”
M
managed application Program that can be monitored or administered, or both from the Console server.
media Physical storage, such as magnetic tape, optical disk, or file system, to which backup
data is written. See also “volume.”
media index Database that contains indexed entries of storage volume location and the lifecycle
status of all data and volumes managed by the NetWorker server. Also known as
media database.
media pool See “pool.”
N
NetWorker server Computer on a network that runs the NetWorker server software, contains the online
indexes, and provides backup and restore services to the clients and storage nodes on
the same network.
NetWorker Software product that is used to manage NetWorker servers and clients. The
Management NetWorker Management Console (NMC) server also provides reporting and
Console monitoring capabilities for all NetWorker processes.
notification Message sent to the NetWorker administrator about important NetWorker events.
Glossary
O
online indexes Databases located on the NetWorker server that contain all the information
pertaining to the client backups (client file index) and backup volumes (media
database).
optimized cloning See ”clone-controlled replication.”
P
pathname Set of instructions to the operating system for accessing a file. An absolute pathname
indicates how to find a file starting from the root directory and working down the
directory tree. A relative pathname indicates how to find a file starting from the
current location.
policy Set of constraints that specify how long the save sets for a client are available for
recovery. Each NetWorker client has a browse policy and a retention policy. When the
browse policy expires, the save sets associated with that policy are no longer readily
available for browsing in an index. When the retention policy expires, the save sets
associated with that policy are marked recyclable.
pool 1. NetWorker feature that assigns specific backup data to be stored on selected media
volumes.
2. Collection of NetWorker backup volumes to which specific data has been backed
up.
R
recover To restore data files from a backup volume to a client disk and apply transactional
(redo) logs to the data to make it consistent with a given point in time.
remote device 1. Storage device that is attached to a storage node that is separate from the
NetWorker server.
2. Storage device located at an offsite location that stores a copy of data from a
primary storage device for disaster recovery.
remote replication Exact copy of deduplicated data that resides on a Data Domain storage system, which
is stored across a LAN or WAN to another Data Domain storage system for disaster
recovery protection.
replication Process of creating a network-efficient, automated exact copy of deduplicated data is

created, for example, from a local Data Domain server source to a remote Data
Domain server target, for disaster recovery.
resource Software component that describes details of the NetWorker server or its clients.
Clients, devices, schedules, groups, and policies are all NetWorker resources. Each
resource has configurable attributes that define its properties.
resource database NetWorker database of information about each configured resource.
restore To retrieve individual data files from backup media and copy the files to disk,
without applying transaction logs. See also “recover.”
retention policy NetWorker setting that determines the minimum period of time that backup data is
retained on a volume available for recovery. Once this time is exceeded, the data is
eligible to be overwritten. See also “browse policy.”
Glossary
retrieve To locate and recover archived files and directories.
S
save NetWorker command that backs up client files to backup media volumes and makes
data entries in the online index.
save set Group of files or a file system that has been backed up on storage media.
save set ID (SSID) Internal identification number assigned to a save set.
save stream Data and save set information that is written to a storage volume during a backup. A
save stream originates from a single save set.
scheduled backup Type of backup that is configured to start automatically at a specified time for a group
of one or more NetWorker clients. A scheduled backup generates a bootstrap save set.
SSIS See “save set ID (SSID).”
storage device See “device.”
storage node Computer with NetWorker software installed whose primary purpose is to receive a
backup stream from one or more backup clients and then write to save sets on storage
media.
T
trap Unsolicited notification sent from the SNMP agent to the network manager’s SNMP
event manager.
V
volume 1. Unit of physical storage medium, such as a magnetic tape, optical disk, or file
system used to store data. Backup data must be stored on a backup volume and
cannot be stored on an archive volume or a clone volume.
2. Identifiable unit of data storage that may reside on one or more computer disks.
volume ID (volid) Internal identification that NetWorker software assigns to a backup volume.
volume name Name that you assign to a backup volume when it is labeled. See also “label.”
VTL Virtual tape library. Software emulation of a physical tape library storage system.
Glossary

Cloning: Emc Networker

Uploaded by

Copyright:

Available Formats

Cloning: Emc Networker

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

Cloning: Emc Networker

Uploaded by

Copyright:

Available Formats

EMC® NetWorker®

Published May, 2011

2 EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide

Chapter 2 Planning and Practices

EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide 3

Chapter 3 Cloning Procedures

Chapter 4 Software Configuration

4 EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide

Chapter 5 NetWorker Module for Microsoft Applications

Chapter 6 NetWorker Module for Databases and Applications

EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide 5

Chapter 7 Recovering Data from Clones

6 EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide

NetWorker product documentation

EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide 7

NetWorker related documentation

8 EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide

Conventions used in this document

Note: A note presents information that is important, but is not hazard-related.

Normal Used in running (nonprocedural) text for:

Bold Used in running (nonprocedural) text for:

Used in procedures for:

Italic Used in all text (including procedures) for:

Courier Used for:

Courier bold Used for:

Courier italic Used in procedures for:

[] Square brackets enclose optional values

| Vertical bar indicates alternate selections - the bar means “or”

{} Braces indicate content that you must specify (that is, x or y or z)

... Ellipses indicate nonessential information omitted from the example

EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide 9

Technical support — For technical support, go to Powerlink and select Support. On

10 EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide

This chapter includes the following sections:

Revision Date Description of added or changed sections

A01 May 16, 2011 Initial publication of this document.

Cloning integration feature

12 EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide

Staging integration feature

Benefits of cloning and staging

Staging integration feature 13

◆ Allows cloning to be scheduled and prioritized outside of the backup window

Additional data protection

14 EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide

16 EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide

◆ Dedicated storage node

NetWorker Management Console

Save set attributes provide the following information:

18 EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide

Figure 1 Cloning example

Staging data example

Figure 2 Staging example

20 EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide

This chapter includes the following sections:

Planning and Practices 21

Deciding when to clone

22 EMC NetWorker Cloning Release 7.6 Service Pack 2 Integration Guide

The decision on when to clone depends on specific circumstances. However, in most

About clone pools