EMC NetWorker with DDBoost - JANELLE FILKIN, WRITER

EMC Solutions

Abstract

This document details architecture detail, technical

considerations, best practice recommendations, and detailed

configuration for EMC NetWorker backup software deployed in

the XYZ environment.

February 2016

XYZ Detailed Design

EMC NetWorker with DDBoost

Document Control

2

1 Document Control

All the trademarks and registered trademarks referenced within this

document are acknowledged as belonging to their various owners.

Copyright All material published in this document is protected by the

Commonwealth Copyright Act 1968. All rights reserved. No material

may be reproduced, in either part or in whole, in any manner

whatsoever, without the express written consent of EMC.

© 2012 EMC Corporation. All Rights Reserved. This document is

PROPRIETARY and CONFIDENTIAL and may not be duplicated,

redistributed, or displayed to any other party without the express written

permission of EMC.

Use, copying, and distribution of any EMC software described in this

publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC

Corporation Trademarks on EMC.com.

If changes are required for this document, please refer to the

document authorities in Table 1.

Table 1. Contact Details for Proposed Changes

Name Title Email Contact

Number

Janelle

Filkin

Implementation

Delivery

Specialist

Table 2 reflects the creation date, along with any alterations since

inception.

Table 2. Drafting and Release History

Version Date Author Description

0.1 Draft 05/02/2016 Janelle Filkin Initial Draft

0.1 Draft 16/02/2016 First review

0.2 Draft 17/02/2016 Janelle Filkin Responses/acceptance to

first review

0.3 Draft 17/02/2016 Review for release to XYZ

review

Copyright

Document

Authorities

Drafting and

Release History

Document Control

3

Table of Contents

1 Document Control .............................................................................................. 2

Copyright .............................................................................................................................. 2

Document Authorities ......................................................................................................... 2

Drafting and Release History .............................................................................................. 2

2 Introduction ......................................................................................................... 9

Purpose ................................................................................................................................. 9

Scope of Document ........................................................................................................... 9

Audience .............................................................................................................................. 9

Included Hardware and Software .................................................................................. 10

Software Inclusions ........................................................................................................................ 10

Out of Scope ...................................................................................................................... 10

3 EMC Roles and Responsibilities ....................................................................... 11

Systems Engineer (SE) ........................................................................................................ 11

Solutions Architect (SA) ..................................................................................................... 11

Project Manager (PM) ...................................................................................................... 11

Implementation Delivery Specialist (IDS)........................................................................ 11

Customer Engineer (CE) ................................................................................................... 11

Storage Operations Specialist (SOS) ............................................................................... 11

Customer Support Centre (CSC) ..................................................................................... 11

4 Document Considerations .............................................................................. 12

Assumptions ........................................................................................................................ 12

Customer Expectation ...................................................................................................... 12

Conventions ....................................................................................................................... 12

Typographical Conventions ........................................................................................................ 12

Capacity Metrics ........................................................................................................................... 12

5 Solution Overview ............................................................................................. 14

Solution Objectives ............................................................................................................ 14

Solution Goals ................................................................................................................................. 14

Solution Overview .............................................................................................................. 14

6 NetWorker Components .................................................................................. 18

NetWorker Components................................................................................................... 18

Storage Performance Sizing for NetWorker Components ..................................................... 18

Console Server and User Interface............................................................................................. 19

NetWorker Server ........................................................................................................................... 20

NetWorker Storage Node ............................................................................................................. 21

NetWorker Client ............................................................................................................................ 23

Document Control

4

NetWorker Performance................................................................................................... 24

Server Parallelism ........................................................................................................................... 24

Multiplexing ..................................................................................................................................... 24

Client and Group Parallelism....................................................................................................... 25

NetWorker Backup Resources ......................................................................................... 26

Clients, save sets, and Client Resources ................................................................................... 26

Backup Groups and Scheduling ................................................................................................ 26

Browse and Retention Policies .................................................................................................... 27

Directives ......................................................................................................................................... 28

Media Pools .................................................................................................................................... 29

Save set Staging ............................................................................................................................ 30

Cloning Considerations .................................................................................................... 30

Clone Methods .............................................................................................................................. 31

Cloning with NetWorker Module for Microsoft Applications ................................................. 32

7 Data Domain Integration ................................................................................ 34

Software Revision Requirements ..................................................................................... 34

Memory and Connection Requirements ....................................................................... 34

Network Considerations ................................................................................................... 35

Firewall Requirements ....................................................................................................... 36

Dedicated Storage Nodes (DSNs) and Direct File Access (DFA) ............................... 36

DD Boost Devices .............................................................................................................. 37

DD Boost Devices and NetWorker .............................................................................................. 37

Virtual Synthetic full backups ........................................................................................... 37

8 Microsoft Integration ........................................................................................ 39

NetWorker Module for Microsoft (NMM) Overview ...................................................... 39

NMM Installation Pre-requisites .................................................................................................... 40

NMM Preconfiguration Checker ................................................................................................. 40

Microsoft Shadow Copy Integration .............................................................................. 40

Data Domain Integration with NMM .............................................................................. 41

NetWorker Software Compatibility ............................................................................................. 41

Direct File Access (DFA) Connectivity ....................................................................................... 42

SQL VDI Integration ........................................................................................................... 42

SQL Server Requirements ............................................................................................................. 42

Supported Backup and Recovery Methods for NMM VDI .................................................... 43

Microsoft SQL Server named log marks ..................................................................................... 44

NMM with SQL VDI Backup Requirements ................................................................................ 45

SQL with NMM VDI Best Practices ............................................................................................... 45

Blackboard application protection methodology ................................................................. 46

Microsoft SharePoint ......................................................................................................... 46

SharePoint Server Requirements ................................................................................................. 46

SharePoint Backups ....................................................................................................................... 47

SharePoint Recovery ..................................................................................................................... 47

FAST Search Server backup and recovery ............................................................................... 47

Document Control

5

SharePoint Server 2013 Apps backup and recovery .............................................................. 47

SharePoint Client Direct ................................................................................................................ 48

SharePoint Archival with EMC SourceOne ............................................................................... 49

User access to archived SharePoint content ........................................................................... 50

Microsoft Active Directory ................................................................................................ 50

Operations supported with Active Directory ........................................................................... 50

Supported Active Directory objects for granular backup and recovery ........................... 50

Active Directory granular backup considerations .................................................................. 51

Advanced Protection Features for Windows ................................................................ 54

Block Based Backups for Windows Servers ............................................................................... 54

Parallel Saves Streams for Windows ........................................................................................... 57

9 Linux and UNIX Integration .............................................................................. 59

Linux and UNIX NetWorker clients.................................................................................... 59

Parallel Save Streams .................................................................................................................... 59

NetWorker Module for Databases and Applications (NMDA) .................................... 59

Basic Capability ............................................................................................................................. 60

Client Direct .................................................................................................................................... 60

NMDA backups to DD Boost devices ........................................................................................ 61

NMDA for Oracle ............................................................................................................... 63

Oracle full and incremental backups ....................................................................................... 63

Backup of Archived Redo Logs .................................................................................................. 63

Control file Auto Backups............................................................................................................. 64

Backup and Restore Optimisation ............................................................................................. 64

Backup Copies ............................................................................................................................... 64

Retention Policies ........................................................................................................................... 65

Save set bundling .......................................................................................................................... 65

Oracle 11gR1 features .................................................................................................................. 66

Oracle 11gR2 features .................................................................................................................. 66

Other Oracle features................................................................................................................... 66

10 VMware vSphere Integration .......................................................................... 68

Virtual Machine Backup Approaches ............................................................................ 68

Client Based .................................................................................................................................... 68

Image based using VADP ............................................................................................................ 68

Image based using EMC Backup and Recovery appliance (VBA) .................................... 69

EMC Backup and Recovery Appliance (VBA) .............................................................. 71

VBA appliance Overview ............................................................................................................ 71

External Proxy Transport Modes .................................................................................................. 72

VBA System Requirements ............................................................................................... 72

Deployment of VBA in the vSphere server................................................................................ 73

VBA Proxy considerations ............................................................................................................. 76

Network and Firewall port requirements ........................................................................ 76

vCenter VBA User Access ............................................................................................................ 76

VBA integration with NMC ........................................................................................................... 79

Document Control

6

EMC Backup and Recovery plug-in for vCenter ..................................................................... 80

11 Isilon Integration ................................................................................................ 83

NAS snapshot operations ................................................................................................. 85

Discovery of non-NetWorker snapshots ..................................................................................... 85

Types of NAS snapshot-based backups .................................................................................... 85

Types of NAS snapshot recoveries .............................................................................................. 87

Snapshot lifecycle policy ............................................................................................................. 88

Recovery Interfaces ...................................................................................................................... 88

12 Management Considerations ........................................................................ 89

NetWorker Management Console (NMC) ..................................................................... 89

Data Protection Advisor (DPA) ........................................................................................ 90

Where DPA fits in the environment ............................................................................................. 91

EMC Data Protection Advisor for Backup................................................................................. 91

NetWorker Licensing ......................................................................................................... 92

NetWorker capacity licensing options and modules ............................................................. 93

User-Based Authorisation .................................................................................................. 94

NMC Authentication ..................................................................................................................... 94

NMC Authorisation ........................................................................................................................ 94

NetWorker Server Authorisation .................................................................................................. 95

Monitoring, Reporting, and Analysis ............................................................................... 98

Alerting ................................................................................................................................ 98

NetWorker SNMP Module ............................................................................................................. 98

Bootstrap Notification ................................................................................................................... 99

13 Firewall Requirements .................................................................................... 100

14 Disaster Recovery ........................................................................................... 102

Windows Bare Metal Recovery (BMR) ..................................................................................... 102

Microsoft Applications .................................................................................................... 104

Clustered Recovery ..................................................................................................................... 104

VMware Virtual Guests ................................................................................................... 104

NetWorker Disaster Recovery ........................................................................................ 105

List of Tables

Table 1. Contact Details for Proposed Changes ........................................................... 2

Table 2. Drafting and Release History .............................................................................. 2

Table 3. Conventions used within this document ........................................................ 12

Table 4. Component Protection Reference ................................................................. 16

Table 5. NetWorker Component IOPS requirements ................................................... 19

Table 6. NetWorker Server configuration ...................................................................... 21

Document Control

7

Table 7. NetWorker Storage Node configuration ........................................................ 22

Table 8. Example Media Pools ....................................................................................... 29

Table 9. Firewall Requirements ....................................................................................... 36

Table 10. Traditional synthetic full versus Virtual synthetic full backups ...................... 38

Table 11. NMM summary of support for backup and recovery .................................. 39

Table 12. SQL Backup Recommendations ..................................................................... 45

Table 13. BBB scenarios...................................................................................................... 55

Table 14. BBB supported OS and Configurations ........................................................... 56

Table 15. BBB unsupported configurations ..................................................................... 57

Table 16. PSS item support ................................................................................................ 57

Table 17. NMDA supported backup levels ..................................................................... 61

Table 18. Guest, VADP and VBA Approach Comparison ............................................ 69

Table 19. VBA Requirements ............................................................................................. 72

Table 20. NetWorker VMware Data Protection tasks .................................................... 74

Table 21. Maximum concurrent sessions per VBA ......................................................... 75

Table 22. Concurrency/parallelism .................................................................................. 75

Table 23. VBA User Account Privilege Requirements .................................................... 77

Table 24. Glossary of snapshots ........................................................................................ 83

Table 25. NAS device support and limitations ................................................................ 83

Table 26. Console Roles ..................................................................................................... 94

Table 27. NetWorker Group Privileges ............................................................................. 95

Table 28. NetWorker Users ................................................................................................. 97

Table 29. NetWorker environment firewall port requirements ................................... 100

Table 30. Components of the ALL save set for Windows Servers .............................. 103

List of Figures

Figure 1. Solution Overview .............................................................................................. 15

Figure 2. High Level NetWorker Backup Flow ................................................................ 18

Figure 3. NetWorker Backup and Clone devices ......................................................... 22

Figure 4. Example VBA policy .......................................................................................... 80

Figure 5. VBA plug-in user interface ................................................................................ 81

Figure 6. NetWorker integration with Isilon snapshots .................................................. 86

Figure 7. Snapshot with rollover - recovery .................................................................... 87

Figure 8. Data Protection Advisor Overview ................................................................. 90

Figure 9. DPA GUI .............................................................................................................. 91

Document Control

8

Figure 10. DPA “Report Card” example reports ............................................................. 92

Introduction

9

2 Introduction

The purpose of this document is to recommend a design of the

NetWorker with Data Domain data protection solution for the XYZ

University (XYZ).

This document will detail the following:

• NetWorker components and associated features. The latest

version of NetWorker will be installed to take advantage of the

more advanced features.

• Data Domain 4200 configuration and integration

• Integration with the following key software and applications:

o Microsoft SQL Server 2005-2012;

o VMware vSphere 5.x;

o EMC Isilon;

o EMC VNX;

o Oracle 11g;

o Blackboard; and

o Microsoft SharePoint 2013.

• The latest version of NetWorker modules will be installed, unless

otherwise noted due to supportability.

EMC Australia (EMC) has been engaged by Technology Partner to

assist in configuring the latest version of EMC NetWorker and add-ons

modules, integrated with 2 x DD4200’s to protect XYZ’s data. This

engagement will cover:

• Recommendations for the NetWorker components, specifically

the NetWorker server, the NetWorker Management Console

server, and Storage Node(s);

• Integrate the NetWorker datazone with DDBoost devices on the

newly acquired DD4200’s;

• Install the latest version of NetWorker on servers in the

environment that will require filesystem backups; and

• Configure features new to NetWorker that will benefit XYZ Data

Protection environment.

The audience for this document is:

• the Technology Partner implementation team for the XYZ

backup infrastructure; and

• XYZ staff, and/or Technology Partner residents responsible for the

ongoing maintenance of the backup infrastructure.

Purpose

Scope of

Document

Audience

Introduction

10

Software Inclusions

NetWorker Server 8.x.x with the following components:

• 52 TB of protected capacity, allowing the deployment of

unlimited client and application modules, including but not

limited to:

▪ NetWorker client modules;

▪ Data Domain Device Enabler;

▪ NetWorker Storage Nodes;

▪ NetWorker Module for Microsoft Applications; and

▪ NDMP protection;

The following components are out of scope in this engagement:

• VNX snapshots and replication.

Included

Hardware and

Software

Out of Scope

EMC Roles and Responsibilities

11

3 EMC Roles and

Responsibilities

This section outlines the roles and responsibilities for EMC personnel.

The SE is responsible for providing technical expertise to the

implementation team for the installation and configuration of EMC

hardware and software products. The SE works closely with the

Solutions Architect (SA) to ensure that the client's solution meets their

technical requirements and operational goals.

The SA is responsible for the design and configuration of the

implementation as well as all associated documentation. The SA is also

responsible for providing technical assistance to the IDS during and post

implementation.

The PM is responsible for coordinating the required activities to deliver

the clients solution. The PM interfaces closely with all roles as well as the

client where required to facilitate this process.

The IDS is responsible for the installation and configuration of EMC

software products at the client's site. This also includes complex storage

system configuration, Storage Area Networks (SANs), and layered

software functionality, e.g. Host Integration and Replication.

The CE is responsible for the installation of EMC hardware products at

the client's site. The CE coordinates troubleshooting to ensure resolution

of configuration issues in a timely manner and is responsible for

certifying client site readiness.

The SOS is responsible for on-site day-to-day management of

configured EMC hardware and software products. This may include a

wide range of activities including capacity and performance reporting,

monitoring, storage provisioning, and coordination of firmware and

software updates.

The EMC CSC provides technical assistance during implementation and

post implementation maintenance.

Systems Engineer

(SE)

Solutions

Architect (SA)

Project Manager

(PM)

Implementation

Delivery

Specialist (IDS)

Customer

Engineer (CE)

Storage

Operations

Specialist (SOS)

Customer

Support Centre

(CSC)

Document Considerations

12

4 Document Considerations

This document assumes the reader is familiar with basic backup

methodology.

It is expected that:

• this design document will provide the key design concepts and

decisions for the XYZ backup environment; and

• EMC best practices and recommendations are used to provide

XYZ with a scalable and available system architecture.

Typographical Conventions

Table 3 details the typographical conventions used within the

document.

Table 3. Conventions used within this document

When you see Meaning

bold The name of a button, field, key, page and so

on.

Emphasis Another part of the current document or an

external document has been referenced.

Computer

Text The text is generated by the computer, a piece

of code, a command, or something that the user

must type.

‘bold’ A directory, document, file or window name,

server name, domain name, drive, attributes.

Capacity Metrics

Storage capacity is generally expressed in units such as Megabytes

(MB), Gigabytes (GB) or TB, however there are two standards for

defining these units.

The units may be defined in terms of base-2 numbers. These numbers

are used in this design document for usable capacity:

• 1 Mebibyte (MiB) = 1,024 x 1,024 bytes (or 220 bytes).

• 1 Gibibyte (GiB) = 1,024 x 1,024 x 1,024 bytes (or 230 bytes).

• 1 Tebibyte (TiB) = 1,024 x 1,024 x 1,024 x 1,024 (or 240 bytes).

The units may be defined in terms of base-10 numbers. These numbers

are used in this design document for physical hard drive and raw

capacity figures.

• 1 MB = 1,000 x 1,000 (or 106 bytes).

• 1 GB = 1,000 x 1,000 x 1,000 (or 109 bytes).

Assumptions

Customer

Expectation

Conventions

Document Considerations

13

• 1 TB = 1,000 x 1,000 x 1,000 x 1,000 (or 1012 bytes).

Solution Overview

14

5 Solution Overview

Solution Goals

The aim of this solution is to improve XYZ’s existing data protection

system, while integrating with the new storage infrastructure.

The solution design has taken into consideration XYZ requirements, as

well as product specific and environmental best practices to provide:

• simplification and ease of backup management;

• future capacity growth in production data;

• ease of data recovery;

• dense virtualised infrastructure backup and recovery;

• centralised monitoring and reporting; and

• Disaster Recovery (DR) capability.

The solution incorporates a single NetWorker datazone consisting of:

• a virtualised Windows 2008 NetWorker Server;

• virtual storage nodes, if required, at each data centre to assist

with backup data redirection;

• a physical Storage Node attached to a physical tape library for

offsite, long term storage;

