NETWORKER 8.1difference

8/16/2019 NETWORKER 8.1difference

1/56

yright © 2013 EMC Corporation. Do not copy - All Rights Reserved.

Welcome to the NetWorker 8.1 Technical Differences: Server, NMC, and Data Domain Integration course.

Click the Notes tab to view text that corresponds to the audio recording.

Click the Supporting Materials tab to download a PDF version of this eLearning.

Copyright © 1996, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 EMC Corporation.All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The informationis subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS ORWARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMSIMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

EMC2, EMC, Data Domain, RSA, EMC Centera, EMC ControlCenter, EMC LifeLine, EMC OnCourse, EMC Proven, EMC Snap,EMC SourceOne, EMC Storage Administrator, Acartus, Access Logix, AdvantEdge, AlphaStor, ApplicationXtender,ArchiveXtender, Atmos, Authentica, Authentic Problems, Automated Resource Manager, AutoStart, AutoSwap,AVALONidm, Avamar, Captiva, Catalog Solution, C-Clip, Celerra, Celerra Replicator, Centera, CenterStage, CentraStar,ClaimPack, ClaimsEditor, CLARiiON, ClientPak, Codebook Correlation Technology, Common Information Model,Configuration Intelligence, Configuresoft, Connectrix, CopyCross, CopyPoint, Dantz, DatabaseXtender, Direct Matrix

Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, elnput, E-Lab, EmailXaminer,EmailXtender, Enginuity, eRoom, Event Explorer, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony, Global FileVirtualization, Graphic Visualization, Greenplum, HighRoad, HomeBase, InfoMover, Infoscape, Infra, InputAccel, InputAccelExpress, Invista, Ionix, ISIS, Max Retriever, MediaStor, MirrorView, Navisphere, NetWorker, nLayers, OnAlert, OpenScale,PixTools, Powerlink, PowerPath, PowerSnap, QuickScan, Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, theRSA logo, SafeLine, SAN Advisor, SAN Copy, SAN Manager, Smarts, SnapImage, SnapSure, SnapView, SRDF, StorageScope,SupportMate, SymmAPI, SymmEnabler, Symmetrix, Symmetrix DMX, Symmetrix VMAX, TimeFinder, UltraFlex, UltraPoint,UltraScale, Unisphere, VMAX, Vblock, Viewlets, Virtual Matrix, Virtual Matrix Architecture, Virtual Provisioning, VisualSAN,VisualSRM, Voyence, VPLEX, VSAM-Assist, WebXtender, xPression, xPresso, YottaYotta, the EMC logo, and whereinformation lives, are registered trademarks or trademarks of EMC Corporation in the United States and other countries.

All other trademarks used herein are the property of their respective owners.

© Copyright 2013 EMC Corporation. All rights reserved. Published in the USA.


2/56


This course covers the enhancements and feature additions to the NetWorker 8.1 release

covering the NetWorker Server and the NetWorker Management Console. This includes the

Recover UI, Recover Wizard, NetWorker Server Disaster Recovery Wizard, Parallel Save

Streams for Unix and Linux systems, Performance improvements, software upgradeimprovements via the Client Push feature, and NFS AFTD enhancements. This course also

covers Data Domain integration enhancements including DDBoost Over Fibre Channel and

Virtual Synthetic Fulls. The goal of this course is to empower you to be able to configure,

implement, monitor, and troubleshoot these features and enhancements.

It is intended for those with knowledge of NetWorker who are responsible for

implementation, management and troubleshooting of the product.


3/56


This module focuses on server and NMC enhancements for NetWorker 8.1.


4/56


In NetWorker 8.1 most recovery operations are supported using the NetWorker

Management Console. Prior to NetWorker 8.1 this was not possible. Application support is

not available through the Recover UI/Wizard.


5/56


The Recover UI is a centralized, GUI-based alternative to doing recovers. Prior to NetWorker

8.1 only the CLI could be used to perform restores. The Recover UI integrates with the NMC

Recover Wizard. Backup and recover progress is displayed in the Recovery Wizard as well as

the NMC log window.


