MR-1CP-NWIM Student Guide

NetWorker
Implementation and Management

Student Guide
EMC Education Services

February 2016
akhan@aayan.com
akhan@aayan.com
Welcome to NetWorker Implementation and Management training.
Copyright ©2016 EMC Corporation. All Rights Reserved. Published in the USA. 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. The trademarks, logos, and service
marks (collectively "Trademarks") appearing in this publication are the property of EMC Corporation and other parties. Nothing contained in this publication
should be construed as granting any license or right to use any Trademark without the prior written permission of the party that owns the Trademark.
EMC, EMC², the EMC logo, AccessAnywhere Access Logix, AdvantEdge, AlphaStor, AppSync ApplicationXtender, ArchiveXtender, Atmos, Authentica, Authentic
Problems, Automated Resource Manager, AutoStart, AutoSwap, AVALONidm, Avamar, Aveksa, Bus-Tech, Captiva, Catalog Solution, C-Clip, Celerra, Celerra
Replicator, Centera, CenterStage, CentraStar, EMC CertTracker. CIO Connect, ClaimPack, ClaimsEditor, Claralert ,cLARiiON, ClientPak, CloudArray, Codebook
Correlation Technology, Common Information Model, Compuset, Compute Anywhere, Configuration Intelligence, Configuresoft, Connectrix, Constellation
Computing, CoprHD, EMC ControlCenter, CopyCross, CopyPoint, CX, DataBridge , Data Protection Suite. Data Protection Advisor, DBClassify, DD Boost, Dantz,
DatabaseXtender, Data Domain, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, DLS ECO, Document Sciences, Documentum, DR Anywhere,
DSSD, ECS, elnput, E-Lab, Elastic Cloud Storage, EmailXaminer, EmailXtender , EMC Centera, EMC ControlCenter, EMC LifeLine, EMCTV, Enginuity, EPFM.
eRoom, Event Explorer, FAST, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony, Global File Virtualization, Graphic Visualization, Greenplum, HighRoad,
HomeBase, Illuminator , InfoArchive, InfoMover, Infoscape, Infra, InputAccel, InputAccel Express, Invista, Ionix, Isilon, ISIS,Kazeon, EMC LifeLine, Mainframe
Appliance for Storage, Mainframe Data Library, Max Retriever, MCx, MediaStor , Metro, MetroPoint, MirrorView, Mozy, Multi-Band Deduplication,Navisphere,
Netstorage, NetWitness, NetWorker, EMC OnCourse, OnRack, OpenScale, Petrocloud, PixTools, Powerlink, PowerPath, PowerSnap, ProSphere,
ProtectEverywhere, ProtectPoint, EMC Proven, EMC Proven Professional, QuickScan, RAPIDPath, EMC RecoverPoint, Rainfinity, RepliCare, RepliStor,
ResourcePak, Retrospect, RSA, the RSA logo, SafeLine, SAN Advisor, SAN Copy, SAN Manager, ScaleIO Smarts, Silver Trail, EMC Snap, SnapImage, SnapSure,
SnapView, SourceOne, SRDF, EMC Storage Administrator, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix, Symmetrix DMX, Symmetrix
VMAX, TimeFinder, TwinStrata, UltraFlex, UltraPoint, UltraScale, Unisphere, Universal Data Consistency, Vblock, VCE. Velocity, Viewlets, ViPR, Virtual Matrix,
Virtual Matrix Architecture, Virtual Provisioning, Virtualize Everything, Compromise Nothing, Virtuent, VMAX, VMAXe, VNX, VNXe, Voyence, VPLEX, VSAM-
Assist, VSAM I/O PLUS, VSET, VSPEX, Watch4net, WebXtender, xPression, xPresso, Xtrem, XtremCache, XtremSF, XtremSW, XtremIO, YottaYotta, Zero-
Friction Enterprise Storage.
Revision Date: February 2016
Revision Number: MR-1CP-NWIM.9.1
Copyright 2016 EMC Corporation. All rights reserved.

akhan@aayan.com Module: Course Introduction 1
This course provides participants with a solid foundation in EMC NetWorker installation,
configuration and administration topics.

A suggested agenda for the NetWorker Implementation and Management five-day course is
shown here. Please note that the actual class agenda may vary from day-to-day.

Having an understanding of where the NetWorker Implementation and Management course fits
into your NetWorker curriculum will help you find the additional training you require.
This slide is a depiction of the NetWorker training options available to you and how they fit into
the EMC certification tracks and exams. The courses in the NetWorker curriculum start at the
fundamental level and progress through specialist to more advanced, expert topics. All courses
in the curriculum are open to all audiences.
The review topics in the first lesson of this course, NetWorker Implementation and
Management, will direct you to the topics in the prerequisite eLearning course, NetWorker
Fundamentals, where you will find more detailed information about each topic.
Technical certification through the EMC Proven™ Professional program for the Storage
Administrators and Implementation Engineers tracks is based on the courses shown in the
diagram.
More information about the these exams and the supporting curriculum can be found at:
https://education.emc.com/guest/certification/.

This module begins with a review of NetWorker data protection functions, components and
terms that were first covered in the prerequisite eLearning course, NetWorker Fundamentals.
Then, we take a detailed look at the role of each NetWorker process in a backup operation and
the content and use of NetWorker control data.

akhan@aayan.com Module: Networker Basics 1
To gain the most benefit from this course, certain prerequisite knowledge is required. The
prerequisite eLearning, NetWorker Fundamentals, provides an effective overview of NetWorker
provided data protection functions, architecture, and terminologies.
This lesson provides a brief review of these prerequisites along with cross-references to the
prerequisite course to help you obtain this knowledge.

EMC NetWorker works within the existing framework of hardware, operating system software,
and network communication protocols to provide a comprehensive and consolidated data
protection solution.
NetWorker protects critical business data by centralizing, automating, and accelerating backup
and recovery operations across an enterprise. NetWorker provides backup and recovery
support for diverse computing and storage environments including business applications and
virtual environments. Performance enhancements, such as block based backups, improve
backup performance and reduce the impact of backups on production environments. User
authentication, authorization and encryption support ensure information security. Backup
storage options include the leading deduplication technologies, disk backup and snapshot
technologies, as well as deep integration with the latest databases and applications.

In addition to backup and recovery, NetWorker provides a full range of data protection
functions including tracking and reporting, aging, cloning, and staging. The NetWorker
Fundamentals prerequisite eLearning introduces these functions and we will look at how
NetWorker supports these functions in detail throughout this course.
A backup is a copy of production data, created and retained for the sole purpose of recovering
deleted or corrupted data.
Recovery is the process of restoring data to a given point in time.
Tracking is the process of storing information or metadata about backup save sets. The
Management Console server uses this information to generate reports.
Aging determines the length of time that backup data is available for recovery. NetWorker
allows you to specify how long individual copies of data are maintained.
Cloning is the process of copying a save set from one NetWorker backup volume to another.
The clone can then be managed independently with its own retention time.
Staging is the process of moving a save set from one volume to another.

To implement a backup and recovery strategy, it is important to understand the roles and
functions of the various components in a NetWorker datazone. A detailed description of each
component is discussed in the NetWorker Fundamentals eLearning course and is summarized
below.
The NetWorker server is a physical or virtual machine that manages the datazone and
facilitates client backups and recoveries. The NetWorker server maintains tracking and
configuration information.
NetWorker storage nodes are dedicated hosts with direct-attached or SAN/LAN-accessible

devices to support the storage of backup data. Storage nodes write data to and read data from
backup devices. The NetWorker server is also a NetWorker storage node.
The Management Console Server provides a global view of the NetWorker backup environment
for centralized management of one or more NetWorker datazones.
The Management Console client is a Java-based graphical user interface accessible from any
supported web browser.
NetWorker supports many types of devices that can be used to store backup data. Device
types include virtual and physical tape, disk, and cloud storage devices. Backup to
deduplication storage is supported with Data Domain and Avamar. Configuring and managing
backup devices is covered in detail later in this course.
Finally, the most fundamental NetWorker component is the NetWorker client. NetWorker client
software provides the functionality for generating backups, pushing the data to a NetWorker
storage node or directly to a backup device, and retrieving data for a recovery. Client software
is installed on all NetWorker hosts.

To understand the backup process, you need to understand the backup terminology associated
with the NetWorker product. Listed here are some common NetWorker terms that were
introduced in NetWorker Fundamentals.
A save set is one or more files, directories, and/or file systems, or application-generated data,
residing on a NetWorker client, that is backed up as a unit to a NetWorker storage node and
written to backup storage. A save stream is a single save set in the process of being backed up
or recovered. The save program is used to back up a save set.
A volume is a unit of media, such as a tape cartridge or file system directory, to which backup
data is written.
A pool is defined as a collection of NetWorker labelled volumes. Pools are used in NetWorker to
assign specific backup data to specific volumes.
A protection group defines a set of data sources to protect, such as clients, VMware objects or
save sets.
A workflow defines an action or set of actions to be performed on an assigned protection

group. Workflows specify when and how often to run. An action defines a data protection
operation like backup, clone or snapshot. Within an action, you specify the backup level(s) and
pool to be used when the action runs.
Protection policies provide an organizational container for the workflows, actions and groups.
As we progress through this course, we will cover these terms in more detail and build upon
these definitions.

This lesson covers the NetWorker processes associated with NetWorker client, storage node,
server and NetWorker Management Console. The lesson concludes with a high-level process
and data flow of a typical NetWorker scheduled backup.

NetWorker processes (or daemons) are involved in almost all NetWorker operations, including
backups and recoveries. There are one or more NetWorker processes to support each of the
three NetWorker host functions:
• Client
• Storage node
• Server
In a Microsoft Windows environment, the core NetWorker processes are started via two
NetWorker services.
The following pages provide summary information about the main NetWorker daemons. For
more detailed information, please see the EMC NetWorker Command Reference Guide or the
man pages.

The NetWorker client process, nsrexecd (network save and recover execution daemon), runs
on NetWorker clients to support remote execution requests from NetWorker servers. For
example, nsrexecd executes a backup command at the request of the NetWorker server. The
nsrexecd process also determines which RPC ports to use to support and request NetWorker
services.
In a UNIX environment, nsrexecd is started automatically during system boot up. In a

Windows environment, nsrexecd is started via the NetWorker Remote Exec Service, which
is configured to start automatically during boot up.