• an EMC Data Domain 4200 (DD4200) appliance at each site.

Backups will be directed to one DD4200 and then replicated

(cloned) to the DD4200 at the other site for offsite protection.

Backups and replication use source based deduplication to

reduce network traffic and improve backup and replication

performance;

• Application consistent data protection for:

▪ the Microsoft SQL database servers using the NetWorker

Module for Microsoft (NMM);

▪ non-Windows database applications, such as Oracle;

• VMWare, using a mix of guest backups (role specific) and VADP

image with VBA (VMware backup appliance). Both options will

be addressed in the document for review.

Recovery of online data will be performed from the Data Domain Boost

devices, direct to clients that have a direct path to the Data Domain.

Figure 1 provides a graphical overview of the NetWorker solution.

Solution

Objectives

Solution

Overview

Chapter 5: Solution Overview

15

Figure 1. Solution Overview

Table 4 provides, at a high level, the EMC software and/or appliance

that will be used to protect each component in the XYZ environment,

requiring protection. In some instances, multiple options will be

referenced as an advanced feature of NetWorker might be more

suited to the particular servers.


16

Table 4. Component Protection Reference

Component Protection Module(s) Refer to section

Virtual

NetWorker

Server

NetWorker Server and NMC NetWorker

Components

Virtual and/or

Physical Servers

running SQL 2008

and 2012 *2014*

NetWorker Module for

Microsoft Applications (NMM)

• SQL VDI

SQL VDI Integration

Blackboard

Application

NMM and VNX Snapshots

• SQL VDI for SQL component

• VNX snapshots (not

covered in this document)

SQL VDI Integration

Virtual and/or

Physical Servers

running Oracle


Databases and Applications

(NMDA)

• Oracle Component

NMDA for Oracle

Windows VM

guest file system

backups

• NetWorker VMware Backup

Appliance (VBA)

• Block Based Backups

• Parallel Save Streams

VMware vSphere

Integration

Block Based

Backups for

Windows Servers

Parallel Saves

Streams for

Windows

Linux VM guest

file system

backups

NetWorker VMware Backup

Appliance (VBA)

Parallel Save Streams

VMware vSphere

Integration

Parallel Save

Streams

Virtual and/or

Physical Servers

running

SharePoint 2013



• SharePoint with VSS

Microsoft SharePoint

Virtual and/or

Physical Servers

running Active

Directory



• Active Directory

Component

Microsoft Active

Directory


17

Component Protection Module(s) Refer to section

Physical

Microsoft 2003+

filesystem

backups

• NetWorker client

• Block Based Backups

(2008+)


(2008+)

Clients, save sets,

and Client

Resources

Block Based

Backups for

Windows Servers

Parallel Saves

Streams for

Windows

Physical Linux

Servers (RHEL,

Debian, SLES,

Ubuntu)

• NetWorker client


Clients, save sets,

and Client

Resources

Parallel Save

Streams

Isilon residing

data

NetWorker Snapshot

Management (NSM)

• NSM and NDMP for NAS

NAS snapshot

operations

Chapter 6: NetWorker Components

18

6 NetWorker Components

This section details the NetWorker software components and technical

considerations that relate to the base NetWorker solution, specifically:

• NetWorker components;

• NetWorker performance;

• NetWorker backup resources; and

• Cloning Considerations.

A NetWorker environment is based around a set of roles that can be

assigned to one or more systems to meet infrastructure and application

backup requirements. The configuration, layout, and scale of these

components are dependent upon the requirements for backup

ingestion, network latency, bandwidth, and infrastructure availability.

Figure 2 provides a high-level overview of the backup workflow across

the NetWorker roles.

Figure 2. High Level NetWorker Backup Flow

Storage Performance Sizing for NetWorker Components

When sizing a NetWorker environment, disk performance is essential to

the overall performance of the NetWorker application. Table 5 details

an indicative figure for each of the NetWorker components, these

figures are based on a small, medium and large NetWorker

environment which is defined as follows:

• A small NetWorker server environment is considered to have less

than 100 clients, or 100 concurrent backup sessions;

NetWorker

Components


19

• A medium NetWorker server environment is considered to have

more than 100, and up to 400 clients or 250 concurrent backup

sessions; and

• A large Networker server environment is considered to have

more than 400 clients, or 500 concurrent backup sessions.

Table 5. NetWorker Component IOPS requirements

Type of operation Small NetWorker

environment

Medium

NetWorker

environment

Large

NetWorker

environment

Concurrent backups 30 80 170

Bootstrap backups 50 150 400

Backup group start-up 50 150 250

Volume management 0 0 100

Large NDMP backups 100 100 200

Standard daily

maintenance tasks

40 75 100

Large internal

database

maintenance

0 100 200

Purge Operations 30 100 200

NMC Reporting 50 75 100

Data Protection

Advisor (DPA)

Reporting

50 100 250

Recovery 30 200 500

Design Decision

XYZ, with less than 200 clients in their backup environment, would be

considered a medium sized environment.

Console Server and User Interface

The NetWorker Management Console (NMC) server role is the conduit

for user management, reporting, and monitoring of NetWorker Servers

and Clients. An administrator utilises the Console User Interface,

accessible via a web browser on any desktop or server.

Design Decision

The NMC Server will be hosted on the same Virtual Machine (VM) as the

NetWorker Server.


20

NetWorker Server

A NetWorker Datazone consists of a single NetWorker Server and the

associated clients (and storage nodes). The NetWorker Server role runs

a database and associated system services to provide backup and

recovery capability for all NetWorker Clients within a NetWorker

Datazone.

The number of NetWorker Servers and therefore datazones is

dependent upon the backup requirements of the environment,

including potential isolation of multiple tenants.

Scalability and infrastructure requirements of the NetWorker Server must

be identified to ensure the server will meet business requirements. The

infrastructure requirements to meet are:

• CPU requirements;

• NetWorker database performance;

• server memory requirements; and

• system bus requirements.

CPU requirements are based around the ability of the server to handle

standard services, NetWorker services, and backup and restore jobs.

NetWorker database performance is crucial as incorrect scoping of the

database can lead to I/O starvation and reduce the capability of the

server. It is recommended to provide sufficient IOPs to cater for:

• Concurrent Backups;

• Bootstrap and Index Backups;

• Backup Group Startup;

• Volume Management;

• Daily Maintenance Tasks;

• Internal Database Maintenance;

• Purge Operations;

• NMC and DPA Reporting;

• Recovery; and

• Growth.

Design Decision

It is recommended for XYZ to utilise NetWorker Capacity Based

Licensing (refer to the NetWorker Licensing section) and to host the

NetWorker server/NMC component on a VM with the specifications

defined in Table 6.

When considering the required IOPS, the NetWorker server will only be

used to perform NetWorker Server operations, with the exception of

Index and Bootstrap backups utilising the Storage Node role. Backup


21

data traffic of clients incapable of Client Direct backups, will utilise

devices attached to a Storage Node, not the NetWorker server.

The values in Table 6 take into account housing NMC on the NetWorker

server.

By utilising a VM, the NetWorker Server is afforded local High Availability.

All vCPU and vRAM will be reserved to prevent resource contention.

Table 6. NetWorker Server configuration

Host Information Configuration

Name

IP Address Cannot use DHCP

Primary Location

Server Vendor VMware Inc

Server Model VMware Virtual Platform

CPU # 4

CPU Speed ~2500 Mhz

RAM (GB) 8 - 16 GB

NIC # 1

NIC Speed 10GbE recommended

32/64 Bit 64-bit

Operating System Windows Server 2008 R2 Enterprise

Primary DNS suffix

# of Disks 1 disk for OS (usually C:\)

1 disk for NetWorker = ~500 GB to 1 TB

NetWorker Storage Node

The NetWorker Storage Node role provides the engine for backup from,

and recovery to NetWorker Clients. As the number of Storage Nodes

increases, so too does the ability to perform more simultaneous

backups across a Datazone.

When the NetWorker Server or a NetWorker Client initiates a backup,

the NetWorker Client sends data to the NetWorker Storage Nodes that

are connected to disk or tape based devices used for data ingestion.

Likewise, when data is retrieved, the client requests this data from the

Storage Node, which is then retrieved from devices attached to the

Storage Node and sent back to the NetWorker Client.


22

Table 7. NetWorker Storage Node configuration

Host Information Configuration

Name

IP Address Cannot use DHCP

Primary Location

Server Vendor VMware Inc

Server Model VMware Virtual Platform

CPU # 4

CPU Speed ~2200 Mhz

RAM (GB) 26 GB

NIC # 1

NIC Speed 10GbE

32/64 Bit 64-bit

Operating System Windows Server 2008 R2 Enterprise

Primary DNS suffix

Primary Use Will be used, for backup and recovery, to

direct traffic to/from the Data Domain for

clients that do not have a direct path to the

Data Domain devices.

Secondary Use Will be used to rollover Isilon snapshots to data

domain backup devices.

Figure 3. NetWorker Backup and Clone devices


23

Design Decision

1x NetWorker storage node is recommended in the environment. This

storage node will be the existing physical server, controlling the SAN

attached tape library.

For ease of configuration and management, all backups will be

directed to DD Boost devices on one DD4200. This backup data will

then be cloned (replicated) to the remote DD4200 utilising NetWorker

Clone Controlled Replication, which takes advantage of replication at

a Data Domain level for fast, offsite, copies.

As NetWorker uses Clone Controlled Replication (CCR), the cloned

data will not actually travel via the storage nodes, but directly between

Data Domains.

The physical storage node will ‘own’ all devices on both Data Domains.

“Backup” device types will be configured on one Data Domain.

“Backup Clone” devices will be configured on the second Data

Domain.

Clones from the Data Domain to tape will be read from the Data

Domain housed in the same Data Centre as the tape library. Refer to

Figure 3 for a more detailed view of the backup and replication/clone

paths.

This configuration is sufficient under the current environment, as most

clients will be utilising the “Client Direct” feature, bypassing the storage

node to send their data direct to the Data Domain.

NetWorker Client

The NetWorker Client role is required on any server where data will be

backed up or restored, separate to VMWare image backups. The

Client communicates with the NetWorker Server and Storage Node

roles to schedule backups and send or retrieve backup data.

The NetWorker Client can also be used to perform user-initiated

backups and restores if permitted.

Design Decision

The NetWorker Client will be provisioned on all systems that require

backup and restore capability. Clients, whose operating system is

supported by NetWorker, will have the latest version installed to enable

them to send backup data direct to the Data Domain DDBoost devices

(DFA).

If a VMware client requires application protection, the NetWorker client

will be deployed for complete application protection, resulting in a VM

guest backup being performed by the NetWorker client. Refer to the


24

VMware section (VMware vSphere Integration) for options on

protecting VM servers.

NetWorker is developed to provide a high performance, enterprise

backup system that can scale to meet large data holding requirements

whilst allowing for a low Recovery Time Objective (RTO).

NetWorker contains key performance features that allow the software

to meet this objective.

Server Parallelism

Server Parallelism allows multiple save sets from single or multiple

NetWorker Clients to flow to the Server and Storage Nodes at the same

time. The more save streams the server can accept, the more data that

can be ingested, depending on the speed of the Storage Node

devices and the back-end storage system.

Server parallelism is not used to control the initiation of backup jobs, but

as a final limit of sessions accepted by a backup server. The server

parallelism value should be as high as possible while not overloading

the NetWorker Server, storage nodes or ingestion point.

There is a relationship between the value of server parallelism and the

degree to which an administrator can exploit the backup efficiencies

of multiplexing. Since server parallelism defines the total number of

client save streams that are accepted at one time, it also defines the

number of save streams available for multiplexing to devices.

When the backup target is a Data Domain device, the server

parallelism setting should take into account the Data Domain

maximum number of streams.

Design Decision

The DD4200 allows a total of 540 simultaneous streams; with 2 x DD4200

recommended for the environment, the theoretical setting for the

NetWorker Server parallelism, could be 1080. Under capacity based

licensing, the NetWorker server can have a maximum of 1024

simultaneous streams which should be more than adequate for the XYZ

environment.

Multiplexing

Multiplexing enables multiple save streams to be written to the same

Storage Node device at the same time. The amount of multiplexing to

a device is based on the Target Sessions and Max Sessions value for

each device. Multiplexing, although it provides increased throughput

by allowing more client save streams to be ingested to a device, it can

potentially increase the restore time as additional media has to be

scanned to retrieve the data compared to a single sequential stream.

Each NetWorker client and storage node installed with DD Boost can

perform up to 60 concurrent backup and recovery sessions (save

NetWorker

Performance


25

streams) per DD Boost device. This high use of sessions reduces the

number of devices needed and thereby reduces the impact on the

Data Domain system performance and maintenance.

A balance is required between the available data transfer rate of the

client save streams from the client file systems and the devices that

receive the data. If the device cannot ingest the data at the speed at

which the clients can serve the data, then the multiplexing will simply

elongate restore times without increasing the performance of the

backup streams.

Design Decision

For disk devices such as Data Domain devices, Target Sessions and Max

Sessions will be set to 1 and 60 respectively. A low Target Sessions value

is due to high performance with Data Domain devices being better

achieved by balancing all jobs across all available devices as evenly as

possible.

Client and Group Parallelism

Client and Group Parallelism enable a NetWorker Client or group to

send multiple save streams concurrently. It is recommended that:

• for regular clients, use the lowest parallelism settings to best

balance between the number of save sets and throughput; and

• for the backup server, set the highest possible client parallelism

to ensure that index backups are not delayed.

It is recommended to reduce client parallelism by default then increase

based on client hardware and data configuration. For the NetWorker

Server client parallelism (for index backups), it is recommended that for:

• small environments (less than 30 servers) to set parallelism to 8;

• medium environments (between 30 and 100 servers) to set

parallelism to 12; and

• large environments (greater than 100 servers) to set parallelism to

16.

If used, the best approach for group parallelism values is:

• Creating backup groups with a maximum of 50 clients with

group parallelism enforced. Large backup groups with more

than 50 clients can result in many operating system processes

starting at the same time causing temporary operating system

resource exhaustion; and

• To stagger backup group start times to reduce the load on the

operating system. For example, it is best to have 4 backup

groups, each with 50 clients, starting at 5 minute intervals than to

have 1 backup group with 200 clients.


26

Design Decision

Due to the medium size of the environment, the NetWorker Server client

parallelism will be set to 12. All other clients will be set to 4 (initially and

increased for clients with many mount points that have sufficient CPU

power). This will account for the SYSTEM drive, one DATA drive, and two

SYSTEM STATE or DR save sets to run concurrently.

Group Parallelism will not be enabled in the environment. However,

clients will be staggered across start times and groups to reduce load

of initial backup processes.

There are several backup configuration items specific to NetWorker

that must be considered and addressed to ensure backups operate

effectively, whilst providing ease of management for backup

administrators.

Clients, save sets, and Client Resources

A NetWorker client computer is any computer whose data must be

backed up. The client data that will be backed up, during a session, is

called a save set. When a Client is combined with one or more save

sets, this is called a Client resource.

This method allows multiple Client resources to be configured for a

Client with each Client resource potentially having separate NetWorker

Groups, schedules, media, retention and policies. This allows separation

of data protection for performance and business requirements. For

example, the SYSTEM STATE and System drives may be backed up at a

different time or to a different media pool to the Databases on a

system.

Design Decision

System backups will be combined in the same Client Resources as

unstructured file data backups. This simplifies the management of the

backup environment.

Backup Groups and Scheduling

There are two components for configuring backup schedules within a

NetWorker environment. Backup Groups specify the time of day at

which all Client Resources within the group will execute, while a

schedule determines which type of backup (e.g. Full, Incremental) is

performed on each day.

This provides flexibility in scheduling and allows:

• Client Resources to have staggered start times based on their

respective group allocations; and

• Client Resources to have differing policies within a group (e.g.

some Client Resources performing Full backups, and others

performing incremental backups).

NetWorker

Backup

Resources


27

By balancing the Backup Groups and Schedules for all Client

Resources, it provides the ability to even out the backup data across

the daily backup window, and across the weekly and monthly backup

cycles.

Design Decision

Backup Groups are already configured in the environment and will

remain as is. For changes to the method of backing up clients that

would require a snapshot approach, new groups will be created to

cater for the snapshot configuration.

Schedules will utilise a ‘Weekly Full’ and ‘Daily Incremental’ approach.

This minimises backup traffic while providing simplified recovery.

For clients that have a large amount of data that rarely changes, EMC

recommends a ‘Monthly Full’ and ‘Daily Incremental/Synthetic Full’

approach.

Browse and Retention Policies

There are two policies that can be applied to the save sets of a Client

Resource for recoverability. These are the Browse Policy and the

Retention Policy.

The Browse Policy determines how long the save sets are stored in the

Client File Indexes of the NetWorker Server, permitting restoration using

the NetWorker Client interface and browsing through the save set for

the required files. While the Browse Policy length has not been

exceeded, the save set is marked as ‘browsable’. The Browse Policy

directly impacts the size of the NetWorker database. A save set is

considered ‘browsable’ until the Browse Policy for all dependent save

sets has expired.

The Retention Policy determines how long the save set is protected by

the NetWorker Server from being removed from the backup media. If

the Browse Policy period has been exceeded, but the Retention Policy

time has not, the save set is marked as ‘Recoverable’. This means that

although the Client Interface does not allow browsing, the data is still

protected and can be restored. Once the Retention Policy has expired,

the save set is marked as ‘Recyclable’. This allows the save set to be

purged when the media is required for new backups once all

dependent save sets are also ‘Recyclable’.


28

Design Decision

For backups residing on the Data Domain, it is recommended to keep

the Browse and Retention policy the same. For the best deduplication

results, it is recommended a minimum retention of 30 days of backup

data reside on the Data Domains.

For data that will then be cloned to physical tape, the clone can have

a longer retention period than the original backup, if required.

For backups with long retention periods, i.e. “10 Years”, the related

browse policy period will be dependent on disk space allocation for the

NetWorker indexes.

Directives

Directives are resources that contain special instructions that control

how the NetWorker Server processes files and directories during backup

and recovery. The NetWorker administrators can create directives to

customise the NetWorker software, maximising the efficiency of

backups, and apply special handling to individual files or directories.

There are three types of directives:

• Global Directives;

• NetWorker User Local Directives; and

• Local Directives.

Global Directives are stored as resources on the NetWorker Server, and