6/56


Prior to NetWorker 8.1, NetWorker Management Console was used for backup management,

and tools such as Winworkr or nwrecover were required for recoveries. Using these

services required logging into the client to initiate a recovery. NetWorker 8.1 introduces the

Recover Wizard that guides the administrator through every step of the recovery process,including the recovery of snapshots, file systems, and Block Based Backups. It also enables

scheduling of recover operations. The Recover Wizard supports browsing save sets and

performing directed recoveries. The Recover Wizard doesn’t support Unix/Linux to Windows

recoveries. Unix to Unix recoveries are supported.

To use the Recover Wizard the NetWorker Management Console, the NetWorker Server

Server, and source and destination client must be at NetWorker 8.1. Backup data saved using

pre-8.1 clients is still recoverable once the NetWorker client has been upgraded to 8.1. All of

the previous NetWorker commands work the same with the exception of the removal of thenwrecover command that has been removed for Unix/Linux installs.


7/56


This video covers performing a recovery using the Recover Wizard.


8/56


In NetWorker 8.1 save sets that contain ACL/metadata associated with root permissions can

now be browsed and recovered by non-root users. Previously this was not possible. The

ACL passthrough box must checked to enable this feature. This box is checked by default.


9/56


Performing a NetWorker Server Disaster Recovery prior to NetWorker 8.1 was a highly

manual process requiring many tasks. In NetWorker 8.1 the recovery of a NetWorker Server

has been simplified and automated using the NetWorker Server Disaster Recovery Wizard.

The NetWorker Server Disaster Recovery Wizard automates the recovery of the Resource andMedia Database, the restarting of the NetWorker services, moving directories, and initiating

an index recover (nsrck). The NetWorker Server Disaster Recovery Wizard has two mode of

operation: fully interactive (recommended) and non-interactive mode using options. Non-

interactive mode is meant for advanced users. The NetWorker Server Disaster Recovery

Wizard is supported on all platforms that the NetWorker Server is supported on. It is part of

the NetWorker Server package.


10/56


This video covers performing a NetWorker Server recovery using the NetWorker Server

Disaster Recovery Wizard.


11/56


This table list the flags that can be used with the NetWorker Server Disaster Recovery

Wizard. Please take a moment to review the flags.

Please note that these are optional flags used in the non-fully interactive mode.


12/56


This is a continuation of the flags that can be used with the wizard.


13/56


NetWorker creates a log file on the NetWorker server for each recover job. The log file

contains detailed information that can assist in troubleshooting recovery failures. All

scanner, recover and index recover messages are logged to nsrdr.log. Daemon.raw is

updated with the result after the disaster recovery operation completes.


14/56


There are two tuning parameters that can be used with the NetWorker Server Disaster

Recovery Wizard. These tuning parameters are used to change the path to the NetWorker

Services and also the number of parallel threads to spawn for performing recoveries. These

parameters are saved in the nsrdr.conf file which is not created by default and must becreated by the user to use the parameters. These parameters must be set prior to running

the wizard.


15/56


Prior to NetWorker 8.1 backing up a large file system could take a very long time. NetWorker

8.1 provides parallel save stream support for Unix and Linux systems. Parallel save streams

are used to break up a large save set into multiple smaller save sets to be backed up at the

same time. This results in a backup that completes faster for file systems on disks thatsupport the increased read parallelism. Each PSS client resource save set entry (mount point,

file system , …) results in 1, 2, 3 or 4 (maximum) physical save sets. Each save set has a

corresponding mmdb record. Both fulls and incrementals are supported. This feature is

enabled for scheduled file system backups by checking the ‘parallel save streams per save

set’ client resource property in NMC or nsradmin. There is no current support for Windows,

Synthetic Fulls or Check Point Restarts.


16/56


Shown are key requirements, limits, and best practices.


17/56


To enable and configure parallel save streams select the client and select Modify Client

Properties. Select Globals (1 of 2) and set the client parallelism for static division among

listed save set entries, and then select the Parallel save streams per save set check box. The

