Data Domain® Implementation With Application Software - MR-1WP-DDIAS SRG

Welcome to Data Domain® Implementation with Application Software.
Copyright ©2015 EMC Corporation. All Rights Reserved. Published in the USA. EMC believes the information in this publication is accurate as of its publication date. The information is subject
to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN
THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. The trademarks, logos, and service marks (collectively "Trademarks")
appearing in this publication are the property of EMC Corporation and other parties. Nothing contained in this publication should be construed as granting any license or right to use any
Trademark without the prior written permission of the party that owns the Trademark.
EMC, EMC² AccessAnywhere Access Logix, AdvantEdge, AlphaStor, AppSync ApplicationXtender, ArchiveXtender, Atmos, Authentica, Authentic Problems, Automated Resource Manager,
AutoStart, AutoSwap, AVALONidm, Avamar, Bus-Tech, Captiva, Catalog Solution, C-Clip, Celerra, Celerra Replicator, Centera, CenterStage, CentraStar, EMC CertTracker. CIO Connect,
ClaimPack, ClaimsEditor, Claralert ,cLARiiON, ClientPak, CloudArray, Codebook Correlation Technology, Common Information Model, Compuset, Compute Anywhere, Configuration
Intelligence, Configuresoft, Connectrix, Constellation Computing, EMC ControlCenter, CopyCross, CopyPoint, CX, DataBridge , Data Protection Suite. Data Protection Advisor, DBClassify, DD
Boost, Dantz, DatabaseXtender, Data Domain, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, DLS ECO, Document Sciences, Documentum, DR Anywhere, ECS, elnput, E-Lab,
Elastic Cloud Storage, EmailXaminer, EmailXtender , EMC Centera, EMC ControlCenter, EMC LifeLine, EMCTV, Enginuity, EPFM. eRoom, Event Explorer, FAST, FarPoint, FirstPass, FLARE,
FormWare, Geosynchrony, Global File Virtualization, Graphic Visualization, Greenplum, HighRoad, HomeBase, Illuminator , InfoArchive, InfoMover, Infoscape, Infra, InputAccel, InputAccel
Express, Invista, Ionix, ISIS,Kazeon, EMC LifeLine, Mainframe Appliance for Storage, Mainframe Data Library, Max Retriever, MCx, MediaStor , Metro, MetroPoint, MirrorView, Multi-Band
Deduplication,Navisphere, Netstorage, NetWorker, nLayers, EMC OnCourse, OnAlert, OpenScale, Petrocloud, PixTools, Powerlink, PowerPath, PowerSnap, ProSphere, ProtectEverywhere,
ProtectPoint, EMC Proven, EMC Proven Professional, QuickScan, RAPIDPath, EMC RecoverPoint, Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, the RSA logo, SafeLine, SAN
Advisor, SAN Copy, SAN Manager, ScaleIO Smarts, EMC Snap, SnapImage, SnapSure, SnapView, SourceOne, SRDF, EMC Storage Administrator, StorageScope, SupportMate, SymmAPI,
SymmEnabler, Symmetrix, Symmetrix DMX, Symmetrix VMAX, TimeFinder, TwinStrata, UltraFlex, UltraPoint, UltraScale, Unisphere, Universal Data Consistency, Vblock, Velocity, Viewlets, ViPR,
Virtual Matrix, Virtual Matrix Architecture, Virtual Provisioning, Virtualize Everything, Compromise Nothing, Virtuent, VMAX, VMAXe, VNX, VNXe, Voyence, VPLEX, VSAM-Assist, VSAM I/O
PLUS, VSET, VSPEX, Watch4net, WebXtender, xPression, xPresso, Xtrem, XtremCache, XtremSF, XtremSW, XtremIO, YottaYotta, Zero-Friction Enterprise Storage.
Revision Date: August 2015
Revision Number: MR-1WP-DDIAS.DDOS5.5.2
Copyright 2015 EMC Corporation. All rights reserved. Data Domain Implementation with Application Software 1
This course covers the implementation of Data Domain systems in backup environments
using a variety of backup applications such as, EMC Networker and Avamar, Symantec
NetBackup and Backup Exec, IBM Tivoli Storage Manager and Oracle RMAN.
This module focuses on a number of key concepts involved in the implementation of EMC
Data Domain systems with application software.
Upon completion of this module, you should be able to describe implementation concepts,
terms architectures, data flow and DD Boost implementations, File system-based versus
VTL environments, and implementation workflows.
This slide presents a general overview of implementation architectures that combine backup
software solutions – listed down the left side of the table – with a NAS, or network-attached
storage environment, or a SAN or storage area network environment. These environments
utilize one or more of the protocols listed along the top, and might also include the DD
Boost option.
The Data Domain system integrates into any of these configurations, as indicated by the
checkmarks.
This lesson covers basic Data Domain concepts and terms and product-specific terms.
This slide provides a brief review of basic terminology associated with the backup
environment.
In all configurations, there are clients that need to be backed up, a server that manages
these backups, a server that writes to and reads from backup targets, and the backup
targets themselves. In some environments, the backup management and read/write
functions are performed on a single server.
Networking connectivity can be via Ethernet LAN or Fibre Channel SAN.
Specific backup software products introduce specific terminology. In a NetBackup or Backup
Exec environment, for example, the server that manages backups is called the Master
Server, while Media Servers write to and read from backup targets. Tivoli Storage Manager
environments employ similar terminology.
The NetWorker environment shown here adds the concept of the NetWorker Data Zone,
encompassing these networked devices.
The NetWorker Clients generate the backup data, while a NetWorker Server manages the
backup traffic. Specifically, the NetWorker Server supports the backup and stores tracking
and configuration information.
NetWorker Storage Nodes write data to and read data from backup targets.
Another way to define a NetWorker data zone is to say that it is the set of hosts managed
by a single NetWorker server. This includes all hosts with backup devices controlled by the
NetWorker server and all hosts who send their backup data to those devices.
NetWorker clients may be backed up by multiple NetWorker servers and therefore may
belong to multiple data zones. NetWorker servers and storage nodes may belong to only
one data zone.
In large NetWorker environments, storage nodes serve as an aggregation point for a large
number of clients. The clients send their data to the storage node with which they are
associated, and the storage node backs up the data to the storage.
CommVault® Simpana™ software is a data protection suite for large-scale enterprises.
The first Simpana system installed must be configured as a CommServe™. A CommServe