can be selectively applied to individual clients by using the Directive

attribute of the Client Resource.

On clients that run Microsoft Windows, users with local Windows

Administrator or Backup Operator privileges can create Local Directives

by using the NetWorker User program. These directives are stored on

the client in a file named networkr.cfg, and are applied throughout the

client’s file systems during scheduled backups.

Users can create Local Directive files named nsr.dir (Windows) or .nsr

(UNIX) anywhere on a client file system that they have permission to

create files. The directives these files apply only to the immediate data

within the path where the directive file is located.

Design Decision

If directives are required, it is recommended Global Directives be

utilised over Local directives for ease of management.

Global directives should be applied to the filesystem backups of

database servers to skip the database files that would otherwise be

protected by an NMM application module, (e.g. Exchange and/or

SQL) or NMDA (e.g. Oracle, Lotus).


29

Media Pools

Backup data is sorted on to backup media volumes by using Media

Pools. A Media Pool is a specific collection of volumes to which the

NetWorker Server writes data. Media Pools act as filters that tell the

server which backup volumes should receive specific data. Since a

save set can potentially match multiple Media Pools, it is important that

additional criteria are supplied where required to ensure that data is

able to be sent to the correct pool.

When configuring pools the administrator should be aware the media

pool criteria for Group takes precedence over the media pool criteria

for client, save set, and level. Data that meets the criteria for both

media pools is written to the media pool associated with the group. If

data does not meet the criteria for any customized group, it is written to

the Default media pool.

Design Decision

Media pools will be created based on:

• Type of backup: For example, database backups would go to a

separate pool from filesystem data to ensure fast daily and DR

restores.

• Location of the backup device; i.e. Data Domain or physical tape.

• Retention period of the data being protected – this is more

important when directing backup data to tape.

Table 8 provides an example of media Pools.

Table 8. Example Media Pools

Pool Name Pool Type Comment on Selection

INDEX Backup index and bootstrap data only

SQL Backup Backup data SQL data only

VMware Backup All VMware data backed up using either

the VADP or VBA method.

Filesystem Backup All standard filesystem backup data.

INDEXClone Backup

Clone

Clone of networker databases. Resides on

the remote DD160

SQLClone Backup

Clone

Clone of the SQL backups. Resides on the

remote DD160

VMwareClone Backup Clone of the VMware image backups.

Resides on the remote DD160

FilesystemClone Backup

Clone

Clone of filesystem backups. Resides on

the remote DD160.


30

Save set Staging

Save set staging is the process of transferring data from one storage

medium to another, and then removing the data from its original

location. The initial backup data can be directed to a high-

performance disk device to reduce backup time. At a later time,

outside of the regular backup period, the data can be moved to a less

expensive but more permanent storage medium, such as Data Domain

or tape. After the backup data is moved, the initial backup data is

deleted from the disk device so that sufficient disk space is available for

the next backup.

Design Decision

Save set Staging will not be used in the XYZ environment.

For added data protection, save sets that have been successfully

written to a NetWorker device can be copied to a different location,

with a longer retention period, using the NetWorker Clone feature. A

Clone is a complete and independent copy of the data, which can be

used for data recovery or to create further Clones. Single save sets or

the entire volume of a NetWorker device may be cloned. A NetWorker

Clone retains the original NetWorker browse and retention policies by

default, but these can be changed to allow the clone copy to have

different policies.

NetWorker allows simultaneous multiple reads and writes on DD Boost

and AFTD devices. This allows the flexibility of running multiple clone jobs

from the same device, generating multiple streams, therefore speeding

up the cloning process.

A clone of stored data may not be created in a different NetWorker

Datazone. For the NetWorker Server to manage and monitor Clone

operations, the Storage Nodes at both the source and target locations

must be clients of the same NetWorker Server. The NetWorker Server

maintains browse and retention policies for all cloned copies and can

monitor and report on their storage operations.

Prior to configuring cloning, it is difficult to determine the best method

for each environment, as the following factors all contribute to the

success of each cloning method:

• Data Type;

• Bandwidth;

• Latency; and

• Clone device destination type.

This is why EMC NetWorker provides various methods of cloning to

ensure adequate coverage for most environments. In larger

Cloning

Considerations


31

environments, scheduled cloning outside of the backup window is

usually the most effective method.

Clone operations between Data Domain devices is further enhanced

by NetWorker automatically splitting clone streams, by volume or client,

into up to 30 streams, thereby speeding up the cloning process and

avoiding the ‘single stream’ clone processing of previous versions.

Clone Methods

NetWorker Clone operations may be configured by several methods,

which are suitable to different environment and storage needs. In some

cases, it may be necessary to use multiple or mixed approaches to

achieve the desired control and flexibility. There are three methods to

create Clones:

• Automatic Cloning;

• Scheduled Cloning; and

• Scripted Cloning.

Automatic Cloning

Save sets can be automatically cloned in one of two ways, each

method is configurable within the Group Resource:

1. When the backup group that contains the save sets has

completed, each save-set will clone, one save-set at a time.

2. Save sets can also be cloned automatically when each save set

completes during a scheduled group backup. However, if save-set-

A has completed and is currently cloning, if save-set-B then

completes, it will wait until save-set-A has completed its cloning

process.

The group is not marked as complete until all backup and clone

operations have completed. Both of these clone methods are suitable

for smaller environments, or a small number of clients, where the Clone

operations need to be completed quickly and immediately within the

backup window.

Scheduled Cloning

NetWorker Scheduled Clone operations can be configured and run in

NMC according to a schedule for predetermined Groups, Clients and

Pools. This method is suitable for environments where copies of save sets

need to be regularly provided, typically as part of a well-defined

maintenance cloning window, which runs independently of the main

backup operation.

The benefit of NetWorker Scheduled Cloning is that the backup group

can be run even if backups from its “set” are still cloning.

Scheduled cloning is beneficial in providing a steady, continuous

stream to tape devices to avoid the “shoe shining” effect.


32

Scripted Cloning

A NetWorker nsrclone script can be created and used to run Clone

operations and be launched either manually or as a scheduled task run

from the OS or an external scheduler. This method is typically used in

larger environments where flexibility and conditional controls are

required.

Design Decision

Clones to run at the end of the every completed save-set are

recommended in the XYZ environment for backups residing on the

Data Domain that are to be cloned to the remote Data Domain.

Scheduled cloning will be used for clone jobs where the final

destination will be physical tape.

Scheduled clone jobs will have the following parameters:

• All Clone jobs set to continue on Error.

• “Limit number of save set clones” will be set to 1 to ensure save

sets that already cloned aren’t repeated in the event a clone

job has to be re-run.

• All Clone jobs set to run every 12 or 24 hours; if backup jobs

complete within a 12-hour window (i.e. 7pm to 7am), then clone

jobs will run every 24 hours (i.e. at 8 or 9am). This will ensure all

backups there were run overnight will be copied offsite the

following morning.

Cloning with NetWorker Module for Microsoft Applications

Unlike file system backups where one file system results in one save set,

the NMM uses Volume Shadow Copy Service (VSS) snapshot

technology to create a point-in-time copy of an application. This

process results in multiple save sets regardless of the file systems or

clients involved.

Because the NMM creates multiple save sets during a run of a

NetWorker backup group, care must be taken to ensure that all save

sets that were created during an NMM backup are included in the

cloning process. Failing to clone all these save set may result in an

inability to perform a full and consistent restore from the clone copy.


33

Design Decision

With the Granular Level Recovery features of NMM for selected

modules, the environment will back up direct to a DD Boost device.

Cloning parameters will then be used to select the entire group to

therefore ensure all save-sets associated with an NMM application

backup are selected and copied to the remote Data Domain for offsite

protection.

Chapter 7: Data Domain Integration

34

7 Data Domain Integration

This section details the considerations for Data Domain integration with

EMC NetWorker, specifically:

• Software Revision Requirements;

• Memory and Connection Requirements;

• Network Considerations;

• Firewall Requirements;

• Dedicated Storage Nodes (DSNs) and Direct File Access (DFA);

and

• DD Boost Devices and NetWorker

To integrate with Data Domain systems and utilise the Client Direct File

Access and other advanced features, the NetWorker environment must

meet the following pre-requisites:

• NetWorker Server must be installed with NetWorker 8.2 or later.

This includes the DD Boost 2.6.x and 3.0.x library;

• DD OS version 5.4 or later;

• NMC version 8.2 or later;

• NetWorker Storage Nodes must be 8.2 or later; and

• NetWorker Clients are recommended to be 8.2 or later.

Design Decision

The NetWorker environment at XYZ will be upgraded to the latest

version of NetWorker installed to take advantage of the more recent,

advanced integrated features.

The Data Domain 4200’s will have the latest version of DDOS installed.

The physical memory requirement for a NetWorker Storage Node

depends on the peak usage of its’ NetWorker Data Domain devices.

• Each device that takes one save stream requires 160 MB of RAM

on the Storage Node;

• Each additional save stream requires 16 MB; and

• The maximum of 60 save streams requires 1104 MB.

These requirements do not allow for other devices and services. These

must also be taken in to consideration.

Software

Revision

Requirements

Memory and

Connection

Requirements


35

It is important that proper consideration is afforded to the network

connectivity between the NetWorker Storage Nodes and the Data

Domain appliances. Not addressing network capability and

connectivity may result in sub-standard backup performance to the

Data Domain appliances.

It is recommended where possible to utilise 10 Gigabit Ethernet (GbE)

network cards when deploying a Data Domain for optimal backup

performance. In environments where this option is not available, it is

recommended that a dedicated network connection be used for

connectivity from the NetWorker Storage Nodes to the Data Domain

appliances. This avoids latency and complexity of shared Ethernet

connections. A separate interface would be used for administration.

Design Decision

NetWorker will utilise DDBoost over the IP interfaces for backup and

recovery to the Data Domain devices.

These DD network interfaces will be configured into a Data Domain

Interface group. This interface group will load balance data streams

across the interfaces.

Replication between Data Domains will be configured via the

NetWorker Clone Controlled Replication feature.

Network

Considerations


36

To provide connectivity between the Data Domain appliances,

NetWorker servers, and NMC, please allow connectivity as identified in

Table 9.

Table 9. Firewall Requirements

Index Source Destination Protocol Ports Notes

1. NW Client Role Data Domain TCP 2049,2052 1

2. NW Client Role Data Domain TCP/UDP 111 1

3. NW Storage Node Data Domain TCP 2049,2052

4. NW Storage Node Data Domain TCP/UDP 111

5. NW Server Role Data Domain TCP 2049,2052

6. NW Server Role Data Domain TCP/UDP 111

161 (snmp)

7. Data Domain NMC Server TCP/UDP 162 (snmp trap)

8. Data Domain SMTP Gateway TCP 25 (smtp)

9. NMC Server Data Domain TCP/UDP 161 (snmp

query)

10. NMC Server Data Domain HTTP 80

11. NMC Server Data Domain HTTPS 443

Notes:

1. Required for client direct backups (i.e. not via Storage Node) to Data Domain using DD

Boost transport

NetWorker’s DSN capability provides high capacity clients with the

mechanism to backup directly to the Data Domain appliance, without

having to transmit data across the network. This can lead to significant

savings in network bandwidth.

Similar to the DSN capability, DFA (Direct File Access), sometimes

referred to as “client direct”, provides DD Boost DSP (Distributed

Segment Processing) integration via certain NetWorker modules and

NetWorker filesystem backups for most platforms. This allows DSN

capability for clients to Data Domain appliances without the need for

additional NetWorker licensing.

The benefit of DFA is that the same Data Domain device can be used

for both DFA clients and non-DFA clients via the NetWorker Storage

Nodes, providing greater performance.

Design Decision

DFA, as part of the NetWorker 8 client and module software will be used

in conjunction with DD Boost over IP for the majority of backups.

Firewall

Requirements

Dedicated

Storage Nodes

(DSNs) and

Direct File

Access (DFA)


37

DD Boost Devices and NetWorker

Best practices suggest limiting the number of boost enabled devices on

the Data Domain. To do this effectively, the number of server and

client streams, device target sessions and max sessions has to be taken

into account.

Device Aliasing within NetWorker allows multiple storage nodes and

clients to write to DD boost devices, therefore keeping the number of

devices on the Data Domain low.

However, what also needs to be considered is the resulting size of the

volume mounted on the DD Boost device.

If the resulting volume is too large, it may take a considerable time to

view the contents on the volume in the NMC GUI and could even result

in errors.

Design Decision

While keeping target sessions low to spread the load over multiple

devices and using device aliasing to keep the number of actual

devices on the Data Domain low, performance tuning monitoring has

suggested device volume sizes of ~200TB would be the optimum size for

the XYZ environment.

Extra devices will be created as necessary to ensure volume sizes do

not exceed 200 TB.

A synthetic full backup combines a full backup and subsequent

incremental backups to form a new full backup, which is called a

synthetic full backup.

A virtual synthetic full (VSF) backup is the same as the synthetic full

backup, except that it is performed on a single Data Domain system.

Like synthetic fulls, VSF uses full and partial backups to create a new full

backup. However, since the backup occurs on a Data Domain system

using new DD Boost API’s, the backup does not require save set data to

be sent over the wire, resulting in improved performance over synthetic

full and traditional backups.

DD Boost

Devices

Virtual Synthetic

full backups


38

Table 10. Traditional synthetic full versus Virtual synthetic full backups

Traditional synthetic full Virtual synthetic full

Data is read from and written to

volumes

Data movement is limited within the same

Data Domain

Supports read/write for all types of

volumes

Only Data Domain devices are supported,

and the source and destination volumes

must belong to the same DDR. As per the

DDBoost API, there are no restrictions if the

volumes belong to different M-Trees in the

same DDR.

Does not require DFA support Requires DFA support

Design Decision

VSF backups will be utilised in the XYZ environment for supported

backup types that do not regularly complete within the backup

window.

Chapter 8: Microsoft Integration

39

8 Microsoft Integration

This section details the Microsoft application backup considerations of

the NetWorker solution, specifically:

• NetWorker Module for Microsoft (NMM) Overview;

• Microsoft Shadow Copy Integration;

• Data Domain Integration with NMM;

• SQL VDI Integration;

• Microsoft SharePoint;

• Microsoft Active Directory; and

• Advanced Protection Features for Windows.

Table 11 depicts the types of backups and restores supported by the

NMM for each of the support applications.

Table 11. NMM summary of support for backup and recovery

Types of backup

and recovery

Active

Directory

SQL

Server

(VSS)

Exchan

ge (VSS)

SharePoin

t Server

(VSS)

Hyper-

V (VSS)

SQL

Server

(VDI)

Scheduled

backup √ √ √ √ √ √

Adhoc backup √

Federated

backup √ √ √

Granular backup √

Conventional

recovery √ √ √ √ √ √

Granular recovery √ √ √ √

Bare Metal

Recovery √ √ √ √ √

To simplify protection and recovery of Microsoft environments, EMC

NMM provides a single, unified solution that leverages Microsoft Volume

Shadow Copy Service (VSS) for snapshot-based protection and

recovery of Microsoft Exchange, SQL and Active Directory as well as

VDI for transaction log-based backup for SQL and SSMS integration (for

SQL 2008 and 2012).

NetWorker

Module for

Microsoft (NMM)

Overview


40

NMM Installation Pre-requisites

Before NMM can be installed there are some conditions that must be

met. These conditions are detailed below:

• The base windows client must be installed to NetWorker client

8.1. To take advantage of new features, it is best to install the

same NetWorker version as the NetWorker server;

• A service account with application (SQL/Exchange/SharePoint)

Administrator rights must be provided;

• The NMM installation must be run as this service account. The

NMM installation documentation provides more detailed

information;

• To install NMM the user must have Windows administrator

privileges locally as well as domain administrator privileges at the

domain level;

• BitLocker encryption must be disabled;

• The required licenses for NMM need to be enabled on the

NetWorker Server, unless using NetWorker capacity license,

which automatically includes NMM licenses; and

• For Microsoft Exchange, Internet Protocol (IP) version 6 (IPv6)

must be disabled on the interface that NetWorker is configured

to use.

NMM Preconfiguration Checker

The NetWorker Module for Microsoft Applications Config Checker

provides pre-installation verification of configuration for Microsoft

SharePoint, Exchange and SQL among others, to ensure proper

operation with EMC NetWorker.

These tests are related to the operating system, software components,

volume Shadow copy Service (VSS) subsystem and generic conditions

that NMM requires.

The NMM integrates with Microsoft applications through the Volume

Shadow Copy Service (VSS) using Microsoft-supplied application writers.

VSS then creates a snapshot of the data that allows the backup of the

application while it is online and in use.

VSS is available with Windows Server 2003, 2008, and 2012, and is a

framework for snapshot and clone creation and management. VSS

coordinates application consistent point-in-time data copy generation

and provides operating system level support for synchronization and

overall coordination.

Within the VSS framework are 3 main components:

• Requestors - The entities that request the creation of a shadow

copy, e.g. NetWorker;

• Providers - These are the software or hardware components that

create and maintain the snapshots or shadow copies requested.

Microsoft

Shadow Copy

Integration


41

The Windows Server OS contains a system or software provider

that accomplishes this mission while EMC and other hardware

vendors supply hardware-based Providers that do the job of

shadow copy creation; and

• Writers - Writers are application- inherent VSS implementations

that play in the VSS framework and ensure data is consistent and

complete before a shadow copy is generated.

The process used by NetWorker to generate a VSS snapshot is shown

below:

• Networker asks VSS to enumerate writers and gather metadata;

• Writers provide an eXtensible Markup Language (XML)

description of backup and recovery options and volumes;

• VSS asks which providers can support a shadow copy for the

required volumes;

• NetWorker asks VSS to create the required shadow copies;

• VSS freezes writers;

• VSS tells providers to create the shadow copies;

• VSS thaws writers; and

• NetWorker indexes the shadow copies as a valid backup and is

ready to mount the shadow copies for additional backup to disk,

tape, or another medium.

NetWorker Software Compatibility

NMM leverages EMC NetWorker integration with EMC Data Domain to

offer the following features:

• Data domain Boost - Client-side IO optimisation through

NetWorker DD Boost capability enables less data to be passed

through the network during NMM backup, which results in faster

backups; and

• Optimised cloning - Data Domain optimised cloning enables

Data Domain based backups to clone to another Data Domain

appliance by using the fast cloning method through DD Boost.