number of PSS run time save streams for a resource in a save set entry is determined at thestart of the backup to be a fixed portion of the client parallelism value (maximum of 4). This

fixed number will equal the number of ‘partial’ physical save sets on backup media and also

the number of mmdb save set records. For example, a PSS client resource with parallelism of

8 and three listed save set entries ‘/filesystemA’, ‘/filesystemB’, and ‘/filesystemC’, the

corresponding number of save streams will be 3, 3 and 2 respectively. Static round-robin

division of the client parallelism is performed by the savegrp prior to starting any of the

client’s save streams. The number of streams remain fixed regardless of one of the file

systems finishing before the other. Client parallelism has been in NetWorker since the early

1990s; this allowed multiple client resource save set list entries to run in parallel (usually an

entry is a file system dir AKA save point or save path) but there is only one save stream per

save set entry and hence only one resultant mmdb save set record (mminfo). Parallel Save

Streams introduced in NetWorker 8.1 allows for multiple save set list entries.


18/56


Backup operations involving multiple save streams can be monitored from the monitoring

tab. Shown are four parallel save streams for a single client resource save set entry

‘/space/tmp/testdir/nw_8_1_nsr’. Their start times can be viewed on the right. Each save

session is identified by a number prefix, except the one stream that retains the pure save setentry name (last one shown in the example).

All but one of the multiple PSS of a single save point backup will start at or around the same

time within a few seconds of each other. The last one, i.e. shown without any save stream

name prefix, will generally start a few seconds or even a few minutes after the others.

This is because it needs to collect and store link relationship information. The spreads all

depend on the overall load on the NetWorker server at the time as well as the requests from

all other clients. As for “save time” each resultant PSS physical/partial save set will always

have its own unique save time. Save times of Parallel Save Streams are different. AnNetWorker Management Console post backup save sets query or mminfo command will list

physical save sets and their start times and save times.


19/56


In NetWorker 8.1 load balancing across storage nodes is now possible. This can be applied to

all NetWorker clients globally or to selected clients only. Save session distribution is not

available for clone or recover operations.


20/56


When using the max sessions option (which is the default option) the NetWorker server first

identifies the available storage node. Next it uses an available device on the first storage

node that is working below its target session level. It continues to select devices until all

devices are at their target level. Once all devices on the first storage node are at their targetsession level, it chooses to use the least loaded device that is running below its max session

level. It will continue to use devices on the current node until all devices are at their max

session level.

Once all devices on the current node are at their max session level, it will move onto the

next available storage node and perform the same order of operations until all devices on

that node are at their max session level. This process will continue until all devices on all

storage nodes are running at their max session level.


21/56


When using the target sessions option the NetWorker server first identifies any available

storage nodes. It then uses the first available device on the first storage node. It continues

to choose devices on the first storage node until all devices on the first storage node are

running at their target session level but below their max session level. NetWorker willchoose to use a device on the next storage node once all of the devices on the first storage

node are running at their target sessions. This occurs even if some of the devices are running

below their max session level. This process continues until all of the available devices on all

available storage nodes are running at their target session levels.

Once all of the devices are running at their target session levels it will run on the least loaded

device that is below its max session level. Once the device has reached its max session

level, it will move onto the next least loaded device. This process will occur until all eligible

storage nodes are running at their max session levels.


22/56


The save session distribution can be changed from within the properties tab of the

NetWorker server. The NetWorker console must be in diagnostic mode to change this value.

This configuration can be overridden on a client basis within the client properties.


23/56


In NetWorker 8.1 registered clients can be upgraded using the Client Push feature. Client

Push, will uninstall the previous software and install the latest software. The clients must be

registered with the NetWorker 8.1 server. Once a NetWorker host is in the Client Push

inventory, Client Push can be used to update the host with software in the softwarerepository database. The Software Administration Wizard or the nsrpush command can be

used to update NetWorker software on specific hosts.

The NMC Software Administration Wizard uses an inventory operation to determine the

software currently installed and also maintains a repository of available NetWorker software.


24/56


To upgrade clients using Client Push the information about the NetWorker packages must be