defines a backup domain called a CommCell™ that manages member Media Agents, Clients,
and data protection storage resources. The CommServe contains a SQL database that
keeps track of the various agents and data protection metadata, such as the media index.
A CommVault Media Agent server is any system, including the CommServe, that has the
iDataMediaAgent installed.
These are some product-specific terms that apply to implementations of Tivoli Storage
Manager or TSM.
Backup and Archive clients (BA Clients) are computers and servers that send or retrieve
data from the TSM Server.
The TSM Servers main function is to coordinate movement of the backup & archive data
from the BA Clients to the storage media. The TSM Database keeps track of each new
transaction in its recovery logs. In case of sudden outage of the TSM server, recovery logs
is the first resort to revert back changes and get the database back to an operational stage.
Storage Pools are collections of like media (tape or disk-based). TSM allows you to build a
hierarchy of storage pools as destinations for specific backup, archive, and migration data.
This lesson covers implementations Supporting DD Boost, DD Boost Architecture, DD Boost
Advantages, using EMC Avamar with DD Boost, and DD Boost for Oracle RMAN.
Among the implementations covered in this course, the Data Domain Boost option is
available for the software applications and protocols shown in the highlighted area.
DD Boost can be added with significant advantages as a software option on Data Domain
systems along with plug-ins and libraries applied as an additional layer onto the supported
implementation architectures.
What are the advantages of implementing the DD Boost option?
DD Boost provides the advantages of improved throughput, backup server managed file
replication and backup server replica awareness. How is this possible and why is this
important in a backup, recovery and archive environment?
Improved throughput of “retaining” data (backups) is accomplished with the Open Storage
Technology (OST) protocol and the Data Domain Distributed Segment Processing (DSP).
OST when compared with CIFS and NFS protocols has a faster throughput. Distributed
Segment Processing offloads part of the deduplication process to the Backup Server (if
enabled) to further improve performance.
Without DD Boost, replication is initiated and managed by the Data Domain system. The
Backup server is not aware of the data written on the replica Data Domain system. With DD
Boost, the Backup server can now initiate and manage file replication.
Because DD Boost allows for the Backup server to be aware of the replica Data Domain
system, it can directly restore and recover from the replica Data Domain system. Prior to
DD Boost, the backup server could not control or manage the replica data. This made
restoring the data from a replica a manual process.
In the case of EMC Avamar implementations, DD Boost significantly increases performance
by distributing parts of the deduplication process to Avamar clients. Prior to DD Boost,
Avamar clients could only send data to an Avamar Data Store or Avamar Virtual Edition.
With the DD Boost Library integrated in Avamar clients, the client can send unique data
segments directly to the Data Domain system. Avamar clients use a multi-stream approach
to send specific data types that are better suited to high-speed inline deduplication to Data
Domain systems.
All other data types are still sent to the Avamar Data Store. This enables users to deploy
the optimal approach to deduplication for different data types and manage the entire
infrastructure from a single interface.
With DD Boost for RMAN, Oracle database administrators (DBAs) can configure RMAN to
centrally manage Data Domain replication via Oracle Enterprise Manager and related CLI
commands. As data is replicated between Data Domain systems, there is no additional
resource consumption on the Oracle server for creating the duplicate copy of the backup.
Once configured, RMAN catalog and the Oracle control file keep track of all local and remote
backup copies. This enables DBAs to use RMAN as a single point of management.
This lesson covers backup and recovery with and without Data Domain and the advantages
of using Data Domain.
The basic flow of data in a backup and recovery environment runs as follows.
The full range of systems that might require their data to be backed up can include LAN
clients, Windows and UNIX Servers, databases and VMWare servers.
The backup traffic gets routed through the servers that write to storage – in this example,
a Tape Library. In this case, tapes are rotated out of the tape library and are shipped via
trucks to an offsite location. The tapes are stored so the data can be recovered in case of a
disaster at the primary site.
The metadata associated with the backup is stored with the backup server managing the
environment. The metadata is instrumental to the backup system’s ability to quickly locate
and restore data.
With tape library storage systems, data is sometimes stored on staging disks called the
primary disk pool. It is then migrated to the physical tape library or primary tape pool. The
primary tape pool is copied and moved offsite (called the copy tape pool). As a result, up to
three copies of the data must be tracked in some situations; the primary disk pool, the
primary tape pool, and the copy tape pool.
A Data Domain system integrates as the primary storage destination for deduplicated and
compressed backups. In this example, Data Domain system A (DDS A) is the primary
destination for backups at the headquarters while Data Domain system B (DDS B) is the
primary destination for backups at the offsite location. Data can be replicated from the
headquarters location to the offsite location via the WAN, preserving a copy at a different
location. The Data Domain system B can also act as the primary target for backups for
clients located at the secondary site.
By implementing Data Domain systems, the tape library configuration becomes optional.
Company policies or the need for regulatory compliance both determine the degree to which
tapes can be entirely or partially replaced at a site. Some sites may also choose to use
Data Domain replication to partially or completely eliminate the transportation of tapes by
truck for vaulting.
By replacing some or all of a company's reliance on tape backups with deduplicated storage
of data on disk, customers can reduce cost, complexity, and the risks associated with tape.
The key advantages of implementing the Data Domain system are:

• Reduction in the overall size and scope of the backup and recovery infrastructure.
• Elimination or reduction of the time and resources needed to create, transport, and
reclaim physical tape.
• Reduction of the number of copies that need to be tracked, thereby reducing backup
server database sizes while increasing performance.
• Increased speed of disaster recovery.
This lesson covers file system (NAS) versus VTL (SAN) Environments, VTL in NetWorker,
NetBackup/Backup Exec, and Tivoli Storage Manager Environments.
Data Domain systems support two integration methods, either in a NAS or Network
Attached Storage environment, via network file system mounts, or as a standalone Virtual
Tape Library (VTL), in a SAN or Storage Area Network configuration.
For network file system access in a NAS environment, the backup software addresses the
Data Domain system via native NFS mounts or CIFS shares. The Backup software addresses
the usable space exactly as it would a standard file system mount point such as NTFS, JFS,
UFS, and so forth.
In a VTL or SAN environment, typically, prior investments have usually been in tape –
either physical or virtual. Administrators who know how to manage, monitor, and configure
SAN environments can adopt the Data Domain system as a Virtual Tape Library more
easily.
Data Domain systems can run in a mixed mode capacity, providing both interface methods
concurrently to one or many servers. This flexibility affords a great number of integration
scenarios.
In the case of NetWorker, administrators already using NetWorker Advanced File Type
Devices (AFTDs) can adopt the Data Domain system as a file system without significant
infrastructure or mindset change. The NetWorker AFTDs accept concurrent streams, writing
them into separate files in the directory structure of the AFTD.
For VTL implementations, use the NetWorker Device Manager drivers to interface with the
VTL Library changer with little policy change.
For VTL implementations, use the STK L180 or the new VTL drive emulation. This allows
the backup software to interface with the VTL Library changer. There is little policy or
procedural changes if the Data Domain system is used to replace a physical tape library.
For NAS configuration of Tivoli Storage Manager, configure FILE CLASS DEVICE via NFS (or
CIFS) exports from the Data Domain system. Note that you cannot use TSM’s Disk Device
Class type with the Data Domain system, only use File Device Class type. This topic is
covered in greater depth in an upcoming module.
In a VTL configuration, the Data Domain system can be a Primary or Copy Pool target.
Use the STK L180 emulation.
This table shows trade-offs between the Data Domain system configured as a File System
versus a VTL.
This table continues with additional trade-offs between the Data Domain system configured
as a File System versus a VTL.
This lesson covers installation and configuration workflow, administration and operation
workflow, and VTL implementation workflow.
Data Domain implementations all follow a similar workflow.
To successfully integrate the Data Domain system into a backup environment, first perform
the basic installation and configuration tasks shown in the diagram.
In the first step, make certain that all installations have occurred, including installation of
all application software as necessary throughout the environment, and installation and
initial configuration of the Data Domain system for proper network access by client systems
and backup servers.
Steps two and three are typically performed by Implementation Engineers.
In the second step, configure the Data Domain system with the correct networking, and
create a backup user.
Third, configure the backup server with the necessary credentials or other settings as
necessary, and create a share on the Data Domain system.
Once the communication between the backup environment and the Data Domain system is
established, you administer and operate the Data Domain system and backup servers in
order to validate the implementation. These steps are typically performed by
Implementation Engineers.
First, perform administrative tasks on the backup system’s administrative console in order
to create a backup job.
Next, you run and monitor the backup job in the backup system’s administrative console.
You can also perform operations to perform backup recovery for a client system.
And finally, you can validate and analyze the backups within the Data Domain System
Manager, where you can view statistics and reports.
To implement DD Boost, you first prepare both the Data Domain systems and the backup
application.
Continue with the DD Boost Implementation by verifying backup and clone functionality.
The workflow for a VTL implementation varies.
In most environments, FC zoning and HBA card installation and configuration will have been
previously completed.
Steps 3 through 5 are typically performed by implementation engineers, and cover