With this method, only deduplicated data is transferred to the

target appliance.

Data Domain integration with NMM has the following requirements:

• NetWorker Server 8.1.x or later;

• NetWorker Storage Node 8.1.x or later;

• NetWorker Client 8.1.x or later;

• NetWorker Client installed on the NMM host;

• NMM version 8.2.x or later; and

• Data Domain OS 5.4 or later for DD Boost functionality.

Data Domain

Integration with

NMM


42

Design Decision

NMM will be utilised for application backups either via NetWorker

scheduled backups or as commands run via user scripts.

NMM backups will be directed to DDBoost devices on the Data

Domain.

Direct File Access (DFA) Connectivity

Servers with NMM installed do not have DD or AFTD devices allocated

directly to them, the DD/AFTD are allocated to a NetWorker Storage

Node. During a DFA enabled backup NMM:

• connects to the storage node to obtain DD/AFTD device

credentials;

• establishes a connection to the DD appliance or AFTD using the

obtained credentials; and

• begins to send data directly to the DD appliance or AFTD.

As a result for both DFA and non-DFA based backups, a Storage Node

is required to be defined within the client resource for each host with

NMM installed.

Client Direct to DD is supported for:

• Microsoft Exchange Server;

• Microsoft SQL Server VSS and VDI;

• Microsoft SharePoint Server;

• Active Directory; and

• Microsoft Hyper-V Server.

Design Decision

NMM will be utilised for all Microsoft database backups.

You can also use the NMM software to backup and restore SQL Server

data utilizing the Virtual Device Interface (VDI), an API provided by

Microsoft SQL Server, to integrate with the SQL Server and enable the

NetWorker software to backup and recover the SQL Server data.

NMM with VDI is the EMC recommended method for protecting SQL

and will be the method discussed in this document.

SQL Server Requirements

NMM supports the following versions of SQL (Standard, Enterprise,

Express2 and Workgroup Editions):

• SQL Server 2005;

• SQL Server 2008 SP3;

SQL VDI

Integration


43

• SQL Server 2008 R2 SP1; and

• SQL Server 2012 SP1.

NMM is supported on the following Windows Server versions:

• Windows Server 2012 R2;

• Windows Server 2012;

• Windows Server 2008 R2 SP1;

• Windows Server 2008 SP2; and

• Windows Server 2003 SP2.

Supported Backup and Recovery Methods for NMM VDI

NMM with VDI provides support for the following types of backup for

SQL Server:

• Manual or traditional backup:

▪ Database;

▪ File (full and differential);

▪ Filegroup (full and differential);

▪ Filestream; and

▪ Transaction log.

• Federated backup:

▪ NMM with VDI provides support for SQL Server 2012 Federated

backup functionality for SQL Server 2012 AlwaysOn databases.

• Backup levels in NMM for SQL VDI backups:

▪ Full - Entire database backup, including all filegroups or files in

the database;

▪ Incremental - Corresponds to a SQL Server transaction log

backup (xlog); and

▪ Differential - Makes a copy of all the pages in a database

modified after the last full database backup.

NMM with VDI provides the following types of recovery:

• Traditional recovery:

▪ Used for data that was backed up by traditional backup; and

▪ Traditional recovery operations recover files, filegroups,

databases and transaction log backups.

• Normal recovery:

▪ Entire set of data associated with one or more SQL Server

backups, including full, incremental and differential backups;

▪ A file, filegroup, or a database to the database originally

backed up; and

▪ Level full, level 1 (differential), and level incremental backups

in the order required by SQL Server.


44

• Copy recovery:

▪ Creates a copy of a database by restoring a SQL Server

database to a new location, or to a new database name.

NMM with VDI provides the following types recovery modes:

• Normal restore mode:

▪ Instructs SQL Server to leave the database in an operational

state after the restore completes. This then enables database

reads and writes.

• No-recovery restore mode:

▪ Activates the SQL Server NORECOVERY database restore

option for the last stage restored. The no-recovery restore

mode places the database in a state that cannot be loaded

after the restore, but is still able to process additional

transaction log restore operations.

• Standby restore mode:

▪ Activates the SQL Server STANDBY database restore option for

the last stage restored, which forces the database to be in a

read-only state between transaction log restore operations.

The standby restore mode provides an undo file for SQL Server

to use when rolling back the transactions.

• Online restore mode:

▪ SQL Server provides the ability to perform a restore operation

while a SQL Server database is active. The database is

completely offline only while the primary filegroup is being

restored. Once the primary filegroup is restored, the database

can be brought online while the rest of the filegroups are being

restored, and then only the data that is being restored is

unavailable.

Microsoft SQL Server named log marks

Microsoft SQL Server enables enhanced point-in-time restore operations

by allowing named log marks to be specified during transaction

creation. Database applications create named log marks when

transactions are performed. The marks enable access to specific

transaction points in a database transaction log backup. NMM restores

to the beginning or end of a named log mark during a database

restore. Restoring data by using named log marks is an improvement

over point-in-time restore. The time associated with restoring to a

specific transaction can be more accurately determined.

When a named log mark is created in the SQL Server database, the log

mark time is saved to the millisecond. However, NetWorker’s time

format, which is used to specify point-in-time restore, only supports

granularity to the second. If named log marks with duplicate names are

created within a second of each other, NMM restores to the most

recently named log mark.


45

NMM with SQL VDI Backup Requirements

Before performing SQL Server backup, ensure that:

• the SQL Server is not running in single user mode; and

• all databases are online.

A database in any of the following states will cause a scheduled

backup to fail in case the database is part of a previously configured

backup:

• Standby;

• Recovering;

• Restoring;

• Recovery Pending;

• Suspect;

• Offline;

• Not recovered;

• Loading; and

• Prerecovery.

Design Decision

SQL backups will be directed to a DDBoost device via DFA from the SQL

server. SQL backups can be either initiated from a scheduled backup

or from a user maintained script on the SQL server.

SQL with NMM VDI Best Practices

Table 12 details the best practices and recommendations to follow

when using NMM for backup and recovery of Microsoft SQL server.

Table 12. SQL Backup Recommendations

Consideration Recommendation

Backup schedules for

file system and

applications.

Define separate schedules for OS and file system data

and application data. This would involve the use of

multiple Client Resources and Schedules. It is also

recommended that they reside in different groups.

Installation path for

Application.

Do not install the application program files on the same

volumes as the application’s database files and logs.

Special characters in

database names.

Database names with special characters will not be

backed up. Ensure there are no special characters in

database names.


46

Design Decision

For SQL 2008 and 2012, NMM will be integrated with SSMS for ease of

backups and restores for the SQL DBA’s. Restores can also be initiated

via the “NetWorker User for SQL” or by using the command line, nsrsqlrc.

If filesystem backups of SQL servers are required, they will be configured

to run at a separate time to the SQL backups.

For filesystem backups of servers that also run SQL, a NetWorker

directive will be configured to skip the SQL databases.

SQL backups will be configured in concert with XYZ DBA’s to ensure all

site specific requirements are catered for.

Blackboard application protection methodology

The SQL portion of the Blackboard application will be protected with

NMM - SQL with VDI.

NMM provides the flexibility of allowing users to run SQL backups from

user maintained scripts.

The unstructured file component of the Blackboard application will be

protected with array based snapshots.

NMM leverages the Windows VSS framework and Microsoft Office

SharePoint Server VSS Writers for consistent point-in-time snapshots and

backs up the entire SharePoint farm. NMM uses the SharePoint Server

VSS Writers to back up SharePoint components.

Third-party software, such as Kroll OnTrack PowerControls would be

required in addition to NetWorker to facilitate the GLR (granular or item

level recovery) functionality.

Additionally, NMM can support efficient backup and granular recovery

of SharePoint farms that leverage remote blob storage.

The following sections outline the benefits of using NMM to protect the

SharePoint environment.

SharePoint Server Requirements

• SharePoint Server 2007;

• SharePoint Server 2010; and

• SharePoint Server 2013.

NMM leverages the Windows VSS framework and Microsoft Office

SharePoint Server VSS Writers for consistent point-in-time snapshots and

backs up the entire SharePoint farm. By using the SharePoint Server VSS

Writers, NMM backs up the following SharePoint components:

• Configuration database - SharePoint configuration database;

Microsoft

SharePoint


47

• Content database - SharePoint content database;

• SharePoint Help Search - (Only for Microsoft SharePoint Server

2007 and 2010) SharePoint search indexes and associated SQL

databases;

• Microsoft Office Search - Microsoft Office search indexes and

associated databases; and

• Service applications - (Only for Microsoft SharePoint Server 2010

and 2013). Individual services can be configured independently

and third-party companies can add services to the platform.

Services that are deployed are named service applications. A

service application provides a resource that can be shared

across sites throughout a farm, and can be accessed by users

through a hosting Web application. Service applications are

associated to Web applications by service application

connections. Some services can be shared across farms.

SharePoint Backups

NMM supports the following types of backup for standalone and

distributed farms:

• SharePoint farm (stand-alone and distributed) level backup; and

• Content database backup.

SharePoint Recovery

NMM supports the following types of recovery for standalone and

distributed farms:

• SharePoint farm (stand-alone and distributed) level recovery;

• Content database recovery; and

• Granular recovery with third-party software, like Kroll Ontrack

PowerControl.

Note Rollback recovery is not supported.

FAST Search Server backup and recovery

NMM supports the backup and recovery of the following in SharePoint

Server 2010:

• FAST Query Search Service Application; and

• FAST Content Search Service Application.

These applications crawl and index the contents to the FAST Search

server. The backup and restore operations of the FAST Query Search

Service Application and the FAST Content Search Service Application

are similar to the default search applications.

SharePoint Server 2013 Apps backup and recovery

The apps for SharePoint Server 2013 provide a new method to deliver

specific information or functionality to a SharePoint site. Site owners can


48

discover and download apps for SharePoint from a public SharePoint

Marketplace or from their organizations internal app Catalog and install

them on their SharePoint sites.

No separate configuration is required when using NMM to perform

backup and recovery of SharePoint apps. Apps store their internal data

in content database and recovering the content database on SQL

server recovers the apps in SharePoint site.

Design Decision

XYZ at this stage do not use SharePoint but will be utilising the

application in the near future.

For protection of SharePoint, it is recommended that all components of

all SharePoint servers/farms be backed up with NMM. To protect the

SharePoint server in a standalone farm, the save set will be:

• APPLICATIONS:\Microsoft Office SharePoint Services

To protect the SharePoint Server distributed farm with two servers, two

client resources will be created, one for each server. Each client will

have a different save set:

• SharePoint web front-end host:

APPLICATIONS:\Microsoft Office SharePoint Services

• SQL Server host save set for server 2:

APPLICATIONS:\SQLServerWriter

If Multiple servers in a distributed farm (eg 4), a resource will be created

for each server in the farm:

• 3 servers will have a save set of:

APPLICATIONS:\Microsoft Office SharePoint Services

• The 4th will have a save set of:

APPLICATIONS:\SQLServerWriter

SharePoint Client Direct

The Client Direct support provided by the NetWorker client is also

included with NMM.

This enables clients with network access to the Data Domain to send

their backup data directly to the boost devices, bypassing the

NetWorker storage nodes. This feature reduces bandwidth usage and

bottlenecks, providing a highly efficient backup data transmission.


49

Design Decision

SharePoint, when installed, will have backups configured to run direct

to DD boost devices on the ‘local’ Data Domain.

SharePoint Archival with EMC SourceOne

EMC SourceOne is a family of Information Governance products and

solutions that make Information Governance actionable. It includes

archiving, compliance and eDiscovery solutions to give customers

starting points for their most pressing information management needs.

EMC is leveraging recommended Microsoft technologies to deliver a

comprehensive offering that gives customers a building block

approach to information governance. EMC is delivering a single pane

of glass for administrators to manage email, SharePoint and files with

the same policies and administration console. All while ensuring a

transparent and seamless end-user experience.

EMC SourceOne for Microsoft SharePoint, supports and enhances an

organization’s use of SharePoint, provides extended operational control

and governance to SharePoint content, and ensures that end users are

involved in the broader information environment and its related

processes without having their day-to-day activities impacted.

The EMC SourceOne for Microsoft SharePoint software includes three

components:

• SharePoint Archive activity wizard;

• SharePoint Archive Search; and

• External BLOB Storage (EBS).

SharePoint Archive activity wizard

This wizard is used to create activities to archive SharePoint content into

the EMC SourceOne Native Archive. Access this wizard through the

EMC SourceOne console.

Depending on access level, SharePoint content that was archived

through a SharePoint Archive activity can be found via:

• EMC SourceOne Search; or

• EMC SourceOne Archive Search available in SharePoint.

SharePoint Archive Search

SharePoint users can search for SharePoint content from the current

farm that was archived in the EMC SourceOne Native Archive, even if

the original SharePoint site no longer exists.

External BLOB Storage (EBS)

EBS is an optional storage management feature that automatically

stores binary large object (BLOB) content in the EMC SourceOne Native


50

Archive instead of in the SharePoint SQL Server. The content is stored,

not archived; the content is not indexed and does not have retention

set.

Users view and retrieve this content through SharePoint, as usual, not

through EMC SourceOne Search or EMC SourceOne Archive Search.

User access to archived SharePoint content

When the SharePoint Archive activity archives a SharePoint item, the

item is stamped with the Active Directory groups and the SharePoint

groups that have access to the item. EMC SourceOne stores the group

information; it does not expand the groups.

When a user logs into Archive Search, EMC SourceOne determines the

user’s groups:

• All Active Directory groups to which the user belongs; and

• All SharePoint groups to which the user belongs on the current

farm.

When a user runs an Archive Search, results are constrained based on

the user’s group membership.

Design Decision

SharePoint protection and archiving will be covered in detail at a later

date when XYZ implement SharePoint.

NMM can be used to protect and recover Active Directory objects.

Backup and recovery of the file system and recovery of the system

state backups must be performed by using NetWorker.

Operations supported with Active Directory

NMM supports:

• granular backup of Active Directory at full and incremental

levels;

• granular recovery of Active Directory, which is recovery of

individual Active Directory objects or object attributes.

Supported Active Directory objects for granular backup and recovery

NMM supports granular backup and recovery of the following Active

Directory objects:

• Users;

• Groups;

• Organizational units;

• Computer;

• Contact;

Microsoft Active

Directory


51

• InetOrgPerson;

• Shared folders; and

• MSMQ queue alias.

Active Directory granular backup considerations

1. A granular backup of Active Directory or ADAM does not use

VSS snapshot technology (non-VSS). Instead, the backup is

routed directly to a granular backup medium:

a. A traditional granular backup of Active Directory backup

enables you to recover individual objects and object

attributes.

b. A granular ADAM backup enables you to recover individual

application partitions.

2. The following guidelines should be considered before performing

an Active Directory granular backup:

3. System-only attributes are not backed up with Active Directory

objects. These attributes are recovered through tombstone

reanimation.

4. Changing the system date and time to an earlier date in the

domain controller is not recommended as each item in the

Active Directory is marked by a time. Active Directory uses the

time to resolve any data conflicts. Recovery of a deleted object

by the NMM client will fail if the date and time are changed

after the object has been backed up. If a change in the system

date or time is necessary, immediately perform a full backup of

the domain.

5. The Group Policy object exists in two places:

a. As an Active Directory object in the Group Policy Container.

b. In the Windows registry.

Many of the settings that can be edited from the Group Policy

Management Console reside in the system registry and not in

Active Directory. Therefore, if these values are changed after a

backup, a recovery will not restore the attribute values and the

system values will take precedence. To restore the attribute

values, you must use NetWorker to recover the SYSTEM

COMPONENTS.

6. A restored user account is automatically disabled, and the

pwdLastSet attribute is not recovered for security. A new

password must be set after a user account is recovered.

7. A change to an object’s memberOf attribute is reflected in the

owner object of that group and not in the object itself.

8. The rootDSE object is dynamic when created. ADAM lists the

connection and the primary registered partition. When a binding

is requested on the rootDSE object, ADAM returns the value of

the default Naming Context. On a domain controller, this value is

always the Domain Naming Context. Reserve the port 50000 for


52

backups of ADAM partitions. For Active Directory, use the

standard LDAP port 389.

9. Many configuration settings are stored in Active Directory, but

LDAP cannot always be used to modify them. Also, some items

stored in Active Directory are references to objects that are

managed by other applications. The appropriate API’s must be

used to modify the objects.

10. A proxy client should not be configured for granular ADAM for

Active Directory backups.

11. For ADAM granular backups, the Windows SYSTEM account,

which the NetWorker binaries run as, must be given access rights

to each instance on the ADAM server.

Design Decision

1. Client definition settings for Active Directory backups:

• NMM does not support deduplication for Active Directory

backups. The following checkboxes need to be unchecked in

the Active Directory client definition: “Data Domain” and “Client

Direct”;

This does not preclude Active Directory backups to DD Boost

devices.

• Assigned schedule can only run level full and incremental

backups;

• Separate client definition for Active Directory Backups;

• Save set field for Active Directory backups will resemble:

CN=common name,U=OU name,DC=domain name,C=suffix;

and

• Backup command field for Active Directory will use

nsradsave.exe.

2. Client definition settings for ADAM backups:

• Separate client definition for ADAM backups;

• Save set field for ADAM backups will resemble:

APPLICATIONS:\ADAM instance_name Writer for ADAM Writer

backup;

• For ADAM objects, to back up ADAM application partitions, the

following command will be entered into the “Backup

Command” field of the ADAM client resource: nsradsave.exe –p

50000;

• Assigned schedule can only run level full and incremental

backups; and

• Each ADAM partition must be backed up with a separate client

definition.


53

3. Separate pool for Active Directory or ADAM backups. They should

not be mixed with other client backups, including snapshots.

4. Group Assignment for Active Directory and ADAM backups:

• No snapshot policy can be defined; and

• No Browse and Retention policy defined in the group; use client

definition.


54

Block Based Backups for Windows Servers

NetWorker Block based backups are high-performance backups that

support NTFS and ReFS file systems.

During block based backups, the backup application scans a volume

or a disk in a file system and backs up all the blocks that are in use in

the file system. Block based backups use the following technologies:

• Use the Volume Shadow Copy Service (VSS) snapshot capability

to create a consistent copy of the source volume for backup.

• Use the Virtual Hard Disk (VHDx), which is sparse, to backup data

to the target device; AFTD or Data Domain devices only.