added from the Media Kit location into the software repository database using the Software

Administration Wizard. The Software Administration Wizard GUI or the nsrpush program can

be used to prepare the software repository database. Once the software has been loaded,NetWorker automatically determines clients to upgrade. To upgrade the clients, the upgrade

package is converted into a save stream and sent to the remote client. The package is

extracted using a temporary location. Existing client software is uninstalled, and the

extracted package is installed. This feature is supported from 7.4+. It can be used to upgrade

any client which is above 7.4 with any NetWorker server version above 7.4.


25/56


To add software to the repository select the “Software Administration Wizard” from the

configuration tab. Next select the “Add or remove products from my software repository”.

Select add software products to the repository. Select the target client OS type to be

upgraded. Finally, specify the location of the Upgrade Media Kit which should be on yourhost computer.


26/56


To configure the repository select the configuration tab and select the Software

Administration Wizard. The Software Administration Wizard will present four options to

configure the repository. To upgrade the software on the NetWorker clients select “Upgrade

the software on my NetWorker clients”. Lastly, select to upgrade all of the clients or a fewselected clients.


27/56


The nsrpush CLI command can also be used to upgrade clients. Using the nsrpush command,

temporary upgrade package paths can be configured for each client. It is also possible to

specify a timeout to cancel the upgrade for each client. These two options cannot be

specified using the GUI.


28/56


Prior to NetWorker 8.1 when performing backups to NFS-based AFTDs the application used a

native Unix path and was unaware of NFS. The OS passed the file access request to its NFS

facility, which communicated with the NFS server. NFS credentials are based on the identity

of the requesting process. There were many issues with using NFS-based AFTDs. The OS didnot provide a flexible method to set NFS credentials. NFS-based AFTDs were accessed as

root because storage node processes were run as root and only clients running as root could

use Direct File Access (DFA) with AFTDs. This meant that many save and recover processes

were unable to use DFA.

In NetWorker 8.1 AFTDs are accessed using NFS analogous to how they are accessed using

CIFS. This method provides an alternative to accessing the NFS export as root. It is

independent of OS NFS capabilities. Mounting the NFS file system is not required. It is

compatible with AFTD features such as Backup to Disk (B2D). The device is configured to useNFS explicitly. It uses an embedded NFS facility to communicate directly with the NFS server.


29/56


These are some of the benefits in using NFS-AFTD devices in NetWorker 8.1.


30/56


To configure NFS-AFTDs in NetWorker 8.1, configure the device path as well as the NFS

device credentials. A numeric UID can be appended to the remote username. The UID must

identify the target user on the NFS server. If the UID is omitted from the device properties

each NetWorker host (storage node or DFA client) will try to locally resolve the username toUID. Depending upon the configuration of the environment, this may not result in the

correct value (it may not match the NFS server). The UID is required if using NFS with

Windows as Windows has no mechanism to resolve a username to a UID. This shows the

configuration changed in NetWorker 8.1.


31/56


These are some of the requirements for using NFS-AFTDs in NetWorker 8.1.


32/56


The Client Configuration Wizard has been enhanced to support the creation and update of

NDMP clients. Users can also browse the NDMP filers to select a save set. The enhanced

Client Configuration Wizard is supported for both NetWorker 8.0 and 8.1. To configure an

NDMP client using the wizard enter the client name and select the NDMP client radio button.Enter the NDMP client credentials. Specify the NDMP backup type. Select the NDMP target

pool. Finally, select the volumes to backup.


33/56


This module focuses on the Data Domain integration enhancements in NetWorker 8.1.


34/56


NetWorker 8.1 supports DDBoost over Fibre Channel. The feature can be leveraged for

customers that have standardized on Fibre Channel as their backup protocol of choice. This

support not only optimizes the customers’ existing investment in their Fibre Channel

infrastructure, but with DDBoost client-side deduplication, the customer can now enjoy 50%faster backups over their traditional VTL-based model. Use of Data Domain Systems reduce

the bandwidth required on the IP network, as well as the disk capacity required. And,

because this support offers both client-side deduplication and support of the Fibre Channel