configuration of the data domain system, device discovery and configuration on the backup
system’s administrative console, followed by performance of normal backup administration
and operation.
This module focused on implementation architectures, implementation concepts and
terminology, DD Boost implementations, data flow, File-system-based versus VTL
environments, basic implementation workflow.
This module focuses on various options and procedures for EMC Data Domain
implementation in a CIFS environment utilizing any of the common backup applications.
Upon completion of this module, you will be able to install and implement in a CIFS
environment and administer and operate backup applications in a CIFS environment.
To successfully integrate the Data Domain system with the backup environment, you will
perform installation and configuration steps as detailed on this slide. Proper installation and
configuration are essential for proper communication.
All backup application software should have previously been installed. If necessary,
complete all installations according to the manufacturer’s instructions.
Verify that the CIFS configuration of the Data Domain system meets the basic requirements
allowing proper access. For example, backup systems should be able to map a network
drive to the Data Domain system backup directory.
The requirements are:
• The Data Domain system must use either the Active Directory or Workgroup
authentication mode.
• The Data Domain system must have a valid CIFS user account with the following
minimum permissions:
– If the account is part of a Domain or Active Directory, it must have at least,
Domain Backup Operator plus Local Administrator permissions.
– If the account is in a workgroup, it must have at least, Backup Operation group
permissions.
established, you will administer and operate the Data Domain system and backup servers in
order to validate the implementation with the steps shown.
This simulated lab covers the tasks shown.
Click the Launch button when you are ready to begin.
This simulation covers adding a backup user to the Data Domain system, and mapping a
CIFS share.
Click the Launch button to start the simulation.
This simulation covers completing the configuration of the Data Domain system as an
Advance File Type Device in NetWorker.
This simulation covers creating a backup job using the configuration wizard and running
backup and restore operations to verify the configuration.
CIFS share.
This simulation covers reconfiguring services on the NetBackup Server by adding logon
credentials to allow for communication between the backup server and the Data Domain
system.
This simulation covers performing administrative and operational tasks in the NetBackup
Administrative Management Console.
This simulation covers manually running a backup policy and monitoring its activity until
completion.
CIFS share.
This simulation covers reconfiguring services on the Backup Exec Server by adding these
logon credentials to allow for communication between the backup server and the Data
Domain system.
This simulation covers performing administrative and operational tasks in the Backup Exec
administrative console.
This simulation covers preparing a Data Domain system to be used as one or more Static
Shared Magnetic Libraries that utilize the CIFS protocol.
This module focused on how to install and implement Data Domain in a CIFS environment,
and administer and operate backups in a CIFS environment.
implementation in an NFS environment.
Upon completion of this module, you will be able to describe implementation for NFS,
describe Data Domain networking and NFS parameters, describe backup server NFS
configurations, and perform an NFS implementation with IBM Tivoli Storage Manager.
Picking up with steps 2, and 3 after the backup software has already been installed, the
goal is to establish communication between the Data Domain system and the Backup server
in an NFS environment. In step 2, the Data Domain system must be configured for
networking with NFS, and in step 3, the backup server must be configured for backups with
NFS mounts.
This slide shows the high level task list for configuring the Data Domain system for Network
connectivity and enabling the backup transport protocol for NFS.
To configure the Data Domain Networking and NFS Parameters, establish an SSH session to
the Data Domain system and run the config setup command. This will launch the
installation wizard.
Configure the Networking Parameters based on your environment.
If the Data Domain system is not on the network – for example, if it doesn’t have an IP
address – you have to directly connect to the Data Domain system via the serial console to
manage the Data Domain system.
Configure the Data Domain system NFS parameters. Configure the Backup server list by
typing an asterisk (*). This allows for any host on the network to connect to the Data
Domain system via NFS. To lock specific hosts, replace the asterisk with a specific
hostname or an IP Address.
Next, you verify access to the Data Domain /backup and /ddvar directories, through an
NFS mount.
The goal is to create a mount on the Backup Server and copy a test file to the Data Domain
system.
The diagram shows the high level task list flow:

1. Create mount points (directories).
2. Mount Data Domain directories on the new mount points.
3. Modify /etc/fstab to mount directories at every boot.
4. Create a backup directory on the NetBackup Server.
Once the NFS Mount procedure is completed, create and copy the file from the Server to
the Data Domain backup directory to validate functionality.
Note: The specific commands differ depending on the platform you are running. Always
refer to documentation for the specific commands for each platform.
The detailed procedures are to create mount points, or directories, using the commands
shown. Then, mount Data Domain directories on the new mount points. Example
commands and parameters are shown. Next, modify /etc/fstab to mount directories at
every boot. Finally create a backup directory on the NetBackup Server.
The specific commands might differ depending on the platform you are running. Always
refer to documentation for the specific commands for each platform.
Once the NFS Mount procedure is completed, create and copy the file from the Server to
the Data Domain backup directory to validate functionality.
The specific commands differ depending on the platform you are running. Always refer to
documentation for the specific commands for each platform.
This lesson covers NFS tasks lists for TSM, overview of device class configurations, and
implementation procedures.
The goal is to integrate the Data Domain system using the NFS protocol to TSM v.5.5 on a
Linux OS Server.
To successfully integrate the Data Domain system into a backup environment, you perform
the basic installation and configuration tasks shown. Proper installation and configuration
are essentials to proper communications.
All backup application software should have previously been installed. If necessary,
complete all installations according to the manufacturers instructions.
established, you administer and operate the Data Domain system and backup servers in
order to validate the implementation.
Tivoli Storage Manager policies are rules that determine how the client data is stored and
managed. The rules include where the data is initially stored, how many backup versions
are kept, how long archive copies are kept, and so on.
The steps in the process are as follows:

1. A client initiates a backup, archive, or migration operation. The file involved in the
operation is bound to a management class. The management class is either the
default or one specified for the file in client options (the client's include-exclude list).
2. If the file is a candidate for backup, archive, or migration based on information in
the management class, the client sends the file and file information to the server.
3. The server checks the management class that is bound to the file to determine the
destination, the name of the Tivoli Storage Manager storage pool where the server
initially stores the file. For backed-up and archived files, destinations are assigned in
the backup and archive copy groups, which are within management classes. For
space-managed files, destinations are assigned in the management class itself.
4. The server stores the file in the storage pool that is identified as the storage
destination.
TSM allows disk type device classes to be defined as either FILE or DISK type. FILE device
classes are commonly used in TSM for virtual volume management, however, most TSM
administrators define disk storage pools using DISK device class definitions and associate
formatted *.dsm files as storage pool volumes.
FILE type device classes are recommended for use with a Data Domain System FILE device
classes allow TSM to perform sequential read/write activity to files within a file‐system.
Incoming backup data is written to a file, and once a file is filled, a new ‘scratch’ file is
automatically created by TSM and is filled with additional incoming backup data.
This simulation covers how to configure Tivoli Storage Manager for use with a Data Domain
system using NFS.
Click the Launch button to begin the simulation.
This simulation covers how to set up an NSF export from the Data Domain system that can
be used by TSM as a file device class backup target.
This simulation covers how to configure Tivoli Storage Manager for use with a Data Domain
system using NFS.
This module covered Implementation for NFS, Data Domain networking and NFS
parameters, backup server NFS configurations, and NFS implementation with IBM Tivoli
Storage Manager.
This module covers various options and procedures for EMC Data Domain implementation
with the DD Boost option in environments utilizing several common backup applications.
Upon completion of this module you will be able to Prepare Data Domain systems for DD
Boost, Prepare the backup application for DD Boost, Configure the backup application for
DD Boost, and Perform backups with DD Boost and verify.
To implement DD Boost, you first prepare both the Data Domain systems and the backup
application.
Continue with the DD Boost Implementation by verifying backup and clone functionality.
This simulation covers DD Boost implementations with EMC NetWorker, EMC Avamar,
Symantec NetBackup, and Symantec Backup Exec. You only need to perform the exercise
for one of the backup environments.
As an option, you can choose to go through all exercises.
Each exercise takes approximately 10 minutes.
This simulation covers preparing the Data Domain systems for integration with the
NetWorker environment enabled for DD Boost.
This simulation covers performing and verifying backups to Data Domain systems in a DD
Boost environment that is configured with EMC NetWorker.
This simulation covers preparing the Data Domain systems for integration with the Avamar
environment enabled for DD Boost.
This simulation covers running backups to verify the Data Domain system integration with
EMC Avamar enabled for DD Boost.
This simulation covers preparing the Data Domain systems for integration with the
NetBackup environment enabled for DD Boost.
This simulation covers configuring the Data Domain system as a Disk Storage Server for
NetBackup using DD Boost. Click the Launch button to start the simulation.
This simulation covers performing and verifying a backup with NetBackup configured for DD
Boost.
This simulation covers performing and verifying a backup with NetBackup configured for DD
Boost.
This simulation covers preparing the Data Domain systems for integration with the Backup
Exec environment enabled for DD Boost.
This simulation covers preparing the Data Domain systems for integration with the Backup
Exec environment enabled for DD Boost.
This simulation covers implementing Oracle RMAN for use with DD Boost.
This simulation covers how to prepare the Data Domain systems prior to integration with
Oracle Recovery Manager (RMAN) enabled for DD Boost.
This module covered how to Prepare Data Domain systems for DD Boost, prepare the
backup application for DD Boost, configure the backup application for DD Boost, perform
backups with DD Boost and verify, and consider best practices.
implementation in a VTL environment.
Upon completion of this module, you will be able to describe a VTL implementation task list,
configure Data Domain for VTL, perform backup application configurations, and prevent
multiplexing.
To implement Data Domain as a VTL with NetWorker, you perform the steps detailed on this
slide.
This simulation covers configuring a Data Domain system for use with NetWorker,
NetBackup and Backup Exec as a VTL.
This simulation covers configuring the VTL feature with a library, pools and tapes, and then
create a VTL group on the Data Domain system.
This simulation covers verifying the discovery of the Data Domain system, and configuring
it as a VTL on the NetWorker Server.
This simulation covers configuring an NDMP-enabled NAS device to be backed up to a Data
Domain system through NetWorker.
This simulation covers configuring the VTL feature on a Data Domain system and configure
NetBackup to use the VTL.
This simulation covers Performing a backup from Backup Exec to a Data Domain system
configured as a VTL.
Multiplexing interleaves backup streams, writing a little of save set 1, then a little of save
set 2, and so on, so that none of the clients sending save sets need to wait for the other
clients to finish.
The interleaving of save sets has a significant impact on deduplication efficiency when the
Data Domain device is used as a virtual tape library (VTL). Multiplexed streams hinder the
deduplication process from efficiently identifying blocks of common data because of the
additional header information added to the data with parallelism.
In order to realize the full benefit of deduplication, EMC recommends multiplexing be turned
off when using the Data Domain appliance as a VTL.
This module focused on how to describe a VTL implementation configure Data Domain for
VTL, and how to perform backup application configurations.
This module focuses on how to find resources on advanced topics, implement NetWorker
best practices, implement CIFS server best practices, and implement NFS server best
practices.
To dig deeper into the many facets of implementation with application software, download
application-specific documentation from the EMC support portal.
You can also check for any recently added or updated documentation by visiting the EMC
support portal.
You can find additional documentation covering advanced topics on specific backup software
products by visiting the manufacturer’s site.
This lesson covers how to prevent multiplexing, NAS Best Practices, and SAN/VTL Best
Practices.
This table shows some of the Best Practices when implementing the Data Domain system as
a file system to NetWorker.
This table shows additional best practices when implementing the Data Domain system as a
file system to NetWorker.
This table shows some of the best practices when Implementing the Data Domain system
as a VTL to NetWorker.
This table shows some of the differences between a Data Domain Device Type and an AFTD.
This lesson covers changing the Default Session Timeout, tuning TCP/IP Parameters, and
Active Directory Requirements.
Certain internal activities on a Data Domain system can take longer than the default CIFS
timeout on the servers. This can lead to an error message during a backup. To avoid a
premature timeout, change the SESSTIMEOUT value from the default 45 seconds to 3600
seconds.
To do so:
1. Open REGEDIT and navigate to
\\HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\LANMANWORKSTATION
\PARAMETERS.
2. In the Parameters folder add a new String Value.
3. Set the Value name to SESSTIMEOUT.
4. Set the Value data to 3600.
With respect to CIFS performance, it is necessary to tune the TCP/IP parameters on each
server. Modify the Windows Registry for the following:
• Send and Receive Window
• TCP Window Size
The modification parameters change slightly depending upon whether the backup server is
Windows 2000/2003/2008 or Windows NT.
The specific procedures for tuning of TCP/IP parameters on Windows 2000/2003/2008
backup servers are shown here.
For full details, download the CIFS and Data Domain Systems Tech Note from the EMC
Support site.
The specific procedures for tuning of TCP/IP parameters on Windows 2000/2003/2008
backup servers are continued here.
Support site.
The specific procedures for tuning of TCP/IP parameters on Windows NT backup servers are
shown here.
Support site.
The specific procedures for tuning of TCP/IP parameters on Windows NT backup servers are
continued here.
Support site.
There are several requirements for CIFS environments configured for Active Directory. For
full details, download the CIFS and Data Domain Systems Tech Note from the EMC Support
site.
In an active directory environment, the most common issues can be separated into two
categories:
• Joining the Domain, where the Data Domain system has trouble joining the Active
Directory domain and
• Client Access, where the Media server is unable to access the Data Domain system to
perform a backup.
To troubleshoot Joining the Domain issues, check physical and transport connectivity
between the two components, mainly TCP connectivity.
On the Data Domain system, check to make sure the time on the Data Domain system is
within five minutes of the Active Directory Server.
Also, check to make sure that the backup user specified on the Data Domain system is a
valid user on the Active Directory Domain with, at minimum, Operator privileges.
The command cifs troubleshooting list-users can help with narrowing down any
issues.
To troubleshoot Client Access issues, again check physical and transport connectivity
between the two components, mainly TCP connectivity.
On the Data Domain system, check to make sure the Media server host is allowed as a
Backup Client.
Also check to make sure that there are no stale Kerberos Tickets.
This lesson covers NFS server performance tuning resources, and hard mounts.
Server tuning is recommended for new Data Domain system implementations using NFS.
Keep in mind NFS mounting configurations depend on the NFS Server type whether in an
HP, Linux, AIX or Solaris environment.
In addition, Data Domain recommends hard-mounts to ensure availability of the server

after reboots or outages.
Refer to the documentation resources available on the Supporting Materials tab for specific
guidelines.
The following examples describe NFS tuning for Tivoli Storage Manager.
This table, which continues on the next slide, outlines standard TSM server tuning
parameters for optimal Data Domain system performance with TSM using NFS.
For more detailed information, please refer to the Tivoli Storage Manager (TSM) Design Best
Practices with Data Domain document.
This table, which is continued from the previous slide, outlines standard TSM server tuning
parameters for optimal Data Domain system performance with TSM using NFS.
Data Domain recommends the following general NFS configuration settings for mounting a
Data Domain system to a TSM server.
Data Domain only supports the TCP protocol with NFS, and recommends hard-mounts to
ensure server availability after outages.
This module focused on how to find resources on advanced topics; implementing NetWorker
best practices, implementing CIFS server best practices, and implementing NFS server best
practices.
For product information, including overviews, data and specification sheets, and white
papers, visit EMC’s website.
For product documentation, knowledge base articles, and additional white papers, visit the
EMC Support Portal.
To find and enroll in follow-on training covering a wide range of topics including system
installation and maintenance, integration and implementation, administration and
troubleshooting, visit EMC Education Services. Search for Data Domain to view a complete
list of offerings.
This course covered Data Domain implementation with EMC NetWorker, EMC Avamar,
Symantec NetBackup, Symantec Backup Exec, IBM Tivoli Storage Manager, Oracle Recovery
Manager (RMAN), and Commvault Simpana.
This concludes the training. Proceed to the course assessment on the next slide.

Data Domain® Implementation With Application Software - MR-1WP-DDIAS SRG

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Data Domain® Implementation With Application Software - MR-1WP-DDIAS SRG

Caricato da

Copyright:

Formati disponibili

Welcome to Data Domain® Implementation with Application Software.

Revision Date: August 2015

Revision Number: MR-1WP-DDIAS.DDOS5.5.2

Networking connectivity can be via Ethernet LAN or Fibre Channel SAN.

The first Simpana system installed must be configured as a CommServe™. A CommServe

The key advantages of implementing the Data Domain system are:

Use the STK L180 emulation.

Steps two and three are typically performed by Implementation Engineers.

Steps 3 through 5 are typically performed by implementation engineers, and cover

Click the Launch button when you are ready to begin.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Configure the Networking Parameters based on your environment.

The diagram shows the high level task list flow:

The steps in the process are as follows:

Click the Launch button to begin the simulation.

Click the Launch button to begin the simulation.

Click the Launch button to begin the simulation.

As an option, you can choose to go through all exercises.

Each exercise takes approximately 10 minutes.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

Click the Launch button to start the simulation.

In addition, Data Domain recommends hard-mounts to ensure availability of the server

Potrebbero piacerti anche