The block based backups support only the following Client Direct

enabled devices as target devices:

• Advanced File Type Devices (AFTDs); and

• Data Domain devices.

Block based incremental backups use the Change Block Tracking (CBT)

driver to identify the changed blocks, and back up only the blocks that

are changed.

Block based backups provide instant access to the backups. A block

based backup enables you to mount the backup by using the same file

system that you used to back up the data. For example, if the data that

you backed up is NTFS, you can mount the block based backup by

using NTFS.

A block based backup provides the following capabilities:

• Mounting of the backup as a file system;

• Maximum of 38 incremental backups after a full backup;

• Mounting of an incremental backup;

• Sparse backup support;

• Backups to disk-like devices;

• Backups to Data Domain;

• Backups of operating system-deduped file systems as source

volumes;

• Virtual full backups to Data Domain;

• Synthetic full backups to AFTD;

• Incremental synthetic full backups to AFTD;

• Backups of volumes up to 63 TB each;

• Recoveries from Data Domain without using CIFS share;

• Recovery of multiple save sets in a single operation; and

• Image recoveries without mounting the backup image.

The virtual full backups apply only to the Data Domain devices. When

you perform an incremental backup to a Data Domain device, you

perform the backup as a virtual full backup. However, the type of the

backup that you have performed is displayed as a full. A virtual full

backup backs up only the changed blocks from its previous full backup

Advanced

Protection

Features for

Windows


55

while referencing the unchanged blocks to the corresponding blocks of

the previous full backup.

Selecting any backup level apart from a level full results in performing a

virtual full backup.

Table 13 lists the backup scenarios and the recovery scenarios that the

block based backups support.BBB scenarios

Table 13. BBB scenarios

Backup scenarios Recovery scenarios

• AFTD backups;

• Backups to Data Domain by using

DD Boost;

• Full backups;

• Virtual full backups;

• Synthetic full backups;

• Incremental backups;

• Incremental synthetic full backups;

and

• Full backups and incremental

backups intermixed with built-in

provisions to anchor the

incremental backups with an

appropriate backup type.

• File level recovery by

mounting the backup

image on a target host;

• Image/destructive recovery

at the block level;

• Image/destructive recovery

from clones; and

• Windows Bare Metal

Recovery (BMR) by using a

WinPE image.


56

Table 14 lists the block based backups support for the following

operating systems and configurations:

Table 14. BBB supported OS and Configurations

Operating Systems and Configurations

• Operating systems on x64:

o Windows client 8.1;

o Windows client 8;

o Windows Server 2012 R2;

o Windows Server 2012; and

o Windows Server 2008 R2

• Operating systems on x86:

o Windows client 8.1; and

o Windows client 8

• Client Direct target devices;

• Concurrent backups of multiple volumes;

• Windows Server 2012 and Windows Server 2012 R2 deduplicated

volumes without rehydrating the deduplicated data;

• Windows Server core installation role;

• Unified Extensible Firmware Interface (UEFI) based systems;

• GUID Partition Table (GPT) and Master Boot Record (MBR) volumes;

• Data Domain systems in a Fibre Channel environment;

• Full backup of Windows Server 2012 Cluster Shared Volumes on File

Servers and windows Clusters; and

• Full and incremental backups of New Technology File System (NTFS)

and Resilient File system (ReFS).

Table 15 lists the capabilities and configurations not supported by block

based backups.


57

Table 15. BBB unsupported configurations

Unsupported Configurations

• FAT file system;

• Backup levels 1 through 9 (only Full and Incremental);

• Cloning of incremental backups;

• Granular save sets at either the folder level or the file level, for

example, D:\data;

• Checkpoint restart;

• Standard NetWorker directives;

• The scanner command with the –i option for rebuilding indexes for

block based backups;

• Staging and the nsrclone command with the –m option for

migrating block based backup save sets to other volumes;

• Image recovery to a system volume;

• Recoveries of ReFS volumes on Windows Server 2008 R2 and

Windows 8 (x86 and x64); and

• Recoveries of dedupe volumes on Windows Server 2008 R2 and

Windows 8 (x86 and x64).

Design Decision

EMC recommends the use of Block Based Backups for windows servers

with large, dense (many small files) file systems.

Parallel Saves Streams for Windows

The parallel save streams (PSS) feature provides the ability for each

Client resource save set to be backed up by multiple parallel save

streams to one or more destination backup devices. PSS is used for the

schedule, file-based backup of file systems.

Table 16. PSS item support

Support

Operating

System

Supported save sets Supported

backup

types

(Virtual)

synthetic

full

Check

point

restart

UNIX, Linux

and

Windows

ALL, individual save

points including,

Disaster_Recovery,

deduplicated, and CSV

volumes (windows only)

Scheduled Yes No

PSS optimizes performance and eliminates scripting for large save

groups. It leverages the parallelism value in the client definition,

dynamically adjusting the streams as required.

When a PSS enabled client resources parallelism value is greater than

the resources number of save points (UNIX mount point, Windows


58

volume drive letter), the schedule backup save group process divides

the parallelism among the save point and starts PSS save processes for

all the save points at approximately the same time.

It is recommended to set the Client resource PSS parallelism value to 2x

or more the number of save points. The number of streams for each PSS

save point is determined before the backup from its client parallelism

value and it remains fixed throughout the backup. It is a value from 1

through 4 (maximum), where 1 indicates a single stream with a

separate PSS process that traverses the save point's file system to

determine the files to back up. The separation of processes for

streaming data and traversing the file system can improve

performance. Also, the number of save processes that run during a PSS

save point backup is equal to the number of save stream processes

assigned with two additional save processes for both the director and

file system traversal processes.

Increasing the default maximum value can improve the performance

for clients with very fast disks. When the client parallelism is less than its

number of save points, some save point backups run in PSS mode, with

only a single stream. Other save points run in the default mode (non-

PSS). Therefore, for consistent use of PSS, set the client parallelism to 2x

or more the number of save points. This ensures multiple streams for

each save point.

It is recommended that large, fast file systems that should benefit from

PSS be put in a new separate PSS-enabled Client resource that is

scheduled separately from the client's other save points. Separate

scheduling is achieved by using two different save groups with different

run times, but the same save group can be used if you avoid client disk

parallel read contention.

Also, use caution when enabling PSS on a single Client resource with

the keyword "All". "All" typically expands to include multiple small

operating file systems that reside on the same installation disk(s). These

file systems usually do not benefit from PSS but instead might waste

valuable PSS multi-streaming resources.

Design Decision

PSS will be enabled for Windows, Linux and UNIX servers with large,

dense filesystems located on fast disk, that would require regular, file

level restores.

Chapter 9: Linux and UNIX Integration

59

9 Linux and UNIX Integration

This section details the Linux and UNIX file system and application

backup considerations of the NetWorker solution, specifically:

• Linux and UNIX NetWorker clients;

• NetWorker Module for Databases and Applications (NMDA); and

• NMDA for Oracle.

NetWorker supports installing the NetWorker client on many versions of

Linux and UNIX operating systems, including:

• Red Hat Enterprise Linux;

• SuSE Linux;

• Oracle Linux;

• CentOS;

• Debian;

• Ubuntu;

• Fedora;

• IBM AIX;

• HP-UX; and

• Oracle Solaris.

Operation of the NetWorker client for Linux and UNIX platforms is similar

to the operation for Windows Servers, in that the entire server can be

protected or selected file systems, directories or files.

Parallel Save Streams

Parallel save streams are supported for Linux and UNIX servers. Refer to

Parallel Saves Streams for Windows section for more information.

NMDA provides a data protection solution for DB2, Information, Lotus

Domino/Notes, MySQL, Oracle and Sybase data. NMDA operates with

the NetWorker software and the supported database software or

application software.

NMDA integrates database backups and file system backups to a

centralized backup server, which relieves the burden of backup from

the database administrator while enabling the database administrator

to retain control of the restore process.

Linux and UNIX

NetWorker

clients

NetWorker

Module for

Databases and

Applications

(NMDA)


60

NMDA provides high performance backups and restores of databases

and applications to and from different NetWorker devices, including

Data Domain devices.

Basic Capability

The NetWorker Module for Database Applications (NMDA) supports the

following basic backup and recovery features:

• Online backup - NMDA can back up an online database or online

application without requiring any downtime;

• Full and incremental backup - NMDA can back up all data or only

the data that has changed. Application-specific topics in this

guide describe the supported types of backups;

• Backup of transaction logs and other files required for recovery -

NMDA can back up all the database components or application

components required for recovery;

• Automatic recovery of a database or application to the current

time or to an arbitrary point-in-time;

• Recovery to the original location or to an alternate location;

• Granular backup and granular recovery - NMDA supports the

following backup and recovery granularities:

▪ Oracle database, tablespace, and datafile backup and

recovery. In addition, Oracle software can perform block-level

recovery;

▪ DB2 database and tablespace backup and recovery;

▪ Informix instance and dbspace backup and recovery;

▪ Lotus database backup and Lotus database and document-

level recovery;

▪ MySQL instance, database, and table backup and recovery;

and

▪ Sybase ASE server and database backup and recovery.

▪ Parallelism – NMDA supports concurrent data streams for a backup

or restore. This technology extracts multiple streams of data in

parallel from a database, and writes them in parallel to one or more

storage devices.

Client Direct

NMDA supports the Client Direct feature, which enables client backups

to bypass the NetWorker storage node and perform one of the

following operations:

• Send deduplicated backup data directly to DD Boost storage

devices; and

• Send non-deduplicated backup data directly to AFTD storage on

Windows only.


61

The Client Direct feature, also known as DFA, reduces bandwidth usage

and bottlenecks at the storage node, and provides highly efficient

transmission of backup data.

NMDA backups to DD Boost devices

An NMDA backup to a Data Domain system configured as a DD Boost

device can take advantage of the DD Boost feature by using the

following two components:

• The DD Boost library API enables the NetWorker software to

communicate with the Data Domain system; and

• The DSP component reviews the data that is already stored on the

Data Domain system and sends only unique data for storage.

At a glance, Table 17 shows, for each Database, the backup levels

supported by NMDA.

Table 17. NMDA supported backup levels

Database

or

application

Supported backup levels

Oracle • Level full, incr, or 1 to 9 - NetWorker server runs the

backup script on that day. The backup level set in the

RMAN backup determines the Oracle backup level;

and

• Level skip - NetWorker server skips the backup on that

day;

DB2 • Level full - DB2 full backup of all the database data;

• Level incr - DB2 incremental backup;

• Level 1 to 9 - DB2 delta backup; and


day.

To support the NetWorker backup levels from the Schedule

resource:

• Set the DB2_APPLY_NW_LEVELS parameter to TRUE in

the NMDA configuration file; and

• Set the TRACKMOD parameter to ON with DB2

command at the operating system command line.

Informix • Level full - ON-Bar level 0 backup of all the selected

dbspaces of the database instance;

• Level1 - ON-Bar level 1 backup of the data that has

changed since the last level 0 backup;

• Level 2 to 9 - ON-Bar level 2 backup of the data that

has changed since the last level 1 backup; and


day.

Lotus • Level full - Lotus full backup of all the data;

• Level incr - Lotus incremental backup of only data that

has changed since the last backup;


62

Database

or

application

Supported backup levels

• Level 1 - Lotus transaction logs only backup; and


day.

Note: NMDA does not support NetWorker backup levels 2 to 9

for Lotus. If specified, the backup will fail.

MySQL • Level full - Full backup of all the data;

• Level incr - Differential incremental backup of only the

data that has changed since the last full or

incremental backup; and

• Level 1 - Cumulative incremental backup of only the

data that has changed since the last full backup.

Note: NMDA does not support NetWorker backup levels 2 to 9

for MySQL. If these are specified, NMDA will use level 1

instead.

Sybase • Level full - Sybase full backup of all the data;

• Level incr - Sybase incremental backup of only the

transaction logs generated since the last full or

incremental backup; and


day.

Note: NMDA does not support the NetWorker backup levels 1

to 9 for a Sybase backup. The backup fails if these levels are

set.

A whole instance incremental backup skips the backup of

any database that does not support incremental backup (i.e.

when the database data and transaction logs are on the

same device).

Design Decision

XYZ will utilise NMDA for Oracle data protection and recovery. Current

RMAN scripts will be modified to send backup data to NetWorker via

NMDA.

Format string of FULL_%d_%U is recommended to ensure unique names

are generated.

allocate channel type will be set to SBT_TAPE to perform backups to

NetWorker.


63

NMDA supports specific features of Oracle Server backup and restore

operations. NMDA interacts with RMAN software through the Oracle

SBT interface to perform Oracle backups and restores.

Oracle full and incremental backups

NMDA supports full and incremental backups of Oracle data:

Backup

level

Functionality

full This includes every used block of the database objects

specified in the RMAN backup script. The backup skips never-

used blocks. This type of backup occurs when you do not

specify a backup occurs when you do not specify a backup

level with the RMAN backup command.

incremental This includes blocks that have changed since the previous

specified backup. Incremental backups occur when you

specify either incremental level=0 or incremental level=1 with

the RMAN backup command. Incremental backups are

dependent on preceding incremental backups in the same

scheduled backup cycle:

• A level 0 incremental is physically identical to a full

backup, but is recorded as incremental in the RMAN

repository.

• A level 1 incremental can be either of the following

backups:

▪ A differential backup, which contains only the data

blocks that changed since the most recent incremental

backup, whether level 0 or 1. The differential backup is

dependent on the preceding level 0 or 1 backup.

Incremental backups are differential by default.

▪ A cumulative backup, which contains only the data

blocks changed since the most recent level 0

incremental backup. The cumulative backup is

dependent on the preceding level 0 backup.

Design Decision

Full and incremental backups of Oracle databases will be performed.

Differential backups will be used for incremental purposes rather than

cumulative.

Backup of Archived Redo Logs

Backups of archived redo logs enable recovery of the database to its

pre-disaster state. Without these backups, the database can only be

recovered to the time of the last consistent Oracle backup. In this case,

the transactions that occurred between the time of the last consistent

backup and the time of the database corruption will be lost.

NMDA for

Oracle


64

It is recommended to perform a full or incremental backup every 24

hours at a minimum, and schedule more frequent backups of only the

archived redo logs.

Design Decision

A separate backup job will be created for each Oracle instance to

perform save set staging of archive redo logs on an hourly basis.

Control file Auto Backups

In addition to regular control file backups, Oracle performs a control file

autobackup after each RMAN backup command if enabled.

With a control file autobackup, RMAN can recover the database even

if the current control file, the recovery catalog, and the server

parameter file are inaccessible. The path used to store the autobackup

follows a well-known format.

Persistent settings can be specified for the control file auto backups

with the configure controlfile autobackup command. For example,

control file autobackup can be enabled by specifying the persistent

setting for the format of the control file autobackup name with the

following commands:

configure controlfile autobackup on configure controlfile

autobackup format for device type ’sbt_tape’ to ’/NMDA_%F/’

If control file autobackup is enabled, NMDA backs up the control file.

With the control file autobackup, Oracle software backs up the current

server parameter file.

Design Decision

Control file autobackup will be enabled for all Oracle databases.

Backup and Restore Optimisation

If Oracle backup optimisation is enabled, RMAN skips selected files

during a backup, based on several criteria. The Oracle backup and

recovery documentation describes these criteria.

The backup of files that would otherwise be skipped due to backup

optimization can be forced using a command option.

The restore optimization function prevents RMAN from restoring a file if

the original file is already in the correct location and contains the

expected information. The force option can also be used with regard

to a restore of a file that would otherwise be skipped due to restore

optimization.

Backup Copies

RMAN with NMDA can create copies of the backup, also known as

duplexing the backup. RMAN can produce up to four identical copies


65

of each backup piece on different NetWorker volumes with one

backup command.

NMDA supports backup copies with manual Oracle backups only.

NMDA does not support the use of the RMAN backup copies

commands during scheduled Oracle backups.

Retention Policies

Oracle RMAN provides an Oracle retention policy for backups. An

Oracle retention policy is based on the recovery window or on

redundancy. The retention policy is not based on a time period, such as

a year. Oracle RMAN considers a backup to be obsolete when the

backup is no longer required according to the Oracle retention policy.

Oracle RMAN checks the retention policy of a backup when running

the report obsolete or delete obsolete command.

NMDA supports the Oracle retention policy with some restrictions. The

NetWorker server has its own browse policy and retention policy to

specify how long data is available for recovery. The NetWorker policies

are based on a user-defined time period. As the Oracle retention policy

is independent from that of the NetWorker server and there is no

mechanism to synchronize the policies, the NetWorker and Oracle

policies could conflict.

To prevent conflicts, do not use both the NetWorker and Oracle

policies. Instead, perform either of the following actions:

• If the NetWorker server policies are used, disable the Oracle

retention policy; or

• If the Oracle retention policy is used, disable the NetWorker

retention policy by setting the NSR_RETENTION_DISABLED

parameter to TRUE in all the RMAN backup scripts. With the

parameter set to TRUE, the NetWorker server never expires the

backups. Run the report obsolete and delete obsolete commands

so that RMAN can delete the backups based on the Oracle

retention policies.

When using the Oracle retention policy, run the crosscheck command

on the NMDA backups before running the report obsolete command or

a delete obsolete command with the device type sbt_tape option. This

action ensures that backups which the NetWorker server considers to

be expired are flagged as expired in the RMAN catalog. As a result,

RMAN can correctly identify which backups are not needed according

to the Oracle retention policy.

Save set bundling

If you configure NMDA save set bundling, NMDA automatically creates

a save set bundle to group all dependent save sets from the same

backup cycle. Save sets are dependent when two or more save sets

are required to restore a database object.

A backup cycle includes the following backups:

• A level 0 incremental backup of the database object; and


66

• All subsequent level 1 incremental backups that are dependent

on the level 0 backup.

Oracle 11gR1 features

With Oracle 11gR1 and later, NMDA supports the following RMAN

features:

• Data Recovery Advisor as described in “Data Recovery Advisor”

on page 52 of the NDMA Administration Guide;

• Archival backup through the RMAN backup...keep command as

described in “Archival backup feature” on page 52 of the NDMA

Administration Guide;

• Improved archived redo log management through the configure

archivelog deletion policy command;

• Improved block media recovery when the recover...block

command replaces the blockrecover command;

• Improved integration and block change tracking support in Data

Guard;