protocol using a real backup-to-disk workflow, the old VTL ‘tape-based’ management may be

eliminated. This means greater reliability and less complexity for the customer. This support

also enables all the features that Data Domain is optimized for, including Virtual Synthetic full

backups, clone controlled replication, global deduplication, and more. DDBoost over Fibre

Channel is supported in Windows and Linux environments.


35/56


Prior to NetWorker 8.1 a NetWorker client could create a device on Data Domain of type

AFTD. This allowed the client to perform all of the NetWorker operations. It also allowed

the client to perform distributed segment processing over IP. Another word for distributed

segment processing is source side deduplication. This minimizes the amount of data sentover the link and also allows random I/O access of the device.

In NetWorker 8.1 DDBoost can communicate to a DDBoost device over IP or Fibre Channel.

The same NetWorker operations that could be performed over IP can now be performed

over FC. The performance characteristics are comparable to DDBoost over IP. To perform

DDBoost over Fibre Channel DDOS 5.3 is required on the Data Domain system.


36/56


Prior to establishing an FC connection the NetWorker Management Console communicates

with the Data Domain system to create a DDBoost Over FC device. During the initial setup,

the user specifies the FC hostname for connecting to the Data Domain system.

Subsequently, a NetWorker Client or Storage Node uses the Data Domain FC hostname toconnect to the device over Fibre Channel. There is no separate data path to the Data

Domain FC device. The NetWorker Client/Storage Node does not require IP connectivity to

the device.

To establish a DDBoost over Fibre Channel connection with a DDBoost FC device the client

first initiates a connection with the DDBoost over Fibre Channel host name. This is a

standard SCSI inquiry. The NetWorker client receives a SCSI response indicating if it is a

DDBoost device or something else. If it is a DDBoost device the NetWorker client sends a

SCSI call out to read the DDBoost host name. If the host name matches what theNetWorker client has, the Data Domain system will send a SCSI response indicating that the

host name matches. Upon a successful connection (match), NetWorker will be able perform

data and metadata operations to the Data Domain device. After the operations are

complete the client closes the connection.

Note: The DDBoost FC hostname uniquely identifies the Data Domain system.


37/56


On the Data Doman system the Fibre Channel host can be found by selecting the DD Boost

tab and then selecting the Fibre Channel tab. This hostname does not have to be the same

as the Data Domain IP hostname. There can only be one Fibre Channel host name per Data

Domain system. There is a procedure that can be followed in the event that the FChostname does not match.


38/56


Fibre Channel connectivity for DDBoost can be configured through the device configuration

wizard. It is also important to specify the Fibre Channel host name. The hostname tells the

client that the device configured can be accessed using the Fibre Channel host name. The

Fibre Channel hostname must match the Fibre Channel hostname configured on the DataDomain system.


39/56


Fibre Channel can also be enabled in the device’s properties. Fibre Channel must be enabled

to use DDBoost Over Fibre Channel.


40/56


In NetWorker 8.1 there are three different types of client modes that can be configured.

These three parameters inform the NetWorker server of the client’s preference to connect to

a Data Domain device. The backup will fail if it is set to IP or FC and no devices of that type

are found / available. There is no preference for a particular protocol (IP or FC) when theclient mode “Any” is selected. When “Any” is selected, the broker selects a device from the

clients associated pool based on various factors such as availability, load, target volume, etc.

These parameters are located within the Apps & Modules section of the client properties.

Migrating from a Virtual Tape Library to a DDBoost FC device is the same as migrating from a

Virtual Tape Library to a DDBoost over IP Device. To perform this, create the new DDBoost

device on the Data Domain system and use NetWorker to rehydrate/clone the data from the

VTL to the Data Domain FC device.


41/56


Prior to backing up a client to Data Domain system using DDBoost over Fibre Channel the FC

attributes must be configured. This requires setting the FC attribute on the Data Domain

system for DDBoost over FC as well as specifying if the NetWorker client has FC access. Once

the attributes have been set, a backup can be initiated. Initiating a backup causes theNetWorker client to contact the NetWorker server to ask for a destination Data Domain