The NetWorker storage node management daemon, nsrsnmd (network save and recover
storage node management daemon, provides an RPC-based service that manages all device
operations and the nsrmmd processes on the storage node on behalf of the nsrd process on the
NetWorker server. The nsrsnmd daemon is responsible for ensuring that the device operations
get performed when needed by nsrd. There is one nsrsnmd process running on each
configured storage node.
The NetWorker storage node daemon, nsrmmd (network save and recover media multiplexing
daemon), runs on NetWorker storage nodes to support reading and writing of data to devices.
The nsrmmd daemon writes the backup data sent by save to a volume in the backup device it is
controlling, sends information to the NetWorker server to track data written to the volume, and
reads data from the volume during operations such as recoveries and cloning. One nsrmmd is
started for each device configured as a NetWorker resource.
Note: For disk-type devices there may be more than one nsrmmd per device.
For each enabled library (jukebox) in a datazone, nsrmmgd on the NetWorker server spawns a
nsrlcpd (network save and recover library control daemon) to control the actual jukebox
resources, such as media, slots, drives, and access ports. After performing a task, nsrlcpd
returns status information to nsrmmgd, which in turn provides it to nsrd.

The NetWorker server processes provide access to NetWorker services such as configuration
information, support for backup and recovery requests, and access to the media database,
client file indexes, and jobs database. NetWorker server daemons include:
nsrd - (network save and recover daemon) is the master daemon. nsrd manages the
NetWorker resource database, which contains almost all NetWorker configuration information.
It also starts the nsrmmdbd and nsrindexd processes. nsrd is started automatically at system
startup. Once started, nsrd starts the other server daemons and the nsrsnmd process on the
storage node.
nsrmmdbd - (network save and recover media management database daemon) provides the
read and write service for the media database.
nsrindexd - (network save and recover index daemon) provides the read and write service
for the client file index databases.
nsrjobd – (network save and recover job daemon) is responsible for coordinating all
scheduled backups. It stores information about these operations and provides it to the
NetWorker server and the NMC server for reporting purposes.
nsrmmgd – (network save and recover media management daemon) manages all library
operations. It is started on the NetWorker server by nsrd when the NetWorker services are
started or when the first jukebox resource is configured and enabled.
In a Windows environment, these processes are started via the NetWorker Backup and
Recover Server service.
Note: For more detailed information, refer to the NetWorker Command Reference Guide.

The three NetWorker Management Console server processes are:
httpd – Apache httpd is the embedded web server.
gstd – (general services toolkit daemon) is the master Console process and is responsible for
starting the gsttclsh and postgres processes. After a Console client has established
communication with the Console server, all further communication is performed through gstd.
postgres – This process manages the PostgreSQL Generic Services Toolkit (GST) database.
This database is also referred to as the Console server database and contains information
concerning all backup, recover, and cloning operations performed on NetWorker servers
managed by the Console server. This information is used by gstd to generate reports.
In a Linux environment, the processes are started automatically during system boot up. On a
Microsoft Windows host, the processes are started via the EMC GST Service which is configured
to start automatically during boot up; httpd is registered as the EMC GST Web Service.

This slide shows a high-level inter-process communication and data flow of a typical NetWorker
scheduled backup to a Data Domain device.
1. The server’s nsrd starts a scheduled backup. nsrd asks nsrjobd to send a remote
execution request to the client’s nsrexecd, requesting that it execute the NetWorker save
command to perform the backup.
2. The save command started on the client communicates with the server’s nsrd (through
nsrjobd) to request backup support.
3. nsrd requests nsrsnmd for backup support, nsrsnmd matches the backup to a storage
node’s nsrmmd based on configuration information and save request attributes.
4. Once the volume has been mounted on the backup device, nsrd directs the client to push
its data to the storage node.
5. The client:
- Pushes the data to the storage node’s nsrmmd
- Sends tracking information to its client file index (CFI) via the server’s nsrindexd
6. nsrmmd on the storage node:
- Writes the data sent by the save command to the volume
- Sends tracking information to the media database via the server’s nsrmmdbd

Resources are used to configure a NetWorker environment. Resources are managed as
configurable objects by the NetWorker administrator. Resource types include policies, clients,
devices, tape libraries, and numerous other configurable components of the backup
environment. Anything configurable to NetWorker is configured as a resource.
A resource is defined by its attributes and the values of those attributes. There can be multiple
configurations or instances for each resource type.
For example, in the slide above, the client resource for bongo has a Save set attribute
configured to back up the /oracle directory. This client is a member of the Payroll group and
the Payroll group is assigned to the File system backups workflow which is configured to start
backups at 9:00 P.M.
Nearly all of the resources are stored on the NetWorker server and managed by the nsrd
daemon. A small number of resources are managed on the NetWorker client.

This lesson covers the directory structure and content of the CFI, media and jobs databases.

The NetWorker server maintains tracking information for save sets in both the client file
indexes (CFIs) and in the media database. Volume information is maintained only in the media
database.
A client file index (CFI) stores information about each file backed up by a NetWorker client.
There is one CFI per physical NetWorker client. The stored information includes file
characteristics such as owner, size, permissions, and modification and access times, as well as
the timestamp of when the file was backed up. All files in a given save set have the exact
same backup timestamp. This information is used to support browsable recoveries, which
allow you to easily recover a client to a specific point in time.
As a save set ages, its CFI records are automatically purged to save space. The length of time
that the records are retained is determined by the Browse policy attribute in the client
resource. CFIs may require large amounts of space on the NetWorker server. Each record in a
CFI uses approximately 160 bytes. The default path of a CFI is
/nsr/index/hostname_of_client/db6.
The media database contains information about all NetWorker volumes and the save sets on
those volumes. For each volume there is a volume record. For each save set on a volume,
there is a save set record. This information is critical for supporting recoveries and is also used
during incremental backups to determine the timestamp of a previous backup. The location of
the media database is /nsr/mm/mmvolrel.
Important: Beginning with NetWorker 9, you specify only a retention period when backing up a
save set. NetWorker uses this value for both the Browse time and the Retention time for the
save set.

A CFI directory contains a header and journal file as well as a series of directories whose
names are hexadecimal time stamps. Each save set tracked in a CFI has a record and a key
file which are stored in a subdirectory determined by the time stamp of the save set
(nsavetime value). The record and key files are named nsavetime.rec, nsavetime.k0 and
nsavetime.k1.
The data in the CFI files is XDR encoded for NetWorker use. Therefore, only NetWorker
GUI/CLI interfaces should be used to view and manage the CFI data.

Each record in a CFI contains the path name of a backed up file or directory, and the
timestamp associated with the save set that it is part of. The timestamp matches the
timestamp of a save set record in the media database, and is used in determining which save
set and volume is needed when recovering the file. File attribute and backup information are
also stored in the CFI.
nsrinfo displays the timestamp in two formats. The nsavetime format is the number of
seconds since January 1, 1970. This is the time format used internally by NetWorker. The
save time format is a more human-readable form of the date and time.

The media database directory structure includes a header file and files to store client records,
save set records and volume records. Each client record, save set record, and volume record
file has a set of supporting index files.
All the files under /nsr/mm make up the media database.
To maintain its integrity only use NetWorker GUI or CLI interfaces to view and manage the
data contained in the media database.
Note: The media database is a SQLite database. Operational requests are handled in parallel
and a targeted cache facility is employed, thus optimizing performance.

The media database contains a record for each NetWorker volume and for each save set
written to a volume.

The jobs database in NetWorker is responsible for managing and monitoring all jobs within the
environment. These jobs include server activities such as cloning, staging, and recovery
operations as well as client activities like save or save groups. When these jobs are started the
jobs database collects all the runtime information as well as completion information.
The jobs database consists of an embedded SQLite database server which is a full database
engine that can handle high loads without performance concerns. The database itself is stored
in a single file on the NetWorker server and is managed via time-based purging. The database
should not exceed 1 GB in size. The jobs database is re-created during NetWorker server
disaster recovery procedures.

This module covered a refresh of NetWorker data protection functions, components and terms
that were first covered in the prerequisite eLearning course, NetWorker Fundamentals. Then,
we took a detailed look at the role of each NetWorker process in a backup operation and the
content and use of NetWorker control data, including the CFI, media and jobs databases.

This module focuses on installation of NetWorker and NetWorker Management Console
software. In addition to the installation process, this module describes how to verify a
successful installation and how to manually start and stop the core NetWorker
daemons/services.

akhan@aayan.com
Module: NetWorker Planning and Installation 1
This lesson covers NetWorker pre-installation planning. This includes examining some
typical NetWorker configurations as well as identifying key items like disk space, firewalls,
networking, and server sizing.

akhan@aayan.com
Before installing NetWorker it is important to review the NetWorker documentation,
particularly the release notes, and the installation guides.
The next step is to identify the host roles that are needed in your environment. This
includes NetWorker server, console server, storage nodes, and any proxy nodes that may
be used.
Once these are identified you need to validate sizing for each of these components as well
as any additional datazone requirements like the use of multi-tenancy.

akhan@aayan.com
At a minimum, review the EMC NetWorker Administration Guide, the EMC NetWorker
Installation Guide, and the EMC NetWorker Release Notes before installing the NetWorker
software.
The Release Notes documentation contains important configuration tips, installation and
upgrade notes, and the latest software patch information.
The Installation Guide provides step-by-step instructions for installing NetWorker server,
storage node, client and NMC.
The Administration Guide describes how to configure and maintain NetWorker.
Finally, the NetWorker 9 differences technical note covers the differences between
NetWorker 9 and previous releases. For information about updating to NetWorker 9 from a
previous NetWorker release, please refer to the Updating to NetWorker 9.0 from a Previous
Release Guide.
NetWorker product information and documentation can be found on the EMC Support web
site, https://support.emc.com. Note that the version numbers and dates of the manuals
will be different than what is shown here.

akhan@aayan.com
One of the first considerations to make is the location of the key NetWorker services. In
particular we are looking at the NetWorker server, NetWorker Management Console (NMC)
and the EMC Licensing Solution License server. These components can be co-located on
the same host, or distributed. It is important that the location of these services be decided
prior to sizing the hardware that will host them.
Additionally, you should consider the way that backup data is sent to the target devices. If
storage nodes will be used, you should determine how many and where they will best be
located. If using client direct, it’s important to ensure that backup clients have direct
access to the devices and you have identified all necessary data paths.
More often than not, you will have a combination of methods, using client direct for some
clients and storage nodes for others.

akhan@aayan.com
A typical NetWorker configuration consists of a NetWorker server located at the primary
data center. Clients are configured to back up to either a storage node, or to the backup
devices directly using client direct. Common backup targets are Data Domain systems
using DD Boost or CIFS/NFS , tape libraries, virtual tape libraries, or CloudBoost appliances.
In addition to the primary data center, there is usually a disaster recovery site which hosts
a remote NetWorker storage node along with remote storage devices. When using Data
Domain, replication is configured to replicate data between local and remote data centers.
Additionally a tape library may be configured at the remote site for cloning data to tape for
long-term retention.

akhan@aayan.com
The unique environment and service level agreements (SLA) of the organization are going
to dictate the design of the NetWorker environment. As another example of what a
NetWorker environment might look like, this configuration uses cloud storage for long-term
data retention. In this configuration, data is backed up to one or more Data Domain
systems at the primary site, then cloned to a CloudBoost appliance and sent to a cloud
storage provider for long term retention. This configuration could also include a DR site
that leverages Data Domain replication, or clone-controlled replication for transferring data
between sites.
Note: It is important to understand that the data protection requirements largely dictate
the design of the NetWorker environment. NetWorker provides a multitude of features and
capabilities to allow it to be customized for even the most complex environments.

akhan@aayan.com
Before installing NetWorker software, you need to determine the proper sizing requirements
based on your environment. Some of these considerations include:
Disk Space Requirements
There are many components of a NetWorker environment that contribute to the disk space
needs. The NetWorker databases are stored on the server and should be sized based on
the number of resources that will be maintained on the server. Depending on your
retention requirements client file indexes can occupy a large amount of disk space as well.
Other disk space considerations include your software repository for pushing client updates,
as well as space required by the NetWorker Management Console and its database. It is
recommended to store the NetWorker databases on a different volume from the operating
system. SAN volumes are an excellent choice because they allow for higher I/O loads along
with advanced features like cloning and replication. NAS storage is not recommended for
the NetWorker databases.
Platform Compatibility
The best platform for your environment is generally the one that you have the most
administrative experience with. This could be Windows or Linux depending on your
environment. Another consideration is the use of a physical NetWorker server or the
NetWorker Virtual Edition (NVE). See the EMC NetWorker Software Compatibility Guide for
supported OS and platforms.
Network Connectivity
During backups and recoveries, there is considerable RPC communication between

NetWorker hosts. Additionally you need to consider the throughput required for
transmitting backup data between clients, storage nodes, and target devices. A common
consideration is whether or not to implement a dedicated network for backup traffic.

akhan@aayan.com
The NetWorker multi-tenancy facility allows for the creation of multiple restricted
datazones. End users can access a single NetWorker server without being able to view
data, backups, recoveries, or modify objects in other datazones. In addition, tenant
administrators within a restricted datazone can only see a very limited amount of the
information managed by the global administrator or other restricted datazones from the
console or CLI.
The multi-tenancy feature is enabled by configuring a restricted datazone resource on the

NetWorker server.
Note: It is recommended that multi-tenancy be configured during installation of a new

NetWorker server. While it is possible to configure an existing NetWorker server with
restricted datazones, it will require significantly more planning and preparation.

akhan@aayan.com
The use of restricted datazones (RDZs) in NetWorker adds an extra layer of privilege in the
environment. For example, a global administrator may create an RDZ for each company
division thus restricting target resources to each division. In this example, the global
administrator maintains the configuration and makes all the changes to each of the RDZs.
Another option is that the global administrator may decide to provide the overall RDZ
structure and configure a tenant administrator for each RDZ who will configure and run
their respective RDZs. This later scenario is typically used by backup service providers.

akhan@aayan.com
This lesson covers the EMC Licensing Solution model as well as some considerations when
upgrading from previous licensing models.

akhan@aayan.com
NetWorker 9 introduces the EMC Licensing Solution model which leverages the Common
Licensing Platform (CLP).
The EMC Licensing Solution is based on capacity and is the only licensing model available
for new NetWorker installations.
With this solution, one or more license servers must be installed in the NetWorker
environment. The license server is responsible for managing the NetWorker license and
capacity allocation across multiple datazones.
The license server reads a license file stored on the server to determine the type of licenses
and the amount of capacity purchased.
Configuration and management of the license server is performed by using the LMTOOLS
application on Windows or LMGRD on Linux.
With the EMC Licensing Solution, license files are node-locked to the License server. The
entitlements are tied to a customer’s ID and not to a specific NetWorker server. This makes
for more flexibility in license management.
The EMC Licensing Solution supports scaling of the NetWorker environment. There may also
be multiple license servers each servicing a set of NetWorker servers. In this case, the
license file for each license server is unique. Each license server is independent of any other
license servers in an environment. For example, in a site with 18 NetWorker servers, one
License server may manage 10 NetWorker servers and a second License server then
manages the remaining 8.

akhan@aayan.com
The license file contains critical information about the location of the license server and
information about the type of licenses and capacity purchased. All NetWorker licenses are
stored in one “master” license file which resides on the license server host. The license
server uses its copy to respond to queries from NetWorker servers for a license.
Additionally a copy of the license file resides on each NetWorker server and is used by the
CLP API to allow contact with the license server.
Contents of a license file include the hostname and IP address of the EMC Licensing
Solution License server. The license file for NetWorker may contain two types of licenses:
an update license which is required if updating from a previous NetWorker release and a
capacity license which enables multiple datazones.
One or more INCREMENT lines make up the actual license(s).
The NETWORKER_UPDATE line is required when updating from a previous NetWorker

release.
NETWORKER_CAPACITY defines the licensed capacity that can be shared across datazones.
Note: License files cannot be edited.

akhan@aayan.com
When the nsrd process is started, the NetWorker server looks for any license resources in
the RAP database. If no license resources are found then the traditional 45 day (30 days
plus 15 days grace) evaluation mode begins. Next, NetWorker contacts the EMC Licensing
Solution License server and requests one unit of capacity. If the capacity entitlement is
missing, another request is scheduled for an hour later until the request is fulfilled. When
the request is honored, a RAP license resource is created in the RAP database licensing the
NetWorker server. If, after 45 days and there is still no license file, the evaluation period
ends and the NetWorker server reverts to restore only mode.
If a NetWorker server is restarted and the EMC Licensing Solution is in effect, the RAP
license resources are queried and all licenses are checked out again. In the event that the
EMC License server cannot be reached, the existing RAP resources are kept and periodic
attempts to check out licenses are made.

akhan@aayan.com
Prior to NetWorker 9, either a traditional or a capacity-based licensing model was used.
The traditional model leveraged enabler and authorization codes to activate specific
features and options. The capacity model allowed the use of all NetWorker features
provided the purchased storage capacity was not exceeded for a datazone. When updating
to NetWorker 9, sites are not automatically converted to the new EMC Licensing Solution
model.
Users of the legacy models may continue to use those models but they must install an EMC
Licensing Solution License server and set up a license file. The license file contains an
update license entitlement that is required to continue using traditional licensing.
Though not mandatory, it is recommended to convert to the EMC Licensing Solution model
for the flexibility and ease of use it affords. The evaluation period provides you with 30 days
along with a 15 days grace period to determine whether you want to continue using a
legacy model or use the EMC Licensing Solution.
If a user of the legacy capacity model wants to migrate to the EMC License Solution upon
upgrade to NetWorker 9, any unused capacity can be carried over and applied to the
amount of storage purchased for the new model.
Note: Once a NetWorker server is using the new model, there is no provision to go back to
legacy licensing.

akhan@aayan.com
Requests for licenses are made to the EMC Licensing Solution License server by the
NetWorker process, nsrlmc. Nsrd schedules nsrlmc for several reasons including updating
the information about the License server, obtaining an update license, or to request a
capacity license.
The EMC Licensing Solution License server keeps count of how many units of capacity are
checked out from a license file. By default, one unit of measure is checked out for each
capacity request that is satisfied. Nsrlmc installs the entitlements on the NetWorker server
through an exchange with the license server. The backup administrator does not manually
install entitlements on the NetWorker server.
When a NetWorker server stops, the license server checks the checked out units back in.
The CLP API provides a function for nsrlmc to maintain this heart beat.

akhan@aayan.com
Install the License server on a supported platform that is accessible to the datazones in the
environment that it will service. EMC recommends that all license server files and binaries
be located on locally mounted disks to ensure that licenses are available while the server is
running.
Note: The EMC Licensing Solution License server is a separate install from the NetWorker 9
server installation. The license server installation package is located in the same location as
the NetWorker server software.
Next, obtain a license file from Licensing@EMC.com. Provide the hostname and IP address
of the license server. NetWorker servers must communicate heartbeat and licensing
information with the EMC license server. By default, the license server and NetWorker will
communicate over port 27000. If port 27000 is not available, indicate which port you will
use as an alternate when obtaining the license file.
Copy the license file to a folder on the License server and the nsr/lic directory on each
NetWorker server that will access this license server. Even if the license server is co-located
with a NetWorker server, it must still be copied to both locations.
Finally, run the LMTools utility (Windows) or lmgrd (Linux) to configure and start the license
server service. To validate the license server service in running on Windows, look for the
service name in Windows Task Manager. The default service name is “Flexlm Service 1”,
however, this can be defined during initial configuration. In Linux, you can search for the
Lmgrd service to validate it is running. The license server application should be running
constantly to serve licenses to NetWorker.

akhan@aayan.com
The properties of the NetWorker server are updated with information from the locally
residing license file and by querying the EMC License server. The CLP License server and
CLP License server port attribute values are obtained from the license file on the NetWorker
server host. Solution ID and CLP SWID are read from a license checked out from the EMC
License server.
The CLP refresh field allows the administrator to force NetWorker to re-query the License
server and license file.

akhan@aayan.com
This lesson covers identifying NetWorker software packages, installing NetWorker software
and configuring NMC to manage multiple NetWorker servers.

akhan@aayan.com
The NetWorker Windows installation packages for NetWorker server and client software
include the packages listed here:
NetWorker.X.x.x.exe is a comprehensive, all-in-one installer for Windows. With this

package you can install the NetWorker server, client, NMC, AuthC, NetWorker adaptor and
Avamar client from one installer.
Smaller, faster installers are available for the NetWorker client and NetWorker extended
client. Use these installers when only installing the client software. These are:
lgtoclnt.X.x.x.exe is recommended to be used when just installing the NetWorker base

client. It is also the preferred installer when installing NMM and all add-ins that require the
NetWorker client first.
lgtoxtdclnt.X.x.x.exe is the extended client package. This package provides additional

feature support for NetWorker clients including NetWorker Snapshot Management, NAS
snapshot, CLI utilities, NetWorker Module for Meditech, and SCVMM features. By separating
the install of the advanced client capabilities into a separate package, the base client install
package is much smaller and more manageable. It gives the administrator additional
flexibility to only install the additional features on a client host where they are required.
In Windows, the extended client is automatically installed when using the NetWorker
package for installing the NetWorker server and storage node. It is not automatically
installed when selecting the client install only from this package.
Please refer to the EMC NetWorker Installation Guide for installation requirements and
detailed procedures.

akhan@aayan.com
This diagram shows the major software packages required for the NetWorker server,
storage node and client installation types and the order that the packages are installed.
The base client package, lgtoclnt, must be installed first. The extended client software
package, lgtoxtdclnt, and the block based backup software, lgtobbb, may also be
required to be installed on the client.
When installing a NetWorker storage node, install the NetWorker client software first,
including the extended client, followed by the storage node rpm, lgtonode.
The NetWorker Authentication Service is a separate package, lgtoauthc, that must be

installed before installing the NetWorker server or NMC software.
When installing a NetWorker server, install the NetWorker client and storage node software
first. Then, install the NetWorker server software package, lgtoserv, and the adaptor
package, lgtoadpt.
Also, as with previous NetWorker releases, the NetWorker Management Console requires
that at least the NetWorker base client is installed first. The NMC installation package is
lgtonmc.
Please refer to the EMC NetWorker Installation Guide for installation requirements and
detailed procedures.

akhan@aayan.com
The NetWorker server is supported on Windows x64 and Linux x64 platforms only.
Note that the NetWorker server is not supported on Solaris, AIX, Linux x86 and HP-UX
platforms; however, NetWorker storage nodes and clients are supported on these
platforms. NetWorker does not support Linux ia64.

akhan@aayan.com
Log into the target computer with administrator privileges. After starting the installation,
accept the license agreement on the Welcome to the Setup Wizard screen. In the
Installation Type and Location window, select the software that you want to install on
the host. Note the default location for the software installation files.
The next several slides cover information that is supplied during the installation process.

akhan@aayan.com
During the NetWorker installation, the wizard prompts for information for configuring the
NetWorker Authentication Service. On this screen, enter the authentication server host
name and port.

akhan@aayan.com
Other configuration options for AuthC include specifying a password for the keystore file
and a password for the authentication service administrator account. After installation,
when you login as the administrator user, use the password specified for the authentication
service administrator account.

akhan@aayan.com
During the installation for NMC, you are prompted for the NMC installation and database
folders, the name of the authentication service host and NMC client service and web server
ports. By default, the user name for the Postgres database on the NMC server is postgres.
This account is used to start the embedded Postgres database. If this account doesn’t exist
at the time of installation, it will be automatically created.

akhan@aayan.com
For new installations, make sure Skip the Migration is selected for the Migrating the
NMC Database window. The NetWorker software processes are automatically started at
the end of the installation.

akhan@aayan.com
To launch the NetWorker Management Console, enter the URL in a supported web browser.
The URL is:
http://console_server:http_service_port
where console_server is the host name of the console server and http_service_port is the
port number for the embedded web server that was specified during the Console server
installation. The default HTTP port is 9000. Alternatively, on Windows, the NMC can be
started from the shortcut on the desktop or from the Windows Start menu.
A supported version of Java Runtime Environment (JRE) must be installed on the Console
client. JRE, which includes Java Web Start, must be installed in order to download and run
the Console client properly. Upon launching the Console client, you are notified if an
appropriate version of JRE is not installed. Follow instructions for downloading and installing
a supported version of JRE from the Java web site. After installing JRE, close and restart the
browser.
The NetWorker Management Console Login screen is displayed to the user. A user
cannot run NMC unless a valid user name and password combination is provided. For User
Name, use administrator and for Password, use the password that was specified for the
NMC authentication during the installation.

akhan@aayan.com
The first time you log in to the NetWorker Management Console, the Console
Configuration Wizard starts and displays a welcome screen.
Click Next to confirm the authentication server service account for the NMC server.
Click Next to specify the NetWorker server that will back up the NMC server database.
Click Next to specify a list of managed NetWorker servers. If this NetWorker Management
Console server will be managing more than one NetWorker server, add the names of each
server on a separate line.
Click Finish to perform the configuration wizard tasks.

akhan@aayan.com
This is the Enterprise screen displayed in NetWorker Management Console. When you
explore this interface, you will notice that most windows in NetWorker will display a list of
links on the right-hand side of the window, as shown here. These links will direct you to
NetWorker documentation, EMC Support, the NetWorker Community Forum and other
NetWorker resources.
To launch NetWorker Administration for a specific NetWorker server, click the server’s
name in this window and double-click the Launch NetWorker Administration link.

akhan@aayan.com
NetWorker uses WiX bootstrapper technology for installation. You can install NetWorker
software using a silent install from the command line. Here are some examples of installing
and uninstalling using the NetWorker-9.0.x.x.exe. (The actual name of the executable may
be different depending on the version of NetWorker used.)
Note that when installing the NetWorker server, ensure that the NetWorker authentication
service is started before starting the NetWorker server services.
For more information about Microsoft Windows silent installations of NetWorker software,
including available installation options and troubleshooting, please refer to the EMC
NetWorker Installation Guide.

akhan@aayan.com
It is recommended that you install the latest version of the 64-bit Java 7 or Java 8 software
on the NetWorker server host before installing the NetWorker server or NetWorker
Authentication Service software.
After installing the NetWorker server, install the EMC License server to use the EMC
Licensing Solution model.
At the beginning of the NetWorker Windows base client installation, you can choose to run
the System Configuration Checker. This checks for any OS-related configuration issues. If
any warnings are brought up, they can be addressed and then the Configuration Checker
can be re-run post-installation to verify that the warnings are cleared.
For NetWorker integration with Avamar, NetWorker uses the Avamar avtar binary on client
hosts. The Avamar client package is included with NetWorker and must be installed on the
client hosts that use the NetWorker Avamar integration for backup storage. This is included
when installing Windows clients using the separate base client install package.
Note: When installing a NetWorker server, skip the NetWorker License Manager software
installation option during the NetWorker installation. This is for the legacy NetWorker
License Manager and is not required in order to use the EMC Licensing Solution.

akhan@aayan.com
This lesson covers how to view the status of the NetWorker processes and how to start and
stop the NetWorker processes. We also discuss how to uninstall the software.

akhan@aayan.com
To verify the NetWorker and Console installations, go to the installation directory and verify
its contents.
In Windows, the default installation directory is C:\Program Files\EMC NetWorker. This

directory contains both binaries and NetWorker databases. Shown above, the Management
and nsr subdirectories exist and have appropriate contents.
For Linux, the NetWorker software is installed in /usr by default. NetWorker binaries are
located in /usr/sbin. NetWorker directories are located in /nsr. Console server is installed
in the /opt/lgtonmc directory and the Console server database is located in
/opt/lgtonmc/lgto_gstdb.

akhan@aayan.com
During a Windows installation, NetWorker and Console server processes are started
automatically. The Windows Task Manager can be used to verify they are running.
For Linux , starting the processes during installation is optional. You can use a command
such as ps to verify the appropriate daemon processes are running.
On Windows, there are always two httpd processes running when the NMC server is active.
On Linux, there are two or more httpd processes running, where the parent httpd process
runs as root and the child processes run as the user name specified during the installation.

akhan@aayan.com
To start the NetWorker services on a Windows NetWorker server:
1. Start the NetWorker Remote Exec Service.
2. Start the NetWorker Backup and Recover Server.
To stop the NetWorker services:
1. Stop the NetWorker Remote Exec Service. Since the EMC GST Service and
the Backup and Recover Server are dependent services, Windows will ask if you
also want to stop these services.
2. Click Yes to stop the services.
3. If desired/applicable, stop the NetWorker Power Monitor service.
To start the Console server service:
1. Start the NetWorker Remote Exec Service.
2. Start the EMC GST Service.

akhan@aayan.com
System processes are started via run-control scripts executed at system startup. When
installing a NetWorker host, a run-control script named networker is installed in the
appropriate system directory, usually a subdirectory of /etc.
The networker script can be executed manually, using a start argument, to start the
NetWorker daemons. When the stop argument is used, all NetWorker daemons, as well as
any other running NetWorker processes, are stopped.
The NetWorker installation process installs a program named nsr_shutdown. This is the
recommended method of gracefully shutting down all NetWorker processes.
When the Console server is installed, a run-control script named gst is placed in the same
location as the networker script. Use an argument of start to start the Console server
daemons and an argument of stop to stop the Console server daemons.
NetWorker server daemons can also be started manually by executing nsrexecd, followed
by nsrd. For a NetWorker client or storage node, only nsrexecd should be started.

akhan@aayan.com
On a Windows host, use Programs and Features from the Control Panel to uninstall the
NetWorker and NetWorker Management Console software. Or use the installation binaries
and select uninstall when prompted for the operation you wish to perform.
On a Linux host, use the operating system’s software removal utility to remove the
software.
In either case, the default behavior during removal is to perform a partial uninstall. This
leaves the NetWorker control data installed. To perform a complete uninstall on a Linux
host, the directory containing the NetWorker control data, \nsr, must be manually removed
using a utility such as rm. To perform a complete uninstall on a Windows host, manually
remove the C:\Program Files\EMC NetWorker folder or whatever folder contains the
NetWorker software.
Important:
Do not remove the install directory if the NetWorker or Console server software packages
will be updated or reinstalled.
Refer to the NetWorker Upgrading Guide available at EMC Support web site,
https://support.emc.com for detailed upgrading instructions.”
As part of the upgrade to NetWorker 9, the NMC database must be migrated to PostgreSQL.
A separate tool called gstdbunload is provided to unload data from the previous NMC
Sybase database. gstdbunload must be run before uninstalling or upgrading the previous
NMC version.

akhan@aayan.com
The lab exercises for this course give you an opportunity to reinforce the information you
are learning in the course. You will be using a virtual data center (VDC) environment to
perform the NetWorker Implementation and Management course lab exercises.
Each student works in their own VDC configuration, accessed with an assigned VDC
username and password. The NetWorker Implementation and Management lab
configuration consists of these five virtual machines:
nw - This is your primary Windows workstation for the labs.
linux-sn – This is your Linux host for the labs.
ad - This is a domain controller and DNS for your configuration.
win-client – This is your NetWorker Windows client.
ddve – a virtual tape library.

akhan@aayan.com
This lab covers installing NetWorker server and NetWorker Management Console server
software on a Windows host in the lab environment. This host will be your NetWorker server
during the remainder of the class. You will perform the initial configuration steps for
NetWorker Management Console. You will install NetWorker client on the second Windows
host and NetWorker storage node on the Linux host. Finally, you install and configure the
License server.

akhan@aayan.com
The NetWorker Virtual Edition solution is a NetWorker server that runs as a virtual appliance
in a VMware environment. The NetWorker Virtual Edition standardizes the NetWorker
solution on VMware infrastructure, thus enabling rapid deployment and simplified
management by virtualizing all aspects of the backup and recovery solution. Benefits
include lowering the cost of ownership by sharing server and storage infrastructure, and
reducing the cost of cost of support and maintenance for additional hardware.
This demonstration walks you through the steps of deploying and configuring a NetWorker
Virtual Edition NetWorker 9 server. To view the demonstration, enter this URL in your web
browser:
https://edutube.emc.com/Player.aspx?vno=McC1OMnFdkoU7hefLR8KZQ==&autoplay=true

akhan@aayan.com
This module covered the installation of NetWorker and NetWorker Management Console
software. In addition to the installation process, this module describes how to verify a
successful installation and how to manually start and stop the core NetWorker
daemons/services.

akhan@aayan.com
This module focuses on the NetWorker media tracking and management functions.
Specifically, we look at the role and function of NetWorker pools, how to create label
templates and pools, and finally, how to label a device into a pool.

akhan@aayan.com Module: Media Tracking and Management 1
A media pool, or pool, is a NetWorker resource that represents a set of volumes. A volume
is associated with a pool when it is labeled.
Pools automatically separate data by data type. Pools are used by the NetWorker server to
direct a save set being backed up or cloned to a set of volumes.
As illustrated in the slide, there are two types of pools – Backup and Backup Clone – that
are used by NetWorker to segregate one type of data from another. For example, a save
set being backed up can only be written to a volume belonging to a Backup pool, and when
a save set is cloned, the new clone copy of the save set can only be written to a volume in
a Backup Clone pool.

A common use of media pools is to segregate data into different pools based on backup
level or type. Pools can be used to maximize recovery speed by consolidating all data for a
specific client onto the same volume. Another use is to target specific data to specific
devices. An example of this is to write all data for the Accounting department to a pool for a
Data Domain device that only contains data from this department.

The table on this slide summarizes how NetWorker determines which pool receives the
backup data, which is based on the configuration of action, client, and pool resource
attributes.
It is recommended to use the Pool attribute in the action resource to specify the pool to be
used for the particular backup action. However, you can elect to use a pool specified in the
client resource by changing the setting of the Client Override Behavior attribute in the
backup action.
If the Client Override Behavior attribute is set to Client Can Not Override, then
NetWorker uses the value for the Pool attribute in the backup action.
If the Client Override Behavior attribute is set to Client Can Override, then the value
for the Pool attribute in the client resource is used. If the Pool value in the client resource
is empty, than the value defined in the backup action is used. This is the default setting for
new action specifications.

The first step in configuring a new pool is to create a NetWorker label template resource.
The label template is used by NetWorker to determine the volume name to assign to a
volume being labeled into the pool. A unique label is created for each volume by applying
the label template.
Ideally, each pool should have its own unique label template. However, more than one pool
can use the same label template. If a volume being labeled resides in an autochanger, or
library, that is configured to match barcode labels, the label template is ignored and the
volume name will be the same as its barcode value.
NetWorker has several pre-created label templates that can be used or you can create new
label templates from the Media window as shown on this slide. The lower left picture shows
the configured label template named Astro. The labels assigned to volumes start with
Astro.001, Astro.002, and so on up to Astro.999 and are based on the values specified in
the Fields and Separator attributes.

The NetWorker pool resource is used to configure a new media pool from the Media window
of NetWorker Administration. Here we are creating a Backup pool named, Astro, that will
use the Astro label template.

Use the Configuration tab of the pool resource to specify these fields:
Max parallelism specifies the maximum number of simultaneous save streams that can be
sent to a drive on which a volume from this pool is mounted.
When the Auto media verify attribute is selected, the NetWorker server verifies data
written to volumes from the pool. Verification occurs when either a volume becomes full or
a volume becomes idle. Data is verified by repositioning the volume to read a portion of the
data previously written to the media. The data read is compared to the original data
written. Verification succeeds if there is a match. If verification fails, the volume is marked
full.
The Recycle from other pools attribute allows recyclable volumes from other pools to be
relabeled into a different pool. The Recycle to other pools attribute allows recyclable
volumes in the pool to be relabeled into a different pool. Both attributes are disabled by
default.
When the Store index entries attribute is enabled (default setting), CFI entries are
generated for save sets that are written to the pool.

Automatically relabeling a recyclable volume allows for volumes to be relabeled outside of
backup windows. Also, backup and clone operations can complete in potentially less time
where appendable volumes are available at the time of the backup or clone.
With the use of virtual tape libraries, recycling of volumes is critical to reclaim disk space.
Relabeling of eligible volumes in a pool can be scheduled to occur automatically using these
attributes under Volume Operations:
• Recycle start: Defines the time to start the automatic relabel process each day. By
default, the automatic relabel process is not done.
• Recycle interval: Defines the interval between two starts of automatic relabel
processes.
• Max volumes to recycle: Defines the maximum number of recyclable volumes that
can be relabeled during each automatic relabel process.
• Recycle last start: This is the last time that scheduled automatic recycling was
performed.
Note: For a complete list of pool and label template resource attributes, see the nsr_pool
and nsr_label topics in the EMC NetWorker Command Reference Guide or the Linux man
pages. Also, please refer to the Media pools topic in the EMC NetWorker Administration
Guide.

A volume must be labeled before NetWorker can write to it. During volume labeling, the
NetWorker software writes a unique label on the volume. Label devices by right-clicking the
device from the Devices window of NetWorker Administration.
The label contains information such as the volume name, the name of the pool to which the
volume was assigned, and the block size to be used when writing to the volume.
During a backup, the NetWorker server matches a save set to the appropriate nsrmmd based
on the pool to which the volume belongs.
The following events happen when a volume is labeled.

• The volume is named and a volume record is created in the media database. If any
previous entry for the volume exists in the media database, it is deleted. Any
existing data on the volume is effectively deleted.
• The volume is assigned to a pool.
• The label being written establishes the volume’s block size which is determined by
the device’s Media type attribute.
In this slide, you can see that we are labeling the device, AFTD1, into the Astro pool that
uses the volume label, Astro.001.

In this lab, you configure a label template resource for a pool and then configure a pool
resource. Then, you will create a NetWorker AFTD device and label this device into the new
pool.

This module focused on the NetWorker media tracking and management functions.
Specifically, we looked at the role and function of NetWorker pools, how to create label
templates and pools, and how to label a device into a pool.

This module focuses on the various ways of performing backups with NetWorker. We look at
the workflows and actions used for traditional, scheduled backups and how to perform
manual backups with user interfaces and commands. This module also covers performing
backups with NetWorker Snapshot Management, how to back up virtual clients and the use
of NetWorker modules for application and database backups.

akhan@aayan.com Module: Performing Backups 1
This lesson covers data protection policies and the resources used for running traditional file
system backups.

NetWorker allows you to perform two types of backups: scheduled and manual.
– A scheduled or server-initiated backup is started from the NetWorker server and
sends a backup request to one or more NetWorker clients. A scheduled backup is
configured to start automatically through the use of NetWorker policies but may
also be started on-demand, either from NetWorker Administration or the
command line.
– A manual or client-initiated backup is started from a NetWorker client by a user
such as the backup administrator. It is usually a one-time only event.
NetWorker provides user interfaces for configuring and running both types of backups as
shown here. Commands are also available for configuring and running backups from the
command line.
Scheduled backups are the preferred option for performing on-going, day-to-day backups
as well as ad-hoc or on-demand backups. By using scheduled backups, you ensure that
data is protected on a regular basis according to specifications that you define in NetWorker
data protection policies. It is recommended to reserve client-initiated backups for specific
use cases only as needed.

The Data Protection lifecycle consists of backing up specific data to primary backup media,
cloning the backup data to secondary backup media, and managing the data through the
length of time it is required to be kept for recovery. With NetWorker, clients are protected
automatically throughout the data protection lifecycle through the use of policies. Policies
enable you to define the resources and settings to implement your business policies for the
data that you want to protect.
Policies allow you to design a data protection solution at the data level instead of at the
host level. You define what data you want to back up for each host using a NetWorker client
resource. Then, you assign those client resources to backup groups. Next, you design
workflows that define the actions or tasks that you want to perform for that group, when to
automatically run the workflow and how often to run.
As you can see here, policies allow for the creation of complex workflows by chaining
multiple actions in a workflow. In this way, you can specify what happens to a group of
client resources throughout the data protection lifecycle.
In the example shown here, for Workflow 1, there is only one action in the workflow. The
save sets defined in the client resources of Protection Group 1 are backed up by the
traditional backup action. Workflow 2 contains two actions. First, a check connectivity action
is performed. Then, only the save sets for the clients in the group that are online are
backed up by the backup action.

These are the steps to create a protection policy.
First, we create client resources for the clients hosting the data that we want to back up.
We create a protection group and add the client resources into the group.
After creating a policy resource, we create a workflow, assign the group to the workflow and
decide when and how often the workflow automatically runs.
Lastly, we create one or more actions in the workflow to specify what we want to occur
during the workflow.
When planning and implementing your protection strategy, you may want to create groups
before creating the workflows as we have outlined here, or you can create workflows first
and then create groups and assign them to the applicable workflows, whichever works best
for you.
The easiest and most common way to create client, group, and policy resources is to use
the wizards and windows in the NetWorker Administration Protection window. In this
lesson, we explore these resources and the options they offer.

NetWorker comes with pre-configured resources to facilitate setup of a data protection
environment using NetWorker.
NetWorker includes two client resources for backing up the NetWorker server and the
NetWorker Management Console server.
There are also several pre-configured policies along with corresponding groups and
workflows. These pre-configured policies are the Bronze, Gold, Platinum, and Silver policies.
You can modify the pre-configured resources and also create your own. Groups, policies and
workflows can also be copied and deleted. Workflows can be moved from one policy to
another.

Create client resources for backup clients. Along with other configuration options, the client
resource specifies the data sets to be backed up. You may decide to have multiple client
resources for a single host machine; for example, you may want to back up different save
sets for the same client host at different times.
NetWorker provides the New Client Wizard to walk users through the steps to quickly
create a client. The New Client Wizard is accessed from the Protection window by right-
clicking Clients.
The wizard asks for the client name and supplies default values for the several attributes in
the client resource. The slide lists the client resource created for a client named
winclient.emc.edu.
It is important to note that prior to configuring the client using the New Client Wizard, we
first installed the NetWorker client software on the client host.
Alternatively, you can use the Properties window of the client resource to create and
configure a NetWorker client.
The New Client Wizard presents the most common client resource fields to allow
administrators to quickly configure client resources for most situations. You will find that
the Client Properties window contains many more fields to further customize backups for
individual client resources and save sets. A full set of attributes is displayed by selecting
Diagnostic Mode from the View menu. We will discuss several of these additional fields
later in this course.
Note: To modify an existing client created with the wizard, right-click the client and select
Modify Client Wizard.

Options displayed by the wizard for configuring the client depend upon the application type
selected. Here you can see some of the client resource options that are available through
the New Client Wizard for a traditional, file system backup.

From the Select File System Objects window, identify the save sets that will be backed up
by this client resource. For a file system backup, NetWorker displays the client’s file
systems allowing you to select the data to be backed up. There is no limit to the number of
save sets you can specify.
The slide shows a specification for backing up two save sets: C:\Documents and Settings
and C:\Program Files.

By default, NetWorker provides a value for the Save set attribute which defines which files
are backed up for this client resource. The default value for the Save set attribute is All,
which causes all local file systems/drives to be backed up. Data included in the All save set
by operating system is shown in the table on the slide.
Important: Certain save sets are excluded from the All save set. Also special keywords can
be used with All to define the file systems to include in a client backup. For a list of
excluded save sets and key words, please refer to the “The All save set” topic in the
NetWorker Administration Guide.
The special save set DISASTER_RECOVERY:\ is used to back up all of the data that is
required to perform a Windows BMR recovery. Recovering Windows hosts is covered in
more detail later in this course.
If Save set is set to anything other than All and you want to back up any of the Windows
SYSTEM save sets, you must explicitly specify them in the save set list.

When planning a traditional backup environment, you organize clients into protection
groups based on the workflow that the group is assigned. For example, assign all clients
that you want to have backed up at certain backup levels starting at 7 P.M. each day into
the same protection group. One protection group is created for each workflow.
Each group can be assigned to only one workflow. The same client resource can be added
to more than one group.

For file system or traditional backups, there are two types of groups that can be defined.
A Basic client group defines a static list of client resources to back up. When creating the
group, you select the client resources to add to the group. In the screenshot on the left, we
have added a winclient.emc.edu client resource to the group.
A Dynamic client group determines the clients to be protected at run time based on the
value of a tag. When the group is created, you specify a tag that is used to choose the
clients. Then, when configuring clients, you assign that tag to all clients that you want to be
members of the group. At run time, NetWorker automatically generates a list of client
resources with a tag that matches the client tag specified for the group. The benefit of this
type of group is that an administrator does not need to remember to add specific clients to
a group; clients are automatically added to the group based on the tag you assign when
creating the client resource. In the example on the right, we have created a dynamic clients
group with a tag of Backup at 7. At run time, this client resource is automatically added to
the group.

Use policies to organize the data protection resources to support the operations that you
want to perform in your backup environment. You may choose to use the pre-configured
policies or create new policies. For example, you can use the pre-configured policies to
organize backup operations by criticality, Bronze, Gold, Platinum and Silver. Another
example is to create policies according to the types of backups performed, such as file
system, database, and snapshot. The choice is up to the backup administrator.
To edit existing policies or create new ones, use the Protection window. Here we have
created a new policy named File system Backups.
Note: For definitions of the attributes displayed on NetWorker property windows,

click in the lower left corner of each window.

From the Protection window create a workflow within the policy. Specify the workflow
name, the time to start the workflow, notification settings for the workflow, and the
protection group. Make sure the Enabled and AutoStart options are selected to ensure
that the workflow runs at the selected time and intervals. The Interval attribute
determines how frequently the workflow runs; the default is every 24 hours or once each
day. The Restart Window attribute specifies the length of time that NetWorker can
manually or automatically restart a failed or canceled workflow.
Note: A group must be assigned to a workflow in order for any actions in the workflow to be
performed.

There are four types of supported actions for traditional backup workflows. These are
Backup Traditional, Probe, Check Connectivity and Clone.
A Backup Traditional action performs a scheduled backup of the save sets defined in the
client resources of the group assigned to the workflow.
A Probe action runs a user-defined script on a client host that passes a return code. If the
return code is 0, the next action such as a backup, is performed. If the return code is 1,
then the next action in the workflow is not performed.
A Check Connectivity action is used to ensure there is connectivity between the clients and
the NetWorker server before a sequential action is performed.
A Clone action is used to create a copy of one or more save sets.
The next several slides in this lesson describe some of the most common options for each of
the backup traditional, probe, and check connectivity action types.

For a traditional backup action, you specify the level of backup to occur on each day of the
selected period, either Weekly by day or Monthly by day. Supported backup levels are
full, incremental, cumulative incremental, logs only, synthetic full and skip.
The default schedule is to perform a full backup on Sunday followed by incremental backups
the rest of the week. To quickly set the same value for each day, select the backup type
from the list and choose Make All. The supported backup levels are explained in detail in
the next several pages.

NetWorker supports full level backups that back up all data in a save set, or one of several
levels that back up only data that has changed since a previous backup. The levels used are
similar to the UNIX ufsdump or dump command.
The backup levels supported by NetWorker are listed on the slide.
A full backup backs up all files and directories in a save set and is the lowest backup level,
being equivalent to a UNIX level 0 backup. A full backup requires the most storage space
and takes the longest time to perform.
An incremental backup contains all files that have changed since the last backup of any
type while a cumulative incremental backup contains files that have changed since the last
full. Using incremental and cumulative incremental backup levels generally takes less time
than performing full backups and uses less volume space. However, using these backup
levels may slow file recovery if multiple save sets are required to recover to a particular
point in time.

A synthetic full backup is formed by combining a full backup and subsequent incremental
backups. The resulting backup is a full backup equivalent to a traditional full backup as of
the time of the last incremental backup used in the creation of the synthetic full backup.
The synthetic full backup is not just the sum of the incremental backups, but takes into
account deleted files as well.
Only the NetWorker server and storage nodes are involved in synthetic full backup
processing. By lessening the number of traditional full backups, the backup workload of
backup clients is reduced, as well as the network overhead involved in transferring the
backup data from the clients to the storage node. Synthetic backups also reduce recovery
time and steps as data can be restored from the synthetic full backup instead of a
traditional full backup and all its dependent incremental backups.
In the example shown on the slide, the synthetic full backup taken on Wednesday combines
the full backup run on Monday with the incremental backups run on Tuesday and
Wednesday. The resulting synthetic full backup is equivalent to a traditional full backup run
at the same time as the Wednesday incremental backup and reflects the state of the data
as of Wednesday’s incremental backup. The incremental backup run on Thursday includes
all changes since the incremental on Wednesday. The next synthetic full backup (not
shown on the slide) will combine the previous synthetic full backup and subsequent
incremental backups.

For Backup Options, choose the storage node and media pool with the devices on which to
store the backup data. Set Retention for the amount of time that the backup data will be
retained. After this period expires, the metadata about the save sets is removed from the
client file index and marked as recyclable in the media database.
When Client Override Behavior is set to Client Can Override, values for Schedule,
Pool, Storage Nodes and Retention policy in the client resource are used instead of the
values for comparable attributes in the backup action. The default for this attribute is to
allow the client to override the action.

Some commonly used options in the Specify the Advanced Options window include:
Retries: The number of times NetWorker should retry failed probe and backup actions.
Retry delay: Amount of time in seconds that NetWorker waits before retrying a failed
action.
Inactivity Timeout: Maximum amount of time that a job is given to fail to communicate
back to the NetWorker server.
Use the Overrides calendar to schedule a level of backup to be performed on a single,

specific date. For example, for this backup action, we went with the default schedule values
of a full backup on Sunday and incremental backups for the other days of the week. We
need to do equipment maintenance on November 4th, so we want to perform a full backup
on the day before. So, we are setting an override level of full for November 3rd.
Note: For definitions of the attributes displayed on NetWorker wizard windows, click in
the lower left corner of each window.

There may be times when you want to treat one client differently from the others in the
group. After allowing client overrides in the backup action of the workflow, a value in the
corresponding client resource’s Schedule, Pool, Storage Nodes and/or Retention policy
attributes will be used for the backup instead of the value in the comparable field in the
action.
This slide shows the attributes in the client resource for specifying a schedule, pool, storage
node and retention. (Note you can see these attributes in the Client Properties window by
enabling Diagnostic Mode from the View menu.) The selections for the Retention policy
attribute can be found in Time Policies from the Server window. The selections for the
Schedule attribute are found under Schedules from the tree in the Protection window.
The options for the various pre-configured Time Policies and Schedules may be modified
if needed.
In the example shown here, we want to keep the save sets defined for this client resource
for a period of one quarter while the backup action specifies a period of one month. All
other save sets for the client resources in the group assigned to the action will be retained
for one month.

A probe action runs a user-defined script on clients that are members of the group that is
assigned to the probe action’s workflow. Based on the result of the probe, the subsequent
backup action in the workflow is either run or not run.
For a probe action, you define the days of the week that the action will run. If the Start
backup only after all probes succeed attribute is checked, the following backup action
runs only if all probes in client resources in the assigned group succeed. Succeed is defined
as a return code of 0. If the field is not checked, the backup action starts if any one of the
probes associated with a client resource in the assigned group succeeds.

A probe is a user-defined script or program that passes a return code. The name of the
probe script must begin with nsr or save. The probe script must reside in the directory that
contains the NetWorker client binaries on each client referencing the probe, such as
C:\Program Files\EMC NetWorker\nsr\bin for Windows clients and /usr/sbin on UNIX
machines.
A NetWorker probe resource is created for each probe script. The probe resource specifies
the probe script name and command options, if any.
The probe resource is then associated with one or more client resources.
The client resources are associated with a group and the group is associated with the
workflow containing the probe action.

A check connectivity action tests connectivity between the NetWorker server and clients
that are members of the group that is assigned to the workflow. Based on the result of the
test, the subsequent action in the workflow, which can be either a probe action or a backup
action, is either run or not run.
For the check connectivity action, you define the days of the week that the action will run.
If the Succeed only after all clients succeed attribute is checked, the following action
runs only if all clients succeed. If the checkbox is cleared, the following action runs if
connectivity is achieved for one or more clients.
Note: Retries, Retry Delay, Inactivity Timeout and Send notification options are not
supported for the check connectivity action.

Now, let’s put all the components of a NetWorker data protection policy together. In
addition to the table view, NetWorker provides a visual representation of each workflow.
This is a view of a basic backup policy configured and displayed from the Protection
window.
The Traditional backups workflow pictured here is a workflow in the policy named File
system Backups for a basic backup. The workflow is configured with one action named
backup. When the workflow runs, the workflow backs up the clients assigned to the File
system backup group to a device in the AFTD Devices pool.
Through the use of policies and workflows, NetWorker enables you to see at-a-glance how
your data is protected.

As we have seen, a workflow can have one action or multiple actions. Multiple actions can
be chained together and run sequentially or concurrently. Where there are multiple actions
in a workflow, a subsequent action in the chain operates on the output generated by the
action that precedes it in the workflow. The subsequent action does not start until the
previous action finishes.
The table summarizes the valid workflows that can be configured for traditional backups
through to a third action. A workflow can be as simple as one backup action or it can be
more complex with a succession of various actions. There are some rules, though, for which
action types can occur where in the succession. For example, the only action that can follow
a traditional backup is a clone action. The clone action can occur either concurrently with or
after the backup action. A workflow for a traditional backup can optionally include a probe
or check connectivity action before the backup. A check connectivity action can be followed
by either a backup action or a probe action. When configuring the actions in a workflow, the
wizard enforces these rules by only presenting the valid action types depending upon the
position of the action in the workflow.
In the example displayed above, a workflow named “Workflow for probe” contains two
actions, a probe action and a backup action. A list of clients to back up is sent to the backup
action depending upon the outcome of the probe action.

To create a workflow for a traditional backup containing more than one action, start with
the first action for the workflow. Per the chart on the previous slide, that can be either a
probe, check connectivity or a backup traditional action. Then, the next action that you add
to the workflow depends upon what was chosen for the first action.
This is an example of a workflow with two actions; a check connectivity action followed by a
backup traditional action.

In this lab, you create the resources necessary for a traditional backup workflow. You create
a new client resource and assign the client to a new group, then create a new policy with a
new workflow and backup traditional action.

This lesson covers the data flow of scheduled or server-initiated backups, how to perform
ad-hoc backups of policies and workflows, and how to initiate policy-based backups from
the command line.
Finally, we discuss running manual, client-initiated backups using the save command and
NetWorker user.

Once a policy and its associated workflows are created, workflows automatically run
according to the time and interval specifications in the workflow. Workflows can also be
started manually on an ad-hoc basis from the NetWorker server using the NetWorker
Administration Protection or Monitoring windows and the nsrpolicy command at the
NetWorker server command line.
In this example, workflows in the DR Backups, Server Protection and Standard Filesystem
policies are enabled for autostart. Each workflow starts according to the schedule defined in
the workflow. The last time a policy, workflow or action was run is displayed in the Start
Time column of the Policies section of the Monitoring window.

Backups that run automatically or manually by a workflow can be referred to as server-
initiated backups as they are started from the NetWorker server.
The policy framework runs the savegrp command for probe and backup actions. savegrp
issues remote execution requests to a configured group of clients, causing the clients to run
a backup command (usually save) for their configured save sets. The client, group, and
policy resources, along with associated workflows and actions, determine what is backed
up, when it is backed up, how it is backed up and where the backup data is stored.
After an action, workflow or policy completes, the NetWorker server executes configured
notifications for these events.
savegrp uses nsrexecd to start saves on NetWorker client hosts. nsrexecd, running on
each client host, only allows remote execution requests from NetWorker hosts listed in the
client’s /nsr/res/servers file. If this file is empty or does not exist, the client can be
backed up by any NetWorker server.
The Priority attribute on the NetWorker client resource allows administrators to control the
order that the NetWorker server contacts clients for backup. A client with the lowest priority
value in a backup operation is contacted first. If a value is not specified, then the backup
order is random. By default, the value for the Priority attribute is set to 500. To guarantee
that the backup of one client occurs before the backup of another, place each client in
separate groups and configure the workflows to start at different times.

Using NetWorker Administration, you can manually start workflows at the policy level or at
the workflow level. Workflows can be started either from the Monitoring window or from
the Protection window.
To run workflows, right-click the name of the policy or workflow that you want to start and
select Start. Starting at the policy level causes all workflows for the policy to start. You can
run a workflow for selected clients in the workflow by selecting the workflow and then
choosing Start Individual Client from the Monitoring menu.
Manually run a workflow to test a new configuration or a change in a configuration to make

sure the workflow is configured correctly and works as expected.

Policies and workflows can also be started by running the nsrpolicy start command on
the NetWorker server. You specify the policy name and optionally, a workflow within the
policy and the name of one or more clients. Workflows must always start from the first or
head action. Granular start of a single action within a workflow is not supported.
When using the nsrpolicy start command, it is possible to override the workflow and run
the workflow for just one or more clients as long as the client(s) are clients that are
specified in the group assigned to the workflow.
In the example shown here, we are starting the workflow, Workflow with multiple actions,
in the policy, File system Backups, for just one of the clients in the workflow.
Important: Client-initiated running of policies is not supported.
Note: There are many other operations that can be performed using nsrpolicy including
configuring policies, workflows and actions. Please refer to the nsrpolicy topic in the
NetWorker Command Reference Guide for details.

Use the NetWorker Administration Monitoring window to track a workflow in progress and
also quickly see the status of the configured policies, workflows, and actions.
As shown here, from the Monitoring window, open up the tree in the Policies section to
the desired level. For backup actions, you can drill down to the clients within the backup.
The status column displays the status of running operations or for the last run time. For
example, a green checkmark indicates a successful completion for the last time the
operation ran. A blue icon indicates an operation is in progress and a red icon points to a
failed operation. There are other policy status icons that may appear; hover the mouse over
an icon to display its meaning. Additional monitoring information can be seen from
Monitoring:
• Policies – Lists all policies, workflows and actions with status, the time the last
backup was run, the duration of the backup, the completion percentage, and the next
time the backup will run. Clicking the Actions tab displays a list of all the configured
actions. Column information indicates the action status and its policy and workflow.
• All Sessions – Displays all sessions currently running on the NetWorker server. You
can select other session tabs to display only certain session types, such as save
sessions, recoveries and clones. You can cancel a session by highlighting the session,
right-clicking and selecting Stop.
• Devices – Contains storage node, volume, pool and performance information for
configured NetWorker devices. The status icon indicates if the device is currently
active (shown here), disabled or idle.
• Log – Contains information about the many actions performed by NetWorker during
the running of the policy or workflow.
• Alerts – May contain information such as the license status alert shown here. The
priority column indicates the criticality of the alert.

To find out more about workflow operations, right-click a workflow from the Monitoring
window and choose Show Details. The Workflow Summary window displays recent
instances of running the selected workflow. Select the instance that you are interested in
and details about the actions of that specific workflow run are displayed in the lower portion
of the window. Clicking Show Messages displays the end of the log file for the selected
workflow instance. Options for the Show Messages window include Get Full Log, Print
and Save the messages to a file on the local host.

With the status icons and messages provided from the Monitoring window, you can quickly
obtain information about failed actions and workflows and begin troubleshooting the failure.
Here is an example of a failed workflow, Workflow with multiple actions. The Policies
section of the window provides a visual status of a problem in the form of the red status
icon for the failed action and workflow. Not shown here, is that there is also a red status
icon next to the workflow’s policy indicating that there was a failure within the policy.
Messages reporting failed operations are listed in the Log section of the window.
By right-clicking the workflow or action and selecting Show Details, NetWorker displays
more information about the operation. In this case, the details for the failed probe action
reports that the action did not contain any defined probes. Using this information, we found
that the client resources in this workflow did not have a probe resource assigned to them.
Because the probe action was configured to require that at least one client must have a
probe execution status of success, the action failed.

You can define the notification settings for a policy and its associated workflows and
actions.
By default, on completion of the workflows and actions in a policy, a notification is sent to

the policy_notifications.log file under …\nsr\logs. Instead of sending a notification on
policy completion, you can choose to send a notification only if one or more of the
workflows in the policy fails or to not send any notifications at all.
Notifications can be sent to a log file or to an email address. You can change the content of
the notification command to send the notification to a different log file or to a mail
recipient.
At the workflow level, you have the choice to use the notification configuration that was set
at the policy level or to send a notification that is defined for the workflow on completion of
all of the actions in the workflow or on failure of any one of the actions. When a notification
is set at the workflow level, it supersedes any notifications configured at the policy level.
Likewise, for an action, you can choose to use the notification configured at the policy level
or you can configure a different command on completion or on failure of the action. When a
notification is set at the action level, the notification is generated in addition to any
notifications generated at the workflow or policy levels.
In the example shown here, the default notification is left unchanged at the policy level.
However, for the backup action, we chose to use a different notification upon completion of
the action. When the action finished, the notification message was written to a file called
tradbkupaction.log in \nsr\logs.
NetWorker supports several pre-defined variables for notifications including: ${NSR

POLICY}, ${NSR WORKFLOW} and ${NSR ACTION}. For example, when the notification
mail -s “workflow ${NSR WORKFLOW} completed” recipient@mailserver is used, the
actual name of the workflow will be substituted in the subject.

You can stop workflows that are currently running at the workflow and at the policy level. If
for some reason an action fails during the execution of a workflow, a workflow may be
restarted. In that case, each action continues where it left off.
Output from running a policy is located under …\nsr\logs\policy in directories specific to

a particular policy, workflow, action and job.

When Checkpoint Restart is enabled, failed backup operations can be automatically or
manually restarted at a known good point, prior to the point-of-failure during the backup. A
known good point is defined as a point in the backup data stream where the data was
successfully written to the backup media and that data can be located and accessed by
subsequent recovery operations. Client backups can be restarted should they fail while
running, and files and directories that have already been backed up are not backed up
again.
The checkpoint restart feature is not enabled by default and is configured on a per client
basis. To enable the feature, check Checkpoint enabled from the client resource General
tab. Checkpoint granularity is the level at which the backup can be restarted, either at
the directory or file level. When restart by directory is selected, after each directory is
saved, the data is committed to the index and media database. If restart by file is selected,
every file is committed to the index and media database. This is time consuming and has
the potential to degrade performance during a backup containing many small files. Because
of this, restarting by file is recommended only for save sets with a few, large files.
Important: The checkpoint restart feature cannot be used on Windows platforms or when
parallel save streams are enabled.
Note: The NMC database cannot be backed up as part of a Checkpoint Restart backup.

By default, a NetWorker client’s Backup command attribute is blank, causing save to be
executed for each save set listed in its save set attribute. By modifying the Backup
command attribute, you can change the command used to perform the backup.
The Backup command attribute is used to enter a specific backup command when using
one of NetWorker’s add-on modules, such as NetWorker Module for Microsoft and
NetWorker Module for Databases and Applications, to perform application-specific backups.
You can create a custom script to perform tasks before, after, or instead of the save
process. These tasks might include moving, deleting or renaming files, stopping and
starting processes, or generating logging information. When writing a custom script, you
must include the save command if you want a save stream to be generated. The save
command should have an argument of $* to retain all of the arguments sent by the
NetWorker server.
The custom script must have a name that begins with nsr or save (for example,
nsr_my_custom_command or save_my_custom_command). The custom script file must also
reside in the same directory as the NetWorker save command. On Windows hosts, the
default location of save is C:\Program Files\EMC NetWorker\nsr\bin; on UNIX hosts,
execute which save to determine the location.
You can also specify the savepnpc command in the client's Backup command attribute. Use
savepnpc if you want to run either pre-processing commands before any client save sets
are backed up and/or post-processing commands after all save sets have been backed up.

As shown in the slide, when a client’s Backup command attribute is blank or contains
anything other than savepnpc, the specified command (or save if the attribute is blank) is
executed once for each save set. Thus, if a client has three save sets, the backup command
is executed three times.

Unlike other backup commands which execute once for each save set, savepnpc runs only
once, regardless of the number of save sets specified in the client resource. This behavior is
useful if the client is running an application that you need to shut down before backing up
the client, savepnpc can stop the application and then restart the application when the
backup is complete.
Note: For more information about using savepnpc, see the savepnpc, preclntsave, and
pstclntsave topics in the NetWorker Command Reference Guide.

A client-initiated backup is a manual process performed on a NetWorker client using either
a GUI or the command line. This type of backup is useful for one-time, ad-hoc backups. The
user specifies which files, directories, and file systems to save. Although the NetWorker
server does not initiate a client-initiated backup, it manages the backup after the client
makes a request. This management includes authorizing the backup and determining which
storage node and backup device the client should send its save stream to.
For a client to execute any type of backup, it must first be configured as a client resource
on the NetWorker server. When the client performs a save, it generates a save stream,
sends it to the assigned storage node, and sends tracking information to the NetWorker
server. The storage node also generates tracking information which it sends to the server.
Client-initiated manual backups have a backup level of manual instead of the backup levels
of full, incremental, and so on.

The save command can be executed directly from the command-line on any NetWorker
client.
On Microsoft Windows clients, client-initiated backups can be performed using the

NetWorker User graphical user interface, winworkr.exe.
In the examples shown here, we are backing up the C:\Program Files\EMC

NetWorker\nsr\logs directory from the Windows client host, winclient.emc.edu.

save is the NetWorker backup command-line utility used to back up files and directories. It
creates a single save set containing the files and directories specified as arguments. If no
files or directories are provided as arguments, the current directory is backed up.
Unless the -x option is used, save will not cross mount points. For example, save / in a
Linux environment backs up only the root file system.
Please refer to the NetWorker Command Reference Guide for additional options and
information about save.
Important: Caution should be exercised when using the –x option because save traverses
network-mounted (NFS, CIFS) file systems and drives. In a Microsoft Windows
environment, running save –x / causes all drives to be backed up.

Previewing the backup does not actually back up any data. Running save with the –n
option performs many of the tasks that take place during a normal backup, such as
contacting the NetWorker server to request permission to back up. However, no save
stream is generated.
Previewing the backup ensures that save is working properly and displays an estimated size
of the save set as well as the number of files to be backed up. A list of files that would be
saved is also displayed.

NetWorker User is used to perform both saves and recoveries from Windows client hosts.
It can be initiated from Windows Start or by executing winworkr.exe on the command line.
The four buttons in the upper-left corner of the window initiate the following tasks:
• Perform a backup – This opens the smaller backup window shown in the slide on the
right.
• Perform a recovery – This opens a recovery window and is discussed in the modules
dealing with recoveries.
• Perform an archive – This requires a special license and is not covered in this
course.
• Verify files – This allows you to verify whether a recent backup or archive operation
was successful by comparing data on disk to data on a volume. See the NetWorker
Administration Guide for details.
The client name and NetWorker server managing the backup or recovery are shown at the
bottom of the NetWorker User window.

From the Backup window, files and folders are marked for backup. Folders are displayed in
the left pane. Clicking a folder displays its contents in the right pane. Items can be marked
for backup in either pane.
After marking the files and directories to back up, click Start (green lightening bolt) to
begin the backup. You can monitor the backup in the Backup Status window, which opens
as soon as the backup begins.

NetWorker User can be configured to perform software compression when generating the
save stream and to password protect and encrypt the data using PW2 encryption. These
capabilities are set in the Special Handling window which is opened via the File menu.
A password must be set before password protection or encryption can be performed. This is
done by selecting Password from the Options menu and entering a password.
Using Special Handling affects all the files backed up during the backup session. To perform
compression, password protection, or encryption only on selected files in the backup, right-
click the item you want to handle specially and select the appropriate action from the menu.
The Attributes column shows the special handling that is currently set. A value of P is
marked for password protection, E for password protection and encryption, and C for
compression.
Important: When choosing a password option, DO NOT FORGET THE PASSWORD!!! It is not
stored anywhere other than the volume on which the data is written. During recovery of
PW2 encrypted data items, you are prompted for the password. If you cannot provide it,
you cannot recover the files. If backup data is password-protected but not encrypted, an
administrative user (root or Administrator) is able to recover the data.

In this lab, you manually run the workflow created previously.

This lesson covers several advanced backup options including synthetic full and block based
backups, NetWorker directives, NetWorker Snapshot Management, and NetWorker backup
support for virtual clients, databases and applications.

Synthetic full backups are supported only for traditional, file system backups. Application
modules and NDMP backups are not supported.
Using synthetic full backups can reduce the number of full backups that need to be run but
does not eliminate the requirement to run full backups. Run synthetic backups as a
replacement for full backups, not in addition to.
Because synthetic full backup operations include only the NetWorker server and storage
node, they have the potential to reduce the impact of backup operations on the network
and client resources. However, it is also important to monitor the impact of synthetic
backup processing on participating storage nodes.
Scheduling recommendations for synthetic full backups include:

• Use a separate workflow for running synthetic full backups.
• Perform full backups on a regular basis, typically once a month or once a quarter.
• Schedule synthetic full backups outside of regular backup windows. Because synthetic
full processing is resource intensive on the storage node, run synthetic full backups at
times other than when backups are running so as not to impact regular backup
processing.

Requirements for running synthetic full backups include:
• A full backup or a synthetic full backup, created with NetWorker 8.0 or later, must
exist.
• All incremental backups participating in the synthetic full backup are included in the
media database.
• All save sets participating in the synthetic full must:
– Have the same client and save set names.
– Be browsable, that is entries for the save set must be in the client file index.
• If you configure multiple workflows to run concurrently, you want to be aware of the
impact of and limit the number of concurrent synthetic full operations. The best
number of concurrent synthetic full operations depends upon the configuration of the
NetWorker server, size of the save sets and number of clients, and the number of
nsrpolicy instances currently running.
• Participating storage nodes must have attached devices for read and write. Synthetic
backups can be directed to any device that can be used in a traditional full backup.
However, because synthetic backup processing involves concurrent recover and save
operations, it is recommended to use backup devices that support concurrent
operations, such as advanced file type and Data Domain devices. This allows
NetWorker to automatically manage volume contention. Also, consider using AFTD or
Data Domain devices to store all participating backups on a single device.

The tasks required for configuring a scheduled synthetic full backup include:
• Create a client resource for each backup client that participates in the synthetic full.
– Ensure that the save sets meet synthetic full requirements.
– Make sure the Backup renamed directories attribute is enabled on the General
tab of the client resource. This attribute is enabled by default for NetWorker 8.0
and above clients.
• Create a group resource and assign the client(s) to the group. Do not mix Windows
with UNIX clients.
• Create a workflow specifically for scheduled synthetic full backups and assign the
group to the workflow. Set the schedule in the backup action to include synthetic full
backups. Remember to still include full backups on a regular basis on the schedule.
• Create a client resource for each storage node that will be performing scheduled
synthetic full backups.

This is an example of a synthetic full backup workflow in action. We are backing up the
client, winclient.emc.edu. For all other days of the week, an incremental backup is
performed. Today, a synthetic full backup is performed.
First, an incremental backup of the save sets is performed (not shown here). Then, a full
backup is performed for the NetWorker storage node client, nwwindows.emc.edu, to
consolidate the most recent, previous full/synthetic full backup with all the incremental
backups that have run since the most recent, previous full/synthetic full backup. At the end
of the synthetic full operation, NetWorker verifies the integrity of the new full backup.

NetWorker supports block based backups (BBB) for Linux and Microsoft Windows platforms.
In a block based backup, NetWorker scans a volume or a disk in a file system in a single,
sequential pass and backs up only the blocks that are in use in the file system. It does this
by taking an image-based backup at the volume level, rather than walking an entire file
system in the backup process. Block based backups use the VSS snapshot capability on
Windows and the Logical Volume Manager and Veritas Volume Manager on Linux to create
consistent copies of source volumes for backups. Block based incremental backups use the
change block tracking methodology to identify and back up only the changed blocks.
Using block based backup technology, backups complete in less time than comparable non-
BBB backups. In addition, no index is created as part of this workflow. This makes block
based backups of particular benefit for high density file systems where, potentially, millions
of files would need to be indexed and indexed again with every backup. The fact that
NetWorker does not create an index in this process is a differentiator in the industry. It
saves time and space in the backup workflow. Even though an index is not created,
recovery at the file level is still supported. This is done by virtually mounting the backup, at
which point, files can be viewed and recovered.

For Linux platforms, in addition to the NetWorker base client installation package, you must
install the BBB software package named lgtobbb to provide a NetWorker client with block
based backup support for incremental backups and recoveries.
Block based backups require the use of client direct, consequently, only AFTD and Data
Domain device types are supported as backup targets. You can, however, clone block based
full backups to other device types including tape and virtual tape.
To enable the block based backup feature, select the Block based backup attribute in the
client resource. Note that Client direct is enabled by default. Valid save sets include the All
save set and volume/volume mount point levels. Save sets at the folder or file level are not
supported for backup. For Linux, each volume group must have at least 10% free space for
block based backups to succeed. This space is required for copy on write snapshot
processing.
Note: Checkpoint restart and standard NetWorker directives are not supported for block
based backups.

Supported backup levels for block based backups are full and incremental.
When backups are sent to an AFTD, selecting any level apart from full or incremental
results in an incremental backup being performed. The next backup after 38 incremental
backups will automatically be a full backup.
On a Data Domain device, selecting any backup level apart from full results in a virtual full
backup. The backup save sets are displayed as level full. Forever incremental backups are
supported.
A full backup must be created initially. Incremental backups must be created on the same
device as full backups. When using incremental backups, the next backup after a reboot of
a client host will be a level full.
Please see the NetWorker Administration Guide for a further discussion of NetWorker block
based backup support.

A directive is a set of statements and arguments that the save command uses when
generating a save stream. Directives allow you to perform optional tasks such as skipping,
compressing, or encrypting files.
There are three types of directives:
• A global directive is a NetWorker resource with directive statements as its attributes.

Global directives are used only by server-initiated backups.
• A local directive file is a text file named .nsr (UNIX) or nsr.dir (Windows) that contains
directive statements. The save command always looks for a directive file in a directory
before backing up the directory. These directives only apply to the data within the path
where the directive file is located. This type of directive affects both server-initiated and
client-initiated backups.
• A NetWorker User local directive (Microsoft Windows only) is created using NetWorker
User by a user logged in with local Windows Administrator privileges. This type of
directive resides in a networkr.cfg file located at the root of the system volume (usually
C:\). The syntax of this type of directive is identical to a server-side directive. A
NetWorker User local directive affects both server-initiated and client-initiated backups.
If there is a conflict between directives, global directives take precedence over local
directives. On Windows systems, NetWorker User local directives take precedence over local
directive files.

The syntax for a directive can include directory specifications, application-specific modules
(ASMs), patterns used for filename matching, and save environment keywords.
A directory specification indicates which directory the ASMs or save environment keywords
are applied to. A single directive resource may contain multiple directory specifications.
• Directory names are specified within double angle brackets, “<< >>”. A directory
specification of “<< / >>” on a Windows host is equivalent to all drives.
• Quotes around the directory specification are not required for a UNIX path name.
• Indentation is optional.
ASMs on following lines affect how files under the specified directory are saved. When an
ASM has a leading + it is recursively applied to all subdirectories.
A pattern is a file or directory name. It may contain the wildcards *, ?, and []. Multiple
pattern arguments are separated by white space.
In the following example, the skip ASM applies only to files or directories in /etc whose
names end in .log.
<< /etc >>
skip: *.log
Note: In a client-side directive, a directory specification is optional. If it is omitted, the

ASMs are applied to the directory containing the directive file. If a directory specification is
used in a client-side directive, it is resolved relative to the directory containing the .nsr or
nsr.dir file.

An application-specific module (ASM) is the part of the directive which directs the save
command to back up certain files in a non-standard way, back up files or directories that
would not normally be backed up, or omit certain files or directories from the backup.
Examples of ASMs include compressasm, which compresses the files or directories in the
save set, and skip, which omits files or directories from the backup. Some of the available
ASMs are listed in the slide. A full list of ASMs is available in the uasm topic in the
NetWorker Command Reference Guide and the UNIX man pages.
ASMs are applied to a whitespace-separated list of patterns (files or directories) specified on

the same line as the ASM. The patterns can include wildcards (*, ?, [], .) but cannot
include pathnames (\ or /). An optional “+” before the ASM causes the ASM to be applied
recursively to subdirectories and their contents.
Examples:
1. Skip the file expenses.xls in the C:\docs directory, and compress all files having a
.mdb extension residing in C:\docs and recursively below it.
<< “C:\docs” >>

skip: expenses.xls
+compressasm: *.mdb
2. Skip all files with .tmp and .jpg extensions anywhere under /opt/data.
<< /opt/data >>

+skip: *.tmp *.TMP *.jpg *.JPG

Save environment keywords are used to affect how current ASMs, as well as ASMs further
down in the directory structure, are to be applied.
In the following example, software compression is being recursively performed on all files
under the root directory. However, the forget keyword says, “Stop applying any ASMs that
are currently in affect” and ignore says “Ignore all .nsr files located in or below
/export/home.”
<< / >>
+compressasm: .
<< /export/home >>
forget
ignore
The result is that nothing under /export/home is compressed and all .nsr files under
/export/home are ignored. Thus, even if a user has a directive file
/export/home/xyz/.nsr containing: skip: image_data which was created to avoid
backing up a directory of large images that can be easily recreated, the directory is actually
backed up because the local directive file is ignored. You could use both ignore and allow
together to correct the situation. To allow only xyz to have a .nsr file, add a second
directive statement, allowing only the .nsr file in the xyz directory. The directive resource
now looks like this:
<< / >>
+compressasm: .
<< /export/home >>
forget
ignore
+compressasm
<< /export/home/xyz >>
allow

Use directive resources to apply global directives to individual client resources for server-
initiated backups. NetWorker provides a number of preconfigured global directives for
various operating systems. These resources can be modified, but they cannot be deleted.
You can also create your own directive resources.
You apply a global directive to individual client resources using the Directive attribute on
the client resource.
In this example, we want to skip all files with an extension of tmp for a specific Windows
client resource. When a backup action runs for this client resource, it will skip all tmp files.

The purpose of configuring local directive files using NetWorker User is to avoid having to
manually edit a nsr.dir file and worry about using correct syntax. Using NetWorker User
simplifies the creation of the directives.
This type of directive has limitations. It can only configure ASMs that NetWorker User is
familiar with. These include null (similar to skip), compressasm, pw1 (password-protect),
and pw2 (encrypt).
To configure the directives, start NetWorker User and select Local Backup Directives from
the Options menu. All files and directories are initially marked. Unmark files and
directories you want skipped during backups, and apply special handling to those items for
which you desire special handling. Save the directives by selecting Save Backup
Directives from the File menu. The networkr.cfg file is created and read by save during
subsequent backups. If the file already exists, it is updated each time you save the
directives.
networkr.cfg resides at the top level of the system volume (usually C:\).
More information about directives can be found in the nsr_directive (for server-side) and
the nsr (for client-side) topics in the NetWorker Command Reference Guide or the
UNIX/Linux man pages. Also, please refer to the Directives topic in the NetWorker
Administration Guide.

NetWorker provides integrated snapshot management for supported clients through the
NetWorker Snapshot Management (NSM) feature. NSM works with replication and mirror
technologies on EMC storage arrays or appliances to create and manage snapshot and
ProtectPoint copies of production data.
A snapshot is a point-in-time (PiT) copy of data files, volumes or file systems. NSM provides
snapshot backups on disk that can be tracked and managed from NetWorker. You can
leverage snapshots for impact-free backups by using a server other than the production
host to perform clones of snapshots to backup media. This alternate proxy host or mount
host will take on the performance burden instead of the production server.
Snapshots provide snapshot restore/recovery capabilities to retrieve data directly from a

snapshot or restore from a clone copy. You can also replace data on a source disk from a
snapshot by performing a rollback restore.
NetWorker provides a single pane of glass approach to data protection. You configure
snapshot backups using NetWorker data protection policies and workflows, allowing you to
manage the snapshot lifecycle from creation to clone and expiration. NetWorker provides
NSM snapshot backups with the same benefits that are offered for conventional backups
such as monitoring, scheduling and reporting.

In the diagram, critical application data is stored on an EMC storage system. Production
data can consist of file systems and databases. At the time of back up, an array-based
point-in-time snapshot is created. NetWorker uses cloning to rollover or copy the snapshot
to backup media, DD Boost or AFTD devices. There can be multiple point-in-time snapshots
taken throughout the day, any one of which may be cloned to backup media as needed,
depending upon the customer’s protection needs.
NSM provides snapshot restore/recovery capabilities to retrieve data directly from a

snapshot (snapshot restore) or from the clone copy. You can also replace data on a source
disk from a snapshot by performing a rollback restore.

NetWorker Snapshot Management supports several EMC array-based and software-based
environments.
Array-based:
VMAX/Symmetrix – TimeFinder SRDF/S: NSM interacts with EMC VMAX/Symmetrix

storage systems using EMC TimeFinder functionality to create and maintain snapshots of
the data. NSM supports both CoW and split-mirror techniques of snapshot data-protection.
VNX/CLARiiON – SnapView: NSM interacts with EMC VNX/CLARiiON, using EMC

SnapView to create and maintain point-in-time copies of the data. Using SnapView, both
the Copy on Write (CoW) and the clone functionalities are provided for VNX.
Software-based:
• RecoverPoint: NSM provides integration of continuous data protection (CDR) and

continuous remote replication (CRR) technology with NetWorker. It provides increased
protection from both logical and physical errors, and thus decreases the exposure to data
loss and increases the ability to create and recover data from multiple recovery points
NAS support includes Isilon OneFS 7.x and higher, VNX, VNX2, and VNXe/VNXe2, and
NetApp OnTAP 8.x and higher.

Performing a snapshot backup with NSM in NetWorker is done by creating a workflow
containing a snapshot backup action. The workflow specifies when and how often the
workflow runs. The number of snapshots taken per day is controlled by the schedule of the
workflow. Other actions supported for snapshot backup workflows are probe, check
connectivity, and clone. A clone action can be configured to occur after the backup action or
it can be an action in a separate workflow. NetWorker Snapshot Management supports
several types of snapshot backup workflows depending on where you intend to store the
snapshot. These workflows are:
Snapshot Only: With a workflow containing only a snapshot backup action, NSM creates a
snapshot on the storage array. The snapshot is retained on the storage array only.
NetWorker catalogs the snapshot as a backup in its media database. For application
backups, NetWorker also records the application files being protected in the CFI. The
snapshot can be used for a snapshot restore.
Snapshot and Rollover: The second workflow depicts a snapshot backup action followed
by a clone action. Here, NSM creates a snapshot and then the save sets specified in the
client resource are copied (cloned) from the snapshot to backup media. Media can be DD
Boost or AFTD devices. The NetWorker media database catalogs both the snapshot and the
rollover/clone. For the clone, NetWorker records the content of the snapshot for file system
backups in the CFI; for the backup and the clone, the application files being protected for
application backups are recorded in the CFI. You can also clone VMAX3 Snapvx snapshots to
ProtectPoint devices. A rollover-only workflow can be achieved by following a snapshot
backup action with a clone action that specifies to delete the source save set after the clone
action completes. In this case, the snapshot is cataloged, cloned to media and then deleted.
Only the rollover is available for recovery.
Delayed Rollover. The third workflow shows a delayed rollover where the clone action is
not directly tied to a snapshot backup action. In this example, a save set group is used to
select the specific input for the clone. We discuss configuring clone operations in a later
module of this course.

The backup snapshot action performs a snapshot of data on the supported snapshot hosts
as defined in the client resource. To create a snapshot backup action, select the backup
action type and then select snapshot for Backup Subtype.
Many of the options in the Policy Action wizard are similar to those for other types of
backups. Of particular note for snapshot backups are the fields on the Specify the
Snapshot Options screen. Snapshot retention is specified using duration-based retention
with the Retention attribute. After the period of time specified here, the save set is
removed from the media/CFI databases and the snapshot is deleted. For Minimum
Retention Time, specify the minimum amount of time to retain the snapshot. When the
minimum amount of time expires, a snapshot action in progress can remove a snapshot
from a storage device to ensure that there is sufficient disk space for the new snapshot.

With data on supported hardware, NSM provides snapshot backup support for file system
clients, NMDA for Oracle and DB2, and NMSAP with Oracle. NSM is part of the NetWorker
extended client software package. This package must be installed on the client to use NSM
features. Each application host and mount host must run NetWorker client and extended
client software. In Windows, the extended client is automatically installed when using the
NetWorker all-in-one installer for installing the NetWorker server and storage node. It is not
automatically installed when selecting the client install only from this package, when using
the separate client installer, or when installing on a UNIX platform. In these cases, install
the extended client package after the base client is installed. Note that using NMDA and
NMSAP with NSM requires installing those packages as well.
The client resource is used to specify snapshot backup options such as the storage array on
which to create the snapshot, and the mount host and storage node to be used for
rollovers. When NSM is enabled for the client resource, the wizard presents storage array
and other NSM backup options for configuration.

The types of snapshot restores that can be performed depend on the storage location and
other factors:
Snapshot restore - You mount and browse the snapshot file system on the storage
node/mount host and select the files, file systems, or volumes to restore.
Restore from clone - You perform a traditional NetWorker restore from backup storage
media.
Rollback restore - You restore the snapshot by using the storage array features. An
application volume is unmounted and its entire contents are replaced by the entire contents
of the selected snapshot.
Important: A rollback destroys all previously existing data on the target application volume.

EMC NetWorker application modules act with third-party applications, together with
NetWorker, to provide a comprehensive data storage management system. Backup and
recovery operations for third-party applications are integrated into the NetWorker network-
wide data protection system, thus providing consistency with other types of NetWorker
backups. Using NetWorker data protection policies and workflows, backups are performed
locally or over the network to a centralized NetWorker server or storage node, or directly
from the client using the NetWorker client direct feature to AFTD or Data Domain storage
devices. NetWorker server provides automatic storage management through automated
backup scheduling, data tracking, cloning, staging and aging.
With NetWorker modules, applications can be backed up in an open and consistent state.
NetWorker application modules fully integrate with third-party, vendor-specific APIs or
applications, eliminating the need to develop or maintain custom backup and recovery
scripts. They provide fast, online, automated, and reliable granular backup and recovery for
popular database, messaging, content, and ERP applications. NetWorker application
modules are listed on the slide and include:
• EMC NetWorker Module for Databases and Applications (NMDA) is a unified
backup solution for various databases and applications. NMDA software works with the
supported database or application software and NetWorker software to support the most
commonly used third-party applications, including IBM DB2, IBM Domino/Notes, Oracle,
MySQL, Sybase, and Informix.
• EMC NetWorker Module for Microsoft Applications (NMM) delivers a unified backup
solution for Microsoft applications. NMM works with Microsoft Volume Shadow Copy
Service (VSS) technology for backups of Microsoft Exchange, SQL, SharePoint, Hyper-V,
and Active Directory. Additionally, this module provides the capability to leverage
Microsoft VDI for SQL Server to provide a second method for Microsoft SQL backups.
• NetWorker Module for SAP provides backup and recovery of SAP applications,
including SAP HANA.
• NetWorker Module for MEDITECH is used to protect MEDITECH implementations.

NetWorker modules work with NetWorker snapshot technology to provide a backup and
recovery strategy for protection of data residing on supported primary storage systems.
NetWorker Module for Database Applications supports integration with NetWorker Snapshot
Management for NMDA for Oracle and DB2 with data on supported primary storage.
NetWorker Module for SAP supports integration with NSM for NMSAP with Oracle with data
on supported primary storage.

The labs cover configuring advanced workflows using a check connectivity action, dynamic
groups, a notification at the action level, and using the skip directive.

This lesson covers the NetWorker options for protecting machines in a VMware
environment. This includes an overview of how VMware client backups are supported as
well as the workflow for image backups.

NetWorker provides support for two primary types of backup and recovery solutions for
VMware virtual clients.
The first option is guest-based where a NetWorker client is installed on each virtual machine
host the same as if it was a physical machine.
The second option is NetWorker VMware Protection which is a NetWorker-integrated

VMware backup solution. NetWorker VMware protection uses an EMC Backup and Recovery
(EBR) appliance on the vSphere server and leverages policy-based backups of VMware
virtual machines. Support is provided for both image-level backups as well as image-level
and file-level restores.
Note: The VADP or legacy option is still supported, though it has been replaced with the
NetWorker VMware Protection solution. More information on the legacy method can be
found in the NetWorker VMware Integration Guide at support.emc.com.
Note: The acronyms EBR and VBA are used interchangeably; both refer to the EMC Backup
Recovery appliance which is also known as the VMware Backup Appliance.

Deciding which backup method to employ for backing up virtual machines depends upon
many factors. These include ease of use, efficiency and impact of backup processing on
resources, as well as backup and restore capabilities. This slide shows some comparisons
between the two current solutions.
Guest-based backup and recovery provides a simple and familiar implementation. Guest-
based backups support database and application backups as well as incremental backups at
the file level. With guest-based backup however, the backup processing load of one virtual
machine can negatively impact system resources available to all VMs hosted on the same
physical ESX server. The virtual machine must be powered on for backups. And, the
NetWorker client software installed on each virtual machine must be maintained and
updated.
NetWorker VMware Protection is presented in the following slides.

NetWorker VMware Protection is a NetWorker-integrated VMware backup and restore
solution. This solution allows you to create backup and cloning policies using NMC. You can
then assign those policies to virtual machines. Backups can be scheduled through NMC or
run manually through NMC and the vSphere Web client. Restores are performed with the
VMware vSphere Web client for virtual machine restores and EMC Data Protection Restore
client for file-level restores.
NetWorker client software is not required on the virtual machines that will be backed up by
the NetWorker VMware Data Protection solution.
The VMware protection solution revolves around the EMC Backup and Recovery appliance
(EBR). The EBR (VBA) registers itself with the vCenter server as well as the NetWorker
server. The VBA includes 8 internal proxy agents. An external proxy adds 8 proxy agents.
Each VBA proxy is controlled by the VBA.
Data protection policies are defined on the NetWorker server using the NetWorker
Management Console. The vCenter administrator applies the protection policies to virtual
machines through the vSphere web client within the EMC Backup and Recovery user
interface. The EMC Backup and Recovery appliance internal storage can reside on FC, iSCSI
or NAS (NFS) storage.

The EMC Backup and Recovery appliance (EBR) is a virtual machine that is deployed from
an OVA file. The EBA has 8 internal proxy agents that allow you to back up 8 VMs
concurrently. You assign a proxy for one backup or one recovery of a VM at a time. To back
up more than 8 VMs concurrently, deploy an external proxy VM. Each external proxy has
eight internal proxy agents.
The EMC Backup and Recovery appliance supports back up to its internal storage and to
Data Domain.

Which appliance to deploy depends on your configuration and requirements. The options
include:
• 0.5 TB OVA
– Backing up to a Data Domain system OR
– Protecting fewer than 10 virtual machines using internal storage
• 4 TB OVA
– Backing up to internal storage and protecting more than 10 virtual machines
• VBA External Proxy
– Deploy the external proxy appliance when performing more than eight concurrent
backups.
External proxies can be used to enhance the scalability and accessibility of the EBR
environment.
• Scalability: The backup administrator can deploy additional external proxies to
increase the total number of virtual machines being backed up simultaneously.
• Accessibility: vSphere supports complex storage topologies which may require a VBA
proxy to be hosted on an ESX host other than the one hosting the VBA. In such
situations, the backup administrator must deploy an external proxy.
Download of the OVA files can be performed from the EMC online support site at
http://support.emc.com

A new EMC Backup and Recovery plug-in is added to the vSphere Web Client.
The vSphere administrator uses the EMC Backup and Recovery plug-in to apply policies to
virtual machines and to perform manual backups of virtual machine(s) and virtual machine
level restores.

After installation, NetWorker automatically creates an AFTD backup device on the internal
storage of the EBR. When using the EBR, the backup device choices are:
• EBR internal storage
• Data Domain
Only backups to a Data Domain device can be cloned.

• Backups to Data Domain devices can be cloned to any device that NetWorker
supports.
• Backups to the EBR appliance internal storage cannot be cloned.

Beginning with NetWorker 9, NetWorker implements a data protection policy concept for
VMware backups with NetWorker while maintaining backward compatibility with NetWorker
VMware backups in 8.2 and the EBR plugin on vSphere. NetWorker supports groups of
VMware objects such as virtual machines and VMDKs for VMware backups, as well as groups
of EBRs/VBAs for VBA backups which are checkpoint backups. You cannot have
VMs/VMware containers/VMDKs in the same group as VBAs.
As groups are the sources of what is to be backed up, VMs to be backed up are added to a
protection group. If you want to add VMs using the EBR GUI, they are added to the EBR
policy.
The cross sync feature checks that whatever is configured in NetWorker gets pushed across
to the EBR before a policy is run thus ensuring consistency and integrity between the two
sides. If the cross sync fails, the policy fails.
In addition to recovery through the GUI, there are FLR and NetWorker CLI commands to
enable CLI recovery. A NetWorker proxy CLI is provided for proxy deployment and
configuration.

NetWorker VMware Protection provides two different levels of data restore. Image-level
restores restore the entire image backup to the original virtual machine, another existing
virtual machine, or a new virtual machine. Image-level restores are less resource intensive
and are best suited for restoring large amounts of data quickly.
With a file-level restore, specific folders or files are restored from an image backup. This
type of restore is more resource intensive and is best suited for restoring a relatively small
amount of data.

An image-level restore is initiated via the Restore a VM wizard from EMC Backup and
Recovery in the vSphere Web Client.

File Level Restore (FLR) can be performed from a web-based program called the EMC Data
Protection Restore Client. The Restore Client is accessed through a web browser. No
NetWorker client software is required to perform a file level restore.

This module focused on the various ways of performing backups with NetWorker. We looked
at the workflows and actions used for traditional, scheduled backups and how to perform
manual backups with user interfaces and commands. This module also covered performing
backups with NetWorker Snapshot Management, how to back up virtual clients and the use
of NetWorker modules for application and database backups.

This module focuses on configuring and managing devices in NetWorker. Specific supported
device types are covered, as well as the configuration of local, remote, AFTD, Data Domain
and tape devices.

akhan@aayan.comModule: Configuring and Managing Devices 1
This lesson covers various device types supported by NetWorker, configuring a storage
node resource and device management with nsrsnmd and nsrmmd.

In NetWorker, devices are classified by device type, how the device is configured and
managed, and by its location relative to the NetWorker server.

NetWorker supports many types of devices that can be used to store backup data. These
device types include:
• Tape: Includes tape drives and cartridges; may be physical or virtual. Examples
include 4mm, 8mm, DLT8000, LTO Ultrium-5, SAIT-1, TS1140.
• Advanced File Type: Refers to an existing file system directory configured in
NetWorker as a backup to disk resource. The media type is adv_file. Once the device
resource is configured, NetWorker uses the directory as a backup volume.
• Cloud: Refers to EMC Atmos configured in NetWorker as a cloud storage device. The
media type is Atmos COS. Backups to a cloud device occur over the TCP/IP network.
Cloud devices configured on a CloudBoost appliance will be configured with a device
type of AFTD.
• Data Domain: Refers to a NetWorker Data Domain DD Boost storage device. The
media type is Data Domain.
Note: The libraries and devices available for configuration are listed in the Devices window
of NetWorker Administration. For an up-to-date list of supported NetWorker devices, refer
to the EMC NetWorker Hardware Compatibility Guide at support.emc.com.

Devices managed by NetWorker are either standalone devices or library devices.
• A standalone device is any type of device that does not have a robotic arm for loading
volumes. Thus, a volume must be manually loaded into the device (and mounted)
before the device can be used for backup or recovery.
• A library (sometimes called an autochanger or a jukebox) is a multiple-volume device
that uses a robotic arm to move media. A library contains one or more drives. Drives
within a library are configured and managed differently than standalone devices.

The NetWorker server manages the flow of save set data sent to a device. To accomplish
this, the server needs to know whether the device is attached to the NetWorker server or to
a remote storage node.
A NetWorker server can manage many storage nodes but a storage node can be managed
by only one NetWorker server. In other words, a storage node cannot exist in two data
zones at the same time.
Relationship to
Description
NW Server
A device that is attached to (either direct or SAN-attached) and
Local
controlled by the NetWorker server.
A device that is attached to (either direct or SAN-attached) and
controlled by a NetWorker storage node that is not also the
NetWorker server.
Remote
All remote device names have an “rd=sn_hostname:” preceding
the device path on the storage node. The slide shows an
example of a remote device name.
Table 6-1: Device/Host Relationships

Storage nodes are the NetWorker components that physically control the backup devices. A
storage node must have the NetWorker client and storage node software installed on the
host. Additionally, a storage node resource is configured for each storage node host.
To create a storage node resource, right-click Storage Nodes in the left pane of the
Devices window and select New. In the resulting window specify the host name of the
storage node. Select the type of storage node, SCSI, NDMP or SILO.
In the status attributes, a Yes for Enabled means that the storage node is available for
use. Specifying No indicates a service or disabled state. New device operations cannot
begin and existing device operations may be cancelled.
We review more of the most commonly used storage node attributes in the course by type
of managed device.
Note: A storage node resource for the NetWorker server is automatically created during
installation of the NetWorker server.

Recall that processes running on a NetWorker storage node include nsrmmd and nsrsnmd.
To support reading and writing of data, one or more nsrmmd processes is started per
configured device. Depending upon the configuration, AFTD and DD Boost devices use
multiple concurrent nsrmmd processes per device and multiple concurrent save sessions per
nsrmmd process.
There is one nsrsnmd process running on each storage node with configured and enabled
devices. nsrsnmd manages all device operations that the nsrmmd processes handle on behalf
of the NetWorker server’s nsrd process. Communication between nsrsnmd and nsrd is
event-based; nsrsnmd is automatically invoked by nsrd, as required.
To verify that the processes are running on a storage node, use the UNIX/Linux ps
command or, on a Windows host, use Windows Task Manager.

In this lab, you configure a storage node resource for the Linux host in your NetWorker lab
environment.

This lesson covers using NetWorker disk storage devices with an emphasis on Data Domain,
cloud, and advanced file type devices.

NetWorker backup to disk devices use disk files that are configured and managed by
NetWorker. Disk devices can reside on a computer’s local disk or they can be located on a
network-attached disk.
The types of NetWorker backup to disk devices include:
• File type device (FTD) – Is the basic, legacy disk device type.
• Advanced file type device (AFTD) - Supports concurrent backup and restore
operations. AFTDs can reside on a local disk on a NetWorker storage node or on network-
attached disk devices that are either NFS or CIFS mounted to a NetWorker storage node.
• DD Boost device - Resides on Data Domain systems with enabled DD Boost. Backup
data is stored in a DD Boost device in deduplicated format.
• Cloud devices - Specific to cloud storage devices, such as EMC Atmos.

A file type device (FTD) uses an existing directory within a file system as its volume. File
devices can be local to Windows/Linux storage nodes or NFS-mounted to Linux storage
nodes. Each save set directed to the device is written to a separate file within the directory.
File type device does not support concurrent read and write operations.
When creating a NetWorker device resource for a file device, the name of the device is the
full pathname of the directory, for example E:\, D:\Filedev1, or /filedevice2. It is strongly
suggested that you create separate file systems for each file type device. If multiple file
devices share the same file system, they will each contend for the available disk space. If a
file device resides in a file system containing operating system or user files, there will also
be contention for available space. If a file type device cannot be assigned its own dedicated
file system, the device’s Volume default capacity attribute should be used to limit the
amount of space that can be used by the device. If this attribute has a value (it is null by
default), the volume becomes full upon the specified amount of data (750 MB, 12 GB, 1 TB,
etc.) being written to it.
After the device resource is created, a file type device’s volume is labeled and mounted.
File type devices are legacy devices and their use is limited. It is recommended to use AFTD
or DD Boost devices instead of file type devices.

Advanced file type devices overcome the main restrictions of traditional file type devices.
Advanced file type devices support multiple backups and read operations, simultaneously.
This allows you to recover, clone, or stage data from an AFTD while backups are in
progress. To support this capability, multiple concurrent nsrmmd processes are used per
device and each nsrmmd can support multiple concurrent save sessions.
The following operations can be performed concurrently on a single storage node:
• Multiple backups and multiple recover operations
• Multiple backups and multiple clone operations
• Multiple backups and one staging operations
• When recovering from an AFTD, save sets are recovered concurrently. Multiple save
sets can be simultaneously recovered to multiple clients. AFTD save sets can be
cloned to two different volumes simultaneously. Concurrent recoveries is limited to file
type recoveries and are performed using the recover command.
• Many file systems can be dynamically enlarged, allowing the size of an AFTD volume
to be increased without relabeling the volume.
• Unlike a file type device, advanced file type devices are supported for both NFS and
CIFS.
The Client Direct feature enables Networker clients to back up directly to AFTDs over CIFS
or NFS, bypassing the storage node.

An advanced file type device responds differently than a file type device to a “disk full”
condition. A file type device behaves much like a tape device. When there is no more room
on the volume, NetWorker marks the volume full and continues backing up the save set to
another volume. This volume may be either a disk or tape volume.
An AFTD volume is never marked as full. A save set being written to an advanced file type
device will never continue (span) onto another volume. Instead, if the file system
containing the volume becomes full, NetWorker suspends all saves being directed to that
device until more space is made available on the volume. A message is displayed stating
that the file system requires more space. The nsrim process is invoked to reclaim space on
the volume. A notification is sent by email to the NetWorker administrator.
You can make more space available in a number of ways:

• Manually delete unneeded save sets.
• Move save sets from the full volume to another volume (staging).
• Dynamically add space to the volume (file system), if it is supported by the operating
system and file system.

Each AFTD device is identified with a single NetWorker storage volume. Before creating an
AFTD resource, create one directory for each disk to be used for the AFTD.
As a security feature to restrict where AFTDs can be created, in the applicable storage node
resource, you can enter the path or paths of the storage directory that will contain AFTDs
into the AFTD allowed directories attribute.
Do not use a temporary directory. It is strongly suggested that you create separate file
systems for each AFTD. If multiple AFTDs share the same file system, they each contend for
the available disk space. If an AFTD resides in a file system containing operating system or
user files, there will also be contention for available space.
For Dynamic nsrmmds, select whether nsrmmd processes on the storage node devices will be
started dynamically. When not selected, which is the default setting, NetWorker runs all
available nsrmmd processes. If selected, NetWorker starts one nsrmmd process per device
and adds more only on demand, as needed.

Each AFTD device is defined by a single path, although the access path may be specified in
different ways for different client hosts.
NetWorker AFTD devices can be created from the Devices window using either the Device
Wizard or the Properties window.
The attributes from the Properties window are shown here; however, with either method,
similar information is provided:
• For Name, enter the name you would like to use for the device. This can be the path
to the device, or it can be a meaningful name of your choosing. If the storage node is
not also the NetWorker server, this AFTD will be a remote device. The remote device
name must use this format: rd=storagenodename:devicename.
• In the Device access information attribute, enter the complete path to the device
directory. Multiple entries may be made. The first path enables the storage node to
access the device via its defined mount point. You can also provide alternate paths for
Client Direct clients.
• Select adv_file as the Media type for advanced file type devices.

On the Configuration tab, set the number of concurrent sessions and the number of
nsrmmd processes the device may handle.
• Target sessions is the number of sessions that a nsrmmd process will handle before
another device on the host will take additional sessions. This setting is used to balance
the sessions among nsrmmd processes. If another device is not available, then another
nsrmmd process on the same device takes the additional sessions. Typically, this field
is set to a lower value. The default value for AFTDs is 4.
• Max sessions is the maximum number of sessions that the device may handle. If no
additional devices are available on the host, then another available storage host will
be used, or retries are attempted until sessions are available. The default value is 32
for AFTDs. This typically provides the best performance.
• Max nsrmmd count limits the number of nsrmmd processes that can run on this
device. This setting is used to balance the nsrmmd load among devices. The default
value for MAX nsrmmd count is 12.
Additional fields to configure include:

• Provide a Remote user name and Password if an NFS or CIFS path is specified in
the Device access information field.
• The AFTD percentage capacity attribute is used to determine at what capacity
NetWorker should stop writing to the AFTD. A value of 0 or leaving the attribute
empty, is equivalent to a setting of 100%. High and low watermarks for the volume
are calculated based on a percentage of the restricted capacity. When changing this
field, the volume must be remounted for the change to take effect.

After the AFTD device resource is created, label a volume in the device into a media pool
and then mount the volume.

You can also use the Device Configuration wizard to create an AFTD. From the Devices
window, right-click Devices and select New Device Wizard. Select AFTD for device type.
Complete the information in the wizard as required. Verify the device settings and select
Finish.

The data load for simultaneous operations can be balanced across available devices by
using the target and max sessions per device. Also, when there are multiple AFTD volumes
belonging to a pool, NetWorker chooses the AFTD with the least amount of used space. By
using the total used capacity for AFTD volume selection, the first labeled device is not
excessively used. Together these capabilities provide for effective load balancing across disk
volumes.
It is possible to configure multiple AFTD devices that share a single storage volume. The
devices can be on the same storage node or on a different storage node. Each device must
have a different name and must specify a path to the storage location. This enables storage
devices and volumes to be better utilized by allowing different devices to mount and access
volumes at the same time. A new session can be distributed to any other nsrmmd seeing
the same volume.
Clients with network access to AFTD or DD Boost storage devices can send their backup
data directly to the storage devices, thus bypassing the storage node in the backup path.
The storage node continues to manage the devices for the NetWorker clients but does not
handle the data. Using Client Direct has the potential for reducing bandwidth usage as the
backup data travels directly from the client to the storage device. Also, any bottlenecks at
the storage node are avoided.

In NetWorker, load balancing across storage nodes is configurable globally across all clients,
or on a client by client basis. Save sessions are distributed based on the selection for the
Save session distribution attribute on the client resource.
Options include:
Max sessions – This option distributes save sessions based on the Max sessions attribute
of all devices configured on the storage node. This is the default.
Target sessions – This option distributes save sessions based on the Target sessions
attribute of all devices configured on the storage node.

When NetWorker is integrated to Data Domain with DD Boost, part of the deduplication
process takes place on the storage node. The distributed segment processing (DSP)
component reviews the data that is already stored on the Data Domain system and sends
only unique data for storage.

The New Device Wizard is the recommended method to create and modify DD Boost
devices. With the wizard, you can also create and modify volume labels and storage pools
for DD Boost devices.
To create a Data Domain device, first launch the New Device Wizard from the Devices
window of NetWorker Administration.
In the Select the Device Type window, select Data Domain.
The New Device Wizard walks you through the remaining steps for creating your Data
Domain device.

Next, select the Data Domain system on which you would like to configure the device. If
you have not already added the Data Domain system in NetWorker, you can do so here as
well. Then, enter the DD Boost username and password. On the next screen, you are
prompted to choose the folder to use as your device.

Once device configuration has been performed, the next step is to configure the media
pools and label and mount the device.
At this point, you can either choose a pool that you have already created for DD Boost
backups and label the device into that pool or you can create a new pool. A dedicated pool
is required for DD Boost devices. Be sure you do not mix DD Boost backups and traditional
backups in the same pool.
Once you have selected a pool, you can check Label and Mount device after creation. In
the next window, choose the storage node for the device and the method of transport, Fibre
Channel or IP.

In SNMP Monitoring Options, type the Data Domain SNMP community string and specify
the events to be monitored.
The last wizard step is to review the configuration settings. The Device Access Information
is the fully qualified hostname of the Data Domain system and the name of the Data
Domain storage folder on the system. A colon (:) separates the Data Domain system name
and the device folder name.
Upon successful configuration, the device is labeled and mounted. In the NetWorker
Administration Devices window, verify that the device is labeled and mounted, ready for
use. The Data Domain system appears as a managed application in the NetWorker
Management Console Enterprise window.

NetWorker supports Virtual Synthetic Full backups with Data Domain. The process of
creating a Virtual Synthetic full is a much more efficient way to create a Synthetic full
backup and it is the default method.
In a typical backup cycle, the administrator schedules a full backup followed by several
incremental backups. To create a Virtual Full backup, NetWorker sends commands to the
Data Domain system that consist of the regions that are required to create a full backup.
During the transfer no data is transferred over the network. Instead, the regions of the full
backup are synthesized from the previous full and incremental backups that are on the
system using pointers. This process eliminates the data that needs to be gathered from the
file server, reducing system overhead, time to complete the process, and network
bandwidth requirements. NetWorker uses the DDBoost API to create the Virtual Synthetic
full backups.
Virtual Synthetic full backups are an out-of-the-box integration with NetWorker, making it
‘self-aware.’ Therefore, if you are using a Data Domain system as your backup target,
NetWorker will use Virtual Synthetic full backups as the backup workflow by default when a
Synthetic full backup is scheduled, thus optimizing incremental backups for file systems.
Virtual Synthetic Fulls reduce the processing overhead associated with traditional Synthetic
full backups by using metadata on the Data Domain system to synthesize a full backup
without moving data across the network. A traditional full backup is recommended only
after every 8-10 Virtual Fulls have been completed. Therefore, the use of Virtual Synthetic
Full backups also reduces the number of traditional full backups from 52 to 6 per year – a
90% reduction. If a Virtual Synthetic full operation fails, NetWorker defaults to creating a
Synthetic full.

Client Direct works with both AFTD and Data Domain devices. This feature is enabled for a
client by default. If a Client Direct backup cannot be performed (e.g. a network connection
to the storage is not supplied), a traditional backup via the storage node is performed.
Client Direct clients require a network connection and remote access to the storage device,
such as a CIFS or NFS path for AFTD devices.
The path(s) to the AFTD device are specified in the device’s Device access information
attribute. If the storage device is directly connected to the storage node, a different access
path is specified for the client than that for the storage node. A configuration using a CIFS
share is shown on the slide.
If the storage device is not directly connected to the storage node, as with NAS, the device
access information is the same for the storage node and clients.
Checkpoint restart supports Client Direct backups only to AFTD devices, and not to DD
Boost devices. If a client is enabled for checkpoint restart and a Client Direct backup is
attempted to a DD Boost device , then the backup reverts to a traditional storage backup.
For Client Direct backups to AFTDs using checkpoint restart, checkpoint restart points are
not made less than 15 seconds apart. Checkpoints are always made after larger files
requiring more than 15 seconds to backup.

Cloud computing or cloud technology is still an evolving model, hence there are many
definitions and points of view. For this lesson, we define cloud as a concept that enables
efficient and convenient on-demand access to all IT resources. These resources include
networks, servers, storage, and applications.
The “as a service” model represents a new way of resource delivery in IT. Just as
virtualization ushered in faster and more robust services, it is now having a similar effect
when applied to servers and storage. Server and storage environments can be easily
provisioned, expanded, contracted, decommissioned, and repurposed yielding extreme
flexibility and elasticity.
Benefits of cloud computing include:

• Increased capabilities
• Improved performance
• Lower cost and reduced risk
• Flexible scaling
• Less infrastructure management complexity

NetWorker provides expanded backup and recovery capabilities through integration with
Cloud Optimized Storage. The NetWorker Cloud Backup Option provides support for backing
up to both private (onsite) and public (offsite) cloud configurations.
Backup operations to cloud storage occur over a TCP I/P network. Data sent to a NetWorker
cloud device can be encrypted and/or compressed. There is also a bandwidth throttling
mechanism for cloud backup devices that allows you to limit the amount of bandwidth that
NetWorker can consume for cloud operations during specified periods of time.
All traditional NetWorker workflows are supported with cloud storage in NetWorker,
including backup, recovery, staging and cloning operations. To send backup data to a cloud,
you direct the backup operation (backup, clone, etc.) to a volume mounted on a cloud
storage device. Save sets on a cloud expire based on retention policies. When save sets
expire, space on the cloud is freed up. Cloud volumes are infinitely appendable. Cloud
volumes are not recycled. Cloud volumes can be manually deleted from the NetWorker
Administration Media window.

In this lab, you will:
• Create a remote AFTD
• Perform a backup to the new device
• Configure a NetWorker device to be used for Client Direct
• Run a Client Direct backup
• Configure a Data Domain device
• Run a backup to the Data Domain device

This lesson covers an overview of using tape libraries with NetWorker including supported
library topologies, multiplexing and OTF, and persistent binding and naming.

akhan@aayan.com Module: Configuring and Managing Devices 32
NetWorker supports a wide array of tape libraries. Regardless of manufacturer, tape
libraries consist of the following components:
• Robotic controller - This is a SCSI-connected device that allows a host to send
requests to and obtain information from the library. For example, a host sends a
request to the robotic controller to move a tape from a slot into a drive.
• Robotic arm - This is the mechanism that moves tapes. It is commonly an arm with a
gripper.
• Slots - This is where volumes are stored when not loaded in a tape drive. Each slot
has a unique element address.
• Media - These are the volumes, which are also known as cartridges or tapes.
• Drives - Each tape/optical drive also has a unique element address.
In addition to the above components, many libraries also have the following:
• Bar code reader - This is an optical device that reads a bar code affixed to a tape.
Using a bar code reader improves the speed of creating or refreshing the library’s
inventory of tape media.
• Import/export port - This is a special port used to move tapes into and out of the
library
without opening the door. It is also known as the Cartridge Access Port (CAP).
• Front panel - This is used to set up and control the library.
• Door - This allows access to the slots, media, and drives. Many libraries have a sensor
that detects when the door has been opened, which may initiate an inventory.

NetWorker supports various library connection topologies.
• A dedicated library is controlled by a single storage node. The robotic controller and all
tape drives are managed by the same storage node.
• A shared library is cabled in such a manner that two or more storage nodes control some
portion of the library. A shared library is supported in SAN (Storage Area Network) and
non-SAN environments. There are two configurations available for shared library
• Static drive assignment - All drives are statically bound to a specific storage node
and multiple storage nodes are assigned a drive. Often used with virtual tape
libraries.
• Dynamic Drive Sharing (DDS) - Supported only in a SAN environment.
Individual drives in the library are controlled by more than one storage node.
However, only one storage node can use a drive at any given time. DDS is used to
share physical tape libraries/drives among storage nodes.

As shown in the slide, all drives in a dedicated library are controlled by a single storage
node. Backup data from clients other than soprano must be sent to the storage node
soprano using the TCP/IP network.

Using Dynamic Drive Sharing (DDS), a tape drive is accessed and used by two or more
storage nodes within a single data zone. However, only one storage node can control a
drive at any given time.
Although it is more common to dynamically share drives residing in a library, standalone

drives may also be dynamically shared.
It should also be noted that not all drives in a library must be dynamically shared. For
example, in the environment depicted in the slide, it would be possible to allow alto access
to all four tape drives but allow soprano access to only the top drive. Thus, only the top
drive would be dynamically shared.
DDS reduces hardware demands by allowing multiple storage nodes to use the same drive,
but at different times. Once configured, the administration (labeling, mounting, etc.) of a
shared drive is the same as for a non-shared drive.
For more information about NetWorker DDS configurations, refer to the EMC NetWorker
Important: DDS is only supported in a storage area network (SAN) environment. DDS is
only supported within a single data zone.
Note: Using DDS with a virtual tape library is not recommended.

In an environment without multiplexing, only one stream of data is written to the device at
any given time. This situation is not ideal because as more clients perform simultaneous
backups, the tape drive’s throughput is not optimized.
Multiplexing enables more than one save stream to write to the same device at the same
time. This allows the device to write to the volume at the collective data rate of the save
streams, up to the maximum data rate of the device.
The amount of multiplexing allowed (the number of save sets that can back up
simultaneously) is primarily controlled by two NetWorker settings, server parallelism and
device target sessions. These settings are discussed in detail in a later module.

Open Tape Format (OTF) is a data format that allows multiplexed, heterogeneous (UNIX,
Windows, NetWare, etc.) data to reside on the same tape. NetWorker clients send data in
save set chunks to a storage node. The storage node arranges them in media records and
media files which are stored in volumes. The way the storage node organizes the records
and files is also platform-independent (Open Tape Format), allowing any NetWorker storage
node to read the data. Because of Open Tape Format, a NetWorker storage node can be
migrated to a host running a different operating system.
Note: For more information on OTF, refer to the mm_data topic in the EMC NetWorker
Command Reference Guide.

After a device resource is created and a volume with a NetWorker label is mounted, nsrmmd
writes save set data to the volume using the process illustrated in the slide:
1. When a save is initiated, nsrmmd interfaces with the device to write the data to the
volume.
2. The nsrmmd daemon performs the following tasks to support multiplexing of backup data,
using Open Tape Format:
• Breaks each save set into chunks.
• Combines chunks from various save sets into records.
• Sends the records to the device which writes them to the volume.
• Periodically, nsrmmd writes end-of-file marks to the volume, creating media files. These
file marks are used for faster positioning during reading of the volume.
3. As each record is written to the volume, nsrmmd sends tracking information to the media
database on the NetWorker server. This information is inserted into volume and save set
records in the database, and tracks the location of each media file, media record, and
save set chunk.
Note: For more information on Open Tape Format, see the mm_data topic in the EMC
NetWorker Command Reference Guide or the UNIX/Linux man pages.

Persistent binding statically maps a target’s WWN address to the desired SCSI address,
ensuring the operating system always sees SAN-presented devices with the same SCSI
target ID across reboots. This feature is enabled by default on some operating systems,
while on others it has to be set manually.
Persistent binding is required for consistent library operations as NetWorker communicates

with the library controller over a SCSI address that is chosen during initial library
configuration.
If the SCSI address changes, the library becomes unavailable. In such situations, it is
required to disable the library and change the “control port” address to reflect the new SCSI
address of the library controller.
Persistent naming is used to ensure that the operating system (OS) or device driver of a
server always creates and uses the same symbolic path for a device (sometimes referred to
as device file).
As a best practice, EMC recommends enabling persistent binding and naming for tape
libraries and tape devices. This avoids device reordering on reboots or plug and play events.
If a device reordering occurs, the NetWorker software is not able to use any affected drives
until the configuration is manually corrected.
For details on how to configure persistent naming from the operating system or device
driver, refer to your operating system and/or device driver documentation.

This lesson covers configuring and managing a library using NetWorker Administration and
commands.

For NetWorker to use a library, a jukebox resource (NSR jukebox) must be created. This is
done using either NetWorker Administration or the command-line utility, jbconfig.
For a library to be configured using NetWorker Administration, the library must be able to
provide hardware information, such as device serial numbers, to NetWorker. If this
information cannot be automatically provided to NetWorker by the firmware, jbconfig is
used to configure the library.

To use NetWorker Administration to configure a library or drive on a storage node, a
storage node resource must exist. The resource is used to scan the host for configurable
tape drives and libraries. Note that a storage node resource is automatically created for the
NetWorker server during installation.
The Skip scsi targets field is used to specify SCSI addresses to skip (in bus.target.lun
format) when performing a scan operation. This is useful if the storage node has tape drives
or libraries that you do not want NetWorker to use. Placing a list of SCSI addresses to be
skipped in the storage node resource results in those addresses being skipped during all
scan operations.

The first step in configuring a library is to scan the controlling storage node for libraries and
devices that are not yet known to the NetWorker server, either direct attached or SAN
attached. This is done by right-clicking the storage node in the left pane of the Devices
window and selecting Scan for devices. A window opens in which you can specify the
storage node to scan. Although the storage node selected in the left-pane is automatically
chosen, you can choose to scan any or all storage nodes for which a storage node resource
is configured.
If there are unconfigured tape drives or libraries on the storage node(s) that you do not
wish to be affected by a scan operation, specify each SCSI ID in the Exclude SCSI Paths
field. This field can be used to prevent NetWorker from configuring a device and from
unnecessarily scanning attached SAN disks or non-tape library/drive SCSI IDs. Any
addresses in the Skip scsi targets attribute of the storage node resource are automatically
included in the Exclude SCSI Paths for the storage node.

You can monitor the progress of the scan operation by viewing the Log window.
After the scan operation is finished, unconfigured devices are displayed in the left pane of
the Devices window. The icon used to represent an unconfigured drive or library looks like
an orange circle containing a wrench.

Next, configure the library (jukebox resource) and its devices. Right-click an unconfigured
tape library in the left pane of the Devices window and select Configure Library. To
create jukebox resources for all unconfigured libraries on a storage node, use the
Configure All Libraries selection.
In the resulting Configure Library window, assign the drives in the library to the storage
node that will control the robot. In the slide, there is only one storage node shown, nwlinux
in the window. However, in a SAN environment, it is possible that additional storage nodes
are able to access the library. If these storage nodes have been scanned by NetWorker,
they are also displayed in the window.
Click Start Configuration to create the jukebox resource and device resources for the
drives within the library.
Important: An unconfigured library is listed in the left pane under each storage node that
has access to it.

After a jukebox resource has been created, the icon for the tape library in the Devices
window changes to reflect the fact that the library is now configured and devices have been
created for the tape drives. In this example, we show a configured library with two tape
drives. The display also shows that there are 15 slots in the library with 14 unlabeled tapes
and one cleaning tape(CLN015L5).

With library sharing, two or more storage nodes are each assigned one or more drives in
the library to manage. Only one storage node manages each drive. When configuring a
shared library, NetWorker uses the device serial numbers read during a scan operation to
determine which storage nodes are able to access each drive in the library.
In the slide, \\.\Tape3 on leg1-win5 and /dev/rmt/2cbn on leg1-sun5 have the same
serial number. NetWorker also recognizes that \\.\Tape2 on leg1-win5 and /dev/rmt/3cbn
on leg1-sun5 have the same serial number and therefore point to the same physical drive.
During library configuration, one drive is assigned to leg1-win5 and the second drive is
assigned to leg1-sun5. After the library has been configured, there are now two device
resources associated with the tape library. One of the drives is configured with leg1-sun5
and the other with leg1-win5. The tape library is controlled by leg1-sun5.
Important: Always configure a library using the storage node that you want to control the
robot.

Device file names, created as a result of persistent naming, depend on the OS and device
drivers used to enable and configure tape devices. Where persistent binding has been
enabled on the host, enable the Use Persistent Names option when scanning for tape
devices, as shown on the slide.

Clicking a configured library displays information about the library’s devices and current
volume inventory.
To view a jukebox resource, right-click the library and select Properties from the drop-
down menu. The General tab shows basic information about the library.

Attributes found on the Configuration tab include:
Auto media management indicates whether NetWorker should automatically label and
write to non-NetWorker tapes as needed. It is disabled by default.
Bar code reader indicates whether NetWorker should list the bar code on the tape in the
jukebox's inventory and in the media database. It is enabled by default.
Match bar code labels indicates whether NetWorker should use the value on the bar code
as the NetWorker volume name for the tape. It is enabled by default.
Max parallelism is the maximum number of drives to use concurrently for a label or
inventory operation. The default value is one less than the number of drives in the jukebox
(Number drives attribute).

NetWorker libraries are managed using either the NetWorker Administration Devices
window or the nsrjb command-line utility.
With the Devices window, label and inventory operations are performed by right-clicking
the library and choosing the appropriate selection from the menu. From the menu, you can
also perform a hardware reset of the library and have volumes moved from the import slots
to empty volume slots.

After configuring a library, a volume must be labeled before the library and its devices can
be used for backups. To label volumes in a library, right-click the library name in the left
pane of the Devices window and select Label.
In Slot List, specify the slots containing the volumes to be labeled.
In Target Media Pool, select the pool to which the volumes will belong.
With Prompt to Overwrite Existing Label checked (default), NetWorker prompts the user
if there is an existing label on the volume.
If the volume should not be recycled automatically, select Allow Manual Recycle.
After a volume is labeled, it must be mounted before NetWorker can use it. This is done
automatically within a library.
When Auto Media Management is enabled, NetWorker automatically mounts a volume in

a device when needed and labels the volume if it is unlabeled.
Note: If an existing volume is labeled in NetWorker, existing data on the volume will be
completely lost. You will not be able to recover any data that existed on the tape before the
label operation.

The Status table in the Devices window shows operations in progress. When there is an
operation that requires user input, such as labeling a tape which already contains a label or
depositing volumes into a library, NetWorker pops up a dialog box automatically and a User
Input icon is displayed in the status table.
If you choose Ignore from the dialog box, the icon remains in the User Input field as a
reminder that input must be provided before the operation will continue. To later supply
input, click the User Input icon on the shortcut bar. Note that this icon is available from
any NetWorker Administration window. Alternately, input can be supplied by selecting
Supply Input from the Operations screen of the Monitoring window.

To see status information for labeled tape volumes , select Tape Volumes in the left pane
of the Media window. Attributes displayed for the volumes include:
• Barcode: the volume’s bar code, if configured
• Used: the amount of data written to the volume
• % Used: the percentage used based on the Volume default capacity value in the
device resource
• Mode: the volume mode; possible values are appendable, manual recycle, read-only
and recyclable
• Expiration: the date on which the volume will become recyclable
• Pool: the pool to which the volume belongs
By double-clicking a volume in the right pane, you can display a list of save sets that have
been written to the selected volume. This is a good way to verify that a first backup to a
tape device is happening as expected.

jbconfig is used in situations where NetWorker Administration doesn’t recognize or
configure the library, and when troubleshooting library configuration problems.
Libraries that have serial numbers can be configured using either NetWorker Administration
or the jbconfig command. However, devices that do not provide serial numbers must be
configured using jbconfig. Also, use jbconfig to configure IBM tape libraries that are
controlled through the use of the IBMs tape driver.

Tape drives in a library have several identifiers, including:
SCSI address - Each tape drive has a unique bus, target, and logical unit number (LUN).
Many people mistakenly believe that the lowest SCSI address is the first tape drive in the
library. This is not always the case.
Library element address - Each slot and tape drive is assigned a unique element address
by the robotic controller. The tape drive with the lowest element address is the first drive;
the next highest element address is the second drive, and so on.
Operating system pathname – A tape drive is accessed through its operating system
device pathname.
When using jbconfig to configure a tape library, you are prompted to enter the operating
system pathname of each drive, beginning with the drive having the lowest element
address. Understanding the order of the drives is necessary to properly configure the
library.
When using jbconfig to configure the library shown in the slide, you are prompted four
times for the pathname of a tape drive in the library. What is the correct sequence of
pathnames to enter? Since you are first prompted for the drive having the lowest element
address, the correct sequence is \\.\Tape3, \\.\Tape2, \\.\Tape1, and \\.\Tape0. This order
corresponds with the ordering of the element addresses.
Persistent binding and persistent naming can be used to resolve issues regarding device
ordering.

Before running jbconfig, make sure that the operating system can see and use the library
and its devices.
The NetWorker inquire command lists all SCSI devices detected by the operating system
on the storage node. This command is part of the storage node software.
The sjisn command is used to display information about a specific library. Not all libraries
support the sjisn command.
The syntax of sjisn is: sjisn bus.target.lun
By comparing the output from inquire and sjisn you can determine the tape drive
ordering and the operating system pathname assigned to each drive.
In the slide, the sjisn output shows the serial number of the drive at element address 1 is
10000091. The output of the inquire command shows the operating system has assigned
the drive with that serial number a device pathname of /dev/nst2. Since 1 is the lowest
numbered element address, when prompted by jbconfig to provide the path name of the
first drive in the library, you should enter /dev/nst2.
Notes:
To ensure consistent results, it is a best practice to disable the library before running
inquire on a configured library.
For more information, see the inquire, changers, and sjisn topics in the EMC NetWorker
Command Reference Guide and the UNIX/Linux man pages.

To test the functionality of a library, the NetWorker sjimm command can be used. It allows
you to move media between slots and drives in a library. You may also be able to move
media using the library’s interface, such as its front panel.
To test a device, load a volume into a drive and then verify the operating system can see
the volume in the drive. This can be done using the mt command, which is native to UNIX
hosts and is provided as part of the NetWorker software on Windows hosts. When mt is
used with the status option, it will either return data on the device in the drive, or state no
device in drive.
You can also use the sjirdtag and sjirelem commands to display the changes being made
by the sjimm command. These commands read the media presence and data from a
jukebox. The sjirelem command can also print where the last place of a piece of media
had been prior to its current location, when the jukebox provides that information.
See the sjimm, mt, sjirdtag, and sjirelem topics in the EMC NetWorker Command
Reference Guide and the UNIX/Linux man pages for more information and a description of
additional features.
Caution: A series of commands exists that allow direct interaction with libraries (sji
commands) and tape drives (cdi commands). These commands should only be used by
expert users, as the consequences of using them can be unknown. These commands may
directly interact with the libraries and drives without the knowledge of NetWorker.

The jbconfig command is executed from the storage node managing the library control
port (robotic arm). If it is a remote storage node, you should use the -s option followed by
the name of the NetWorker server. If the –s option is not used and nsrd is not running on
the local host, you are prompted for the name of the NetWorker server on which the
jukebox resource will be configured.
Since jbconfig creates a jukebox resource on the NetWorker server, if it is executed from
a storage node, the administrative user running the command must belong to the
NetWorker server’s Administrators user group. After jbconfig creates the resource, the
user can be removed from the user group.
After the jukebox resource is created, it is managed using either of the standard
administrative interfaces: NetWorker Administration or nsradmin.

jbconfig prompts vary from library to library, but commonly include:
Type of Jukebox - This course covers auto-detected SCSI libraries.
Which Jukebox - Select the library to configure from the list of auto-detected libraries.
Only SCSI libraries that have not already been configured are listed. If there is only one
configurable library, you are not prompted.
Jukebox Name - The name you want to assign to the library.
Auto Clean - Indicates whether to use NetWorker to manage device cleaning.

Is any drive intended for NDMP use? - Network Data Management Protocol (NDMP) is a
protocol used by Network Attached Storage (NAS) devices to control backups and backup
devices. Answer yes if any of the drives will be used to receive NDMP data.
Additional jbconfig prompts include:
Is any drive going to have more than one path defined - Answer yes if dynamic drive
sharing is being configured for any of the drives in the library.
The pathname of each tape device – This is the operating system pathname.
Device type - such as LTO2 or DLT7000
After receiving all your input, jbconfig lists the options that have been set.

nsrjb is a NetWorker command line utility used to manage NetWorker library (jukebox)
operations. nsrjb can be used to perform tasks such as labeling volumes, mounting and
unmounting volumes, and inventorying and resetting a library. The slide shows several
examples of using the command.
Some of the common command options include:

• -C - List the jukebox contents. (This is the default option.)
• -H - Reset the jukebox to a known state: drives emptied, etc.
• -E - Reset the jukebox element status.
• -I - Inventory the volumes in the jukebox.
• -S slots - The slot(s) to use for operations such as labeling, inventorying,
withdrawing, etc.
• -j jbname - Specify the jukebox on which to perform the operation.
• -u - Unmount the volume, drive, or slot specified.
• -l - Mount (load) the volume, drive, or slot specified.
• -f device - The device to use for the operation.
• -L - Label the volume, drive, or slot specified.
• -v - Produce verbose output.
• -p - Verify and print the volume label.
Note: nsrjb has many additional options. See the nsrjb topic in the EMC NetWorker
Command Reference Guide and the UNIX/Linux man pages for more information.

This demonstration covers the procedures for configuring tape library resources in
NetWorker. Included in this demonstration is a walkthrough of scanning for devices on
storage nodes, configuring library and tape devices, as well as performing common tape
operations.

This module covered configuring and managing devices in NetWorker. Specific supported
device types were covered, as well as the configuration of local, remote, AFTD, Data
Domain and tape devices.

This module focuses on NetWorker database management. We discuss how to query and
manage the CFI and media database using NetWorker Administration and various
commands. We also look at how NetWorker selects volumes for backup.

akhan@aayan.comModule: NetWorker Database Management 1
This lesson covers how to view CFI and media database information using various
NetWorker interfaces. We discuss the interfaces for managing the media database and CFI;
save set and volume status and aging; as well as how NetWorker selects a volume for
writing.

This slide shows the NetWorker interfaces available for displaying the contents of, and/or
querying, the media database and client file indexes.
nsrinfo, nsrls, and mminfo are usually executed on the NetWorker server. However, both
nsrinfo and mminfo have a –s nw_server option which allows you to run the command
from any NetWorker host.

The NetWorker nsrinfo command, when specified with only a client name as an argument,
displays a list of all files being tracked in that client’s CFI. With additional options, nsrinfo
can list all files backed up at a specific time or with a specific pathname.
When using a Windows pathname on a UNIX command-line, single quotes are required to
turn off the special meaning of the backslash. An ending ‘\’ or ‘/’ in a pathname is required
to match a directory with that pathname.
nsrinfo(1m) syntax:
nsrinfo [ -options ] clientname
Where clientname is the name of a NetWorker client and is a required argument. The
output of nsrinfo includes the pathname of each file, and the date and time it was backed
up, in both savetime and nsavetime formats.

akhan@aayan.com Module: NetWorker Database Management 4
The NetWorker nsrls command displays summary information concerning CFI usage.
nsrls(1m) syntax:
nsrls [ clientname | -m ]
Where clientname is the name of a NetWorker client and, if specified, causes that client’s
CFI usage to be summarized. If no arguments are specified, summary information is
displayed for all CFIs.
Output of nsrls includes the total number of records contained in the CFI and the total
amount of disk space used by the CFI.
nsrls has a -m option which displays the number of records in each of the media database
files and the amount of disk space used by each file.

To view information about each client's CFI or to manually remove CFI entries, click Client
Indexes in the left pane of the NetWorker Administration’s Media window. A list of all
NetWorker clients is displayed along with the overall size of each client’s CFI and the
number of cycles being tracked.
Right-clicking a client pops up a context menu from which you can display more detailed
information about the client’s CFI or perform a consistency check on it.
If you choose Show Save Sets from the context menu, the Index Save Sets window pops
up which displays the names of all the client’s browsable save sets and the amount of space
in the CFI used for file entries from those save sets. Upon selecting a save set name in the
upper pane, information for each individual save set with that name is displayed in the
bottom pane.
A CFI commonly contains several cycles worth of entries for each save set name.
A cycle is defined in NetWorker as a Full backup and all its dependent save sets.
Incremental and cumulative incremental save sets are dependent on the most recent Full
save set for a current recovery of the save set.
To give an example of what a cycle is, if a client has a 28 day retention policy, uses a
schedule of running a full backup on Sunday and incremental backups the rest of the week,
and has a save set list of C:\Windows\Fonts, the client’s CFI will contain four or five cycles
of the C:\Windows\Fonts save sets, with each cycle being comprised of a full backup and its
six dependent incremental save sets.
To manually remove entries from a CFI prior to the entries being automatically purged due
to normal aging of data, Remove Oldest Cycle removes all entries belonging to the oldest
full save set of the selected save set name and all entries belonging to its dependent save
sets. This is commonly done to quickly reduce the size of a CFI.

The NetWorker mminfo command is used to display information from media database
volume and save set records. It is also used to perform queries of the media database and
generate customized reports.
mminfo(1m) syntax:
mminfo [ -options ] [ -q queryspec ] [ -r reportspec ] [ volname ]
If no arguments are specified, the output includes all browsable save sets created since
midnight of the previous day. By default, the fields displayed include the save set name,
client name, timestamp, size, backup level, and the name of the volume containing the
save set.
If portions of a save set reside on multiple volumes, there is a line of output for each
volume.
Options and arguments are used to define other queries and reports. If the volname
argument is used, the output is restricted to save sets on that volume.
Several common mminfo usage examples are shown on the slide.

The query option, -q queryspec, allows you to specify a custom query on fields (attributes)
within the media database. The –r reportspec option allows you to specify which fields to
include in the output of matching records.
Queries may use the operators ‘<‘, ‘>’, and ‘=’ to compare a field to a value. Commas are
used to separate multiple queries. If queryspec begins with the negation operator ‘!’, the
comparison matches only if the field does not match the value.
Reports are generated by providing a comma-separated list of volume or save set attributes
which are displayed in the order specified. To specify a field width within a report, append
“(width)” to the attribute keyword, for example “name(10)”.
In the slide, the -q queryspec syntax is used to query the database for save sets named
C:\Windows\Fonts that have more than one copy:
mminfo -q "copies>1, name=C:\Windows\Fonts" ...
-r reportspec is used to display the name of the save set truncated (or blank-padded) to
10 characters, the save set ID, the clone ID, the number of copies, the volume containing
the save set, and the client name:
mminfo ... -r "name(10), ssid, cloneid, copies, volume, client”
Important: There are many volume and save set attributes that may be used for querying
and reporting. All of these options are listed and described in the mminfo(1m) man page
and the NetWorker Command Reference Guide.

You can query a client’s snapshot save sets using the mminfo command. The -q snap
option lists all snapshot save sets for a particular client.
To list the snapshot save sets for a client, type the following command at the prompt:
mminfo -s server -q snap -c client
where :
• server – hostname of NetWorker server
• client – hostname of the client from which NSM backed the data up
Note: The NetWorker Command Reference Guide and NetWorker man pages provide further
details on these operations.

The slide lists common mminfo options for querying the media database and generating
reports.
Additional mminfo Examples
Query NetWorker server bongo’s media database, reporting on all browsable save sets, with
a colon (:) separating each field of output. This can be executed on any NetWorker client.
mminfo -s bongo -a -xc:
Display all save sets with a name of /stardata that were backed up from alto, generate
verbose output and separate the fields with a semi-colon. The semi-colon must be quoted
(UNIX only) because it is special to all UNIX shells.
mminfo –c alto –N /stardata –v –xc’;’
Query the database for save sets older than 2 days. The default set of attributes is
displayed.
mminfo -q "savetime < 2 days ago"
Query the database for save sets backed up from flute within the past 2 days.
mminfo -q "savetime > 2 days ago, client=flute"
Display information on volumes containing save sets backed up from flute and which were
written to during the past week.
mminfo -m -t "last week" -q client=flute
Note: See the mminfo(1m) man page and the NetWorker Command Reference Guide for
examples and further information.

The NetWorker Administration GUI can be used to display volume and save set information
by using the Volumes selection in the Media window.
When the Volumes option is selected in the left pane, a list of all volumes is displayed.
Right-clicking on a volume pops up a context menu used for performing tasks associated
with volumes; such as displaying all save sets on a volume and deleting a volume from the
media database.
Double-clicking a volume also displays all save sets on the volume. The information
displayed is equivalent to that generated by using mminfo –v volumename.

The NetWorker Administration GUI also provides the ability to query the media database
and display information concerning save sets matching the query.
To perform a query, click Save Sets in the left pane of the Media window. In the right
pane, specify the save set characteristics of those save sets you want information about.
Change to the Save Set List tab to perform the query and report matching save sets.
In the Query Save Set tab, you can choose to display only those save sets matching a
specific status and type. The default value is All for both Status and Type.
Copies commonly refers to how many times a save set has been cloned. A save set that
has been cloned once has 2 copies, the original and one clone. Additionally, any save set
written to an advanced file type device is seen as having 2 copies. The drop-down menu in
the Copies field allows you to perform comparisons using the ‘=‘, ‘>’ and ‘<‘ operators.
You can specify the maximum backup level of the save set. Since a full backup is
equivalent to a level 0, selecting Full matches only full level backups. To match client-
initiated save sets, All must be selected.
When selecting a range of values for the Save Time field, a calendar is displayed from
which you select the desired date. A specific time of day can be specified by manually
editing the From and To fields.

Much of the management of the NetWorker databases is performed automatically, such as
aging of save sets and volumes, and performing of consistency checks. NetWorker also
provides command-line and GUI administrative interfaces for manual administration of the
databases and their content. This slide lists these interfaces and their functions.
While the command-line utilities in the slide are usually executed on the NetWorker server,
both nsrmm and mmlocate include a –s nw_server option which allows you to run the
command from any NetWorker host.
Note: The nsrmm command has numerous functions. In the context of database
management, it is used to change the save set and volume status, delete save sets and
volume records from the media database, and age save sets. nsrmm can also be used to
manage standalone devices, including the labeling and mounting of volumes.

Retention specified on the backup action is used to set the aging values for a client’s save
sets. If client overrides are allowed on the action, the Retention policy field on the client is
used, if supplied.
You will may also see references to a Browse policy on the client resource or Browse
time when looking at save set metadata. The browse policy was used in previous versions
of NetWorker. Beginning with NetWorker 9, NetWorker uses the Retention value for both
the Browse time and the Retention time.
When a save set is backed up, the value for Retention is added to the current date to
determine the save set’s browse time and retention time. These values are stored in the
save set record as the ssbrowse and ssretent attributes, and are used to determine when
the save set changes from one status to another as it ages.
Browse time (ssbrowse) = Backup Date + Browse Policy
Retention time (ssretent) = Backup Date + Retention Policy
The browse time specifies the date when the save set’s entries are removed from the
client’s CFI, thereby making the save set no longer browsable. The retention time specifies
the date when the save set expires and is no longer required. Beginning with NetWorker
9, the browse time and the retention time will be the same.
Save sets are checked for aging automatically once a day when the Server backup
workflow runs or by manually running nsrim. Dependent save sets may delay the aging of
certain save sets. For example, a level Full save set that has passed its browse time will
remain browsable (and therefore tracked in the CFI) until all incremental save sets that
depend on the full save set also pass their browse times. Thus, the aging of save sets may
be delayed by up to one cycle period, where a cycle is defined as the length of time
between full backups.

All save sets are tracked in the media database. Each save set record has a status field
which reflects the save set’s aging status. Primary statuses include browsable,
recoverable, and recyclable. A save set may also be assigned a secondary status of
suspect if a read error occurs during a recovery attempt of the save set contents.
A browsable save set has not passed its browse time and is therefore still tracked in both
the media database and a client file index. Both a browsable recovery and a save set
recovery can be performed on the save set.
A recoverable save set has passed its browse time but has not exceeded its retention
time. Because it has passed its browse time it is no longer tracked in a client file index.
Only a saveset recovery can be performed without rebuilding the client file index for that
saveset.
A recyclable save set has passed both its browse and retention times. A recyclable save
set is treated exactly like a recoverable save set except it will not keep the volume it is on
from being automatically recycled (relabeled).
Note: The mminfo(1m) man page contains more information for the other mminfo status
flags.
Important: A recyclable save set on a tape volume is only removed when that tape is
relabeled. A recyclable save set residing on a file type or an adv_file type device is
removed by nsrim on the same day it becomes recyclable.
Beginning with NetWorker 9, you specify only a retention period when backing up a save
set. NetWorker uses this value for both the Browse time and the Retention time for the
save set.

NetWorker volumes are also tracked in the media database and have one or more statuses
(modes) assigned to them reflecting their age and other conditions. The slide lists the
major volume modes.
When NetWorker labels a volume, the volume is assigned a status of appendable. Backups
can only be written to appendable volumes.
When a volume becomes full, it is assigned a status of full and can no longer be used for
backups. A tape volume will become full when the physical EOM (end of media) marker is
encountered during a save or when a write error results in the save being directed to
another volume.
When all save sets on a volume become recyclable, the status of the volume itself changes
to recyclable. Recyclable volumes may be automatically recycled (relabeled) by NetWorker
in the event that no appendable volumes are available to satisfy a backup request.
An administrator may assign a secondary mode of manual (recycle) to a volume. A volume

with a status of manual will never be automatically relabeled by NetWorker, even if the
primary mode of the volume is recyclable and a pending backup is waiting for another
volume.
A volume can be manually assigned a status of read only. This will keep additional data
from being written to the volume. Full and recyclable volumes are automatically given a
secondary status of read only.
Important: Manually setting a volume to read only does not keep it from being recycled, it
only prevents further data from being written to it.

nsrim handles aging of save set and volume records within the media database, and is
responsible for enforcing retention times for all clients. nsrim also removes tracking
information from the CFI when a save set passes the retention period. The nsrim command
is invoked automatically once a day when the Server backup workflow runs. However, you
can also run nsrim manually from the command line.
nsrim syntax:
nsrim [ -option arg ] [ -option ]
Note: See the nsrim(1m) man page or the NetWorker Command Reference Guide for more
information.

You can use nsrmm to change an existing save set browse or retention time, using -w
browse_time and -e retention_time, respectively. Using these options sets the save set
ssbrowse and ssretent fields in the media database, which are used by nsrim for aging of
the save set. Changing an existing save set’s browse and retention times is useful for
extending or shortening the life cycle of a specific save set.
nsrmm syntax pertaining to browse and retention times:

nsrmm [ -w browse_time ] [ -e retention_time ] -S ssid
You can specify browse_time and retention_time in any format described in the
nsr_getdate(3) man page. The time can be an absolute time such as MM/DD/YY, or a time
relative to the current date, such as “2 Months” or “4 years”.
The -S ssid option specifies the save set(s) to modify.
Changing the retention time for a save set changes the dates for all instances of the save
set.
NetWorker uses the retention time value for both the retention and browse times. This is
shown on the slide. Notice that after running the nsrmm command that contains different
values for changing the browse and retention times, the mminfo command shows that the
browse time is still the same as the retention time.
Notes:
Changing a client’s Retention policy attribute does not affect the browse and retention
times of existing save sets.
See the nsrmm(1m) man page and the NetWorker Command Reference Guide for more
information.

You can manually change the status of volumes and save sets by using nsrmm with the -o
mode option.
nsrmm syntax pertaining to the -o mode option:

nsrmm -o mode volume | -S ssid
where mode can be any of the modes listed in the slide. The volume argument is the name
of the volume whose record you want to change.
If a write error occurs when writing to a volume, the volume mode is changed to full to
avoid trying to write additional data to a volume which is possibly damaged. However, if
the error was actually caused by the device, using nsrmm with the notfull argument can be
used to make the volume appendable again.
The -S ssid option is used to change the status of specific save sets. A common use is to
reset the status of a suspect save set after determining that the volume really is not
damaged.
It is important to use caution when manually specifying a volume as recyclable. If the

volume being modified contains browsable or recoverable save sets, the status of those will
not be changed. However, the volume itself will become recyclable and any save sets on
the volume may be recycled when the volume is recycled, regardless of their status.
Note: You must unmount a volume to change its status.

After a backup starts and the NetWorker server determines what pool the save set should
be written to, it is then necessary to determine what volume within that pool to use.
The volume used falls in one of the five categories listed below in order of priority. Each of
these categories requires the volume be available on an appropriate storage node.
1. Mounted, appendable volume from the required pool.

If there is no appendable volume currently mounted, the NetWorker server generates
an alert stating that a volume from the appropriate pool is not immediately available.
The server then continues its search for a volume to use.
2. Unmounted, appendable volume from the required pool.
3. Unmounted, recyclable volume from the required pool.
4. Unmounted, recyclable volume from a different pool. (This is disabled by default.)

If Auto media management is not enabled, the volume request is not cleared from
the Alerts window, and the NetWorker administrator must manually provide a volume
to satisfy the request before the backup can continue. If Auto media management is
enabled, NetWorker looks for one more type of volume, listed below.
5. Unmounted, unlabeled volume.

Any volume without a NetWorker label is considered unlabeled.

This lab covers using NetWorker Administration to remove the oldest save set cycle and
viewing save set details using the Media window.

This lesson covers managing save set and volume records, performing a CFI consistency
check, and restoring NetWorker control data with scanner.

nsrmm can be used to remove information from CFIs and the media database. Combining
the –d and –P options allows you to remove CFI entries of individual save sets or of all save
sets on a volume. Removal of CFI records is commonly referred to as purging.
Using the –d option without –P removes save set and/or volume records from the media
database.
Note: The NetWorker scanner command can be used to restore database information for
save sets and volumes that are inadvertently deleted.

Using the –d option with volume name removes the references to the volume. This
example deletes the volume M00002L5.

You can also manage save set and volume records from the NetWorker Administration
Media window. Choose either Disk Volumes or Tape Volumes in the left pane to display
a list of volumes. Then, right-click a volume to bring up a context menu. From the context
menu, you can perform the same set of media database management tasks as nsrmm.
Change Mode - Allows you to change a volume’s mode to either appendable or

recyclable, or set/unset the secondary mode of read only. This is the same as
nsrmm –o { readonly | notreadonly }.
Set Location - This is discussed on the next page.
Recycle - Allows you to set a volume to manual or automatic recycle. This is the same as
nsrmm -o { manual | notmanual }.
Delete - Allows you to purge CFI entries of all save sets on the volume. You can
additionally
remove the volume record and all the corresponding save set records. This is the
same as nsrmm -dP volume.

Volume records in the media database have a location field that you can use to track the
volume’s location. The location can be a string of up to 64 characters. This field is useful for
tracking volumes which have been removed from the jukebox and for volumes moved
offsite.
If a volume is labeled in a jukebox, the location field is automatically set to the name of
the jukebox. The field can be manually updated using mmlocate or NetWorker
Administration
mmlocate syntax:
mmlocate [ -options ] [ location ]
The location argument specifies what to set the location to or which volumes to manage
based on location. The default (no options/arguments) lists all volumes and their location
values.

You can also specify the physical location of the volume for reference purposes in the
NetWorker Administration interface. Select the Tape volume from the list of volumes.
Right-click the volume in the right pane and select Set Location. The Set Location dialog
box appears. Type the description for the physical location of the volume and click OK.
Here on the slide the example shows the tape volume selected is M00005L5 and the set
location to Moved to the third shelf of cabinet 3.

Use nsrck to check, recover, or remove a client file index. nsrck also cross-checks the
media database with the contents of each CFI. Each time the NetWorker server starts, it
runs nsrck -L 1.
nsrck syntax:
nsrck [ -L level ] [ -options ] [ clientname ]
With no arguments, nsrck performs a level 3 check of all CFIs.
The slide shows the seven levels of consistency checking that nsrck can perform. Each level
incorporates the actions of the lower levels. Level 7 is different from all other levels in that
it is used only for recovery of a CFI.

scanner can perform numerous functions. Before executing scanner, you must load a
volume into a NetWorker device. You then provide the pathname of the device as an
argument to scanner, which is executed on the storage controlling the device.
With no options, scanner reads the entire volume and displays a list of save sets found.
Information displayed includes save set name, SSID, and date and time of the backup.
Additionally any media errors that occur will be reported as well.
The –m option causes scanner to read the entire volume, creating save set records in the
media database for any save sets not currently tracked. If the media database does not
have a volume record for the volume being scanned, a volume record is created.
When the –i option is used, scanner populates the media database with volume and save
set information, just like with –m, but additionally populates the appropriate client file
indexes with file information read from each save set on the volume. This operation can be
very time consuming if there are many save sets with lots of files.
When used in combination with the –i option, –S ssid is used to restrict which save set(s)
the operation is performed on. For example, to populate a CFI with the list of files from
save sets 1289372 and 1236738, located on a volume in device \\.\Tape1, the command
would be:
scanner –i –S 1289372 –S 1236738 \\.\Tape1
To recover the entire media database or an entire CFI, use the nsrdr command. This is
discussed later in this course in the Recovering NMC and NetWorker Servers module.

The following scenario is presented in this slide:
• Use the nsrlogin utility to log in to the NetWorker system and perform operations as
an authenticated user.
• A recent full backup of a save set is not needed because the data was corrupted before
the backup took place. It was written to a file device and needs to be deleted to free up
space. mminfo is used to determine the SSID of the save set.
• nsrmm is used to delete the save set record. Unfortunately, the administrator specifies
the wrong SSID. mminfo is executed again just to verify that the save set is indeed
gone. It is now necessary to rebuild the deleted save set record.

• nsrmm, with no arguments, is used to locate the volume containing the save set. From
the output, it is determined that the volume is already loaded in device C:\Adv_File. If
the volume were in an autochanger, nsrjb would be used instead of nsrmm.
• scanner is used to recreate the media database save set record. The output is
redirected because when the –m option is used, scanner oddly enough generates a
recover stream that is not needed in this situation.
• The administrator runs mminfo to see if the save set is once again being tracked and
discovers that although the save set record is back, the save set is not browsable. The
save set needs to be returned to its original status, which was browsable.
• The administrator can run scanner is again with the –i option to populate the client
file index.

In this lab, you change the status of a save set and the mode of a volume. You will also
change the volume’s recycle policy.

This module focused on NetWorker database management. We discussed how to query and
manage the CFI and media database using NetWorker Administration and various
commands. We also looked at how NetWorker selects volumes for backup.

This module focuses on performing NetWorker recoveries. The various ways of restoring
NetWorker client data, as well as the client roles in each, are explained. Finally the specific
procedures for performing selected file, save set, and directed recoveries are reviewed.

akhan@aayan.com Module: Performing NetWorker Recoveries 1
This lesson covers an introduction to the three types of NetWorker recoveries, how to use the
various NetWorker recovery utilities, and volume and storage node selection for recoveries.

A recovery restores data to its original state at a specific point in time. NetWorker is flexible in
how recoveries are performed while at the same time maintaining necessary security to avoid
recovery of data by non-authorized persons. NetWorker supports restoring one or more individual
files, directories or file systems from NetWorker client backups. The three types of recoveries that
we discuss in this module are: Browsable, Save Set, and Directed.
Recoveries can be categorized by the method used to recover the data. In a Browsable
Recovery, the administrator or user browses and selects the set of files and directories to be
recovered using interfaces that require information from the client file index.
In a Save Set Recovery, data is recovered by selecting a save set.
A Directed Recovery is any recovery in which data that was backed up from one computer is
recovered to another.

Browsable Recoveries are the most flexible and easy to use method of recovering data.
Consider using a browsable recovery when you want to recover only the files that you mark for
recovery and no other files. Also, when you don’t know the exact name of a file, the file can be
located by browsing through the file system. When recovering an entire directory or file system, a
point-in-time recovery is automatically performed. This restores the directory or file system to the
way it looked as of the most recent backup. Because of the point-in-time feature, browsable
recoveries are useful when the most recent backup is not a full backup and files have been
deleted or renamed since the full backup. The recovery will not restore a file that has been
deleted and will recover a renamed file only with its current name.
A Save Set Recovery can be performed at any time for any save set. By default, an entire save
set is recovered. However, you can recover individual files and directories. A save set recovery is
commonly done:
• When the last backup was a full backup and you want to recover the entire save set.
• When a large number of files are being recovered from a single save set. If a save set has
millions of files, the process of marking each file for recovery during a browsable recovery
can take a considerable amount of time. A save set recovery does not require marking each
file and thus can lead to faster file recovery.

In any recovery, there are three client roles - administering client, source client, and destination
client - that are performed by one or more NetWorker hosts.
Following is a description of the three client roles in a recovery:

• Source client: The NetWorker client from which the data being recovered was originally
backed up.
• Destination client: The NetWorker client to which the data is being recovered.
• Administering client: The NetWorker client (local host) performing the recovery.
The most common recovery is where a single NetWorker client performs all three roles. For
example, you might be logged in on hostA (administering client), recovering data previously
backed up from hostA (source client), to its original location on hostA (destination client).
Another example of a common recovery is initiating a recovery of a remote client’s files from a
central administering client. For example, the administrator may perform a recovery from HostB
(administering client) of a file backed up from HostA (source client) to HostA (destination client).

When a single client performs all three client roles in a recovery, there are no security issues; a
client’s data can always be recovered back to the client.
The user on the client must belong to a NetWorker user group that has the Recover Local Data
privilege (members of the NetWorker Administrators and Users user groups automatically have
this privilege). The user also must have operating system ownership of the files being recovered
and have write privileges to the directories where the data is recovered.

With the Recover wizard you can schedule the recovery to be performed automatically at a later
time. The Recover wizard allows you to perform most NetWorker recoveries through the
NetWorker Administration without having to log into the client or any other application. The
Recover wizard is the preferred way of performing a recovery, however, the other utilities are
available if needed.
For Microsoft Windows clients, recoveries can be performed using the NetWorker User graphical
user interface on the NetWorker client. Select NetWorker User from Windows > Apps by
name.
Recoveries may also be performed from the command line by using the command, recover, on
any NetWorker client. This option is available for all platforms.

To restore a client’s data using NetWorker User:
1. Select the type of recovery that you want to perform.
2. From the Operation menu select Recover/Directed Recovery to run a browsable recovery;
3. Select the type of recovery. Select Save Set Recovery to perform a save set recovery. You
are then prompted for the source client whose data you will restore. The Source Client
window only contains clients for which the administering client has remote access privileges.
4. When performing a browsable recovery, you are prompted for the destination client. This is
the same as the source host unless you are performing a directed recovery.
5. After selecting the data to be recovered (either by file or by save set selection), click Start
(green lightening-bolt) to begin the recovery.

The NetWorker recover command is available on all NetWorker clients. The recover command
runs in either of two modes; interactive (default mode) or non-interactive (-a option). Interactive
mode allows you to use subcommands in a shell-like environment. With the subcommands, you
can navigate the CFI, mark files for recovery, and perform most of the functions available when
using NetWorker User or NetWorker Administration Recover.
recover(1m) syntax:
recover [ -options ] [ pathname ... ]
recover automatically assumes the source client is the same as the administering client. To
specify a different source client, use the –c option. If the administering client is configured as a
NetWorker client in multiple data zones, you can use the –s option to specify the NetWorker
server that will control the recovery.
The pathname argument is either the path to set as the initial working directory for browsing
(interactive mode) or, if the -a option is used (non-interactive mode), the path(s) to recover. The
default initial working directory is the current directory.
Note: See the EMC NetWorker Command Reference Guide for more information including a
description of the command options and subcommands.

By default, NetWorker recovers data by attempting to return a file to its original folder using its
original file name. However, if another file with the same name already exists in the folder, a file
naming conflict occurs. NetWorker prompts you for how to resolve the conflict. The choices are:
• Rename the file being recovered: The existing file is untouched and the file being
recovered is recovered to the same folder, but with a different file name. By default, a tilde
(~) is placed in front of the original name, but when prompted, you can specify any name
you like. If another file with a name of ~filename already exists, an additional tilde is pre-
pended to the new name. As many tildes will be added as is necessary to make the filename
unique.
• Discard the file being recovered: The existing file is untouched and the recovered file is
discarded.
• Overwrite the existing file: The existing file is deleted and replaced by the recovered file.
Alternatively, you can choose to relocate the recovered data to a different directory. The folder
you specify in the Relocate recovered data to field will be created if it does not exist.
Subfolders are created as necessary to retain the folder hierarchy that existed when the files were
backed up. There may be times when you want to recover a set of files to a location other than
the folder from which they were backed up. Relocating recovered files is useful for comparing an
existing set of files with the same set of files that were previously backed up.
Note: In NetWorker User, you can select the action to be performed when a file naming conflict
occurs prior to beginning the recovery.

After making a selection of the data to be recovered, users can view a list of the volumes needed
to recover the data marked for recovery. If a volume is currently mounted, the device on which
it is mounted is also displayed.

You can monitor the recovery in the Status window which opens as soon as the recovery begins
when using NetWorker User and NetWorker Recover.
Important: Do not close the Status window until a recover completion message is displayed.
Prematurely closing the window aborts the recovery.
When running the recover command, information about each file in the recovery can be
displayed by using the verbose subcommand.

Where there is potentially more than one volume for recovery, the highest priority is given to the
volume containing a complete, non-suspect save set status. If all volumes still have equal priority,
then priority is given to the volume that is mounted. If all the volumes are mounted, then priority
is given according to media type, with AFTD having top priority. Next in priority is location, with
highest priority given to volumes in a library.
Note: Save set status can be changed with options available in the NetWorker Administration
Media window and with the nsrmm command.

When a recovery is initiated, the NetWorker server selects the storage node to read the volume(s)
based on the following prioritized criteria:
Priority Criteria
#
1 If the volume to be read is already mounted on a device, the storage node
controlling that device
2 The first storage node listed in the Recover storage nodes attribute of the
NetWorker client resource that is being recovered having access to the
required volume.
3 The first storage node listed in the Storage nodes attribute of the NetWorker
client resource that is being recovered having access to the required volume
4 The storage node listed in the Read hostname attribute of the jukebox
resource, or if this is empty, storage nodes on which a device in the library is
configured
The Read hostname attribute in the Configuration tab of the jukebox resource specifies the
storage node to use for recoveries and cloning if a client’s preferred storage nodes are not
available. The default value of this attribute is the hostname of the storage node controlling the
first drive in the library.

The Recover wizard in NetWorker Administration provides a NetWorker datazone with a
centralized recovery method. The wizard supports browsable, save set and directed recoveries.
The wizard does not support cross-platform recoveries. With the Recover wizard, you can create
and save a recover configuration that you can reuse, schedule and modify later.

Select the source host, destination host and the recovery type. Before starting the recovery
wizard ensure that the destination host is a client of the NetWorker server and is running
NetWorker 8.1 or later software. For a directed recovery, the Remote Access attribute of the
source client must contain the host name of the destination client.

Clicking Browse provides you with the ability to browse for the files and directories to perform a
file selection recovery from a specific date and time. You select the specific files or directories for
recovery. You have the option to restore to the original path or specify a new destination path.

The Obtain the Volume Information window enables you to determine how the recovery wizard
selects the volumes that will be used for the recovery. You can choose to either allow NetWorker
to select the volume or to select the volumes to be used.
After providing a name for the recovery, you can choose to either start the recovery now or
schedule the recovery to start at a later time.

You can monitor the recovery results in the Check the Recovery Results window from the
Recover wizard through to the recover completion time. NetWorker also stores the recovery log
file in the …nsr\logs\recover directory.

This lesson covers performing recoveries by file selection including recovering as of a specific
point-in-time and using NetWorker interfaces to perform recovery by file selection.

A browsable recovery can only be performed on a browsable save set. Any user is able to perform
a browsable recovery. However, only those files for which the user has read permission can be
recovered. During a recovery, the user selects the set of files and directories to be recovered.
When recovering an entire directory or file system, a point-in-time recovery is automatically
performed. This restores the directory or file system to the way it looked as of the most recent
backup.

If the recover program determines that multiple save sets (a full and its dependent save
sets) are required for the recovery, it uses the CFI to determine if any files were deleted
in the time between the most recent full backup and the most recent non-full backup.
These deleted files are not recovered. Likewise, the CFI is used to determine if a file was
renamed since the most recent full backup. If it was, the file will be recovered only with
its most recent name.
By default, a browsable recovery restores data as of the most recent backup. A
browsable recovery can also be performed to restore data as of a date in the past.

A file selection recovery method, or browsable recovery, inspects the client file index that
NetWorker creates for the source host, to gather information about backups. When the recovery
process reviews entries in the client file index, you can browse the backup data and select the
files and directories to recover.
In a browsable recovery, the recovery wizard shows a representation of a client’s directory
structure as it existed at a specific point in time. This representation is generated from the
contents of the client’s CFI and can be browsed much the same way you would traverse a file
system in Windows Explorer. However, the difference is, for a recovery, you are viewing the
contents of the CFI and not the files residing on disk.

It is possible to recover a version of a file other than the most recent version.
1. Highlight the file you want to recover.
2. Select Versions from the recover configuration menu and NetWorker displays all versions of
the file.
3. One or more versions of a file can be selected for recovery.

The set of files displayed within a recovery utility is determined by the recovery browse time.
By default, the browse time is the current date and time. Based on the CFI contents from the
most recent full backup and subsequent level and incremental backups, NetWorker is able to
determine what the directory structure on disk looks like as of the most recent backup. That
directory structure is what you are presented with in the recovery interface. If you mark and
recover all files that are displayed, your computer will be restored to how it was at the time of the
last backup.

You can change the browse time to a date in the past, causing the NetWorker recovery interface
to display (and recover) only files backed up prior to the browse time. Marking a file for recovery
automatically selects the most recent version of the file backed up prior to the browse time.
You might want to change the browse time if you need to:
• Retrieve an old version of multiple files
• Retrieve an old version of an entire directory, file system, or client
• Look for a file that is still browsable but is not displayed in the GUI
This can happen if the file was deleted prior to the most recent full backup.
Changing the browse time is an option in all NetWorker recovery interfaces. In the NetWorker
Recover wizard, the option is found in the Versions menu and Change Browse Time is
displayed to change the browse time.
Important: If you need to recover files from different points in time, either use the Versions
option for each file or perform multiple recoveries with different browse times.

The Search feature allows you to locate a file or directory by typing its name. This feature is
particularly useful in situations where:
• You do not know which directory contains the file you want to recover.
• You want to recover a file that is still browsable but was deleted from disk before the last
full backup. Recall that the recovery interfaces support point-in-time recovery by
displaying only those files it believes were on disk as of the most recent backup.
Search is an option in the Select the Data to Recover window. When specifying the file or
directory to locate, the wildcards ‘*’ (match zero or more occurrences of any character) and ‘?’
(match any one character) are allowed. The search is not case-sensitive. The search begins with
the highlighted folder or specified directory and descends into its subfolders. Files and directories
matching the search criteria are displayed and can be selected for recovery.

With recover, the default method of recovery is by file selection. In the example on the left of the
slide, the files in the /windows/fonts directory are being recovered. The add command is used
to add the current version of the file to the recovery list.
In the example on the right, the versions command is used to determine that a previous version
of the file, Config.xml, was backed up on Oct 29. To recover that version of the file, the
changetime command is used to change the browse time to a time afternoon of Oct 29 making
the backup on Oct 29 the most current version prior to the new browse time. After adding that
version of the file to the recovery list, the list command is used to verify that it was added.
Note: See the NetWorker Command Reference Guide for more information including a description
of the command options and subcommands.

This lesson covers save set recoveries including recovering to a specific point in time and using
the features of the NetWorker interfaces to perform save set recoveries.

A save set recovery can be performed for any save set. System administrator privileges are
required to perform a save set recovery.
One or more save sets are specified during the recovery. Although the default behavior is that
each save set is entirely recovered, you can specify a set of individual files or directories to be
recovered instead.
Since a save set recovery does not utilize CFI information, it does not perform a point-in-time
recovery.

The ability to automatically recover to a point-in-time is not supported using a save set recovery.
Let’s assume that save sets backed up on Days 1-6 were browsable for only one month. Now, on
Day 36, none of those save sets are browsable and you want to recover the file system to the way
it looked after the incremental backup on Day 6. The following steps must be performed:
1. Recover the Day 1 Full save set.
2. Recover the Day 5 Cumulative incremental save set.
3. Recover the Day 6 incremental.
If no files were deleted or renamed between Day 1 and Day 6, the file system is now fully and
accurately recovered. However, if deletions occurred, files which didn’t exist on Day 6 were
recovered in the Day 1 or Day 5 recoveries. Additionally, if a file was renamed, it will now exist
under both its original and new names. For the recovered file system to accurately reflect the Day
6 file system, you must determine which deletions and renames occurred and manually perform
them again.

The number of full and incremental save sets needed for recovery depends on the schedule
(backup levels) used immediately prior to the point in time you wish to recover the data.
To identify the save sets you need for a save set recovery:
1. Identify the most recent full backup of the save set.
2. Identify the most recent cumulative incremental backup of the save set.
3. Identify all the incremental backups that was performed after the most recent cumulative
incremental backup until you reach the desired point in time.
In the example shown on the slide, a recovery is performed after Day 7’s backup. To perform the
recovery, you need the Full save set from Day 1, the cumulative incremental save set from Day 4
and the incremental save sets from Days 5, 6, and 7.

A save set recovery does not reference the client file index where deleting and renaming of files is
recorded. This leads to the following behavior:
• Directories and files deleted during the backup cycle are recovered.
• Directories and files renamed during the backup cycle are recovered multiple times, once for
each name by which they were known.
When you have recovered the last save set required to restore your data to a specific point in
time, you may need to perform additional file handling. This could include deleting files and
directories that were deleted during the backup cycle and renaming files that were renamed
during the backup cycle.

From NetWorker Administration select Recover from the menu bar and then select New
Recover. In the Select the Recovery Hosts screen specify the source host name and
destination host name, if different.

When performing a save set recovery, the recovery wizard displays a list of save set names
backed up from the client. After selecting the save set, all save sets with that name are displayed.
One or more versions may then be marked for recovery.
As with browsable recoveries, you can perform searches and view properties, versions and
volumes for selected items.

Provide the path for recovery and specify options for duplicate file names.
If you want to recover a subset of the save set, select Advanced Options and specify the path of
the directory or file to be recovered in the Extra recover options attribute. Multiple items can be
specified, separated by a space.
In this example, we have selected the save set, C:\Documents in the Select the Data to
Recover window. However, we only want to recover the C:\Documents \Morefiles directory from
that save set. When the recover runs, only the contents of the specified directory are recovered.

Provide a name for the recovery, then verify the configuration and perform the recovery.

To perform a save set recovery with the recover command, use the –S option followed by the
SSID of the save set. Multiple –S options can be used in the same command. A save set recovery
using the command line is always non-interactive.
Note: Before performing the recovery, determine the SSID of the save set to be recovered using
NetWorker Administration or the mminfo command.
See the NetWorker Command Reference Guide for more information including a description of the
command options and subcommands.

This lesson covers the procedures, interfaces and requirements for performing directed recoveries
in NetWorker.

A directed recovery is defined as a recovery in which the data that was backed up from one
computer is recovered to another.
The benefits of performing a directed recovery include being able to:

• Obtain files from a source computer which is inoperable.
• Perform all recoveries from a single NetWorker client in the data zone, thereby providing
central recovery management and control.
• Transfer files from one client to another.

The following access rights are required for directed recoveries:
Recovery must be launched by the root user (UNIX) or Windows Administrator on the host
performing the recovery. This host must be a NetWorker client of the NetWorker server. The user
must have the Remote Access All Clients privilege on the NetWorker server. Note that users in the
Administrators group on the NetWorker server are automatically granted the necessary privileges.
The Remote access attribute in the source client’s client resource must contain the destination
client if the user@destination client does not have the Remote Access All Clients privilege.
The destination client must allow remote execution requests from the administering client.
Remote execution is performed by nsrexecd. Remote execution privileges are controlled by the
following methods:
– The /nsr/res/servers file on the destination client lists the hosts authorized to make
remote execution requests.
– nsrexecd on the destination client can use the –s option to specify a host authorized to
make remote execution requests. If this option is used, the /nsr/res/servers file is
ignored.
– Optionally, the Disable directed recover attribute can be set to yes in a NetWorker
client’s resource database, /nsr/res/nsrladb. This disallows directed recoveries from
any remote host. (nsradmin –d /nsr/res/nsrladb)

The source and destination clients must be of the same platform type. You can perform directed
recoveries between UNIX NetWorker clients and between Windows NetWorker clients. You cannot
recover data backed up from UNIX clients to non-UNIX clients, and vice versa. The administering
host may be a different platform type from the other clients.
Additionally, you may not be able to recover files between dissimilar file system formats. For
example, you cannot recover data from an NTFS file system on a Windows client to a FAT file
system because of the way file permissions are handled. However, files from a FAT file system can
be recovered to an NTFS file system because there are no permissions in a FAT file system; NTFS
gives recovered files the permissions of the directory they are recovered to.
Note: SYSTEM and VSS SYSTEM save sets cannot be recovered using a directed recovery.

To perform a directed recovery using the Recover wizard, first select the source and destination
clients. In the slide, nw.emc.edu is the administering client, win-client.emc.edu is the source
client and nw.emc.edu is selected as the destination client.
Only clients for which nw.emc.edu has remote access privileges are displayed in the client
selection windows.

After you have selected the source and destination clients, the contents of the source client’s CFI
is displayed, allowing you to browse and mark files for recovery in the exact same manner as in a
normal browsable recovery.
Upon initiating the actual recovery, the administering client contacts nsrexecd on the destination
client and requests that it execute recover with the list of files provided.

To perform a directed recovery using NetWorker User, perform a browsable recovery. First select
the source and destination clients. In the slide, nw.emc.edu is the administering client, win-
client.emc.edu is the source client and nw.emc.edu is selected as the destination client.
Only clients for which nw.emc.edu has remote access privileges are displayed in the client
selection windows.
After you have selected the source and destination clients, the contents of the source client’s CFI
is displayed, allowing you to browse and mark files for recovery in the exact same manner as in a
normal browsable recovery.
Upon initiating the actual recovery, the administering client contacts nsrexecd on the destination
client and requests that it execute recover with the list of files provided.

Directed recoveries can also be performed using the recover command.
The -c client option specifies the source client and the -R client option specifies the
destination client. The required -i [YNR] option specifies what the destination client should do in
response to file naming conflicts:
-iN the file is not recovered if a conflict occurs
-iY the existing file is overwritten when a conflict occurs
-iR renames the file when a conflict occurs; .R is appended to each recovered file name in
UNIX/Linux; ~ is placed in front of file name in Windows
As an example of a directed, browsable recovery, the following command is executed from

nw.emc.edu and recovers files backed up from win-client.emc.edu to the client nw.emc.edu,
overwriting existing files:
recover -c win-client.emc.edu -R nw.emc.edu –iY
To perform a directed save set recovery using recover, use this command format:
recover –s nw_server –R destination_client –i{NYR} –S ssid

This lesson covers snapshot recoveries including privileges and platform requirements, and using
the features of the NetWorker interfaces to perform directed recoveries.

There are three recovery types available from a snapshot backup. They are snapshot, rollover and
rollback recoveries. Fast and easy recovery is another benefit for NSM.
Snapshot Recovery: A snapshot saveset is mounted giving the administrator the ability to
browse and select directories or individual files to restore.
Rollover: A conventional NetWorker restore is performed from the backup storage media. You
can also recover from the snapshot, either full or partial. If the data was rolled over to backup
media. In short , whatever you can do with a NetWorker created backup to media, you can do
with an NSM generated backup to media.
Rollback: The snapshot is restored by using the storage array capabilities. A volume on the
application host is unmounted and the rollback replaces the entire content of the unmounted
volume. You can perform a rollback, which reverts the entire disk to state to the time of the
snapshot. This is done at the array-level.
For example file systems E:\, F:\, and G:\ live on LUN 02E. Rolling back G will restore everything
on LUN 02E including E:\ and F:\.The recovery from snapshot management includes the ability to
perform a rollback which will overwrite the original data , as well as mount the save set from
browse and recovery.
NetWorker supports three types of user interfaces for snapshot recovery operations
• NMC Recover wizard
• nsrsnapadmin command utility
• nsrsnap_recover command
Note: NetWorker does not support rollbacks on RecoverPoint appliance. Rollbacks destroys all
previously existing data on the source appliance volume.

NetWorker Recover wizard provide a GUI-based recovery workflow. When a client is selected, if
NSM is detected, the recover UI detects all available snapshots and save sets, and choices and
visibilities related to recovering the data. When the actual recover takes place, nsrsnap recover is
invoked, using the values collected by the wizard.
The wizard supports snapshot recovers, rollover, standard media recoveries. The progress is
visible in both the Wizard and the NMC Monitoring interface. Operations are also logged to the
standard recovery logs.

You can use the Recover wizard in NetWorker Administration to restore file system data from a
snapshot stored on a supported array.
Select the Filesystem (Snapshot) recovery type from Available Recovery Types.

The window provides you with the ability to browse the snapshots to recover. Mount the save set
for recovery and select the storage node. Then, choose the destination for the recovery.

When performing a rollback snapshot, you see a warning that a rollback is a destructive
operation.

This lab includes performing a file recovery, a save set recovery, and a scheduled recovery
operation.

This module focused on performing NetWorker recoveries. The various ways of restoring
NetWorker client data, as well as the client roles in each were explained. The specific procedures
for performing selected file, save set, and directed recoveries were reviewed.

This module focuses on cloning and staging in a NetWorker environment. Specifically the
cloning and staging processes are reviewed, as well as the procedures for configuring and
running both.

akhan@aayan.com Module: Performing Cloning and Staging 1
This lesson covers the procedures for performing cloning in the NetWorker environment
including configuring automatic, or scheduled, and manual clone operations.

NetWorker provides the ability to further manage and protect save sets and volumes
through the use of cloning and staging. Cloning copies save sets to another volume
belonging to a clone pool while staging moves save sets to another volume.

Cloning allows you to create identical copies of save sets to be used in case of damage to
the original media or for offsite storage.
Clone operations use the Recover Pipe to Save (RPS) method to clone data. With this
method, the existing NetWorker backup and recover framework is used to replicate the data
from source to destination. Clone performs a save set recover operation on the source and
stores data in a buffer. Then, a save thread consumes the data and performs a save
operation onto the destination. You can clone save sets either manually or automatically.
Nsrclone,running on the NetWorker server, initiates the clone operation and spawns
nsrrecopy on the source storage node. Data movement is performed by the nsrrecopy
binary on the source storage node. There are two threads for nsrrecopy: one for read
and one for write. One nsrrecopy is spawned per volume and multiple volumes of save
sets can be cloned in parallel.
Two devices are required for cloning. Save sets are always completely cloned. Thus, if a
save set begins on one volume and continues (spans) onto one or more additional volumes,
each of the source volumes will be mounted and read during the clone operation.
Conversely, if the destination volume becomes full during a clone operation, another
volume from the same pool must be made available for the cloning to continue. Concurrent
clone, backup, and recovery operations can be performed on the same device at the same
time when using advanced file type or Data Domain devices.
No volume may contain more than one instance (copy) of a save set. This eliminates the
possibility of losing multiple instances of a save set if a single volume becomes damaged.
Since backup data cannot be mixed with clone data on a volume, it is required that the
destination volume belong to a clone pool.

There are two ways to clone save sets using policies and workflows:
• You can configure cloning to occur in the same workflow as a backup action (backup and
clone workflow). In this configuration, you create a workflow with a backup action and a
clone action. The clone action can occur after the backup action or concurrently with the
backup action. There can be a single clone action or multiple clone actions.
• You can configure cloning to occur in a workflow apart from the backup action (clone-
only workflow). In this configuration, you create a group for save set selection and
specify that group and a clone action in the clone-only workflow. There can be multiple
clone actions in the workflow. This is useful if you want the clone operations to occur at
different times from backup operations.

This is a view of a backup and clone workflow in a policy called Standard Filesystem. In this
example, the workflow is configured with two actions, a backup action followed by a clone
action. Backup data is written to the pool specified in the backup action. After the backup
completes, the data is cloned to the pool specified in the clone action.

The slide shows the workflow properties for our backup and clone workflow example. Here
you can see that the backup action is followed by a clone action.

When creating a clone action that is a member of a backup and clone workflow, you specify
the action name and action type of Clone for Action Information. For Clone Options,
specify the destination storage node, the destination pool, which is a clone-type pool, and
retention for the clone save sets. You can choose to delete the source save sets after the
clone operation completes. You can also filter the input data to the clone by time, save set,
clients and backup level.

In the example shown here, we have created two clone-only workflows in the Clone Only
policy. To configure a clone-only workflow, you first create a save set group where you
specify either the selection criteria or the IDs of the save sets to be cloned. Then, you
associate the group with a workflow that contains a clone action.

There are two types of protection groups that can be used to clone the save sets in clone-
only workflows. With these groups, you specify the save sets to be cloned. The type of
protection group that you use depends on the way why you are configuring the workflow.
Save Set Query group - Use a Save Set Query group in clone-only workflows where you
want to clone save sets on an ongoing basis, based on save set criteria.
Save Set ID List group – Use a save set group in clone-only workflows where you want to
clone a specific list of save sets. Specify the save set ID/cloneID (ssid/clonid) identifiers.

The slide shows the workflow properties for the Clone with List of Save Sets clone-only
workflow example. Here you can see that we have associated this workflow with the Save
set group. There is only one clone action in the workflow. When the workflow runs, the save
set specified in the protection group will be cloned.

When creating a clone action that is a member of a clone-only workflow, you specify the
action name and action type of Clone for Action Information. For Clone Options, specify
the source and destination storage nodes, the destination pool, which is a clone-type pool,
and retention for the clone save sets. You can choose to delete the source save sets after
the clone operation completes.

The nsrclone command is used to perform manual clone operations.
When the –S option is used, a list of save set IDs must be specified. If the –S option is not
used, arguments following any options must be NetWorker volume names.
nsrclone(1m) syntax:
nsrclone [options] -S ssid ... | volume ...
where ssid is a save set to clone; volume is a volume containing save sets to clone. Note
that ssid/cloneid may also be used to specify which save set with multiple copies to use as a
source. Additional information including a full list of the command options can be found in
the NetWorker Command Reference Guide, or the NetWorker Cloning Integration Guide.
Note: The nsrclone command requires specific privileges based on session authentication.
Use the nsrlogin command to authenticate a user and generate a token for the nsrclone
and mminfo commands.

Once the clone operation is complete, validate that the save sets are cloned. The save sets
now are available on two volumes.

When cloning a volume, it is not a byte-by-byte copy. Only save sets that begin on the
volume are cloned. If a save set begins on the volume and spans to one or more additional
volumes, each of those volumes will be mounted and read. Thus, to clone a volume really
means to clone, in their entirety, all save sets beginning on the volume.
Multiple volumes can be specified on the command-line. The -f option of the nsrclone
command can be used to specify a file (or standard input) containing a list of volumes to
clone. When using an input file, each volume must be on a line by itself.
Note: The first flag associated with a save set indicates which part of the save set is stored
on a volume. This flag can be displayed with the mminfo -v command and is also displayed
when viewing the save sets for a volume in the Volume Save Sets window in NetWorker
Administration Media. Values for the first flag are:
• c: Save set is completely contained on this volume.
• h: Save set spans volumes and the head is contained on this volume.
• m: Save set spans volumes and a middle section is contained on this volume.
• t: The tail section of a spanning save set is contained on this volume.

The –t start_time option causes nsrclone to automatically determine which save sets have
been backed up since start_time (based upon the savetime value) and clone them.
start_time can be specified using any nsr_getdate(3) format. By default, all save sets
backed up since start_time are cloned. To specify a time range, the –e end_time option
can be used to specify the end time of the range. If -e end_time is used, the default value
of start_time is end_time – 24 hours.
Options -c client_name, -C less_than_copies_in_pool, -g group_name, -l level can be used

with the -t or -e option to extend save set selection capabilities. Also, -N saveset_name
allows for selection on save set name.
Examples
• Clone all save sets backed up since 1:00 a.m. this morning:
nsrclone –S –t “01:00”
• Clone all save sets backed up in the last 24 hours with backup level full and group
Default:
nsrclone -S –e now -l full -g Default (now is a valid nsr_getdate format)
• Clone all save sets backed up between 9:00 p.m. yesterday and 8:00 a.m. this morning:
nsrclone –S -t “yesterday 21:00” –e “08:00”

Each instance of a save set has its own clone browse and retention time which is tracked in
the save set record of the media database. Browse and retention times for clone data can
be extended beyond that of the original save set, enabling browsing and recovery of clone
data after the original save sets have expired.
You can specify a retention policy value for the clone save set that differs from the value
that is defined for the original save set. When the retention policy differs for the original
and clone save set, you can expire the original save set and reclaim the space on the
source AFTD but maintain the data on a clone volume for future recoveries.
If the clone instance is written to a pool having a retention policy, the retention time of that
save set instance is determined by the pool’s retention policy instead of the client’s
retention policy. A different clone retention time can also be set using the –y retent_time
option with nsrclone and with the nsrmm -e command. Setting the clone’s retention to a
longer period than the client’s retention allows the clone to remain recoverable even after
the original backup is no longer retained. Note that retention specified from the command
line overrides the retention policy for the clone pool.
The browse period for a clone can be extended with the -w option of nsrclone when creating
a clone save set. Note that the browse period is left unchanged if the save set’s browse
date is later or if the new time has already passed. This option requires the -y retention
option and must not be greater than the retention time.
Important: The date on which a volume becomes recyclable is determined by the clone
retention times of save set instances on the volume, not by the save set retention times.
For example, if 10/17/16 was the longest save set retention time on a volume and the
longest clone retention time on the volume was 1/1/2016, the volume would not become
recyclable until 1/1/17.

The slide shows how to set the Retention policy attribute in the pool resource. When
creating a backup clone pool, it is necessary to deselect the Store index entries attribute.
This is because duplicate CFI entries cannot be created during a clone operation.

With the NetWorker Cloud Backup Option, copies of backup data can be stored on internet-
based storage as an alternative to sending tapes offsite. This provides a tape-less offsite
storage solution, eliminating the complex requirements of managing tapes.
Cloning backup data to a cloud complements backing up to disk. In the example shown on
the slide, backups are first written to disk. Then, the backup data is cloned to a volume on
an CloudBoost appliance. The original backup data is retained on disk only as long as
required for short term recovery operations. Data on cloud storage is retained for a longer
period of time according to business requirements for long term/offsite storage.

Reporting on clone operations can be achieved through the reports available in NetWorker
Management Console. The Policy Statistics report category provides you with the ability to
create reports that contain details and summary information about data protection policies,
some of which are listed here. The category includes both basic and drill down reports.
Here, we see a Policy Summary report showing the clone count and clone size for the
Backup and Clone policy.

This lesson covers clone controlled replication.

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 a source or
target of cloning. You can also clone from a Data Domain device to tape or to any other device
type.
Data that is cloned from one Data Domain device to a target Data Domain device, typically at a
remote location, retains its deduplication format and is known as clone controlled replication
(CCR) or as an optimized clone.
Clone controlled replication uses the native Data Domain replication feature to copy data from
one Data Domain system to another. 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. For clone controlled replication, clone employs intelligence
when creating groups to clone so that all threads are equally balanced. It uses fast copy
instead of file copy for replication within the same Data Domain device.
The clone is created quickly and uses low bandwidth and low storage capacity. A clone that is
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.

This slide shows configuration requirements that must be in place in order to perform a
clone controlled replication. Ensure that the storage nodes for both source and target Data
Domain devices are clients of the same NetWorker server. The Data Domain systems must
be properly licensed for DD Boost and replication. The Alias attribute of the client resource
for the storage nodes and the NetWorker server must include the names in use for the
hosts.

CCR cloning in NetWorker employs logic to group save sets for cloning based on threshold
value using the parameters and default values shown here. At a high level, this is what is
involved in the grouping of save sets:
First, an estimate of overhead for save sets is determined. This is the amount of time for
processing the save sets to include both computational and data transfer overhead. Then, if
the total save set overhead is small (< max thread*threshold), the initial parallelism is
increased so the job finishes within a short period of time. If total save set overhead is
large (> max thread*threshold), the default initial parallelism is used.
Default settings can be modified by changing these environment variables as follows:

• NSR_CLCP_NET_OH (Network overhead) “LOW”, “MED”, “HIGH”
• NSR_CLCP_SS_OH (Save set overhead) VALUE IN SECONDS
• NSR_CLCP_TH (Group threshold) VALUE IN SECONDS
• NSR_CLCP_MIN_CONCURRENCY (Min thread count)
• NSR_CLCP_MAX_CONCURRENCY(Max thread count)
You can also fine-tune the load balancing parameters through the use of a file
/nsr/debug/update_rps_ccr_env. In this file, you can specify the following variables:
• Network=LOW|MED|HIGH (Default = MED)
• Computation=integer (<=30) (Default = 2)
• Threshold=integer (<30*60) (Default = 10 * 60)

A target Data Domain device for CCR is labeled into a backup clone pool.

This lesson covers the procedures for configuring automatic and manual staging of data in
NetWorker.

Staging a save set moves it from one storage volume to another.
Like cloning, staging requires two devices, one or more source volumes, and one or more
destination volumes.
When a save set is staged, it is actually cloned, resulting in an additional instance (copy) of
the save set being tracked in the media database save set record. Upon successful
completion of the clone operation, the information pertaining to the original instance (copy)
of the save set is removed from the save set record.
If the save set being staged is on tape, it remains on the tape until the tape is relabeled. If
the save set being staged is on a file or adv_file type device, it is immediately deleted from
the device/volume (directory).
Unlike cloning, destination volumes do not have to belong to a clone pool.
Staging is often used to move save sets from file and adv_file devices to long term media
such as tape. This allows the most recent backups to be written to and recovered from disk,
then moved to tape to free space for subsequent backups. Staging is also used to remove
non-recyclable save sets from an otherwise recyclable volume.

nsrstage is the command line utility used to stage save sets.
nsrstage syntax:
nsrstage [ -options ] -m -S ssid[/cloneid ] ...
-m is a required option to stage (move) save sets and -S ssid specifies which save set(s)
to stage. The optional /cloneid is for save sets with more than one instance (copy), to
identify the instance of the save set to stage. If an instance is not specified, all instances
except for the staged copy are deleted from the media database.
Note: See the NetWorker Command Reference Guide for more information and specific
command options..

A NetWorker stage resource is used to monitor selected file and adv_file type devices and
to automatically stage save sets from the device’s volume to other media when the volume
becomes too full.
Automatic save set staging is designed to move data from file/adv_file type devices to tape.
Staging allows you to perform backups to disk, potentially maximizing backup performance,
and later move the save sets to tape.
Staging prevents the file/adv_file type device from becoming full by periodically checking
the following:
• How long each save set has been on the file type device - Save sets are staged
after a specified number of days or hours, regardless of how full the volume (file
system) is.
• The percentage fullness of the file system on which the file/adv_file type
device directory resides - Save sets are staged when the file system reaches a
certain percentage of utilization (the high water mark), regardless of a save set’s age.
Once staging begins, it continues until the file system utilization has decreased to the
specified low water mark.

A NetWorker stage resource is used to monitor and manage selected disk type devices.
There is one preconfigured stage resource, default stage, having the default attribute
values shown in the slide.

The Operations tab of the stage resource allows you to perform manual staging. After
selecting and performing any of the operations, the Start now attribute is returned to a
null value.
Choose Recover space to immediately perform a recover space operation.
Select check file system to perform an immediate check of the fullness of the file
system(s) to determine whether the high-water mark has been reached, thereby requiring
automatic staging.
After selecting stage all save sets and clicking OK, all save sets residing on all devices
managed by the stage resource will be staged.

In this lab, you configure a backup and clone workflow and an automatic staging resource.

This module focused on cloning and staging in a NetWorker environment. Specifically the
cloning and staging processes were reviewed, as well as the procedures for configuring and
running both.

This module focuses on the security features of NetWorker. It covers authenticating
users with the NetWorker Authentication Service, AuthC. We look at managing
external and local users and NetWorker user groups, the various types of
NetWorker logs and how to configure NetWorker in a firewall environment.

akhan@aayan.com Module: NetWorker Security 1
This lesson introduces the various types of NetWorker security features, including access
control, secure communications, logs and audit features, and data security. We examine in
more detail how to use encryption for backup data.

Security is an important component of NetWorker and is accomplished in a number of ways.
The access control features of NetWorker enable authenticated users to perform secure
administrative functions, and backup and recovery operations.
NetWorker provides logs that record the sequence of activities for the NetWorker server,
NetWorker Management Console server, and each NetWorker client. Resource update
logging provides for the tracking of all resource changes made on a NetWorker server. This
information is useful for accountability where there are multiple NetWorker administrators,
for security in the event of a system intrusion and for general auditing of modifications.
Auditable security events include authentication attempts, privilege checks and resource
creation and deletion. Multiple systems can send their audit data to the same audit log
server thus providing centralized audit capabilities.
Communication settings ensure secure channels for communication between NetWorker

components and between NetWorker components and external components and systems.
Through the use of user authentication and authorization, NetWorker administrators can
restrict user access to backup data for restores. Security from disclosure of backup data can
also be provided by encrypting data during backup operations. When enabled, data is
encrypted on the client as the save stream is generated.
We review these security features throughout the lessons in this module.

User access to NetWorker servers through the NetWorker Administration window always
comes from the NetWorker Management Console server.
When users log into the NetWorker Management Console server, the user’s credentials are
authenticated using the NetWorker Authentication Service. NetWorker Authentication
Service, or AuthC, provides token-based authentication for NMC and CLI users.
Authenticated users are granted privileges in NMC through the use of specific NMC roles.
Users with appropriate permissions are granted access to NetWorker Administration for
individual NetWorker servers through NMC.
NetWorker server administrators with appropriate privileges can restrict access to

NetWorker Administration functions and resources based on membership of the
authenticated user in various user groups.
In the next lessons of this module, we examine NetWorker authentication and authorization
in detail.

NetWorker hosts and daemons use the nsrauth GSS mechanism to authenticate
components and users, and to verify hosts. The nsrauth authentication mechanism is
enabled by default and is strong authentication based on the secure socket layer protocol
which is provided by the OpenSSL library. Each NetWorker host has a nsrexecd service
which provides authentication services. Each nsrexecd has its own private key and self-
signed certificate for authentication. The private key is generated by nsrexecd when it
starts up or one can be loaded from a file. The corresponding self-signed certificate is
generated by the private key. GSS is required for the following NetWorker functionalities:
client configuration wizard, file system browse from client configuration, and software
distribution.
For compatibility with earlier NetWorker releases, oldauth authentication is supported. If

two hosts cannot authenticate by using strong authentication, you can enable
authentication by using oldauth. You can specify the minimum authentication strength that
is allowed for any host relationship. Refer to the NetWorker Security Configuration Guide
for details on configuring minimum nsrauth authentication strengths.

You can encrypt backup data on Windows and UNIX hosts using the NetWorker aes
Application Specific Module (ASM). The aes ASM provides 256-bit data encryption.
NetWorker uses the Datazone pass phrase attribute in the NetWorker server resource
(NSR) to generate the datazone encryption key that is used during backup and recovery
operations with encryption. When enabling backup encryption, specify a value for the
Datazone pass phrase attribute. If you do not specify a Datazone pass phrase,
NetWorker uses a default pass phrase.
You control access to the pass phrase through the lockbox resource on the NetWorker
server. NetWorker administrators with sufficient privileges can specify a list of users that
have permissions to store, retrieve and delete AES pass phrases. Only users specified in the
lockbox resource can modify the Datazone pass phrase attribute in the NSR resource.

You enable encryption for save set backups by applying the aes directive to the client
resource. Select Encryption directive for the Directive attribute. When this client is
backed up, the save sets will be encrypted.
In this example, when the any backup workflow containing this client runs, the save set is
encrypted during the backup operation.

You can recover aes encrypted data by using the Recovery wizard in NetWorker
Administration, NetWorker User on a Windows host, or the NetWorker recover command.
During a recovery of encrypted backup data, the pass phrase that was used to encrypt the
data must be used to decrypt it for a successful recovery. By default, NetWorker uses the
current value of the Datazone pass phrase attribute to recover the data. If the key
generated from this pass phrase fails, NetWorker uses the key generated from the default
pass phrase. If this fails, NetWorker fails the recovery.
Note: The –p pass-phrase option for the recover command, can be used to specify an
additional pass phrase to use when attempting to recover files backed up using the aes
directive. Using this option causes recover to generate an encryption key from the pass
phrase and try it if the default and current datazone pass phrase keys do not work. This
option can be specified multiple times.

This lesson covers NetWorker authentication using AuthC as well as NMC user roles and
configuring users and hosts in NMC.

NetWorker uses AuthC, the NetWorker Authentication Service, to provide token-based
authentication for NMC and CLI users. Authenticated users can then perform secure
administrative functions and backup and recovery operations.
AuthC is a web-based application installed on each NetWorker server. It supports two types
of users and authentication. For authentication service local users, user names and
passwords are maintained and authenticated using the local AuthC database. Optionally,
AuthC can be configured to also use an LDAP or Active Directory (AD) server for
authentication. With external authentication, user names and passwords are maintained by
the external authority.
The AuthC local database is used to store AuthC configuration information and to verify
credentials for local users. An hierarchical database structure is maintained for users and
groups to support multi-tenant configurations. The AuthC database is backed up by the
default Server Protection policy.

Using the model pictured here, let’s describe at a high level what happens when a user logs
into a NetWorker Management Console server. The NMC server contacts the NetWorker
Authentication Service on the NetWorker server to verify the user credentials. The
NetWorker Authentication Service compares the user credentials with user information
stored in the local user database, or contacts an external authentication authority to verify
the details, if configured to do so. If the user verification succeeds, the NetWorker
Authentication Service generates a token for the user account and sends the token to the
NMC server. The NMC server login succeeds.
Next, the NMC server looks up the user role membership for the user to determine the level
of authorization that the user has on the NMC server. When the user attempts to connect to
a NetWorker server, if the user has the rights to manage the selected NetWorker server,
the NMC server provides the token information about the user to the NetWorker server.
The NetWorker server compares the information contained in the token with contents of the
External roles attribute in each configured user group to determine the authorization level
that the user has on the NetWorker server. NetWorker then allows or denies the user
request.

These are the high-level steps for integrating the NetWorker Authentication Service with
NetWorker.
First, during the NetWorker server installation process, AuthC is installed on every
NetWorker server host. This is done as part of the NetWorker server installation process for
Windows and is a required package for Linux NetWorker server installations. When you
install a NetWorker Management Console server, you specify the name of the NetWorker
server that will authenticate access to the NMC server. For example, if the NMC is managing
more than one NetWorker server, you designate one of the NetWorker servers as the AuthC
authentication host for the NMC.
Next, establish trusts between NetWorker servers if the NMC will be managing more than
one datazone.
Then, configure LDAP or AD authentication, if desired, as well as any local users for NMC.
Assign roles and privileges to the users in NMC and the NetWorker servers.
Finally, log in to NMC with a valid username and password.
We go into more detail for each step in the next several slides.

The NMC server can only use one NetWorker Authentication Service to provide
authentication services. If the NMC server manages more than one NetWorker server, trust
must be established between each managed NetWorker server and the AuthC service that
provides the authentication services to the NMC server. Establishing trust enables users
that are authenticated by the AuthC service on one NetWorker server to access another
NetWorker server.
Trust is established using the nsrauthtrust command. Run the command on the host
where you are adding the trust. The command format is:
nsrauthtrust -H Authentication_service_host –P
Authentication_service_port_number
where: Authentication_service_host is the hostname of the NetWorker server that

authenticates the NMC server host. The default port number is 9090.
Note: When a NetWorker server is on the host that provides the authentication services to
the NMC server, trust is established automatically.

You use NetWorker Management Console and command line tools to configure and manage
authentication and authorization.
Use NetWorker Management Console to create and modify user accounts in the local user
database.
The CLI tools, authc_config and authc_mgmt, are used to configure and manage
authentication and the AuthC database. Uses for the commands include:
Use authc_config on the NetWorker server to configure the NetWorker Authentication

Service to authenticate users by using an external authentication authority, AD or LDAP.
Other operations that can be performed with this command include tenant management,
permission and password policies, token policies, service and user options management,
and service query management.
Use authc_mgmt to manage local database user accounts and groups, local user options
management, and user and group query management. Other operations such as querying
the LDAP or AD directory are also accomplished with this tool.
The NetWorker Security Configuration Guide contains detailed information about configuring
and using authc_config and authc_mgmt.

By default, NetWorker Authentication Service verifies NMC user login credentials using the
local AuthC database. You can also configure NetWorker Authentication to use an external
authority database such as LDAP or AD for authentication, in addition to the local user
database.
Use the authc_config command to configure AuthC for external authentication. The
authc_config command shown here configures the NetWorker Authentication Service to
authenticate users in an AD directory in our lab on a host named, dc, in the domain,
emc.edu.
After configuring authentication with an AD directory with authc_config, use the

authc_mgmt command to confirm that you can successfully query the AD directory.
We use both of these commands in an upcoming lab for this module.

Access to NetWorker Console functionality is implemented through the use of users and
user roles. The role assigned to a user account determines the tasks the user can perform
in Console. The roles cannot be deleted and the privileges of each role cannot be changed.
There are three Console user roles: Console Security Administrator, Console Application
Administrator, and Console User.
When NMC is first launched, the default NMC user account, administrator, and the
authentication server service account are assigned to all three Console user roles.
Notes:
AuthC creates a built-in local administrator account during installation. When you log into
the NMC server for the first time, the wizard creates a service account for the NMC server in
the AuthC database with the format svc_nmc_nmc_servername . The NMC server uses this
account for interprocess communications between the NMC server and a managed
NetWorker server. It is recommended that you do not modify the properties of the service
account.
You can use the GST_RESET_PW environmental variable to reset the administrator
password.

The Console server’s Setup window is used to configure and manage NMC users, including
creating new Console users.
There are two categories of NMC users:
Authentication Service User refers to users that are managed locally by the NetWorker
Authentication Service. You create the user names and maintain the passwords using NMC.
Note that you can also assign NMC roles to local users from the Identity tab.
External Repository User refers to user accounts that are created and maintained, including
password maintenance, by an external authority server when AuthC is configured to use the
external authority for authentication. When using external authentication, when a user logs
into NMC for the first time, a user object is automatically created. Optionally, you can
create the user object in NMC first as shown here. In this case, AuthC verifies that the user
name is a valid name in the external repository.
Users can manage data in NMC, such as reports and events, for hosts to which the user is
given permission. By default, a user can manage all hosts. Depending upon the user role
assigned to the user, user access to specific hosts can be restricted using the Permissions
tab.
Note: A user must belong to the Console Security Administrator role to add new Console
users. To manage local users with the Console Security Administrator role, the user must a
member of a NetWorker Authentication Service group that has administrator privileges. For
example, the Administrators group.

Authorization settings control the rights or permissions that are granted to a user and
enable access to resources managed by NetWorker and the NMC server. After creating new
users in the NetWorker Authentication Service database or configuring the NetWorker
Authentication Service to use an external authority for authentication, you must configure
the NMC server to enable access for both local and external users.
To set the level of access (privileges) that the user has to the NMC server, map each user
or group that you want to have access to the NMC to one of the three NMC roles. Map local
users to a role using the Local Users section of the Edit User Role window. Use the
External Roles section to add external users. To add an external user, type the
distinguished name of the user or group.
In the example shown here, we have mapped a local user, MaryAdmin, and the external
user group, networker_admins, to the Console Application Administrator role. By mapping
the external user group, all members of the group can access the NMC server. Notice that
the authentication server service account for the NMC server, svc_nmc_nmc_nwwindows,
and the user, administrator, are automatically local users for the user role.
Note: To assign roles, the user must belong to the Console Security Administrator role.

Log into the NMC server with a valid user name and password. You can log into the NMC
server using either a local user account or a user account in a configured, external
authentication authority. Note that logins for tenant configurations are supported.
Continuing on with our examples, after configuring external authentication with the AD
server of emc.edu, we are logging into the NMC with the login account, tparker. This
account is a member of the networker_admins group.

To use token-based authentication with a CLI command such as a backup or recovery
operation, first run the nsrlogin command on the host where the CLI commands will be
run. The NetWorker host contacts the NetWorker Authentication Service to validate the user
log in credentials. When validation is successful, the application issues a token to the
NetWorker host for the user account running the command. The user account can perform
secure client-initiated operations until the token expires.
In this example, the nsrlogin command is run to validate the user tparker and generate a
token for the user.

A token remains valid for a period of time as defined in the AuthC local database. By
default, this is 480 minutes or 8 hours. To modify the token expiration timeout value, select
the Configure Authentication Service Token Timeout option from the Setup menu of
the Setup window.
When a token expires, an expiration message appears:

• If the user is connected to NetWorker Administration, the connection closes.
– The user is prompted for a password and to generate a new token.
– After the new token is issued, the user can re-establish the connection to the
NetWorker server.
• When the user is connected to NMC,
– The user is prompted for a password and to generate a new token.
– After a new token is issued, the user can use the NMC GUI.
• For a CLI authenticated user, any in-progress, user-initiated operation completes. The
user must run the nsrlogin command again to generate a new token.

For your reference, this is a list of NetWorker logs containing information relating to the
AuthC service. The logs are located in directories on Windows servers below …\nsr\authc-
server and in comparable paths on Linux. For troubleshooting and verifying operations,
these logs are especially helpful:
• authc-server.log, the main authentication service log
• authc-server-audit.log, for security audit messages

You can change a local user’s configuration, such as an assigned role or password, from the
Setup window by viewing Properties for the selected user. In the Identity tab, you can
change the full name, description, groups, roles and password.
For both external and local users, the Login Information tab provides details about the
last user login.
For all users, use the Properties window for each role to change the users that are
members of a selected role.
Note: To assign roles and edit permissions, the user must belong to the Console Security
Administrator role.

A NetWorker Management Console server can be configured to manage multiple NetWorker
servers or Data Domain systems. To display a list of hosts managed by the Console server
and to add new managed hosts, go to the Enterprise window. In the left pane, a
hierarchical list of managed hosts, including NetWorker servers, is displayed.
When setting up a new installation of NMC, you are prompted to specify the NetWorker
servers that will be managed by the NMC during execution of the Console Configuration
Wizard. After this initial setup, new NetWorker servers can be added to the Console from
the Enterprise window.
To add a new NetWorker server to manage, right-click Enterprise in the tree and then
select New > Host. In the Create Host window, specify the name of the NetWorker server
to manage. In the Select Host Type window, select NetWorker to manage a NetWorker
server. Next, in the Manage NetWorker window, choose whether to gather information
from the NetWorker server.
Alternatively, the gstmodconf command-line utility can be run on the Console server to
manage the NMC and add an additional NetWorker server. See the NetWorker Command
Reference Guide for additional information concerning options and arguments.
From Enterprise, you can also create new folders in the Enterprise tree to organize
multiple hosts into groups.

The System Options from the Setup menu of the Setup window enable users to fine-tune
the performance of the NMC server. Because changing these options could potentially
degrade performance of the NMC server, exercise careful consideration and caution before
making any changes. For example, change the debug level for troubleshooting only and
then set it back to 0 when finished.
The User authentication for NetWorker attribute defines how the Console user accesses
a managed NetWorker server. When enabled, which is the default option, an access request
to a NetWorker server is based on the Console user name. There is a separate network
connection from the NMC server to a NetWorker server for each Console user that has an
Administration window open to that server. If disabled, the user id of the gstd process
owner determines the Console user access and there is only one connection from the NMC
server to a managed NetWorker server
From the Setup menu you can also perform some of the NMC configuration tasks that you
run the first time that you start a NetWorker Management Console, such as the running the
Console Configuration Wizard and setting the name of the server that will back up the
NMC.
For detailed information about using these options, please refer to the NetWorker

This lesson covers authorizing users in NetWorker Administration through the use of
NetWorker user groups. Specific topics include an overview of the default, built-in user
groups, creating and editing user groups, and user group properties.

Access to a NetWorker server is granted based on the authenticated user. When a user
launches NetWorker Administration from NMC, the NMC server sends the token to the
NetWorker server. NetWorker uses the user’s token to authenticate and authorize the
operations performed using NetWorker Administration.

Users and groups are authorized to perform specific tasks on a NetWorker server based on
membership in one or more user groups on the NetWorker server and the privileges
assigned to the user group.
Specific users or groups of users are associated with a user group via the External roles
and Users attributes of the user group’s resource.
Each NetWorker user group has a specific set of privileges associated with it, defined by the
Privileges attribute. Users and groups of users must be a member of one or more user
groups with privileges that correspond to the tasks that they need to perform.

For token-based authorization, NetWorker uses the External roles attribute in a user
group resource to determine user membership for users in the AuthC local user database,
LDAP directory and AD directory. NetWorker uses this attribute to validate user
authorization for operations that require token-based authentication such as operations that
you perform in NetWorker Administration. (Operations performed in the NetWorker
Administration interface always use token-based authorization.)
To add a NMC/AuthC local user to External roles, click the “+” sign and select the user
from the list of local users and groups. To add an external user, type the distinguished
name of the user or group. It is recommended to specify user names where a user belongs
to a large number of groups.
Here we see an example of adding the networker_admins group and the MaryAdmin local
user to the External roles attribute of a user group.
The Users attribute of a user group defines membership for operating system users that
perform operations outside of NetWorker Administration. These include CLI commands such
as nsradmin, save and recover, and NetWorker modules, such as NMM and NMDA. To add a
user in the Users attribute, use a “name=value ,host=value” format. An example of this
format is: “user=sally, host=winhost”. An asterisk (*) when used as a value, means all
possible values.

NetWorker provides these nine, role-based user groups preconfigured with specific
privileges. You can assign users to one or more of these groups based on their
administrative role.
The privileges associated with each user group can be modified with the exception of the
Application Administrators user group and the Security Administrators user group. The
preconfigured user groups cannot be deleted. Additional groups, however, can be created
by the administrator to meet the specific needs of a data protection environment.
The NetWorker Authentication Service Administrators group is automatically added to the

Application Administrators and Security Administrators user groups on the local NetWorker
server.
For a detailed description of all user privileges that can be assigned to a user group within
NetWorker, refer to the NetWorker User Groups topic in the NetWorker Security
Configuration Guide.

Additional user groups can be created as needed. This is convenient if there are specific
users that you would like to assign specific NetWorker duties to but do not fit into the
predefined categories.

Administrator is an attribute in the NSR (server) resource which contains a list of users or
groups that are allowed to add, delete, and update all NetWorker resources.
For example, to have access to the client database (nsrexec), a user must be a member of
the Administrator list.

When configuring AuthC, you established trust between each remote NetWorker server
managed by the NMC and the NetWorker Authentication Service that provides
authentication services to the NMC server.
After establishing trust, NetWorker Authentication Service users must be granted access to
each NetWorker server that is not local to the NetWorker Authentication Service. This is
done by updating the user groups on each NetWorker server to include the users requiring
access to the NetWorker server.
Use the nsraddadmin command to grant the NetWorker Authentication Service groups
access to the NetWorker server. This adds the NetWorker Authentication Service
Administrators group to the External Roles of the Security Administrators and Application
Administrators user groups and the Users group to the External Roles of the Users user
group. The format of the command is:
nsraddadmin –H authentication_service_host –P
authentication_service_port_number
where the default port number is 9090.
Next, use NetWorker Administration to add the service account for the NMC server
(svc_nmc_nmc_server_name) to the External Roles attribute of the Users user group.

This lesson covers NetWorker resource update logging, audit logging capabilities, and
NetWorker server and Console server logs.

NetWorker uses the resource database to store the resources for a NetWorker data zone.
The resource database exists on the NetWorker server. There is one file per configured
resource and each file is stored in any of ten subdirectories (00-09) under /nsr/res/nsrdb.
The information in the resource database is managed via NetWorker administrative

interfaces. The master NetWorker server daemon, nsrd, is responsible for managing all
NetWorker server resources. It handles all queries and update requests to the resource
database. Resource information is transmitted via the Resource Administration Platform
(RAP) protocol between nsrd and NetWorker administrative interfaces.
Important: Resource files are text files and are to be modified only using NetWorker
administrative resources, including NetWorker Administration and the nsradmin command.
DO NOT EDIT THEM! See the nsradmin topic in the NetWorker Command Reference Guide
for a description of nsradmin options, commands and examples.
Note: Other files and directories may exist in /nsr/res. Also, a small amount of resource
information exists in the /nsr/res/nsrladb directory on each NetWorker client.

Resource update logging enables the administrator to track changes made to configuration
resources. The NetWorker server records resource changes in the rap.log file located in
…/nsr/logs directory.
Resource update logging is enabled using the Monitor RAP attribute in the NetWorker
server resource (NSR). By default, this attribute is enabled but hidden. To display the
Monitor RAP attribute, enable the diagnostic mode from the View menu. Then, right-click
the name of the NetWorker server from any NetWorker Administration window and select
Properties.
Note: There are several NetWorker client resources, such as NSR Port Range, that are
managed by nsrexecd and therefore excluded from the resource update logging feature.
These resources are maintained in the directory /nsr/res/nsrladb on all NetWorker
clients.

The rap.log file contains an entry for resource changes (creation/deletion/modification)
made on the NetWorker server. NetWorker provides sufficient information to enable an
administrator to undo a change.
For each event, there are several lines of information written to the file. This includes a
time stamp of when the change was made followed by the type of action performed
(CHANGED, CREATED, or DELETED) and the affected NSR resource type. Remaining lines
provide the details of the modification. If the type of action is CHANGED, the old value is
displayed followed by the new value. If the action is CREATED or DELETED, all the
resource’s attributes and attribute values are displayed.
Here we have an example of the rap.log file entry for a change made to a client resource.
The save set for the client was changed from C:\Windows\Fonts to C:\Program Files\EMC
NetWorker\nsr\logs. You can see that the log mentions both the old and the new value for
the save set.
Note: Each data protection policy is described by a single resource called NSR Protection
Policy. The NSR Protection Policy resource describes one or more workflows and each
workflow contains one or more actions. In the rap.log you will see when a NSR Protection
Policy is created and when it is started.

NetWorker provides the security audit logging feature to record events related to the
security and integrity of the data zone.
NetWorker assigns a severity to each security audit message. At installation, each client is
automatically configured to use security audit logging. NetWorker clients send security audit
messages to the nsrlogd daemon. NetWorker records messages in the security audit log
file when the severity level of the message is equal to or greater than the auditing severity
level defined in the Security Audit Log properties. Severity levels are informational,
warning, notification, error, critical and severe. The default value is error. Examples of
auditable security events include authentication attempts and privilege changes.
Any client host in the datazone can be configured to run nsrlogd. By default, nsrlogd runs
on the NetWorker server. The nsrlogd receives audit messages from the NMC gstd, the
nsrexecd on each client including the NMC, and the daemons running on the NetWorker
server. Administrators can view the properties of the security audit log attribute from the
Server window of the NetWorker server. The attributes of the security audit log resource
can be modified by members of the Security Administrators user group and the NetWorker
server’s Administrator attribute. Changes made to the resource are automatically copied
to each client in the datazone supporting audit logging.
The security audit log file contains the timestamp, the category, the program name, and
the unrendered message for each security audit message. On the NetWorker server, the
security audit log file is …nsr\logs\networker_server_sec_audit.raw.
The Security Audit Logging topic in the NetWorker Security Configuration Guide contains
examples of security audit log configurations and also a list of resources and attributes
monitored by the security audit log.

NetWorker maintains many log files on the NetWorker server and Console server, in
addition to the previously mentioned rap.log and security audit log files. For Windows
hosts, logs are located on the NetWorker server in the …\nsr\logs directory; Console
server logs are located in …\Management\gst\logs. For Linux hosts, the paths are
/nsr/logs and /opt/lgtonmc/management/logs respectively.
Listed on the table above are some of the most often used logs.
For troubleshooting tasks, the daemon.raw log on the NetWorker server is especially helpful.
The installation log files on the Console software are useful when troubleshooting a problem
with the Console software and for tracking decisions made during installation, such as the
HTTP service port chosen for the web interface.

Several NetWorker log files, identified with the .raw extension, are written in tokenized
format. Raw files include daemon.raw (NetWorker server), gstd.raw (Console server),
networkr.raw (NetWorker User program), and workflow and action logs. The tokens are the
same regardless of the locale of the host. When viewing these locale-independent raw logs
using the nsr_render_log command, the tokens are rendered using the locale of the
current host. Thus, a log file viewed on an English system will display English text. If the
same file is viewed, for example, on a host in the Chinese locale, Chinese output is
displayed.
All other log files, as well as messages displayed in the NetWorker Console, use the locale in
which the service that is generating the log messages is running. Use a text viewer to view
the content of these logs.

nsr_render_log has many options that allow filtering of output based on specified criteria.
If more than one value is specified for a criteria (up to eight values per criteria are allowed),
the set of values should be enclosed in quotes. Multiple values for a criteria are OR’d while
multiple criteria types are AND’d.
Review the NetWorker Command Reference Guide for command options and more
examples.

These labs cover configuring AuthC to use an external authentication authority and using
NetWorker server logs.

This lesson covers configuring NetWorker in a firewall environment, including the
differences between service and connection ports, port requirements, and procedures for
configuring port ranges.

Firewalls monitor all traffic flowing between two or more networks and allow only authorized
traffic, as defined by administrative policies.
Firewall support enables you to back up NetWorker clients that are separated from the
NetWorker server by a packet filtering firewall. It is first necessary to determine which
TCP/IP ports will be utilized by the NetWorker server and which ports will be used by the
NetWorker client. The firewall must then be configured to allow packets to be sent to the
appropriate range of ports on the destination hosts.
If a storage node must communicate through the firewall with either the NetWorker server
or a NetWorker client, it is also necessary to calculate the range of ports that the storage
node will use. Then, configure the firewall appropriately to allow communication between
the storage node and the other NetWorker hosts.

NetWorker uses two types of TCP/IP ports for interprocess communication: connection
ports and service ports.
Communication between NetWorker processes is initiated from a connection port on the

source host. The communication request is sent to a service port on the destination host
where a NetWorker process is listening.
Examples of NetWorker interprocess communication include:

• nsrjobd on the NetWorker server asking nsrexecd on the client to spawn a save
process.
• savefs on a NetWorker client sending file index information to nsrindexd on the
server.
TCP/IP fallback ports include Ports 111 and 514.

When a NetWorker daemon/service is started, it begins listening on a service port assigned
to it by the EMC portmapper. NetWorker processes initiate communication using client-side
ports within the host’s connection port range. If the configured service port range is not
large enough, the associated services and processes cannot communicate through the
firewall.
The port numbers used by the NetWorker processes or services, except for nsrexecd, are
assigned from the service port range that is set in the NetWorker software.
Note that nsrexecd on every type of NetWorker host will always try to listen on ports 7937
and 7938. The ports will be used no matter what the value of the range in the NetWorker
software, unless another process is already listening on those ports when NetWorker is
started. NetWorker requires the port 7938 for rpcbind (portmapper) to be running and
available through the firewall, or NetWorker will cease to function correctly.
Permitted port ranges are stored in the NSR system port ranges resource in the resource
database, /nsr/res/nsrladb on each NetWorker host. The resource is used and managed
by nsrexecd. Whenever NetWorker daemons/services are started, nsrexecd is always the
first process to start. It is important that whenever NetWorker server processes are started
manually, nsrexecd is started first. Failure to do so might cause the ports to be assigned
randomly or outside the desired range. Note that the ports in the Excluded service ports
attribute are ports that are reserved for other services. Specified ports will be excluded
from RPC service ports.

Port requirements vary based on the components that you are installing, the environment
you are installing in, and the version of NetWorker you are using. Because of this, it is
important to understand the processes and subsequently, the ports used by each of the
NetWorker components.
The table displayed here lists the standard NetWorker services, the ports required for each
and the function(s) for which the process is used: either server, storage node, client, or the
audit log server. Library and device related processes are discussed on the next slide.
Additional applications and features may use additional ports, therefore it is important to
identify the features and components that will be used in your environment and determine
the port requirements specific to that unique environment.
A standard NetWorker client requires at least four TCP service ports; snapshot services
require an additional two ports. The NetWorker server requires a minimum of 15 TCP
service ports.
For the most detailed information regarding NetWorker services and port requirements refer
to the NetWorker Security Configuration Guide.

The ports listed on the slide are for device related ports used by the storage nodes and
NetWorker server when devices are attached. One port is required for each jukebox managed
by the storage node, as well as ports for the nsrmmd processes. The minimum number of
service ports that a storage node requires is 5 (4 for the NetWorker client and 1 for nsrsnmd).
The number of ports required by the nsrmmd processes is determined by the type of devices you
are using and how you have them configured.
In enterprise environments where unattended firewall ports need to be restricted for security
reasons, the storage node settings for mmds for disabled devices and Dynamic nsrmmds
unselected (static mode) offer more control because they cause all available nsrmmd firewall
ports to be attended by running nsrmmd services. This is particularly useful in cases where
security will not allow ports to be open and unused. When these options are configured
correctly it can keep an active process running for all devices even when they are not in use or
disabled. For more information on both of these settings refer to the NetWorker Administration
Guide.

After calculating the number of service ports required by each NetWorker host, determine
the service port range or ranges that will include the calculated number of ports. When
specifying a range, begin at port 7937. 7937 is always the first port in the range because
nsrexecd is always started on that port. Alternatively, you can specify one range of 7937-
7938 and then one or more additional ranges for the remainder of the ports.
The actual configuration of the firewall is done by the firewall administrator, based on the
port information you provide. The number of ports that need to be opened in the firewall
depend on those NetWorker hosts that are separated by the firewall. In the example shown
here, the firewall should be configured to allow transmission of TCP/IP packets destined for
the following hosts/ports:
• NetWorker Server 7937-7955
• Storage Node 7937-7943
• Client A 7937-7940
• Client B 7937-7940
Note: The default port for the NetWorker Authentication Service is 9090. This example does
not take into account any nsrmmd related storage node or device configurations such as
nsrmmd's for disabled devices or dynamic nsrmmd's, as these settings may impact the ports
required.

The slide lists the steps to be performed to restrict the NetWorker service port range. Note
that this must be performed for each host where it is desired to change the service port
range.
The following administrative interfaces are available for configuring NetWorker port ranges:
• nsrports
• NetWorker Administration
• nsradmin
In order to change the port ranges on a host, the user must have update access to the NSR
system port ranges resource for that host. Unlike NetWorker resources that reside on the
NetWorker server and are managed by users belonging to the server’s Administrator list,
the NSR system port ranges resource has its own administrator list on each NetWorker
host. To give the user update privileges, add the user to the administrator list for this
resource on the host.
1.On the host, type: nsradmin -s server –p nsrexec where server is the host for
which ports are to be modified.
2.Use the print sub-command to list the NSR system port ranges resource.
3.Use the update sub-command to modify the administrator attribute.
4.Save the update and quit nsradmin.

The nsrports program can be used to view or update the port ranges from the command
line.
The syntax of nsrports is:
nsrports –s networker_host [ -S | -C ] port_range
nsrports can be run from any host. The -s option is used to specify a remote host whose
service port range will be modified.
If the -s option is not used, the port ranges on the local host will be modified.
The –S option is used to specify a new service port range for the host.
The -C option is used to specify a new connection port range for the host. By default,
NetWorker defines a range of 0-0 for connection ports.
If neither option is used, the current port ranges are displayed. Non-contiguous ranges may
be specified by including more than one range.

The slide illustrates the steps required to configure a port range using the NetWorker
Administration window.
1. Click Hosts from NetWorker Administration.
2. Right-click a host from the list of Local Hosts and select Configure Port.
3. In the General tab, modify the Service Ports attribute and, if desired, the
Administrator attribute. Non-contiguous service port ranges may be specified by
including more than one range in the Service Ports attribute.
4. Click OK.

The slide illustrates the steps required to configure a port range using nsradmin.
1. Type: nsradmin –s server –p nsrexec where server is the host for which ports are
to be modified.
2. Use the print sub-command to list the NSR system port ranges resource.
3. Use the update sub-command to modify the service ports attribute.
4. Save the update and quit nsradmin.
Note: This command is run for each host for which port changes are to be made.

Three ports are required for connections between the Console server (gstd) and Console
clients.
One port, default 9000, is used for the web server. The second port, default 9001, is used
for RPC calls from the NMC Java client to the Console server. These ports are not taken
from the range configured using nsrports. Instead, they can be changed during the
installation of NMC server.
The third port is used for database queries and is 5432. This port cannot be changed.
The firewalls protecting the Console server and the client must be configured to allow
communication over these three ports. It is important that the range of ports used by
NetWorker on the host where the NMC server is installed do not overlap with these ports.
In addition to these ports, two more ports are required if using Data Domain within the
environment. SNMP requires the use of port 161 as well as 162 for capturing SNMP traps from
the Data Domain device.

After determining the minimum service port ranges for the NetWorker server and clients,
the firewall must be configured to allow transfer of the following types of packets. The port
ranges used are from the example shown on the slide.
• Packets are destined for the NetWorker server’s IP address, if they are going to a port
in the range 7937-7955.
• Packets are destined for the NetWorker client’s IP address, if they are going to a port
in the range 7937-7940.
• Packets are destined for the NetWorker storage node’s IP address, if they are going to
a port in the range 7937-7943.
It is possible to fine-tune the firewall configuration. In this example, if the NetWorker

storage node was on the same side of the firewall as the NetWorker server, the firewall
would not necessarily need to allow packets to be sent to port 7937 of the storage node.
This is because the client will normally communicate only with the portmapper and nsrmmd
processes on the storage node and not with nsrexecd. However, by restricting packets
going to port 7937, the client would not be able to perform tasks such as a directed
recovery to the storage node.
It is important that the firewall rules be configured to accept packets with the SYN bit for
ports in the service ports range.

The RPC protocol underlies all NetWorker services. RPC is a protocol which allows a program
running on one host to cause code to be executed on another host.
The nsrrpcinfo command is used to determine which ports are registered to NetWorker
processes. rpcinfo might be helpful in fine-tuning the exact number of ports needed for a
particular environment.
netstat is used to display a list of ports that are in use and, if appropriate, what
destination port they are connected to.
Use the netstat -a command to determine port allocation.
iperf is used as network testing tool that can create TCP and UDP data streams and
measure the throughput of the network. iperf allows the user to set various parameters
that can be used for testing a network or alternately for optimizing or tuning a network.
iperf works on various platforms.
Note: rpcinfo may not work successfully through a firewall.

This module focuses on the security features of NetWorker. It covers authenticating
users with the NetWorker Authentication Service, AuthC. We look at managing
external and local users and NetWorker user groups, the various types of
NetWorker logs and how to configure NetWorker in a firewall environment.

This module focuses on administering the NetWorker server. Specifically, we cover viewing
and customizing reports, managing parallelism, software distribution capabilities, and revisit
NetWorker multi-tenancy.

akhan@aayan.com Module: Administering NetWorker 1
This lesson covers events and reporting in a NetWorker environment. Specifically, the
settings for gathering information as well as configuring reports and notifications in
NetWorker and the NetWorker Management Console are discussed.

The NetWorker Management Console allows for the configuration of data collection at the
application host level. An administrator can specify whether to capture events and/or
reporting data on all configured hosts or just specific ones.
To change whether the Console server captures events and gathers reporting data from a
managed NetWorker server, select the NetWorker server in the Console Enterprise
window, right-click NetWorker (the managed application) in the right pane, and select
Properties from the context menu.
Selecting Capture Events allows events such as license warnings and pending media
requests to be displayed in the Console Events window. Selecting Gather Reporting Data
allows the Console server to accumulate data retrieved from the NetWorker server jobs
database to be used when creating reports.

The Events window contains important notices generated by the NMC and managed
servers. Types of NetWorker events include failed policy backups, pending media requests,
automatic disabling of devices due to too many consecutive write errors, as well as
NetWorker licensing notifications.
In order for the NMC to capture events from a specific server, the Capture Events options
must be selected for each server.

The NMC Reports window contains all of the reports that can be run within the NMC. The
preconfigured reports are separated into seven different categories based on function.

Two types of reports are provided in the NMC. Basic reports are reports that provide data
at a single level; these typically include summary and detailed reports. In contrast,
drilldown reports provide data at a single level, as well as the ability to drill down to deeper
levels providing greater depth of information within a single report. The two types of
reports are easily identifiable based on the icon used to represent them. Report icons with
a black downward-pointing arrow indicate drilldown reports.

For each report, there are a number of parameters that can be specified. By default, all
possible values of each parameter are selected. For example, the Policy Summary report
automatically displays information about all NetWorker policies viewable by the user
running the report. All Console database information matching this query, regardless of the
save set timestamp, is included in the report.
To customize the report, deselect one or more values from one or more of the parameters,
or restrict the time period for which the report is generated. The ‘<‘ button deselects an
individual value while ‘<<‘ deselects all selected values. The ‘>’ button selects an
unselected value while ‘>>’ selects all unselected values. A customized report can be saved
for later use.

After specifying the parameters on which to query, change to the View Report tab to
perform the query and display the results. The parameters used for the query are
displayed in the upper right corner and the actual report is displayed below them.
Clicking the heading of a field causes the report to be sorted on that field. Clicking the
same heading again reverses the sort.

A report can be displayed in a number of different formats, including a table, a document,
and a chart.
Right-clicking anywhere in a report pops up the context menu shown in the slide from which
you can choose the report format.
By default, reports are displayed in a tabular format in portrait orientation. You can use the
context menu to change the orientation to landscape.

The default tabular display can be modified by selecting Document from the context menu,
as shown on the slide. Displaying a report in document format is useful if you want to print
the report.
To return to the default tabular view, select Interactive from the context menu.

There are several types of chart formats including bar chart, pie chart, plot chart, and
stacking bar chart. Each type of chart displays the same information but in a different
format. To display a report in chart format, select Chart from the context menu. Then,
select the type of chart from the choices in the Chart Type drop-down menu. Select the
type(s) of data to display with the Chart Selection field.
In a stacking bar chart, multiple pieces of information are displayed in each bar.

In most report types, you can select Zoom from the context menu to change the size of
what is displayed. Additionally, you can choose Print from the context menu to send the
report to a printer.
The context menu also has an Export selection which allows you to export the displayed
information to a file in PDF, HTML or Postscript format. Reports displayed in a tabular
format also allow exporting to be performed in CSV format.

Drilldown reports are designated by a small black triangle on the bottom of the report icon
in the Reports window.
In a drilldown report, you can double-click items within the report to view more detailed
information. The types of information displayed when drilling down and the order in which
they appear are listed at the top of the report above the query parameters in a section
called Drill Down Sequence.
Note: You can reverse the drilldown sequence by right-clicking in a report and selecting
Back from the context menu.

You can customize a report by deselecting any of the selected parameters or by changing
the time period used for the query.
To save the customized query parameters, right-click the report that you customized in the
left pane and select Save As from the context menu.
After you specify a name for the report, the customized report will be filed in the left pane
below the preconfigured report.
By default, a customized report is stored as private for the user who created it and only
appears in that user’s list of reports. The owner, or the NetWorker administrator, may
choose to share the report with others by right-clicking the report name in the left pane and
choosing Share from the context menu. Once enabled for sharing, the report appears in
the list of reports for all users.

To perform a query and generate a report from the command-line, use the gstclreport
command. There are a large number of options used to specify items such as the user to
perform the query as, the query parameters, and the format of the report.
Command line reports may only be printed or run to generate exported output. They
cannot be saved or shared. Drill-down reports cannot be run from the command line.
Note: Support of command line reporting requires JRE version 7 or later. Uncomment and
change the SET JAVA_HOME statement in the gstclreport.bat file to the Java location
prior to running the command.

The information contained in the NMC database is used when generating reports. To
manage the size of the database, there are five categories of configurable parameters that
allow you to retain various types of data for differing lengths of time.
Statistical Data consists of all save set data, retrieved from a NetWorker server’s media
database, for use in generating backup statistics reports. Once retrieved from a NetWorker
server and stored in the NMC database, the save set data is retained, by default, for a
period of one year.
Recover Statistics consists of all recovery operations performed by NetWorker servers. This
information is kept in the console database for one year, by default.
Audit Data is kept in the NMC database for one year, by default. This information consists
of a complete record of all activities performed by all NMC users.
Completion Data is kept for one month, by default. Completion data includes information
about all backed up save sets.
Completion Messages include the success/failure status of each backup. By default, this
information is retained for two weeks.

ConnectEMC allows for NetWorker administrators to quickly and easily send NetWorker
configuration information to EMC support automatically, on a regular basis.
You can configure it using either the Server tab in NetWorker Administration or the
nsradmin command. ConnectEMC provides an email report of only RAP database
information. The following are not included:
• Log data
• Backup summary information and backup data
• Non-NetWorker configuration information
• Passwords and other security sensitive information
• Any options specified in the Exclude attributes or Exclude resources fields
Note: Both ConnectEMC and Report Home can be used to provide the same information to
EMC Support. ConnectEMC is the preferred option and care should be taken to ensure that
both options are not configured.

Many NetWorker processes within a datazone notify the NetWorker server when they finish
performing their assigned task or when they are having difficulty performing a task due to
undesirable conditions. Some common conditions might include:
• No appendable volumes available for a backup
• A NetWorker license has expired or is about to expire
• A tape drive needs cleaning
• An advanced file type device has become full
Priorities are assigned to each notification depending on the message’s importance.

Priorities can range from informational where no problem exists, to critical, where it is
possible that NetWorker is unable to perform a backup.
There are numerous preconfigured NetWorker notifications, so that when a particular event
occurs at a specific priority, it can perform some action to either correct the situation or
somehow notify the NetWorker administrator that the condition exists.

A notification’s Event attribute specifies one or more events which trigger the notification.
Each message generated as the result of an event is flagged with a severity level or priority.
A notification’s Priority attribute specifies the severity level(s) at which the message must
be flagged for the notification to be performed.
Lastly, the Action attribute specifies the command that is executed when a selected event
at a specified priority occurs. For a NetWorker server running Microsoft Windows,
NetWorker provides the following commands that are commonly used in notifications:
• nsrlog which directs the message contents to a specified log file
• nsrlpr can be used to send the message contents to a printer
• smtpmail is used to email message contents to a specified email address
A Linux NetWorker server already has the utilities necessary for logging information (the
syslog facility and the logger command), printing (lp or lpr), and sending email (mail or
mailx).
To customize a NetWorker environment, you can either modify the action performed for an
existing notification or you can create a customized notification. This may involve creating a
new notification or copying an existing notification and modifying the action, resulting in
multiple actions being performed for the same event.
Note: Any path name specified in the Action attribute that contains a space character
must be enclosed in double quotes.

This lab covers NetWorker reporting, including the running of reports and creating custom
reports.

This lesson covers managing parallelism in NetWorker. Specifically, we look at the different
levels that parallelism can be defined. Additionally, we review the impact of parallelism as
well as the target and max session variables.

Parallelism can be configured on different types of resources and allows for a granular level
of control over the maximum number of save streams that may be backed up
simultaneously at different levels within the datazone.
Server parallelism defines the number of simultaneous data streams that the NetWorker
server allows. Each storage node that you enable and connect to the NetWorker server
increases the maximum parallelism value. The default value with one storage node is 32.
Typically, it is recommended that this value be set as high as possible without overloading
the NetWorker server.
Action parallelism defines the maximum number of concurrent activities that can occur on
all clients in a group that is associated with the workflow that contains the action. For a
backup action, the default parallelism value is 100, for clone actions it is 10, and all other
action types have a default value of 0, meaning unrestricted.

Client parallelism is the maximum number of save sets that may be backed up
simultaneously from a single client. If multiple (logical) client resources exist for a host and
are backed up at the same time, the maximum number of save sets backed up
simultaneously from the physical host is the sum of the Parallelism value for each client
backing up. By default the Parallelism value is set to 4; however, for the NetWorker
server’s client resource the default value is 12 to accommodate server CFI backups.
Pool parallelism defines the maximum number of simultaneous sessions that can be sent to
a particular NetWorker pool. The default value is 0, meaning unrestricted.

In this example, we look at the impact on the NetWorker server when server parallelism is
set to a value of 1.
Save streams cannot be multiplexed when server parallelism is set to 1 because the
NetWorker server only allows one save set at a time to be backed up. Save sets are backed
up on a first-come, first-serve basis until the parallelism value is reached.
Parallelism is one of NetWorker’s key performance tuning parameters. It helps determine

the amount of multiplexing that occurs when writing to a device. If parallelism is set too
high, it might overload the network, clients, storage nodes, or the NetWorker server. If
parallelism is set too low, there may be an insufficient number of save streams directed to a
device for it to achieve its maximum throughput.
Note: This slide is for illustration purposes only, it is never recommended to set the server
parallelism to a value of 1.

In the next example, we consider the impact of increasing the server parallelism value to
2.
The number of save streams assigned to a device is determined by the value of the device
resource’s Target sessions attribute. When a device is receiving the number of save
streams specified by its Target sessions value, the NetWorker server attempts to direct
additional save sets to other available devices. If there are no other devices available to
receive additional save streams, the NetWorker server can direct the save streams to the
device already receiving its target number of save streams. Thus, Target sessions is not a
hard limit; the NetWorker server can override the value if necessary.
Each device resource also has an attribute called Max sessions. This attribute is a hard
limit on the number of save streams that may be directed to the device.
Note: This slide is for illustration purposes only, it is never recommended to set the server
parallelism to a value of 2.

In this final example, we review the impact when server parallelism is set to a value of 8.
The following steps explain how the backup illustrated in the slide occurs.
1. Client oboe backs up its /usr and /mail save sets. The save streams are directed to the
first device because its Target sessions value is set to 2.
2. Client clarinet’s /mail and /tmp save sets are directed to the second device because the
first device is already receiving the number of save streams specified by its Target
sessions value. At this point, both devices are now receiving their desired number of
save streams.
3. Since server parallelism is 8, the NetWorker server will start four additional save
sessions. Since a device’s Target sessions is a soft limit, the server overrides the
value and directs the streams to the two devices.
Although the slide depicts the save streams being directed to the devices in a round-robin
fashion, each additional save stream is directed to the least utilized device as determined
by the device resource’s Accesses attribute.
Note: The slide assumes that both devices contain a volume from the same pool and that
all save sets can be written to that pool. If multiple pools are used for the save sets, the
behavior of the backups may be considerably different.

Parallel save streams (PSS) are used to automatically break up a large save set into
multiple smaller save sets to be backed up at the same time. This results in a backup that
completes faster for file systems on disks that support the increased read parallelism. Each
PSS client resource’s save set entry (mount point, file system) results in multiple save
sets. Each save set has a corresponding media database record. Synthetic and Virtual
Synthetic full backups for UNIX, Linux, and Windows are supported.
This feature is enabled for scheduled file system backups by checking the Parallel save
streams per save set client resource property.

Parallel save streams (PSS) are configured at the client level. To use PSS for a specific
client resource, modify the properties of the client and select Parallel save streams per
save set. The maximum number of save streams allowed will be controlled by the client’s
Parallelism value. PSS works best on clients with large file systems hosted on disks that
support high read performance.
Optionally, support is provided to specify the number of streams to use per save set. This
can be done by defining the PSS:streams_per_ss variable under the Save operations
attribute of the client properties Apps & Modules tab.
Note: When using the PSS:streams_per_ss variable, it is recommended to set the client
parallelism to 4 or a value higher than the PSS:streams_per_ss variable. Failure to do so
could result in failure of PSS backups.

If you are backing up virtual clients, you can base the client parallelism setting on the
underlying physical host. In this way, the total number of save streams for all virtual
clients that reside on a physical host are limited to the value specified for the physical host.
To configure this, select Physical client parallelism on the properties of the virtual client
with Diagnostic Mode enabled.

When backups are run using PSS, NMC displays the progress of each partial save set in the
NetWorker Administration Monitoring window. As save streams are freed from backup
completion, they will be dynamically reallocated to other save sets until the max parallelism
value is met.

This example illustrates the benefits of using parallel save streams in terms of backup
completion time. In this example, a client is backing up a save set consisting of 3 volumes.
Client parallelism is set to 10 and the default of 4 is used for max stream per save point.
The differences between no parallel stream processing and parallel save streams (PSS)
includes the number of streams started concurrently and what happens when a stream is
freed. With PSS, the backup starts both C:\ and D:\ with 4 streams and E:\ with 2 streams,
up to the client parallelism value of 10. After one hour, C:\ and D:\ are finished and the 8
streams used are available to be reallocated. E:\ continues backing up with 4 streams which
is the default max stream per save point value. Without parallel stream processing, the
total backup time is determined by the largest volume and would take approximately 20
hours. With PSS, the backup window is approximately five hours.

This lesson covers using the Hosts window in NetWorker Administration which includes
configuring the software repository, inventorying installed software and updating client
software packages.

NetWorker features a Hosts window for the management of NetWorker packages and local
host activities. The options available in this window provide the administrator with
information up front about each of the hosts in the environment.
The Hosts window is divided into three sub-tasks:
• Known Hosts — Provides information about the configured hosts and their certificates,
NetWorker version, operating system, and performed software operations. You can also
determine whether the host is eligible for an upgrade.
• Software Inventory — Displays information about the software packages that are
installed on the host, and provides the option to upgrade the software and monitor the
upgrade in the Software Operations pane.
• Software Repository — Displays a view of the NetWorker server's repository, providing

version information for all products that are installed on the NetWorker host. You can
also add to the repository from this view.

Selecting Known hosts displays a list of NetWorker hosts in the datazone that have an
associated client resource on the NetWorker server.
Fields displayed for Known hosts include:

Hostname - The name of the NetWorker host as it appears in the Name attribute of
the NetWorker client resource.
OS - The operating system of the client as it appears in the OS attribute of the
NetWorker client resource. The operating system attribute appears blank until you have
performed one successful backup operation for the host or performed an inventory
operation.
NetWorker version - The version of the NetWorker software on the host. This attribute
appears blank until you have performed one successful backup operation for the host.
Right-click Known Hosts to use the context menu to perform tasks such as displaying host
details, performing an inventory, upgrading software and configuring local ports.

The Software Inventory pane displays information about the NetWorker software that is
installed on the known hosts in the datazone. The information that appears in this view is
based on information that is gathered during the last inventory operation. You can only run
an inventory operation after you add software into the software repository.
Fields displayed for Software Inventory include:

Hostname - The name of the NetWorker host
OS - The operating system of the host
OS Platform - The operating system architecture of the host
Package name - The names of the NetWorker packages that are installed on the host
that you can use Package Manager to upgrade
Version - The version of the detected NetWorker software
Upgrade available - Displays Yes when the software repository contains a version of
the NetWorker software that you can upgrade on the client.
Upgrade Software on the context menu provides the option to upgrade the software and
monitor the upgrade in the Software Operations pane.

The Software Repository pane displays information about the NetWorker packages that
are contained in the NetWorker software repository.
Fields displayed for Software Repository include:

Software – The name of the NetWorker software in the software repository
Version - The version of the NetWorker software package
Package Name - The name of the NetWorker package
OS - The operating system for the package
OS Platform - The OS architecture for the package
Size - The size of the NetWorker package
Add to Repository on the context menu provides the option to add software packages to
the software repository.

The software distribution feature, Package Manager, distributes software and performs
software updates to one or more NetWorker hosts from the NetWorker server. Package
Manager replaces the client push feature that was available in previous versions of
NetWorker. With Package Manager, you can centrally manage NetWorker software updates
to hosts in the datazone that have NetWorker software that supports a Package Manager
update. These slides show the software distribution steps using NetWorker Host
Management.
By default, NetWorker will use the location NetWorker install\repository for the
software repository. If you want to use an alternate location, create the directory that you
want to use. Then, use Add to Repository from the Software Repository pane to specify
the location of the repository and to add NetWorker software packages into the repository.
On an on-going basis, manage the repository by adding and deleting software, as needed.
Note: The EMC NetWorker Updating to NetWorker 9.0 from a Previous NetWorker Release
Guide describes how to use Package Manager to update NetWorker software.

Next, perform an inventory of the hosts in the datazone.
Perform Inventory provides information about the current software version, operating
system and performed software operations for the selected host(s).
Software Inventory displays information about the NetWorker software that is installed
on known hosts in the datazone. The information that appears in this view is based on
information that is gathered during the last inventory operation. You can only run an
inventory operation after you add software into the software repository.
Use Software Operations to monitor the successful inventory operations.

Then, upgrade the NetWorker software on the eligible hosts. You can choose to upgrade
NetWorker software packages by client, or by product and version for many clients at a
time.
The slide shows an example of using NetWorker Host Management to upgrade the client
package on the client, nwwindows.emc.edu, from NetWorker version 8.2 to version 9.
Note: Before upgrading, ensure that all NetWorker scheduled backups have been stopped.

Upgrade and inventory activities in progress can be monitored using the Software
Operations pane in NetWorker Host Management. The slide shows an example of
monitoring an inventory operation.

This lesson covers the NetWorker multi-tenancy facility and the use of Restricted Data
Zones.

Restricted Data Zones (RDZ)allow multiple tenants to share a single NetWorker
environment. This offers customers who need to provide backup services to various clients
an ability to create logical datazones within a backup environment. This is particularly
useful with service providers managing multiple tenants within a single infrastructure.
However, this can also be used to provide a simplified experience for casual NetWorker
administrators allowing for departmentalized administration of certain clients and resources.
Multiple resources, such as clients, devices, and storage nodes, etc., can be assigned with a
Restricted Data Zone for better utilization. Restricted Data Zones are a standard feature in
NetWorker version 8.0 and higher, therefore no additional licenses are required for use.
The Restricted Data Zone feature results in autonomy for tenants in a hosted or service
provider environment, and a simplified experience for NetWorker administrators.
With NetWorker 9 and higher:
• You can also associate an RDZ resource to an individual resource (for example, to a
client, protection policy, protection group, and so on) from the resource itself.
• Non-default resources, that are previously associated to the global zone and therefore
unusable by an RDZ, are now shared resources that can be used by an RDZ.

The Restricted Data Zone is a feature that allows for resources from a single NetWorker
environment to be segmented into individual Restricted Data Zones. The overall goal of
Restricted Data Zones is to isolate and separate users and resources within a NetWorker
environment.
The Global Administrator performs the role of an administrator over the entire datazone as
well as setup and configuration of restricted Data Zones.
The Tenant Administrator can view all resources in a Restricted Data Zone but can only
modify resources designated to them for modification.
Restricted Data Zones are complex. When attempting to utilize the Restricted Data Zone
capabilities in an existing NetWorker environment, changes have to be made in order to fit
Restricted Data Zones. If an environment is considering using Restricted Data Zones, it is
best to start the process on the initial NetWorker install with a new environment rather than
trying to modify an existing NetWorker environment to use Restricted Data Zones.
For a complete list of rules and a more detailed discussion of Restricted Data Zones, please
refer to the EMC NetWorker Administration Guide.

Configuring a Restricted Data Zone is performed in the same manner as configuring any
other resource within NetWorker. From the Server window, right-click Restricted Data
Zones and select New. The Create Restricted Data Zone window will appear from which
point you can configure the Restricted Data Zone with the desired resources, users and
roles.
Configuration is performed by adding users and roles along with their associated privileges
to the user configuration. Next, select the resources available within the NetWorker
datazone that you are granting the Restricted Data Zone permission to use.
For more information about configuring Restricted Data Zones, refer to the EMC NetWorker

Various resources can be assigned to a Restricted Data Zone such as devices and clients.

Similarly, resources such as groups and policies can also be assigned to a Restricted Data
Zone.

This module focused on administering the NetWorker server. Specifically, we reviewed
creating reports, managing parallelism, software distribution capabilities, and the
NetWorker multi-tenancy facility.

This module focuses on recovering Windows hosts and configuring NetWorker in cluster
environments. Specifically, we discuss backup and recovery for Windows BMR with
NetWorker as well as the configuration, backup and recovery of clustered NetWorker clients.

akhan@aayan.com
Module: Recovering Windows Hosts and Cluster Environments 1
This lesson introduces Windows server disaster recovery. For a complete discussion of
Windows server disaster recovery operations with NetWorker, including requirements and
best practices, please refer to the EMC NetWorker Administration Guide.

akhan@aayan.com
Bare Metal Recovery (BMR) is an operation that restores the operating system and data on
a host after a catastrophic failure. NetWorker provides an automated BMR for Windows that
identifies critical volumes and performs recovery for a disabled computer. Note that
NetWorker BMR does not support back up or recovery of user data or application data
unless the data resides on a critical volume. This type of data, such as Microsoft Word
documents or Excel databases, should be backed up with regular file system or application
backup operations.
You can use NetWorker BMR for recovery of both physical and virtual hosts. NetWorker
Windows BMR supports file system backup and recovery. Additional backup and recovery
software, such as NetWorker Module for Microsoft (NMM), and procedures are required for
backup and restore of application data.

akhan@aayan.com
A Windows BMR with NetWorker requires a successful backup of each component save set
in the DISASTER_RECOVERY:\ save set. This save set encapsulates all of the critical
volumes required to provide complete Windows disaster recovery capabilities. The
DISASTER_RECOVERY:\ save set is included in a backup when the save set list is ALL or
DISASTER_RECOVERY:\. NetWorker performs the Windows BMR backup while the Windows
operating system is inactive. NetWorker supports both full and incremental backup levels of
the DISASTER_RECOVERY:\ save set.
The DISASTER_RECOVERY:\ save set includes all critical volumes, the WINDOWS ROLES
AND FEATURES save set, the System Reserved partition, and the UEFI partition, if
available. The WINDOWS ROLES AND FEATURES save set contains data associated with the
roles and features installed on the Windows server and metadata that represents the
volume data which the ALL or DISASTER_RECOVER:\ save set backs up. Note that block
based backups do not support this save set.
Critical volumes are volumes that contain files for an installed Windows service, any non-
critical volume that has a critical volume mounted on it, a non-critical volume that serves as
a parent to a critical volume, and all volumes on a dynamic disk if at least one volume is
critical. Note that files that are associated with application VSS writers are not backed up as
part of the DISASTER_RECOVERY:\ save set and cannot be recovered unless they are
backed up by an application backup program, such as NMM. The DISASTER_RECOVERY:\
save set does not include data for clusters, Active Directory, DFS-R, and Windows Failover
Cluster.
It is recommended to perform regular backups of the DISASTER_RECOVERY:\ save set and

also to back up the save set after any changes to host system components, Windows roles
and features, and Windows updates and service packs.
Refer to the NetWorker Administration Guide for a complete discussion of the components
of the DISASTER_RECOVERY:\ save set.

akhan@aayan.com
Requirements for NetWorker Windows BMR include:
• The source and target hosts use the same operating system architecture and processor
architecture.
• The hardware on the target host is operational.
• The target host has a minimum of 512 MB of RAM.
• The startup hard disk capacity must at least as large as that of the source host.
• The number of disks on the target host is greater than or equal to the number of disks
there were on the source host. The disk LUN numbering on the target host must match
the disk LUN numbering on the source host.
• The RAID configuration on the target computer cannot interfere with the disk order of
the hard disks. The disk or RAID drivers used on the source system are compatible with
the disk or RAID controllers in the target system. The recovery process restores the
backup to the same logical disk number that was used by the source host. You cannot
restore the operating system to another hard disk.
• Windows BMR supports IDE, SATA, or SCSI hard disks. You can make the backup on one
type of hard disk and recover on another type of hard disk. For example, SAS to SATA is
supported.
• NIC drivers that match the NIC in the target host. These drives are installed after the
recovery and reboot completes.

akhan@aayan.com
A NetWorker BMR for a Windows host is a restore operation performed from the NetWorker
Windows BMR boot image. Specific files or save sets cannot be recovered during a BMR.
The target system can access the Windows BMR image as a bootable CD volume or from a
network boot location. Here is a summary of the disaster recovery tasks for a Windows
physical or virtual host using NetWorker.
In order to perform a BMR, a valid backup of the DISASTER_RECOVERY:\ save set must
exist. This can be verified by performing a save set query from the NetWorker
Administration Media window. Next, ensure you have configuration information such as
driver software if the new host has different hardware than the source host, network name
and IP address of the target host and the NetWorker server and storage node, the default
gateway and name of the DNS server, and the NetWorker volumes that contain the backup
save sets.
You use the Windows BMR image available from http://support.emc.com to create a
bootable CD or deploy this image for a network boot operation. The Windows BMR image
contains the Windows PE operating system, NetWorker binaries and a wizard which controls
the recovery process. When the Windows host is booted using the Windows BMR image, the
recovery process starts the NetWorker BMR wizard which will guide the user through the
recovery process. The BMR process restores the operating system that was installed on the
source host. If recovering to a different host with different hardware, after the recovery and
reboot completes, Windows prompts the user to install the required drivers. As mentioned
previously, data from non-critical volumes including user files and application database files
must be recovered after performing the disaster recovery.
For a complete discussion of Windows server disaster recovery operations with NetWorker,
please refer to the NetWorker Administration Guide. As with all recovery operations, it is
recommended that the process and procedures for Windows server disaster recovery be
tested without completing the entire recovery process (exit before formatting the drives
and performing the actual recovery) to ensure successful recovery when needed. Be aware
that running the wizard to completion will format the disks chosen to restore which erases
any existing data.

akhan@aayan.com
This lesson covers backup and recovery of clusters as well as the configuration of cluster
clients in a NetWorker environment. Topics include cluster components and characteristics,
the procedure for configuring cluster-aware clients and the management of path ownership
with clusters.

akhan@aayan.com
Clustering is a common practice that can help ensure that data or applications are
continuously available to clients on a network. The basic premise of clustering is simple:
two or more nodes (physical hosts) are connected and appear to network users as a single,
highly available system.
When using a clustering application, all nodes in a cluster share one or more disk resources.
In an active/passive cluster, only one of the nodes in the cluster is active at any given time.
The active node is responsible for managing the shared resources. All other nodes in the
cluster are passive nodes. If the active node fails for any reason, one of the passive nodes
will take control of the shared resources.
Clustering can involve more than two nodes and may also involve load balancing. Clustering
can also be configured in active/active arrangements where there are multiple shared
resources and each of the nodes is the active node for one or more resources. This module
covers a basic cluster environment of two nodes in an active/passive configuration.

akhan@aayan.com
A shared resource may be either a set of files or an application. There may be many shared
resources within a cluster. A shared resource within a cluster is referred to by any of
several different names, depending on the clustering software being used. For the
remainder of this lesson, a shared resource is referred to as a virtual service. A virtual
service is always managed by the active node.
A virtual service is not a physical host, but rather a shared resource that each node of the
cluster can access. Each shared resource may be comprised of multiple components, such
as files, processes, data, and so on, and is assigned its own hostname and IP address. It is
seen by hosts outside the cluster as a normal physical host.
During normal operation, the active node manages all communication between the virtual
services and other hosts on the network. If a planned shutdown or failure of the active node
occurs, control of the virtual services is transferred to the other node in the cluster, which
changes from the passive to the active node.
When the failed node is returned to a functional condition, it becomes the passive node and
is available for failover in the event of a failure of the current active node.

akhan@aayan.com
A cluster-aware NetWorker application determines path ownership of the virtual services in
the cluster. With a cluster-aware NetWorker application, NetWorker can back up the shared
resources and write the client file index entries for the virtual client.
Creating a cluster-aware NetWorker application involves DNS preparation and also tasks
that must be run that are applicable to each type of supported cluster environment.
Clustering a NetWorker client involves installing NetWorker client software on each node in
the cluster and making the clients cluster-aware. In addition to creating NetWorker client
resources for each node, one or more client resources are created for each virtual service.
This course provides an overview of the generic steps for configuring NetWorker in a
clustered environment. Procedures for preparing the cluster and for creating cluster-aware
NetWorker clients differ by type of supported cluster environment. For this information,
please refer to the EMC NetWorker Cluster Integration Guide.

akhan@aayan.com
Clustering a NetWorker client involves installing NetWorker client software on each node in
the cluster in the same location on a private disk. Cluster integration support for the
NetWorker client is provided by the NetWorker extended client installation package. In
addition to the base client installation package, the extended client must also be installed
on all physical nodes in the cluster.

akhan@aayan.com
A cluster-aware NetWorker client is aware of the clustered IP address and shared file
systems in a cluster. This allows you to create virtual client resources to back up the shared
resources.
With most cluster types, you run a cluster configuration script to configure a cluster-aware
client. This slide shows the location of the script by type of cluster environment. Note that
there may be additional steps to create a cluster-aware client depending upon the cluster
type.
For MSFCS clusters, NetWorker supports backup and recovery of file system data on
Windows Server 2012 and Windows Server 2012 R2 file servers configured for Windows
Continuous Availability with Cluster Shared Volumes (CSV).
For detailed configuration steps for cluster-aware clients, please refer to the Configuring the
Cluster chapter in the EMC NetWorker Cluster Integration Guide.

akhan@aayan.com
NetWorker client resources are created for each node in the cluster as well as for each
virtual service. In a cluster environment with two nodes and one virtual service, you
configure at least three NetWorker client resources.
Each physical node backs up data residing on its own local disks. You create NetWorker
client resources for the physical nodes as you would a non-clustered backup client.
A virtual client backs up the shared clustered data. If the cluster has multiple virtual
services which require multiple hostnames and IP addresses, it is necessary to create at
least one NetWorker client resource for each virtual service. Specify the root user or system
account for each physical node within the cluster in the Remote Access field. This allows
recoveries of the virtual client to be performed by the active node, regardless of which node
is currently active. Specify any environment variables in the Application Information field.
For example, you might optionally specify a preferred server order list for a CSV backup.
When creating the client resources, make sure that the Save set attribute of the virtual
client(s) and the nodes account for all data, shared and non-shared, on the systems.
Ensure that the virtual client is backing up all shared data and that the NetWorker client
resource of each node includes the local data on that host. Although the All save set is
supported for a virtual client, it is recommended that you use the All save set only for the
nodes. When All is specified for a node, it does not include the shared data.
As with any NetWorker client, multiple client resources may be configured for each node
and virtual service. Remember that each virtual client has its own hostname and IP address
and that all hosts must be listed in the appropriate name service database. It is important
that reverse lookups behave correctly.

akhan@aayan.com
The clustered data is backed up as though it belongs to the virtual client. When the virtual
client backs up, its CFI is updated, regardless of which node is active.
Recovery of data backed up from a private disk on a physical node follows the same
procedures as for a non-clustered host. If a recovery of data from the shared resource is
required, whichever node is active can perform the recovery. Ensure that the Remote
Access attribute of the virtual client resource contains an entry for each physical cluster
node.
In a UNIX cluster, the virtual client’s shared data is mounted on the active node. To recover
data belonging to the virtual client, a normal browsable or save set recovery is performed
from the active node. However, the virtual client is selected as the source client and the
data must be relocated to the directory on the active node where the shared data is
mounted.
To recover data to the virtual client in a Windows environment, the active node is the
administering client in the recovery and the virtual client is both the source and destination
clients.

akhan@aayan.com
In a clustered environment, NetWorker must determine which save sets are owned by the
nodes and which save sets are owned by the virtual client(s). The criteria used to determine
save set ownership are called path ownership rules. These rules determine which CFI the
save set tracking information is written to. If NetWorker determines that a save set defined
in a client resource is not owned by that client, NetWorker might not back up the save set
during a server-initiated backup. This prevents a clustered host from writing to multiple
client file indexes which can cause recovery problems.
To determine if an incorrect CFI will be used, preview a server-initiated backup of each

node and virtual client after the cluster is configured. Monitor the save sets that are backed
up and watch which CFI is updated when a client is backed up. Use the mminfo command
to verify that the backup information saves to the correct CFI. If a backup of a node results
in the virtual client’s CFI being updated or, conversely, a backup of a virtual client results in
the active node’s CFI being updated, difficulties may result when browsing for files during a
recovery.
To ignore path ownership rules and force a back up of file systems that a client does not
own, you can create an empty pathownerignore file in the directory containing the
NetWorker binaries. This file is created on each node. Its existence forces NetWorker to
back up all specified save sets regardless of ownership conflicts. It is important to realize
that creating the pathownerignore file is not recommended, but may be necessary if the
cluster resources are incorrectly configured. Remember that this file does not override the
path ownership rules, it simply ignores them. This may result in tracking information being
sent to an incorrect CFI, possibly causing problems when performing browsable recoveries.

akhan@aayan.com
If you create a pathownerignore file, check whether the save set tracking information is
written to the correct client file index. If it goes to the wrong CFI, you can force the tracking
information to go to a specific client’s index.
To force save sets to be written to a specific CFI, it is necessary to modify the Backup
command attribute of the client whose data is being sent to the incorrect CFI. The
following command should be placed in this attribute: save –c client_name where
client_name is the hostname of the client being backed up.
If you are backing up an application server using a NetWorker module, make sure that you
are using the -c client_name arguments (or similar arguments) required by the NetWorker
module. Refer to the applicable module documentation for details on options for the backup
command used by each NetWorker module.
Note: Use the mminfo command to confirm that the backup information saves to the
correct client file index. (Details from the NetWorker Administration Monitoring window
indicate that backups correspond to the physical client where you configured the save sets.)

akhan@aayan.com
It is often desirable to back up clustered data to devices managed by the cluster nodes,
thereby avoiding TCP/IP traffic. NetWorker supports the environment where each node in a
cluster is configured as a NetWorker storage node. NetWorker client and storage node
software are installed on each node, and each node controls one or more backup devices.
The virtual client is backed up to a device managed by the active node. All devices within
the cluster are created as remote devices. By default, data from a virtual client is backed up
to the first storage node listed in the Storage Node attribute of the virtual client resource.
To tell NetWorker to back up to the devices attached to the current physical host, use the
storage node keyword curphyhost as the only value in the Storage Node attribute.
In the configuration shown on the slide, both cluster nodes are functional storage nodes.
The active node (Node A) backs up its local save sets to its own backup device, and the
passive node (Node B) backs up its local save sets to its own backup device. Save sets
belonging to the virtual client are backed up by the active node (Node A) to a device
controlled by the active node.
Additionally, clients outside the cluster can be configured to direct their save sets to any
NetWorker storage node residing within the cluster. Since the storage node is not a shared
resource, if either Node A or Node B fails, the storage nodes list of each physical or virtual
client backing up to the failed node will be consulted to determine where to redirect the
backup.
Although some clustering products have the ability to fail over backup devices between
nodes, it is beyond the scope of this course.

akhan@aayan.com
This module focused on recovering Windows hosts and configuring NetWorker in cluster
environments. Specifically, we discussed backup and recovery for Windows BMR with
NetWorker as well as the configuration, backup and recovery of clustered NetWorker clients.

akhan@aayan.com
This module focuses on the recovery of control data residing on the NetWorker server and
the NetWorker Management Console server.

akhan@aayan.com
Module: Recovering NetWorker and NMC Servers 1
This lesson focuses on protecting the NetWorker server and NMC databases. We look at the
Server Protection policy, backing up the NetWorker server and NMC databases, and the
NetWorker bootstrap save set.

akhan@aayan.com
The NetWorker server and NMC server are protected with the Server Protection policy. The
workflows in the policy are configured to run daily.
When you install the NetWorker server, the installation process creates the default Server
Protection policy for NMC and NetWorker server backup and maintenance activities. The
Server Protection policy includes the Server backup and NMC server backup default
workflows. You can edit and change the default policy and associated workflows and
actions, and also create your own policies and workflows for NetWorker and NMC server
protection.
Once you install the NMC server and connect to the NMC GUI for the first time, the Console
Configuration wizard prompts the administrator to configure the NetWorker server that
will back up the NMC server database.

akhan@aayan.com
The Server backup workflow performs two actions: Expiration and Server database backup.
The Expiration action marks expired save sets as recyclable.
The Server db backup action performs a bootstrap backup and a backup of the client file
indexes, by default. The data in the bootstrap backup enables you to perform a disaster
recovery of the NetWorker server. The bootstrap backup contains the media database,
authentication service database and the resource files (resource database and the Package
Manager database).
The Server Protection group is assigned to the Server backup workflow. This contains a
dynamically generated list of the client resources for the NetWorker server. By default, the
Server backup workflow is configured to back up to the Default pool. This should be
changed in the Server db backup action to a configured pool in your backup environment.
As a best practice, it is recommended to write all bootstrap and Client File Index backups to
a dedicated pool.
The Server backup workflow is scheduled to start daily at 10 a.m.

akhan@aayan.com
The NMC server backup workflow performs a traditional backup of the NMC database. The
workflow is scheduled to start a full backup daily at 2 p.m. The default NMC server group
which contains the NMC server is assigned to the NMC server backup workflow. By default,
this workflow is configured to back up to the Default pool. This should be changed in the
NMC server backup action to a configured pool in your backup environment.
Notes:
The NMC server database backup only supports full and skip backup levels.

akhan@aayan.com
The bootstrap backup is required for recovery of the NetWorker server databases. In the
event that a recovery is required, you need to know its save set ID (SSID) and the name of
the volume on which it is located. There are several ways to obtain information about
bootstrap backups. These methods include notifications, log files, and using mminfo.
The Server backup Action report, displayed here, is generated when the Server db
backup action runs. The report shows the backup save sets and the Bootstrap backup
report, including the save set id and volumes for recent bootstrap save sets. This report is
included in the notification when the workflows and actions for the Server Protection
policy complete. By default, this notification is appended to the file,
policy_notifications.log in the …\nsr\logs directory, along with notifications sent to
that file by all other running policies.
To isolate the notifications about server protection, you can change the notification for the
Server Protection policy to go to another file or to go to email. You can also just show
information about the Server db backup action by configuring a notification at the action
level that will be created when the action completes. This is shown on the slide.
Any way you choose to receive the Server backup Action report, it is important to ensure
that you are regularly receiving the bootstrap information and filing it in a safe location for
later reference in case a recovery is necessary.

akhan@aayan.com
You can also find information about bootstrap save sets in the log messages for individual
operations of the Server db backup action. These logs are available on the NetWorker
server in directories under …\nsr\logs\policy\Server Protection\Server backup. You
can also look at the messages for individual runs of this action by highlighting the Server
backup workflow in the Monitoring window, selecting Show Details and drilling down to
the full log message for the desired Server db backup action. You can choose to print or
save the message.
Another way to locate the bootstrap save set is with the mminfo – B command. This
command displays a list of bootstrap save sets with their save set ID and volume
information. The exact location (file and record number) of the save set on the volumes is
also displayed when tape media is used.

akhan@aayan.com
This lesson covers the procedures for recovering the NetWorker server, including recovering
the NetWorker bootstrap data as well as the client file indexes. Also, we discuss recovering
of media database, resource database and NMC database.

akhan@aayan.com
The bootstrap save set is used by nsrdr to recover the NetWorker server.
The slide summarizes the steps needed to perform a complete recovery of a NetWorker
server. The steps assume that the original server is no longer available and a new
NetWorker server is being configured.
1. Before installing NetWorker, verify the functionality of the server it is being installed
on.
2. To recover the bootstrap save set, NetWorker must already be installed. Thus, it is
necessary to perform a default installation of the NetWorker server. The original
default resource files will be installed, in addition to an empty media and jobs
database.
3. After starting all the NetWorker daemons/services, the only customization you must
perform to the default NW installation is to create a device resource for the device
used to recover the bootstrap save set.
4. Use nsrdr to recover the bootstrap save set and optionally recover the client file
indexes.
Note: Although recovery of the bootstrap save set is required during recovery of a
NetWorker server, recovery of individual client file index save sets is optional. A client file
index provides a browsable interface during recovery, as well as the ability to easily recover
to a particular point in time. If these benefits are not immediately necessary, you may
decide not to recover the CFI of individual (or all) clients, especially if an index is extremely
large. If you choose not to recover a client’s index, you must create an empty CFI prior to
the next backup of the client.

akhan@aayan.com
1. All NetWorker processes must be running prior to executing nsrdr.
2. Configure a NetWorker device resource and insert the volume containing the bootstrap
save set into the device. Make sure you do not label the volume as you will erase all
data on it.
3. Using nsrdr is the only method of recovering the bootstrap save set.
nsrdr is interactive, prompting for the SSID of the bootstrap save set being recovered. It
also prompts you to replace the existing resource configuration database folder, to replace
the NetWorker Authentication Server database file, and to recover the client file indexes.

akhan@aayan.com
There may be situations where the entire NetWorker server does not need to be recovered.
The media database may be damaged, corrupted, or missing important information, but the
resource directory is perfectly fine. Conversely, NetWorker resources may have been
accidentally or maliciously deleted or modified, requiring that only the resource directory be
recovered.
Regardless of which component is missing, it is recommended that you restore both

together to ensure consistency between the databases. Use nsrdr to recover the bootstrap
save set thus restoring the media database and resource files.
To insert missing volume or save set information into the media database, the scanner
command is used to scan a volume and insert information directly into the media database
(and optionally, client file indexes) while reading the volume.
The conditions shown in the slide are discussed on the following pages.

akhan@aayan.com
The slide summarizes the steps needed to perform a recovery of the NetWorker control data
with nsrdr. NetWorker must be running in order to run nsrdr.
1. Shutdown the NetWorker processes, if running, and rename the existing /nsr/mm and
/nsr/res directories. By renaming the directories, you will have a copy of the
directories as they were before the recovery is run. This also allows NetWorker to start
even though the media database or resource files may be corrupted or damaged.
2. Start all NetWorker processes/services. NetWorker will create an empty media
database and a resource directory with a default set of resources.
3. Next, create a device resource for the device that will be used to recover the bootstrap
save set. Do NOT label the volume containing the bootstrap as you will erase all the
data on the volume. When creating an AFTD or Data Domain device, create the device
resource that has the volume containing the bootstrap save set mounted in it. Do NOT
label the device. Close NetWorker Administration.
4. Use nsrdr to recover the bootstrap save set and optionally recover the client file
indexes and NetWorker Authentication Service database. Running nsrdr will overwrite
the /nsr/mm directory. You will have the option to keep the /nsr/res folder (not
recover the resource files) or replace the resource files with recovered resource files.
If you choose to replace the resource files, nsrdr will save the existing /nsr/res
folder as res.<timestamp>.

akhan@aayan.com
If you do not know the volume and save set ID of the most recent bootstrap save set, here
are some additional methods of locating the information.
The daemon.raw file in the NetWorker server log directory may contain an entry showing
which volume the most recent bootstrap save set was written to.
If the previous method does not provide a volume name, another option is to use the
scanner command with the -B option to locate information about bootstrap save sets. This
method requires that you guess which volume contains the most recent bootstrap save set
and manually load it into a drive before running scanner.
scanner -B reads an entire volume and displays information about the most recent
bootstrap save set found. Depending on the size of the volume and the speed of the device,
this process can sometimes be lengthy. If the most recent bootstrap save set on the
volume is not the one you want, load another volume into the drive and run scanner again.
Note: scanner reads the volume directly without using nsrmmd. Therefore, it is not
necessary that NetWorker services be running.

akhan@aayan.com
After a bootstrap recovery, it is possible that some volumes may contain save sets that are
newer than the recovered bootstrap. If any backup or clone processes wrote data to any of
the volumes after the bootstrap save set was created, the recovered media database will
not contain information about the save sets. These save sets could potentially be
overwritten. The volume flag, S, indicates that save sets on the volume may need to be
scanned into the media database. When this flag is set, the volume is “locked” and a
recover space operation will not be performed for disk volumes.
By default, nsrdr will mark all disk volumes in the database as read-only and scan needed
to indicate that you must scan the save set information back into the media database
before you can use the volume. For tape volumes, if you suspect that backups or clones
were written to those volumes after the latest bootstrap was created, running the nsrdr
command with the –N option will cause the scan needed flag to be set on all volumes.
To find out if there are any volumes with save sets that need to be scanned, select Tape
Volumes or Disk Volumes from the NetWorker Administration Media window. You can
manually change the mode of a volume to scan needed by right-clicking the volume in the
right pane and selecting Mark Scan Needed > Scan is needed.
To clear the scan needed volume flag for disk volumes, first run the scanner –i device
command. For tape volumes, when the scan needed mode is set and you try to mount a
tape volume that has save sets newer than what is recorded in the media database, you will
receive a message with the last known file and record number in the media database. If
you suspect that there were save sets that were saved after the last bootstrap backup, use
this information with the scanner –f file –r record –I device command to scan the
volume from the last known record numbers. Then, to remove the scan needed flag from
the volume, from the NetWorker Administration Media window, right-click the volume and
select Scan is NOT needed from the Mark Scan Needed window.
See the NetWorker Command Reference Guide and the NetWorker Administration Guide for
more information.

akhan@aayan.com
When recovering the bootstrap save set with nsrdr, you have the option to recover CFIs
after the recovery operation restarts the NetWorker services. You may choose to skip this
step if the CFIs are not immediately necessary. Create an empty CFI prior to the next
backup of a client. You can then run nsrdr later to recover the CFIs for selected clients.
To recover only specific CFIs, run nsrdr with the –I command line option to specify a list of
clients or use the –f option to specify an input file.
To recover specific client file indexes:
1. Verify that the NetWorker server daemons/services are running.
2. Execute the nsrdr –I client_name or nsrdr –f client_list_input_file

command.
See the NetWorker Command Reference Guide for more information.
Important: When recovering an index that already contains entries, the entries being
recovered are merged with the existing entries.

akhan@aayan.com
To recover the Console server database:
1. Stop the GST service (gstd) if it is currently running.
2. At a command prompt, enter the recoverpsm command:

recoverpsm [ -s server ] [ -c client ] [ -d destination ] [ -p pass-
phrase ] [ -t time ] –[ hfO ] Staging Directory
3. Restart the Console server.
For Linux hosts, if you did not install NMC server software in the default path /opt/lgtonmc,
add the NMC_install_dir/bin directory to the LD_LIBRARY_PATH environment variable.
Note: For more information on recoverpsm, please refer to EMC NetWorker Administration
Guide and the EMC NetWorker Command Reference Guide.

akhan@aayan.com
In these lab exercises, you will:
• Configure and run the Server Protection policy workflows
• Perform a recovery of the bootstrap and CFI save set
• Perform a recovery of the media database
• Perform a recovery of NMC database
• Verify that the recoveries were successful

akhan@aayan.com
This module focused on the recovery of control data residing on the NetWorker server and
the NetWorker Management Console server.

akhan@aayan.com
This course covered topics related to the installation, configuration, maintenance and
management of a NetWorker backup environment.

akhan@aayan.com
akhan@aayan.com

MR-1CP-NWIM Student Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MR-1CP-NWIM Student Guide

Transféré par

Droits d'auteur :

Formats disponibles

NetWorker

Implementation and Management

EMC Education Services

Revision Date: February 2016

Revision Number: MR-1CP-NWIM.9.1

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Recovery is the process of restoring data to a given point in time.

Copyright 2016 EMC Corporation. All rights reserved.

NetWorker storage nodes are dedicated hosts with direct-attached or SAN/LAN-accessible

Copyright 2016 EMC Corporation. All rights reserved.

A workflow defines an action or set of actions to be performed on an assigned protection

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

In a UNIX environment, nsrexecd is started automatically during system boot up. In a

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

httpd – Apache httpd is the embedded web server.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

All the files under /nsr/mm make up the media database.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

The Administration Guide describes how to configure and maintain NetWorker.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Disk Space Requirements

During backups and recoveries, there is considerable RPC communication between

Copyright 2016 EMC Corporation. All rights reserved.

The multi-tenancy feature is enabled by configuring a restricted datazone resource on the

Note: It is recommended that multi-tenancy be configured during installation of a new

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

One or more INCREMENT lines make up the actual license(s).

The NETWORKER_UPDATE line is required when updating from a previous NetWorker

Note: License files cannot be edited.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.

Copyright 2016 EMC Corporation. All rights reserved.