• Backup of read-only transportable tablespaces; and

• Oracle Enterprise Manager enhancements with new interfaces for

the Data Recovery Advisor.

Oracle 11gR2 features

With Oracle 11gR2, NMDA supports these RMAN features:

• Enhanced duplicate command that can duplicate a database

without connecting to a target database by using the NMDA

backups of the target database (connections to a catalog and

an auxiliary database are required);

• Tablespace Point-in-Time Recovery (TSPITR) enhancement that

recovers a dropped tablespace and recovers to a point-in-time

before bringing the tablespace online; and

• Advanced Compression Option.

Note Do not enable both Oracle and NetWorker compression for

NMDA Oracle backups.

• Oracle Grid infrastructure for either a stand-alone database or a

RAC.

• Oracle ASM Dynamic Volume Manager (Oracle ADVM), a new

feature of Oracle ASM that provides volume management

services and a standard disk device driver interface to clients.

• Policy-managed RAC databases.

Other Oracle features

NMDA supports other Oracle RMAN features, for example:

• Fast incremental backups that use change tracking files;

• Management of backup duration and throttling;


67

• Backups and restores of data that resides on Oracle ASM;

• Backup of the fast recovery area;

• Data Recovery Advisor;

• Archival backup through the RMAN backup…keep command;

• Improved archived redo log management through the

configure archivelog deletion policy command;

• Improved block media recovery when the recover…block

command replaces the blockrecover command;

• Improved integration and block change tracking support in

Data Guard;

• Backup of read-only transportable tablespaces; and

• Oracle Enterprise manager enhancements with new interfaces

for the Data recovery Advisor.

Design Decision

A configuration decision will be listed here when we know more about

the XYZ Oracle environment and requirements.

Chapter 10: VMware vSphere Integration

68

10 VMware vSphere

Integration

This section details the VMware vSphere integration portion of the

NetWorker solution, specifically:

• Virtual Machine Backup Approaches;

• EMC Backup and Recovery Appliance (VBA);

• VBA System Requirements; and

• Network and Firewall port requirements.

When protecting the data of a VM there are two main approaches for

backup and recovery being, Client based and Image based. For

Image based backups there are two methods using either VADP or the

VBA appliance.

Client Based

This approach involves installing a NetWorker Client onto each VM.

Using this approach, the VM is effectively treated as a standalone

server and protected using the VMs network interfaces. This method is

popular as the same process can be employed for both physical and

virtual servers potentially reducing operational complexity.

For incremental and differential level backups, the NetWorker Client is

able to determine the changes in the local file systems attached to the

clients and only backup the changed data.

The client based approach provides a simple backup approach for

VMs; however, it lacks the integration with VMware and can therefore

lead to inefficiencies in the backup environment.

Image based using VADP

This approach uses the VMware vStorage APIs for Data Protection

(VADP) to offload the backup processing from the VM to a separate

elected backup proxy. In this approach, the processing is completed

on the proxy host. This approach is initially more complex to configure

but can improve the overall effectiveness into the environment.

For incremental backups Changed Block Tracking (CBT) can be

enabled VMs running on vSphere 4.0 or later with virtual hardware 7.

CBT allows disk sectors that have changed to be tracked, when

NetWorker initiates a backup of the VM the virtual drive block changes

are analysed and used to determine which files to backup. CBT is only

supported on VMs running Windows and using the NTFS file system. Full

image level recovery is not supported from a CBT-Based incremental

backup.

Virtual Machine

Backup

Approaches


69

VADP does not support the backup and recovery of drives marked as

independent persistent within VMware, if these drive types are

detected during a backup they are skipped and a message is logged

to the backup administrator. If the use of independent persistent drives

is used within VMware and are required to be protected by NetWorker

these must be protected using a NetWorker Client installed onto the

host.

Image based using EMC Backup and Recovery appliance (VBA)

VBA provides full integration with VMware vSphere and enables

backups and recoveries from the vSphere UI. VBA is a software

appliance that is installed into an existing VMware environment as an

OVA deployment. VBA enhances administration by enabling the

VMware Administrator to kick off backups from vSphere.

The NetWorker Admin is responsible for ensuring that the backups

adhere to corporate compliances (SLAs, retention, disaster recovery,

etc) by defining the policies and backup targets within NMC

(NetWorker Management Console). VBA backups can be monitored

from NMC.

A web based UI is available to the system administrator and enables

recoveries directly from a VM. VBA supports file level recovery of

Windows and Linux.

Table 18 compares the features available in guest and image based

backup types and recovery approaches.

Table 18. Guest, VADP and VBA Approach Comparison

Option Guest-based VADP VBA

Recommend for • Application-

consistent

backups

• Shared

storage not

available

• LAN free backups

• Disaster recovery

• Shared storage

environments

• Direct backup to

tape

• LAN free backups

• Disaster recovery

• Shared storage

environments

• Forever incremental

VMDK (Image)

level backups

No Yes Yes

Individual file

backups

Yes Yes for windows guest

only

Not required

Incremental File level File level Block level, leverages CBT

CBT Not supported File level Block level

Virtual full

backup

Not supported Not supported Backup is always virtual full

File level restore Yes Yes for Windows guest

OS only

Yes for Windows and Linux


70

Option Guest-based VADP VBA

Deduplication

supported

Yes Yes - Direct backup to

Data Domain

Yes - Direct backup to

VBA internal storage or to

a Data Domain

appliance. Leverages

source as well as target-

level Deduplication

Impact on

virtual machine

High Low Low

Impact on

ESX/ESXi server

High Medium, if snapshots

performed for multiple

VMs on same

ESX/Datastore

Medium depending on

number of snapshots on

VMs of the same ESX

Backup

performance

Slower Faster - dependant on

resources on proxy and

whether FLR required

Faster

Additional

hardware

requirements

No Uses a physical or

virtual proxy

Uses internal or external

proxies. Each VBA and

external proxy has 8

internal proxies

embedded.

Proxy Not applicable Physical (SAN) or virtual

(hotadd)

Virtual (hotadd)

vCenter auto-

discovery

Not applicable Supported Not supported

Configuration NetWorker client

configured

through Client

configuration

wizard

Proxy and virtual

machine as Networker

client configured

through Client

Configuration Wizard.

VBA registration through

web interface

Configure VM as

a NetWorker

client?

Yes Yes No

Transport mode

supported

Not applicable Hotadd, SAN, NDBSSL,

NBD.

Hotadd (default), NBD

(fallback)

Design Decision

VBA will be utilised in the XYZ environment to perform image level

backups of VM servers not running applications.


71

VBA appliance Overview

NetWorker VMware Protection provides a VBA that, when deployed

and configured, allows you to set up backup policies in NMC and then

assign VMs to those backup policies by using the VBA plug-in within the

vSphere Web Client.

Some advantages of VBA include:

• Supports forever incremental;

• Uses existing AVE (Avamar Virtual Edition) technology;

• Supports file-level recovery directly into the VM on Linux and

Windows;

• Uses advanced FLR to perform file-level recovery from other VMs

to a VM; and

• Backups directed to a Data Domain from a VBA can be cloned

to another Data Domain, AFTD or physical tape.

Limitations of VBA include:

• VBA cannot coexist with VADP or any third-party backup plug-in

in the same vCenter;

• VBA cannot detect if there is another VBA in vCenter. Care must

be taken when assigning VM backups to an appliance;

• You can only backup to VBAs internal storage or to a Data

Domain;

• Only backups to a Data Domain can be cloned to other media;

and

• Only image-level backups can be performed; you cannot

perform individual folder or drive-level backups. However, file-

level recoveries ARE supported for both Windows and Linux.

Best practices for VBA include:

• Deploy the VBA appliance on shared VMFS5 or higher to avoid

block size limitations;

• Avoid deploying VMs with IDE virtual disks; using IDE virtual disks

degrades the backup performance;

• Hotadd transport mode should be used for faster backups and

restores and less exposure to network routing, firewall and SSL

certificate issues. To support hotadd mode, deploy the EMC

Backup and Recovery appliance on an ESXi host that has a path

to the storage holding the virtual disk(s) being backed up; and

• Install VMware Tools on each VM that you want to backup using

the EMC Backup and Recovery plug-in user interface. VMware

Tools adds additional backup capability that quiesces certain

processes on the guest OS prior to backup. VMware Tools is also

required for some features used in File Level Restore.

EMC Backup

and Recovery

Appliance (VBA)


72

For Change Block Tracking (CBT) support, ensure:

• that all VMs run VMware hardware version 7 or higher; and

• if a disk is added or dynamically expanded on a VM, a new full

backup must be taken for CBT to function.

VBA does not support the following disk types:

• Independent;

• RDM Independent - Virtual Compatibility Mode; and

• RDM Physical Compatibility Mode.

External Proxy Transport Modes

The NetWorker VMware Protection (VBA) solution supports the hotadd

and nbd transport modes. The hotadd mode is the default transport

mode:

• Network Block Device (NBD) - This mode can be used for both

virtual and physical proxy servers. In this mode, the vSphere

server hosting the VM handles the backup resources required as

the backup data is transferred over the IP network to the

external proxy. NBD mode is not supported for restores and

permits 20 concurrent backups per vSphere host; and

• Hotadd - This mode requires a virtual proxy, all backup related

I/O is handled internally by the VMware I/O subsystem using

Small Computer Systems Interface (SCSI) hotadd technology.

While this mode does provide better transfer rates that the NBD

and NBDSSL modes an additional backup related CPU, memory

and I/O load is placed on the vSphere server. VMs with

Integrated Drive Electronics (IDE) virtual disks are not supported.

VBA is available in 2 capacities - a 0.5 TB and 4 TB OVA. Table 19

provides more information on the VBA requirements.

Table 19. VBA Requirements

Component Requirements

NetWorker 8.2 Server software with NMC

0.5 TB OVA CPU: 4 * 2 GHz

Memory: 8 GB

Disks: 3 * 250 GB

Backup storage capacity: 0.5 TB

OS: 250 GB

VBA System

Requirements


73

Component Requirements

4 TB OVA CPU: 4 * 2 GHz

Memory: 12GB- 24GB physical memory

16GB swap space

Disks: 6 * 1 TB

Backup storage capacity: 4 TB

OS: 250 GB

Proxy Appliance CPU: 4 * 2 GHz

Memory: 4 GB

Disks: 2 disks (16 GB and 1 GB)

vCenter Server Version 5.5 and later

Linux or Windows platform or VC appliance

vShere Web Client

Must enable web browsers with Adobe Flash

Player version 11.5 or higher to access the

vSphere Web Client, File-level recovery (FLR)

and EMC Backup and Recover plug-in user

interface.

ESX/ESXi server Version 5.1 and later

Changed Block Tracking (CBT) enabled

Data Domain DDR OS at DDOS 5.4.0.4 and later

DDBoost user requires administrator privileges

Deployment of VBA in the vSphere server

VBA becomes available when it is deployed in the vSphere server and

registered with NetWorker and vCenter.

Backups can then be restored from the vSphere Web Client, or file-level

recoveries can be performed using the EMC Data Protection Restore

Client user interface.

Data Protection policies, scheduling of backups and assigning of

backup policies to an VBA can be performed from NMC. As VBA is a

virtual appliance, only the hotadd and nbd transport modes are

supported.

The EMC Backup and Recovery appliance leverages VMware Tools to

synchronize time through NTP. All ESXi hosts and the vCenter Server

should have NTP configured correctly. The VBA appliance obtains the

correct time through VMware Tools and should not be configured with

NTP.


74

Table 20 compares tasks in NMC with tasks in the vSphere Web Client

and the EMC Data Protection restore client.

Table 20. NetWorker VMware Data Protection tasks

Program/Role Task

VMware vSphere

Web Client

interface with

EMC Backup

and Recovery

plug-in

Assign VMs to the backup policy created in NMC.

Start an adhoc VM backup.

Restore a full VM backup.

NOTE: When you start a policy from the vsphere Web

client interface, you can only perform backups and not

clones.

NMC Create and edit Data Protection policies (backup,

clone).

Assign a backup policy to the VMware Backup

Appliance.

Start or schedule a policy for backup.

Note: When you start a policy from NMC, you can

perform both backups and clones, based on the

actions defined in the policy.

EMC Data

Protection

Restore Client

Perform file-level restores.

Note: Supports both Windows and Linux platforms.

Performance considerations must be considered when deploying an

VBA:

• Backups to a Data Domain occur faster than backups to VBA

internal storage;

• VBA can backup up to 8 VMs in parallel. If requiring to backup

more VMs in parallel, then add external proxies. Each external

proxy can backup up to 8 VMs;

• For better performance, EMC recommends using a dedicated

data store for VBA;

• Each VM backup to a Data Domain consumes 1 session on the

Data Domain\ device. Create more Data Domain devices if

maximum limit of 60 sessions to a single device is exceeded; and

• EMC recommends using 1 VBA + 2 External proxies per vCenter.

Table 21 provides information on expected performance for different

setups.


75

Table 21. Maximum concurrent sessions per VBA

Deployed per vCenter Maximum

concurrent

sessions

1 VBA 8

1 VBA + 1 external proxy 16

1 VBA + 2 external proxies 24

1 VBA + 3 external proxies 26

Table 22 details the concurrency per component

Table 22. Concurrency/parallelism

Component Concurrency

count

Notes

Proxies per vCenter 3 vCenter with the default

configuration achieves good

performance with 25 sessions.

Each VBA has 8 internal proxies,

and the external proxy adds 8

more concurrent sessions.

Therefore use 1 VBA and 2

external proxies.

VMs per policy 25 vCenter can process 25 VMs at a

time. If a policy contains more

than 25 VMs, the remaining VMs

will be queued.

VBA appliance 26

concurrent

VMs

The maximum concurrent sessions

per VBA is 26, irrespective of the

target device.

External proxy 24

concurrent

hotadd

VMDKs

External proxy has only 2 SCSI

controllers which limits the

concurrent hotadd sessions to 24.

If you backup more than 24

VMDKs, the backup uses NBD

mode

vCenter 25

concurrent

sessions

EMC recommends a maximum of

25 concurrent VM backups per

vCenter. If vCenter runs on a

standalone server with the

vCenter database running on

SQL, then a single vCenter can

process more than 25 VMs at a

time.


76

Component Concurrency

count

Notes

vCenter 2 external

proxies (VBA

includes an

internal

proxy)

Due to the above

recommendation, EMC

recommends 2 external proxies

per VBA for concurrent backups.

VBA Proxy considerations

EMC Backup and Recovery selects a proxy from the proxy pool based

on its availability and periodically refreshes the Proxy to datastore

association. If a Proxy is available and has access to the datastore of

the VM that you want to backup, then the Proxy uses hotadd mode. If

a Proxy is available but does not have access to the datastore of the

VM that you want to backup, then the Proxy uses NDB mode, which is

over LAN and typically slower than hotadd mode.

Currently the number of hotadd sessions that an external Proxy can

establish depends on the total number of VMDKs present on all the VMs

being backed up. For example, a Proxy with one controller can only

support 12 hotadd sessions, and if there are more than 12 VMDKs being

backed up, then the proxy will fallback to nbd mode for the remaining

VMDKs.

A proxy can be restricted to only backing up datastores on the ESXi

host that houses the proxy.

Each external proxy VM has 2 SCSI controllers and each SCSI controller

allows a maximum of 12 hotadd backups and recoveries. Therefore,

each external proxy can simultaneously perform 24 hotadd

backup/recovery operations. Any backup operation that exceed this

number will result in the backup falling back to nbd transport mode.

NetWorker backs up each virtual disk from the VM sequentially when

the VM has more than2 VMDK files. However, if you leverage CBT,

backup speed increases with very little or no change rate of data on

VMs.

Refer to Table 29 NetWorker environment firewall port requirements for

all firewall port requirements.

vCenter VBA User Access

EMC recommends using a separate vCenter user account that is strictly

dedicated for use with VBA. The user would need the following

privileges as detailed in Table 23.

Network and

Firewall port

requirements


77

Table 23. VBA User Account Privilege Requirements

Setting vCenter 5.1 required privileges vCenter 5.0 required privileges

Alarms • Create alarm • Create alarm

Datastore • Allocate space

• Browse datastore

• Low level file operations

• Move datastore

• Remove datastore

• Remove file

• Rename datastore

• Allocate space

• Browse datastore

• Low level file operations

• Move datastore

• Remove datastore

• Remove file

• Rename datastore

Extension • Register extension

• Unregister extension

• Update extension

Folder • Create folder • Create folder

Global • Cancel task

• Disable method

• Enable method

• Licenses

• Log event

• Manage custom attributes

• Settings

• Cancel task

• Disable method

• Enable method

• Licenses

• Log event

• Manage custom attributes

• Settings

Network • Assign network

• Configure

• Assign network

• Configure

Resource • Assign virtual machine to

resource pool

• Assign virtual machine to

resource pool

Sessions • Validate session • Validate session

Tasks • Create task

• Update task

• Create task

• Update task

vApp • Export

• vApp application

configuration

• Export

• vApp application

configuration

Virtual Machine


78


Configuration • Add existing disk

• Add new disk

• Add or remove device

• Advanced

• Change CPU count

• Change resource

• Disk change tracking

• Disk Lease

• Host USB device

• Memory

• Modify device setting

• Raw device

• Reload from path

• Remove disk

• Rename

• Reset guest information

• Settings

• Swapfile placement

• Upgrade virtual hardware

• Extend virtual disk

• Add existing disk

• Add new disk

• Add or remove device

• Advanced

• Change CPU count

• Change resource

• Disk change tracking

• Disk Lease

• Host USB device

• Memory

• Modify device setting

• Raw device

• Reload from path

• Remove disk

• Rename

• Reset guest information

• Settings

• Swapfile placement

• Upgrade virtual hardware

• Extend virtual disk

Guest Operations • Guest operation

modifications

• Guest operation program

execution

• Guest operation queries

• Guest operation

modifications

• Guest operation program

execution

• Guest operation queries

Interaction • Console interaction

• Guest operating system

management by VIX API

• Power off

• Power on

• Reset

• VMware Tools install

• Acquire guest ticket

• Console interaction

• Power off

• Power on

• Reset

• VMware Tools install

Inventory • Create new

• Register

• Remove

• Unregister

• Create new

• Register

• Remove

• Unregister

Provisioning • Allow disk access

• Allow read-only disk access

• Allow virtual machine

download

• Mark as Template