device to backup to. This causes the NetWorker server to check the client configuration

based on its database to see if it is capable of backing up over Fibre Channel. If the client is

capable of backing up over Fibre Channel, it looks for the Fibre Channel devices that can be

used and picks one to use.


42/56


After the NetWorker Server verifies both client and the Data Domain device, it performs the

backup. During the backup the NetWorker client contacts the NetWorker storage node for

the Data Domain device level details over IP. The storage node checks for the Data Domain

device, ensures the device is online, and presents the login credentials for the data path. Itthen sends this information (login) to the NetWorker client over IP. The client then performs

a Client Direct connection to the Data Domain device and writes the data to the Data Domain

device over FC. In the event that the storage nodes determines that the client cannot

perform backups over Fibre Channel, the client will send the backup data to the storage

node over IP and then the storage node will write the backup data to the Data Domain

device over FC. This is an alternate path.


43/56


During a recovery operation the NetWorker client contacts the NetWorker server for the

destination Data Domain device over IP. The NetWorker server looks at its device resource

database and its client resource database to see if the client has Fibre Channel support and if

the device is also Fibre Channel enabled. Once both have been verified the NetWorkerserver sends the client information and device information to the NetWorker storage node

over IP. The storage node determines if the NetWorker client can perform a Client Direct

recovery over Fibre Channel or if the storage node must perform the recovery. If the storage

node determines that the client can perform a Client Direct operation over Fibre Channel, it

will send the device login information to the client over IP. The client will then perform a

Client Direct recovery over FC. If the client cannot perform a Client Direct recovery, the

storage node will perform the recovery operation over FC and then send the recovered data

to the client over IP.

Client Direct is disabled when using DDBoost over Fibre Channel to a Data Domain device

when the NetWorker client does not have or support DDBoost over Fibre Channel. In this

case the SCSI device discovery only occurs on the NetWorker storage node. The storage

node is the only node than can perform DDBoost operations in this scenario.


44/56


These are the supported combinations for backup, recover, and cloning operations with

DDBoost over Fibre Channel. For Synthetics both native and virtual are fully supported even

over heterogeneous interfaces.


45/56


This matrix shows the outcome of the backup or recovery operations possible when one or

more NetWorker components are upgraded to NetWorker 8.1. Backups and recovery

operations can only occur to and from non-FC devices in the following cases. This is because

FC devices cannot be created. If the NetWorker Server and Storage Node have beenupgrade to 8.1, but the client has not, the client can only perform Client Direct backup and

recovery operations to non-FC devices while the storage node can perform backup and

recovery operations to FC devices. This is a valid configuration. If the NetWorker Client and

the NetWorker Storage node are upgraded to 8.1, they can only perform DDBoost operations

over IP. This is because the NetWorker server is not able to record FC devices in its database.

Lastly if all components are upgraded, Client Direct operations are supported over FC and IP.


46/56


Displayed are the requirements to configure DDBoost over Fibre Channel.

The decision on which to upgrade first(Data Domain OS or the NetWorker software) depends

upon the version of DDBoost that the existing storage node uses and the version of DDOS. If

DDBoost supports DDOS 5.3, it is better to upgrade to DDOS first. If DDBoost does not

support DDOS 5.3, check if DDBoost 2.6 can support the existing DDOS version. If it is

compatible with DDBoost 2.6.X, the NetWorker storage node should be upgraded first before

upgrading to DDOS 5.3.

Existing FC devices can be configured to be DDBoost Over Fibre Channel devices.


47/56


In NetWorker 8.0 NetWorker introduced support for synthetic full backups without DataDomain. NetWorker 8.1 introduces support for Virtual Synthetic Full backups with DataDomain. The processes of creating a Virtual Synthetic fulls is a much better way to create aSynthetic full backup and it is now the default method in NetWorker 8.1.