• Allow disk access

• Allow read-only disk access

• Allow virtual machine

download

• Mark as Template


79


Snapshot

Management

• Create snapshot

• Remove Snapshot

• Revert to snapshot

State • Create snapshot

• Remove Snapshot

• Revert to snapshot

VBA integration with NMC

In the Configuration tab of NMC, two resource groups are displayed in

the lower part of the left hand pane:

• VMware Backup Appliance - displays the registered VMware

Backup Appliance(s); and

• VMware Protection Policies - displays the default policy after

NetWorker registers the first VMware Backup Appliance.

Additionally, new resources appear in the Devices window. NetWorker

automatically creates a default device for the VMware Backup

Appliance, based on the media type AFTD, for the VMware Backup

Appliances internal storage.

NetWorker creates a default policy (“Default”) and this is applied to all

registered VMware backup appliances. New policies can be created

to backup VMs based on retention, how many clones required etc.

The options configurable in the policy are:

• Start time - when the policy will start the backup;

• Interval - how often the policy will run. i.e. 24:00 means it will run

every 24 hours;

• Autostart - Enabled means it will run automatically;

• Actions are then assigned to the policy. For example, if you want

to backup and then clone, two actions, Backup and Clone will

need to be created;

• These are then assigned to the policy in order of Backup first,

then Clone;

• Destination pools, either to the VBA internal device or to a Data

Domain device are assigned;

• For clone operations, a clone pool containing tapes will be

selected; and

• Browse and Retention policies for index management are also

configurable. A clone operation can have a different browse

and retention period to a Backup operation.


80

The policy can be assigned to multiple VBAs if there are multiple in the

environment.

An example policy is displayed in Figure 4.

Figure 4. Example VBA policy

Cloning operations can be configured to run concurrently, similar to

NetWorker’s immediate cloning operation which allows a group to start

cloning upon each save set completion.

Policies can be started manually, for testing purposes and the progress

can be viewed in the NMC Monitoring window.

EMC Backup and Recovery plug-in for vCenter

The vSphere Web Client provides access to the EMC Backup and

Recovery plug-in user interface. The VBA plug-in user interface functions

as a plug-in within the vSphere Web Client to connect to the EMC

Backup and Recovery appliance for VM backup storage.

You cannot use the VBA appliance without a vCenter Server. In linked

mode, the EMC Backup and Recovery appliance works only with the

vCenter to which it is associated.

The VBA plug-in user interface appears in the vSphere Web Client and

allows you to add VMs to the policies created in NMC.


81

Figure 5. VBA plug-in user interface

The VBA plug-in allows you to configure and manage the VBA

appliance. The VBA plug-in user interface provides the following

functionality:

• Backup:

▪ Provides a list of scheduled backup policies and their details;

▪ Enables users to add VMs to protect to the backup policies;

and

▪ Enables users to run backup policies on demand. When

backups are started from the VBA plug-in, the clone actions

associated with the policy will not run. Only when run from

NMC will clone actions also run.

• Restore:

▪ Provides a list of successful backups that users can restore

from.

• Reports:

▪ Provides backup status reports for the VMS on the vCenter

Server that you added to a backup policy.

• Configuration:

▪ Displays VBA configuration information and allows editing of

some of the settings.

▪ Allows running of integrity checks.


82

Design Decision

VBA is recommended to protect virtual machines. A 0.5 TB VBA and 2 x

external proxies will be implemented, redirecting image backups of

VM’s to Data Domain devices.

The VM image backups will then be replicated/cloned to the remote

Data Domain.

XYZ will provide a user with the specified privileges to use for backup

and recovery integration. This user will be used for backup and

recovery operations only for audit purposes.

Chapter 11: Isilon Integration

83

11 Isilon Integration

The EMC® NetWorker® server software includes optional features to

enable NetWorker snapshot management for network-attached

storage (NAS) also called NSM for NAS. Supported NAS devices are

EMC Isilon®, EMC VNX®, EMC VNX2®, EMC VNXe® and NetApp.

NAS devices are configured as clients of the NetWorker server, for

example, by using the Client Configuration Wizard, but you do not

install NetWorker client software on a NAS device. NAS snapshot and

replication features are covered by NDMP licenses.

Table 24. Glossary of snapshots

Term Definition

snapshot Point-in-time (PiT) copy of specific data files, volumes,

or file systems on an application host that is created on

an external disk subsystem, such as a NAS device.

snapshot

backup

A snapshot created on a storage array as a backup

(the snapshot is left on the array).

rollover The backup of a snapshot to conventional media, such

as disk or tape.

snapshot

retention

A snapshot maintained on the array (allows for multiple

snapshots to be available for PiT recovery).

snapshot restore A restore from a snapshot backup (i.e. the snapshot on

the array).

recover To restore data files from a backup storage to a client

and apply transaction (redo) logs to the data to make

it consistent with a given point-in-time.

restore 1. Recover.

2. To retrieve individual data files from a backup and

copy the files to a client without applying

transaction logs.

rollover-only

backup

A rollover whereupon the snapshot copy is deleted

from the array.

Table 25. NAS device support and limitations

NAS device Characteristics

EMC Isilon • Supports snapshots with SnapshotIQ and requires

OneFS 7.02 or later;

• Supports replications with SyncIQ and requires

OneFS 7.1 or later;

• Supports snapshots and replication at the directory

level;


84

NAS device Characteristics

• Supports in-place and out-of-place recovery of

snapshot directories;

• Supports directed recovery; and

• Does not support in-place or out-of-place recovery

from a remotely replicated snapshot.

EMC VNX/VNX2 • Supports snapshots at the file system level;

• The client resource must specify the Control Station

name;

• Supports directed recovery;

• Does not support in-place or out-of-place snapshot

recovery; and

• Does not support replication.

EMC VNXe • Requires Unisphere Management client (uemcli) on

the NetWorker server;

• Supports snapshots at the file system level;

• The Client resource must specify the Control Station

name;

• Supports directed recovery;

• Does not support in-place or out-of-place snapshot

recovery; and

• Does not support replication.

NetApp • Requires operating system libraries from the NetApp

Manageability SDK, available from NetApp. On

Microsoft Windows, install in a directory in the

system-level PATH variable. On Linux, install in the

/usr/lib64 directory;

• Supports snapshots at the volume-level only. No

support for cluster-mode systems or for replication

(SnapMirror and SnapVault);

• Supports OnTAP8.0 or later (7-mode only);

• Supports in-place and out-of-place recovery of

snapshot files but not directories or save sets (except

if the save set is a single file), and only to the same

volume as the source;

• Supports directed recovery; and

• Does not support a temporary mount point for

snapshot browse and recovery (NetApp on Linux

limitation). Must use an existing NFS mount point.

Design Decision

XYZ will utilise NSM for NAS for their Isilon. All information going forward in

this section will address NAS for Isilon only.


85

A NAS device is a dedicated file server that provides primary data

storage for application servers in a heterogeneous network

environment. A NAS device may also be called a NAS filer, NDMP data

server, NDMP client, or a data mover. The NAS device organizes and

presents stored data as file systems. Data backup and data recovery

operations can also use NDMP over a TCP/IP network. NDMP enables

the required device drivers between the primary NAS device storage

and secondary storage on tape or VTL devices.

The amount of data stored on NAS devices can often be large and the

backup times for tape and VTL devices can exceed the available

backup window. By scheduling local point-in-time snapshot copies of

the NAS data, NetWorker can replicate the snapshot data and use

whatever time is required to rollover the data to the backup media

independently of the normal backup windows.

NetWorker works with NAS devices to perform the following snapshot

and replication operations:

• Create a local snapshot save sets of specified data on the NAS

device;

• Replicate specified snapshot data on a source NAS device to a

different location on the device or to a location on a different

NAS device;

• Perform immediate or delayed rollover of specified snapshot

save sets to secondary storage by using NDMP;

• Apply retention policies to manage the lifecycles of snapshot,

replication, and rollover save sets; and

• Recover specified data from snapshots and rollovers.

NetWorker applies retention policies to manage the lifecycles of

snapshot and rollover save sets.

Discovery of non-NetWorker snapshots

NetWorker can discover snapshots on the NAS device that NetWorker

did not create. NetWorker can manage these snapshots as follows:

• NetWorker catalogs all discovered snapshots as snapshot save

sets;

• NetWorker can roll over, recover, and report details of

discovered snapshots but cannot delete them; and

• You can schedule discovery once per day or perform discovery

manually.

Types of NAS snapshot-based backups

The types of NAS snapshot-based backup that you configure depend

on where you intend to create and store the snapshots, as follows:

• Local snapshot only:

NAS snapshot

operations


86

▪ NetWorker creates a snapshot of specified files on the ANS

device and retains the snapshot on the device. The NetWorker

server catalogs the snapshot as a backup in the media

database and can perform a recovery from the snapshot.

• Local snapshot with rollover:

▪ Local snapshot and rollover backup – NetWorker creates a

snapshot of specified files on the NAS device and immediately

rolls over the snapshot to conventional storage on tape or VTL

media. The NAS device retains the snapshot. The NetWorker

media database catalogs both the snapshot and the rollover

as backups. The NetWorker client file index catalogs the

rollover. The NetWorker server can perform a recovery from

either the snapshot or the rollover; and

▪ Rollover-only backup – NetWorker creates a snapshot of

specified files on the NAS device and immediately rolls over

the snapshot to conventional tape or VTL media. When the

rollover completes, NetWorker deletes the snapshot. The

NetWorker server can recover only from the rollover.

• Snapshot with replication snapshot (Isilon only):

▪ NetWorker creates a snapshot of specified files on a NAS

device that you configured with replication policies, and the

device-specific features replicate the file to either the same

device or to a remote NAS device. When this operation

completes, NetWorker creates a snapshot of the replicated

data. The NetWorker server catalogs the remote snapshot as a

backup in the media database. The NetWorker server can

perform rollover and recovery operations from that snapshot.

Figure 6. NetWorker integration with Isilon snapshots


87

Types of NAS snapshot recoveries

The types of recovery that you can perform for snapshot-based save

sets depends on the location of the snapshot backup and where you

want to recover the data:

• Snapshot recovery – NetWorker mounts the snapshot volume

where you can browse the save sets and select the directories or

the individual files to recover:

▪ In-place – recovers files and directories to their original

locations on the NAS device;

▪ Out-of-place – recovers files and directories to a new

location you specify on the NAS device; or

▪ Directory recovery – recovers files and directories to the

NetWorker host that runs the recovery. You can configure

the recovery directory as an NFS or CIFS file share, which

enables you to recover to a remote location, such as

another client or a NAS device.

• Recovery from rollover – essentially the same as recovery from a

backup. You perform a conventional NetWorker recovery from

the backup storage media.

Figure 7. Snapshot with rollover - recovery


88

Design Decision

Selected Isilon snapshots will be rolled over to Data Domain devices via

the physical storage node.

If required, snapshots rolled over to Data Domain devices can be

cloned to physical tape.

Replication of Isilon snapshots will occur to the remote Isilon.

Restores can occur from rollover on Data Domain devices or physical

tape.

Snapshot lifecycle policy

NetWorker software provides lifecycle policies for snapshot save sets.

Snapshot policies specify the following information:

• The time interval between the snapshots;

• The maximum number of snapshots stored on a NAS device,

after which NetWorker automatically deletes the oldest

snapshots; and

• Which snapshots NetWorker backs up to conventional storage

media.

Recovery Interfaces

Administrators can use the following interfaces to recover snapshot-

based data:

• The NetWorker Recovery Wizard is the recommended interface

to use to recover data from the snapshots and conventional

storage media.

• The nsrsnapadmin command utility provides an interactive

Command Line interface (CLI) session for various snapshot-

related operations, including recovery from a snapshot and

recovery from conventional storage media.

• The nsrnassnap_recover command provides another CLI method

to recover data from a snapshot or conventional storage media.

Chapter 12: Management Considerations

89

12 Management

Considerations

This section details the technical considerations and configuration

options available in regard to management for the NetWorker

environment, specifically:

• NetWorker Management Console (NMC);

• Data Protection Advisor (DPA);

• User-Based Authorisation;

• Monitoring, Reporting, and Analysis; and

• Alerting.

The central pane for NetWorker Server management is the NMC.

The NMC consists of two main windows:

• Console window; and

• Administration window.

The Console window is used to monitor and report on all NetWorker

Servers across the entire environment, view events, manage devices

across all NetWorker Servers, configure user authentication, and

produce backup reports.

The Administrator window is used to configure a single NetWorker

Server, including associated clients and their related policies and

schedules.

Design Decision

The NMC is used to configure and manage the NetWorker Server in the

environment. The NMC will be hosted on the same VM as the

NetWorker server.

NetWorker

Management

Console (NMC)


90

Effectively managing your data protection environment is often labour

intensive and complex. It requires knowledge of the backup

applications, replication technologies, and the entire supporting

infrastructure. Adding to the complexity, there are varying service-level

agreements (SLAs) for backup and recovery, replication, and

virtualization, as well as audit and compliance requirements to

consider. And, with many IT organizations having multiple data centres,

combined with new hybrid computing models, data is often spread

across a mix of private and public cloud resources, which increases the

difficulty in seeing and managing data wherever it may reside.

EMC Data Protection Advisor (DPA) software improves recovery

confidence and manages service levels. With DPA, users can unify and

automate monitoring, analysis and reporting across backup and

recovery environments while reducing complexity, lowering costs and

eliminating manual efforts.

• Increase visibility: DPA provides real-time protection assurance as

environments change. It offers comprehensive, end-to-end data

protection environment visibility in a single, unified product;

• Reduce Costs: consolidate information enterprise-wide to

reduce administrative efforts, accelerate problem resolution and

forecast resource and capacity planning;

• Prove Protection: Understand potential risks and data protection

strategy exposures across multiple backup and recovery

products so applications are recoverable and data is safe;

• Lessen complexity: Use an automated, unified approach to

managing the data protection environment, greatly simplifying

the monitoring process and tuning the environment to maximize

utilisation; and

• Automate Processes: Remove manual data collection, analysis,

alerting and reporting effort for key backup and recovery

management to drive an efficient, risk-managed and simplified

environment.

Figure 8. Data Protection Advisor Overview

Data Protection

Advisor (DPA)


91

Where DPA fits in the environment

Data Protection Advisor supports multiple technologies in your IT

environment for backup and recovery, replication, file servers, and

physical and virtual server infrastructures.

Figure 9. DPA GUI

EMC Data Protection Advisor for Backup

The support for backup is the most comprehensive in the industry,

supporting 12 different backup solutions via a single user interface. DPA

collects data from the supporting infrastructure as well as the backup

application, providing visibility and access to the information to rapidly

spot and troubleshoot problems through root cause analysis, forecast

capacity needs and optimize existing resources.


92

Figure 10. DPA “Report Card” example reports

When managing a backup environment, it is critical to have visibility

into the infrastructure components as well as the backup application

and its success and failures related to backup jobs. To provide that

visibility, Data Protection Advisor supports the underlying components

including virtual tape libraries, deduplication storage systems, clients,

servers, LAN/SAN, switches, tape, and network-attached storage.

By collecting all of this information, Data Protection Advisor can provide

monitoring, alerting, troubleshooting, capacity planning, optimization,

and reporting across all of the supported technologies. This insight

speeds and improves decision-making, resulting in reduced effort for

backup and operations teams.

Design Decision

DPA will not be implemented for management/monitoring at XYZ.

NetWorker has two licensing models:

• Module based licensing; and

• Capacity based licensing.

Module or traditional based licensing licenses the base NetWorker

server, including a number of client licenses. Extra license modules are

then purchased for each component that is to be protected or

included in the data protection environment - tape libraries etc.

Capacity or sourced based licensing is defined as the total capacity of

data on the clients or devices on which:

• The NetWorker software is installed; and

NetWorker

Licensing


93

• The NetWorker software is used to provide data protection.

Source capacity is measured as the total capacity of data that is

protected by the NetWorker software over a two-month period. This is

irrespective of where the data is backed up, i.e. to disk, VTL or tape.

Capacity licensing includes two types of license enablers:

• NetWorker Datazone Enabler - A datazone enabler, when

installed on the NetWorker server, enables the software for

capacity licensing. Without it, the NetWorker datazone remains

under the traditional licensing model. One NetWorker Datazone

Enabler is required for each NetWorker server or datazone; and

• Tiered Capacity Entitlement -Tiered Capacity Entitlement License

enablers must be added for each NetWorker server or datazone

to protect up to the amount of purchased licensed source

terabytes.

The Tiered Capacity Entitlement License Enabler is available in 1

TB and 10 TB increments.

NetWorker capacity licensing options and modules

With capacity licensing, you can deploy unlimited quantities of the

following NetWorker options and modules to protect up to the amount

of licensed capacity:

• AlphaStor;

• NetWorker clients including the following:

▪ Deduplication clients;

▪ NDMP clients; and

▪ Virtual Edition clients.

• NetWorker Server and Storage Node;

• NetWorker Autochanger Software Module;

• NetWorker Data Domain Device Type, using DD Boost;

• NetWorker Disk Backup;

• NetWorker Dynamic Drive Sharing;

• NetWorker Fast Start;

• NetWorker Module for Databases and Applications;

• NetWorker Module for MEDITECH;

• NetWorker Module for Microsoft Applications;

• NetWorker Module for Microsoft Exchange Server;

• NetWorker Module for SAP with Oracle;

• NetWorker SNMP Module; and

• NetWorker Virtual Tape Library Option.


94

Design Decision

XYZ will utilise NetWorker Capacity Based Licensing.

NetWorker User based authorisation is based around Users and Groups.

There are also three components where access must be granted:

• NMC.

• NetWorker Server.

NMC Authentication

In NetWorker there are two modes of NMC user Authentication:

• Non-Lightweight Directory Access Protocol (LDAP) mode or

Native mode; and

• LDAP mode.

The NMC server is in non-LDAP mode by default, i.e. native NMC

authentication will be the default authentication mechanism to

authenticate NMC users.

For LDAP mode to be enabled, a user already with the Console Security

Administrator role needs to configure an external authentication

authority. NMC authentication requests will be routed to the external

authentication authority.

NMC Authorisation

Once authentication has been configured for NMC, the users must be

provided NMC access using the roles outlined in Table 26.

Table 26. Console Roles

Role Privileges Required

Console Security

Administrator

Add, delete, and edit users.

Configure login authentication.

Control user access to managed applications such as

a NetWorker Server.

All tasks available to a Console User role.

Console

Application

Administrator

Configure Console system options.

Set retention policies for reports.

View custom reports.

Specify the NetWorker Server to backup the Console

database.

Specify a NetWorker License Manager server.

Run the Console Configuration wizard.

All tasks available to a Console User role.

User-Based

Authorisation


95

Role Privileges Required

Console User All tasks except for those tasks explicitly mentioned for

the Console Security Administrator and the Console

Application Administrator.

By default, Console users can view all managed NetWorker Servers.

However, Console users must still be granted explicit privileges on a

NetWorker Server.

NetWorker Server Authorisation

The NetWorker Server utilises the existing NMC authentication as this is

the main method to access the NetWorker Server. Users may be

explicitly granted access without access to the NMC (e.g. for

command line access).

Similar to NMC authenticated users, the users must be added to one of

the Networker Server groups defined below:

Table 27. NetWorker Group Privileges

NetWorker server-

side User Groups

Associated Privileges

Security

Administrators

View security settings

Change security settings

Create security settings

Delete security settings

Application

Administrators

Remote Access All Clients

Configure NetWorker

Operate NetWorker

Monitor NetWorker

Operate Devices and

Jukeboxes

Recover Local Data

Recover Remote Data

Backup Local Data

Backup Remote Data

Create Application

Settings

View Application

Settings

Change Application

Settings

Delete Application

Settings

Archive Data

Monitors Monitor NetWorker

Operate Devices and

Jukeboxes

Recover Local Data

Recover Remote Data

Backup Local Data

Backup Remote Data

View Application

Settings

View Security Settings

Archive Data

Operators Remote Access All Clients

View Application Settings

Operate NetWorker

Monitor NetWorker

Operate Devices and

Jukeboxes

Recover Local Data

Recover Remote Data

Backup Local Data

Backup Remote Data

Archive Data


96

NetWorker server-

side User Groups

Associated Privileges

Auditors View security settings

Users Monitor NetWorker

Recover Local Data

Backup Local Data

Database Operators Remote Access All Clients

Operate NetWorker

Monitor NetWorker

Operate Devices and

Jukeboxes

Recover Local Data

Recover Remote Data

Backup Local Data

Backup Remote Data

Archive Data

Database

Administrators

Remote Access All Clients

Configure NetWorker

Operate NetWorker

Monitor NetWorker

Operate Devices and

Jukeboxes

Recover Local Data

Recover Remote Data

Backup Local Data

Backup Remote Data

Archive Data

Members of the Application Administrators group have permission to

perform all NetWorker functions, except utilities that require root or

Microsoft Windows Administrator access. The UNIX root user and

members of the Microsoft Windows Administrators group are always

members of this group and cannot be removed.

By default, members of the Users group are granted permission to back

up and recover local data and to monitor NetWorker operations. They

cannot view or edit configurations.

NMC and NetWorker can also use an external authentication authority

which enables you to log into the Console server with user names and

passwords that are maintained by a LDAP or a Microsoft Active

Directory (AD).

User privileges are controlled by mapping LDAP or AD user roles or user

names to console user roles.

When an LDAP or AD user logs into the Console server and connects to

a NetWorker server, the following occurs:

• The Networker server performs a look-up to get the LDAP or AD

group that the OS authenticated user belongs to, in the external

authority. The NetWorker server does not authenticate the user

against the LDAP authority; and

• The privileges assigned to a user on the NetWorker server are

based on the LDAP user or the group entries present in the

external roles attribute of the User Group resource on the

NetWorker server.


97

Table 28 details the default configuration for NetWorker native

authentication upon installation.

Table 28. NetWorker Users

Users Group Comments

root@localhost Application

Administrators

User ‘root’ on the NetWorker Server

host is automatically added to the

Administrator list.

system@localhost Application

Administrators

User ‘system’ on the NetWorker Server

host is automatically added to the

Administrator list.

*@* Users By default, all users at all hosts can

backup and recovery of local data.

Administrator Application

Administrators

Default NMC User

Design Decision

XYZ will utilise NMC native Authentication.


98

DPA provides query based and printable reports. DPA can collect and

display historical data for the NetWorker software, including backup

and recovery jobs.

DPA's sophisticated reporting engine provides highly customizable

reports to highlight problems within the environment, and enables

customers to perform Capacity Management, Service Level Reporting,

Chargeback, Change Management, and Troubleshooting.

DPA's Predictive Analysis Engine provides customers with early warning

of problems that might be about to occur, and generates alerts

allowing customers to resolve problems sooner, reducing business

impact.

NMC also provides reports to facilitate trend analysis, capacity

planning and problem detection. NMC automatically collects data on

continual bases from the NetWorker datazone(s). NMC then integrates

and processes this data to produce several reports on backup status,

backup statistics, events, inactive files, hosts, users and devices. NMC

reports are not automatically generated unless scripted by users and

run via the operating system scheduler.

NetWorker software generates an event based on various factors,

including the following scenarios:

• The software or hardware encounters an error that requires user

intervention to resolve;

• A NetWorker backup group has failed;

• Drive ordering or serial number mismatch issues - a description of

the problem is provided, along with a corrective action to fix the

problem;

• Capacity monitoring - for example, reaching the space

threshold on the deduplication node;

• NetWorker software is unable to poll a host it is monitoring for

events or for generating reports; and

• A license or enabler code managed by the License Manager is

about to expire.

These events can be sent to a variety of destinations (e.g. using the

Windows event log, files, and printers). The most common methods of

notification are SNMP and email.

NetWorker SNMP Module

The NetWorker SNMP Module allows NetWorker Servers to send

notification messages to SNMP management agents. For this to be

successful, it is a requirement that SNMP-enabled network

management software be configured to accept traps from the

NetWorker Server.

Monitoring,

Reporting, and

Analysis

Alerting


99

The NetWorker SNMP Module uses traps to communicate NetWorker

event notifications to SNMP management stations. A trap is an

unsolicited notification sent from the SNMP agent (such as the

NetWorker Server) to the SNMP event manager. The types of traps that

the NetWorker Server sends are determined when the NetWorker SNMP

notification is configured within the NetWorker Server.

Bootstrap Notification

When a backup group includes the NetWorker Server, or if the server is

not in an active group, the NetWorker Server generates a special save

set called the bootstrap, which includes the media database and

configuration files. In both cases, a bootstrap email or printout is

generated whether the scheduled backup is initiated automatically or

manually.

The bootstrap information is essential for recovery from a disaster. By

default, the bootstrap reports are generated and sent as an email. If

the bootstrap notification is configured for email and an email recipient

is not configured, then the bootstrap reports will not be sent. However,

when an email recipient is later configured, the bootstrap reports are

generated the next time as part of the backup operation and the

previous reports are also sent to the email recipient along with the

current report.

Design Decisions

Bootstrap notification will be configured to email backup

administrators.

NMC will be used for any reports XYZ require as DPA is not part of the

engagement.

NetWorker alerts and notifications will be utilised to keep backup

administrators abreast of occurrences in the backup environment.

Chapter 13: Firewall Requirements

100

13 Firewall Requirements

The following table displays firewall ports required for each of the

modules and appliances addressed in this document.

Table 29. NetWorker environment firewall port requirements


1. NW Client Role NW Server Role TCP 7937-8193 1

2. NW Client Role NW Storage Node Role TCP 7937-8193 1

3. NW Client Role Data Domain TCP 2049,2052 2

4. NW Client Role Data Domain TCP/UDP 111 2

5. EMC Data Protection Restore

Client Interface

VBA TCP 8543 (File-level recovery)

6. EMC Backup and Recovery

Configure

VBA TCP 8543 (VBA configuration)

7. vCenter VBA 8543 EMC Backup and Recovery plug-in for

vSphere Web Client

8. NW Storage Node NW Client Role TCP 7937-7942 1

9. NW Storage Node NW Server Role TCP 7937-8193 1

10. NW Storage Node Data Domain TCP 2049,2052

11. NW Storage Node Data Domain TCP/UDP 111

12. NW Storage Node ESX Cluster TCP 902 5

13. NW Storage Node vCenter TCP 443

7937-7942

5

14. NW Server Role NW Client Role TCP 7937-7942

15. NW Server Role NW Storage Node TCP 7937-8193 1

16. NW Server Role Data Domain TCP 2049,2052

17. NW Server Role Data Domain TCP/UDP 111

161 (snmp)

18. NW Server Role vCenter TCP 443

7937-7942

5

19. NW Server Role VBA TCP

RPC

8080

8543 (web service calls)

7937-9936 (Checkpoint restarts)

20. NW Server Role NW Client Role w/ NMM TCP 6278 (Control port)

6279 (Data port)

21. DPA Application Server Role DPA Agent (Collector) TCP 3741 (http) 8

22. DPA Application Server Role SMTP Gateway TCP 25 (smtp)

23. DPA Application Server Role SNMP Trap Destination TCP/UDP 162 (snmp trap)

24. DPA Agent (Collector) DPA Application Server Role TCP 9002 (https) 8

25. DPA Application Server Role DPA Data Server Role TCP 9003

26. DPA Data Server Role DPA Application Server Role TCP 9002 (https)

27. DPA Management Workstation DPA Application Server Role TCP 9002 (https)

28. VBA NW Server Role TCP 7937-7942

29. VBA DNS TCP 53 (Name resolution)

30. VBA NW Server TCP 8080 (initiate operation in NW)

31. VBA NW Server RPC 7937-9936 (NetWorker client comms)

32. VBA Data Domain TCP 7, 22, 80, 111, 131, 163, 2047, 2052

(Data Domain Management)

33. VBA VMware SSO TCP 744 (Auth to SSO if using)

34. VBA vCenter TCP 443 (vCenter Integration)

35. VBA ESX Servers TCP 443, 111, 902 (backup and recovery

operations)

36. VBA External proxy TCP 28002-28009 (pre-NW 8.2)

28102 (NW 8.2)

37. External proxy VBA TCP 28001, 27000, 29000 (external proxy to

MCS and GSAN)

Chapter 13: Firewall Requirements

101


38. Data Domain NMC Server TCP/UDP 162 (snmp trap)

39. Data Domain SMTP Gateway TCP 25 (smtp)

40. Data Domain VBA TCP 161 (snmp traps)

41. NAS Device (NDMP Backup) NW NDMP-DSA Server Role TCP 10000 7

42. NMC Server Data Domain TCP/UDP 161 (snmp query)

43. NMC Server NW Server Role TCP 7937-8193 1

44. NMC Server SMTP Gateway TCP 25

45. Customer Management

Console(s)

NMC Server TCP 2638

9000

9001

Notes:

1. Range limited on server using nsrports. Default is 7937-9936

2. Required for client direct backups (i.e. not via Storage Node) to Data Domain using DD

Boost transport

3. Required for Clone Controlled Replication between Data Domain devices

4. Assumes DPA collector running on NW Server Role

5. Required only when traditional VADP backup is used

6. Only required when NetWorker Module for Microsoft is used on the NW Client Role

7. Only required for NDMP backups of NAS filers

8. DPA Agent Collector usually installed on NW Server

Chapter 14: Disaster Recovery

102

14 Disaster Recovery

This section details the technical considerations for Disaster Recovery of

the backup environment and backup data sets, specifically:

• Windows Bare Metal Recovery (BMR);

• Microsoft Applications;

• VMware Virtual Guests; and

• NetWorker Disaster Recovery.

Windows Bare Metal Recovery (BMR)

NetWorker supports Windows BMR for NetWorker clients running the

following operating systems:

• Windows 2012 (x64);

• Windows Storage Server 2012;

• Windows 2008 (x86 and x64) and Windows 2008 Server Core;

• Windows 2008 R2 SP1 (x64) and Windows 2008 R2 Server Core;

• Windows 8 (x86 and x64);

• Windows 7 (x86 and x64); and

• Windows 7 SP1 (x86 and x64).

NetWorker Windows DR provides an automated BMR solution by using

the Windows ASR writer and other VSS writers to identify critical volumes

that are needed to perform a disaster recovery on a disabled system.

NetWorker DR is performed offline, which means that the Windows

operating system is not active. This avoids the need to reinstall Windows

manually and also avoids the problems that occur when restoring

operating system files to an active Windows system.

To support Windows DR, NetWorker provides a bootable Windows DR

image that contains NetWorker binaries and a wizard to control the DR

process.

NetWorker now supports BMR recoveries to VMware virtual machines. In

addition to providing a method to transition a physical computer to a

virtual equivalent, the process allows you to recover a BMR image to

server hardware that is no longer available during a disaster event.

Support has been added for backup and recovery of unmounted UEFI

partitions on computers and virtual machines that run a 64-bit version of

a supported windows operating system.

VSS File Level Recovery provides the ability to browse, select and

restore any System State file from the backup of the volume where it

resides.


103

NetWorker supports backup and recovery of Windows Server 2012

Servers configured with Windows Continuous Availability using Cluster

Shared Volumes (CSV).

NetWorker Windows BMR does not support the backup and recovery of

critical System State data located on Storage Spaces virtual disks. BMR

backup skips all critical volume data located on Storage Spaces and it

is not added to the BMR critical volume list. As long as the Storage Pool

disks that compose a Storage Spaces virtual disk are not damaged, a

recovery to the original computer includes mounting the Storage Pool

virtual disks after recovering the computers critical volumes.

The following considerations need to be made when using BMR:

• When specifying a clone job for DR save sets, the

DISASTER_RECOVERY:\ save set and its corresponding OSSR save

sets must be specified;

• NTFS and ReFS file systems are the only supported volume type.

FAT file systems are not supported as DR volumes;

• Windows DR of a Domain Controller is non-authoritative by

default. If an authoritative restore is required, Directory Services

Restore Mode (DSRM) mode must be used directly from the

NetWorker DR wizard;

• Windows roles that utilise external databases (SQL) require the

use of NMM to perform a restore of the SQL databases;

• The DFSR namespaces are junction mount points and are not

backed up with the DISASTER_RECOVERY:\ or ALL save set even

if the DFSR shares reside on a critical volume. To backup DFSR

Shares, either use the new save set ALL-DFSR or provide the full

DFSR Share path as the save set name; and

• The Windows BMR image does not contain a driver for any of the

VMware VMXNET Network Interface Card (NIC) models.

However, the Windows BMR image does contain a driver for the

e1000 NIC. If there is at least one e1000 NIC configured for the

VM, DR can be performed. Alternatively, custom NIC drivers can

be used when running the Windows DR wizard.

Table 30 provides the components of the ALL save set for NetWorker

Table 30. Components of the ALL save set for Windows Servers

Operating System Type Components of All save set

Windows Server 2003 with VSS

enabled.

VSS SYSTEM BOOT:\

VSS SYSTEM FILESET:\

VSS SYSTEM SERVICES:\

VSS USER DATA:\

VSS OTHER:\

VSS ASR DISK:\ (Windows Server 2003 only)

All local physical drives


104

Operating System Type Components of All save set

Windows Server 2008, Windows

Server 2008 R2, Windows 7,

Windows Server 2012, Windows 8,

Windows Storage Server 2012 in

NetWorker 8.1.

DISASTER_RECOVERY:\

WINDOWS ROLES AND FEATURES

All local physical drives

SRP or EFI, as applicable

Design Decision

BMR will be implemented with the appropriate ALL save sets for all

Windows servers that are supported in the environment. The “All” save

set is used for simplicity, with a DR save set being activated as part of

“All” every full backup.

To perform a DR of a server utilising the NMM module, it is important

that:

• A backup of all application data is performed using NMM;

• A backup of all non-application file systems is performed using

NMM; and

• A DR system backup is performed using the NetWorker Client.

If these pre-requisites are met, recovery is simply reversed:

• Perform a DR system recovery using the NetWorker recovery CD;

• Perform a recovery of all non-application file systems using NMM;

and

• Perform a recovery of all application data using NMM.

Clustered Recovery

In the event a DR is required for a clustered system, the process for

recovery is like a single node recovery:

• Perform a DR system recovery using the NetWorker recovery CD

for Node A;

• Perform a DR system recovery using the NetWorker recovery CD

for Node B;

• Reconfigure clustering and add the required disks to the nodes

and to the clustering configuration;

• Perform a recovery of all non-application file systems using NMM;

and

• Perform a recovery of all application data using NMM.

In the event that a Windows VM is unavailable that has been backed

up using the VBA backup approach, a full image level recovery can be

performed using the “Restore a backup wizard” available from the VBA

plug-in user interface in the vSphere Web Client. For this to be

successful, if restoring to the original location and the VMDK file still

exists, it will be overwritten.

Microsoft

Applications

VMware Virtual

Guests


105

There are two components for DR for the NetWorker Server and

associated roles:

• A DR event has occurred that has left the NetWorker Server

intact, with the requirement to perform DR operations on other

servers, potentially at another site; and

• A DR event has occurred that has left the NetWorker Server non-

operational.

With the NetWorker Server still available, DR on all physical servers can

be completed using the ASR and BMR methods, with additional save

sets for applications restored using the NMM or NMDA.

For VM’s, an image level recovery will be performed. Application data

can then be restored, if required, utilising NMM or NMDA if those

modules were used to protect the application.

DR on the NetWorker Server would need to be performed in the

following scenarios:

• The NetWorker VM has become non-operational, but the

underlying storage containing the VMDK is intact; and

• The NetWorker VM and underlying storage is non-operational.

In either scenario, the following information may be required (some for

confirmation purposes only):

• NetWorker bootstrap information;

• Fully qualified domain names, IP addresses, and hostnames;

• For Domain Name System (DNS) clients, maintain the DNS host’s

Internet address and hostname;

• Hard drive configuration;

• Lists of any Windows volume mount points;

• The operating system version and patches installed; and

• Operating system configuration.

It is recommended a copy of the NetWorker VM (vNSR), with the same

name/IP address be available in the site, turned off of course, in the

event the production NetWorker server is destroyed. The copy vNSR can

be powered up, pointing the same virtual disks containing the

NetWorker software and databases.

NetWorker

Disaster

Recovery

EMC²

When information comes together,

Your world moves ahead

Phone: +61 7 3032 5100

Fax: +61 7 3032 5101

EMC NetWorker with DDBoost - JANELLE FILKIN, WRITER

Documents

Transcript of EMC NetWorker with DDBoost - JANELLE FILKIN, WRITER