In typical backup cycle the administrator will schedule a full backup followed by severalincremental backups. To create a Virtual Full backup, NetWorker sends commands to theData Domain System that consist of the regions that are required to create a full backup.During the transfer no data is transferred over the network. Instead, the regions of the fullbackup are synthesized from the previous full and incrementals that are on the system usingpointers. This process eliminates the data that needs to be gathered from the file server,reducing system overhead, time to complete the process, and network bandwidthrequirements. NetWorker uses the DDBoost API to create the Virtual Synthetic full.

Virtual Synthetic full backups are an out-of-the-box integration with NetWorker, making it‘self -aware.’ Therefore, if your customer is using a Data Domain System as their backuptarget, NetWorker will use Virtual Synthetic full backups as the backup workflow by defaultwhen a Synthetic full backup is scheduled, thus optimizing incremental backups for filesystems. Virtual Synthetics reduce the processing overhead associated with traditionalSynthetic full backups by using metadata on the Data Domain system to synthesize a fullbackup without moving data across the network. A traditional full backup is recommendedonly after every 8-10 Virtual Fulls have been completed. Therefore, the use of VirtualSynthetic Full backups also reduces the number of traditional full backups from 52 to 6 peryear – a 90% reduction. If a Virtual Synthetic full operation fails, NetWorker will default to

creating a Synthetic full.


48/56


The operations involved in creating a Synthetic full verses a Virtual Synthetic full are very

different. With a traditional Synthetic full nsrcopy reads and writes to the Data Domain

device. Then nsrcopy updates the index. When creating a Virtual Synthetic full, nsrcopy

issues a DDP_SYNTHESIZE call and then notifies nsrconsolidate which performs the indexupdate. The major difference here is that creating Synthetic fulls requires copying data

(previous fulls and incrementals) from the Data Domain system and writing new data to the

Data Domain system to create the Synthetic full. Creating a Virtual Synthetic full does not

require reading the previous data to create the Virtual Synthetic full.


49/56


Using the NMC GUI Virtual Synthetic fulls can be disabled for troubleshooting purposes.

There is a hidden option (Perform virtual synthetic full) located on the advanced tab of the

group that can be used to disable the Virtual Synthetic full operations . Virtual Synthetic fulls

are enabled by default. Diagnostic mode must be enabled to view this option.


50/56


The NetWorker CLI can also be used to disable Virtual Synthetic fulls for troubleshooting

purposes. The command line option applies only to the instance of the nsrconsolidate

command being run. If the command is run again without the option it will perform a virtual

synthetic full backup.


51/56


Debugging info can be obtained by using these commands.


52/56


Listed are a few requirements to create Virtual Synthetic fulls. It is important to note that

Virtual Synthetic fulls cannot use directives such as encryption or compression like Synthetic

fulls can because data is not read from the Data Domain device during the creation of the

Virtual Synthetic full. The “skip” directive is not supported with both virtual and non-virtualsynthetic full operation. Both source and target devices must be DDBoost devices (on the

same DDR) for virtual synthetic full to work. There is no additional Networker license

required using virtual synthetic full. DDBoost licensing is required for both Boost over IP as

well as FC.


53/56


Immediate clone controlled replication introduced in NetWorker 8.1 has been added in

support of Data Domain. It enables cloning to begin as soon as a save set as part of a group

has finished being backed up. This means that the cloning process can begin almost

concurrently with the backup process, speeding up the time to DR readiness by up to 90%.

Previous versions of NetWorker required that the entire group finish its backup before a

clone operation could be initiated. And, these groups can be very large. Therefore,

immediate cloning helps support Recovery Point Objectives, enabling a faster time to

Disaster Recovery readiness, and can more efficiently utilize the network bandwidth used for

replication during off-peak hours.


54/56


Immediate cloning can be configured in the setup tab within the group properties.

Immediate cloning (start on each save set completion) is the default option for cloning. The

clone immediate option is set in the RAP database. During the operation this setting is

checked and if it is set to perform immediate cloning then the save sets will be cloned assoon as they are backed up.


55/56


This course covered NetWorker 8.1 Server, NMC, and Data Domain Integration features and

enhancements.

This concludes the training. Please, proceed to the course assessment.


56/56

Documents

NETWORKER 8.1difference