Data Domain Solutions Design: Downloadable Content

DATA DOMAIN
SOLUTIONS DESIGN
DOWNLOADABLE CONTENT
DOWNLOADABLE CONTENT
Internal Use - Confidential
Table of Contents
Data Domain Solutions Design ................................................................................. 1

Data Domain Solutions Design ............................................................................................ 1
Technology Review Key Features........................................................................................ 1
Performance Tuning 1 ......................................................................................................... 3
Performance Tuning 2 ......................................................................................................... 4
Avamar/Data Domain Architecture ....................................................................................... 5
ProtectPoint/Data Domain Architecture ................................................................................ 6
Networker/Data Domain Architecture ................................................................................... 7
Data Domain Best Practices ................................................................................................ 8
Data Domain Sizing 2 .......................................................................................................... 8
Data Domain Sizing 3 .......................................................................................................... 9
Selecting Data Domain Capacity........................................................................................ 10
Compression Examples ..................................................................................................... 11
Selecting Burn Rate ........................................................................................................... 12
Burn Rate .......................................................................................................................... 13
Throughput Requirements ................................................................................................. 13
Sizing Best Practices ......................................................................................................... 14
Performance Buffer ............................................................................................................ 15
Sizing Considerations/Assumptions ................................................................................... 16
Data Protection Design Scenarios.......................................................................... 17

Primary Data Domain to DR Data Domain ......................................................................... 17
Primary Data Domain to DR Data Domain to DD CT to Public Cloud ................................. 17
Primary Data Domain to DR Data Domain and DD Cloud Tier ........................................... 18
Primary Data Domain > Cloud-based DD VE > DD CT to Public Cloud ............................. 18
Primary Data Domain > Cloud-based DD VE on Object Storage (Road Map) .................... 19
Primary Data Domain > Backup Appliance > Isolated Recovery Vault ............................... 19
ROBO (Remote Office/Branch Office) DD to Primary DD .................................................. 20
Case studies ............................................................................................................. 21

Case Study 1: Data Domain with Replication (NetBackup) ................................................ 21
Data Domain Solutions Design
Internal Use - Confidential

Page ii © Copyright 2020 Dell Inc.
Case Study 1: NetBackup Environment ............................................................................. 22
Case Study 1: NetBackup Environment Solution ............................................................... 23
Case Study 1: NetBackup Environment Solution ............................................................... 23
Case Study 2: VMware ...................................................................................................... 24
Case Study 2: VMware Environment.................................................................................. 25
Case Study 2: VMware Solution......................................................................................... 25
Case Study 3: NAS ............................................................................................................ 26
Case Study 3: Current Backup Environment ...................................................................... 28
Case Study 3: NAS Solution 1 ........................................................................................... 29
Case Study 3: NAS Solution 2 ........................................................................................... 30
Data Protection ........................................................................................................ 31

Data Protection .................................................................................................................. 31
©
Internal Use - Confidential Copyright 2020 Dell Inc. Page iii
This section covers:
• Technology Review
• Performance Tuning
• Architecture Design
• Performance Tuning
• More Design Considerations
• Best Practices
Technology Review Key Features
Data integrity
The DD OS Data Invulnerability Architecture protects against data loss from
hardware and software failures.
Data Compression
Using Global Compression, a Data Domain system eliminates redundant data from
each backup image and stores only unique data.
Restore Operations.
© Copyright
Internal Use - Confidential 2020 Dell Inc. Page 1
Restores create little or no contention with backup or other restore operations.

Incremental backups are always reliable and can be easily accessed. Full backups
can be performed more frequently without the penalty of storing redundant data.
Unlike tape drive backups, multiple processes can access a Data Domain system
simultaneously.
Data Domain Replication

Data Domain sets up and manages the replication of backup data between two
Data Domain systems. An individual Data Domain system can be a part of multiple
replication pairs. One system can serve as a source for one or more pairs and a
destination for one or more pairs.
Configuration and Management

Data Domain systems can be accessed via CLI, Data Domain System Manager,
and Data Domain Management Center. A Data Domain system has a complete
command set available to users in a command-line interface.
Use the Data Domain Enterprise Manager to perform initial system configuration.
Make configuration changes after initial configuration, display system and
component status, and generate reports and charts.
The Data Domain Management Center is a virtual appliance-based solution for

centralized management of multiple Data Domain systems.
Note: For more information about the basics, check the Data Domain
Fundamentals course.
Page
Internal Use - Confidential 2 © Copyright 2020 Dell Inc.
Performance Tuning 1
These tuning issues are performance considerations internal to the DD system.

Simultaneous Streams: For optimal performance, Data Domain recommends
limits on simultaneous streams between Data Domain systems and your backup
servers. See the DellEMC® Data Domain® Operating System Version 6.0
Administration Guide for limits on specific models.
Number of Shelves: For high end DDRs max performance can be impacted by
having too few shelves in the solution.
Encryption options: The default AES 256-bit (CBC) encryption is not the most
secure encryption. The AES 256-bit Galois/Counter Mode (GWindowsCM) is the
most secure algorithm but it is slower than the Cipher block Chaining (CBC) mode.
Local Compression option: Data Domain system uses a local compression

algorithm that is developed to maximize throughput as data is written to disk. The
default algorithm (lz) allows shorter backup for backup jobs but uses more space.
Local compression options provide a trade-off between slower performance and
space usage. The other options are gzfast and gz. They are explained in detail
later in this lesson.
Cleaning: A default schedule runs the cleaning operation every Tuesday at 6 a.m.
(Tuesday @ 0600). You can change the schedule, or you can run the operation
manually. Data Domain recommends running the cleaning operation after a week.
© Copyright
During the cleaning operation, the file system is available for all normal operations
including backup (write) and restore (read). Although cleaning uses a significant
amount of system resources, cleaning is self-throttling and gives up system
resources in the presence of user traffic.
Performance Tuning 2
These tuning issues are more performance considerations internal to the DD

system.
High Replication Load: High-bandwidth replication or many replication streams

may lower overall performance during backup times.
RAID Rebuilds: Data Domain Systems that are undergoing a RAID rebuild
experience degradation in maximum performance.
Reading Old Data: For cleaning as data ages on the DD system, reading aged
data may get slower especially if it is old.
Number of MTrees: Different Data Domain models have different MTree limits.
The table for these specifications is shown on the next slide.
Number of Files: Data Domain recommends storing no more than 1 billion files on
a system. The overall performance for the Data Domain system falls to
unacceptable levels if the system is required to support the maximum file amount
Page
and the workload from the client machines is not carefully controlled.
When the file system passes the billion file limit, several processes or operations
might be adversely affected, for example: Cleaning may take a long time to
complete - several days. AutoSupport operations may take more time and any
process or command that must enumerate all the files.
Avamar/Data Domain Architecture
Here is what is contained in the Avamar/Data Domain Solution:

Avamar Datastore:
–Single Server Node
–Avamar Licenses.
Data Domain:
–Supports Data Domain’s released products
–No new Data Domain equipment required
–Requires DD Boost License
Workload:
–Avamar Data Store manages data for the Avamar solution and stores the
metadata
–Data Domain system is the backup target.
© Copyright
ProtectPoint/Data Domain Architecture
The ProtectPoint solution is made up of several component products, however its

operation can be simplified as this diagram shows. Unlike traditional data protection
products where data is read by the same system that uses the data, ProtectPoint
provides the protection at an array level.
Most companies use high-performance storage array system such as Dell EMC
VMAX3and XtremIO to store critical business data. ProtectPoint integrates with
these arrays to identify and capture data reliably and then moves this data to Data
Domain protection storage providing fast, efficient and flexible data protection.
The method that is used to capture the data depends on the array and solution type
being used, however essentially a point in time copy is created using a snapshot on
the primary storage. This snapshot is then moved to the protection storage via a
Storage Area Network (SAN) to the Data Domain system. This process can be
repeated, so to accommodate multiple versions and can also be reversed to
provide restore capabilities.
Page
Networker/Data Domain Architecture
There are essentially four types of devices you can configure in NetWorker to use a
Data Domain system for backup storage. These devices are:
1.file (NFS)
2.adv_file (NFS or CIFS)
3.tape drives (Data Domain VTL)
4.Data Domain (DD Boost) In the first three types of devices (file, adv_file, and
VTL), NetWorker is unaware of the fact that backup data is deduplicated in the
Data Domain system.
Deduplication processing occurs on the Data Domain system. The NetWorker

configuration steps for these three types of devices using Data Domain as a target
are not any different than configuring these types of devices with other backup
hardware products.
A NetWorker Advanced File type Device (AFTD) accepts concurrent streams

writing into separate files in the directory structure of the AFTD. This makes it
possible for a Data Domain storage system to find and remove common data, thus
achieving optimal deduplication performance. AFTD devices use the LAN to
transmit data and can be configured to use either NFS or CIFS protocols.
The Data Domain storage system can also be configured as a virtual tape library
(VTL) to emulate one or more tape libraries. NetWorker can use the Data Domain
© Copyright
storage device as a VTL in an existing SAN environment. NDMP over the LAN
uses the integrated NDMP Tape Server. With the Data Domain device and DD
Boost, NetWorker shares in the deduplication processing with the Data Domain
system by using Distributed Segment Processing (DSP).
This configuration brings several benefits to the overall solution around

performance and awareness of backups that are replicated to other Data Domain
systems. The Data Domain device can be configured over IP and Fibre Channel.
Data Domain Best Practices
This section covers the following Data Domain best practices:
• Data Domain Sizing

• Data Domain Capacity
• Compression Examples
• Selecting Burn Rate
• Throughput Requirements
• Sizing Best Practices
• Performance Buffer
• Sizing Considerations
Data Domain Sizing 2
These considerations are for sizing. Refer to the EBSS and associated
questionnaires to gather such information.
The baseline information that is needed is the same as would be used to calculate
the requirements for any storage requirement.
Page
The effects of deduplication get factored in later. Essentially the size, frequency,
and type of the backups must be known as well as the retention and replication
requirements.
Data Domain Sizing 3
These considerations are for sizing.
The baseline information that is needed is the same as would be used to calculate
the requirements for any storage requirement.
The effects of deduplication get factored in later. Essentially the size, frequency,
and type of the backups must be known as well as the retention and replication
requirements.
© Copyright
Selecting Data Domain Capacity
From the data you gathered, the first calculation to make is to determine the
amount of storage capacity needed. This calculation is where a sense of what to
expect from the effects of deduplication is needed.
Compression rates vary depending on the characteristics of the data and how
many backup sets are retained. This can vary from small values in the range of 5x
to much larger values of 20x or more. It is helpful to have a realistic estimate.
Some types of data, clients, and situations do not yield the best deduplication
results. This result includes encrypted and compressed files; rich media and email
messages yield little initial commonality. This factor may come from tests or
experience with the actual data set, or it may come from some general
compression examples.
Retention policy is an important factor in determining the compression rate.

Retaining more backup sets usually increases the number of duplicates, and
compression goes up as a result. The tip here is to run the capacity calculations
across a range of retention times to see where the best trade-off is between
retention and compression.
Page
Compression Examples
Compression rates depend on various variables so it is sometimes difficult to say

ahead of time what rates can be expected.
The highest rates are seen when many full backups are stored. General average
rates can be used as a starting point for the calculations and then the numbers can
be refined after real data is available.
It is important to realize that challenging data types such as precompressed and

encrypted files, as the compression rate is reduced for those types.
© Copyright
Selecting Burn Rate
Capacity calculations are a matter of adding up the space that is needed for each
backup that is retained.
In this example, 1 TB of data is backed up. A conservative compression rate of 5x

may have come from a test or is a reasonable assumption to start with. This
compression rate gives 200 GB needed for the initial backup. If there is about a
10% change rate in the data each day, then incremental backups would be about
100 GB each. The compression rate may be more in the range of 10x.
When subsequent full backups run, it is likely that they compress at a much higher
rate so in this case 25x is used. Four daily incrementals needing 10 GB and one
weekly backup needing 40 GB yield a burn rate of 80 GB per week. Running the 80
GB weekly burn rate over the full 8-week retention period means that an estimated
640 GB is needed to store the daily incrementals and the weekly fulls.
Adding this compression to the original full backup results in 840 GB needed. Use
a Data Domain system with 1 TB of useable capacity for this scenario. That
configuration would mean that the unit would operate at about 84% of capacity.
This configuration may be ok. However, a system with a larger capacity or that can
have more storage added might be a better choice to allow for data growth.
Page
Burn Rate
Performance measurements that are based on tests or real backup cycles can be
found and compared to original calculations.
A good source of burn rate information is from the data available on the Data
Domain system itself. The filesys compression report is available in the command
line and is recorded in the daily Autosupport message.
The 7-day postcompression burn rate can be used as a relatively accurate

prediction of the expected weekly burn rates. This rate is accurate if the unit has
been through at least a full weekly cycle. The 24-hour postcompression burn rate is
useful for capturing backup anomalies.
Throughput Requirements
© Copyright
In this sample calculation, the full backup set of 6500 GB is required to be backed
up within a 10-hour window.
This throughput yields a raw requirement of being able to process at least 650 GB
per hour.
Sizing Best Practices
Best practices are to be conservative in the assumptions and calculate a 15% to

25% buffer. This procedure should be complete for both the capacity and the
throughput calculations.
Page
Performance Buffer
Good practice is to select a unit that could operate at no more than 75% to 85% of
its rated capacity.
In this example, the throughput requirement of 3.6 TB per hour would load the
DD2200 to about 95% of capacity. A better choice would be a model with higher
throughput capability such as the DD2500.
Again, results vary according to the environment. Consult the Dell EMC Support
website and consider proof-of-concept testing to confirm the achievable
performance.
© Copyright
Sizing Considerations/Assumptions
Here are some additional assumptions and considerations to keep in mind when
selecting the DD model to implement.
Sizing results that are presented represent the minimum requirements.

Performance results that are presented are based on the slowest protocol selected.
All data that is backed up during the first week has minimal compression rate.
Minimum of two weeks retention is required.
DPS Solution Builder uses preprogrammed compression ratios. The default values
are a starting point and not the definitive values to be used in all sizing.
You must change the default Daily Change % to match that of your customer’s
environment. Data Domain default change rates may be changed when in Detail
Level “High.”
Page
Data Protection Design Scenarios
Primary Data Domain to DR Data Domain
This is a common design scenario with Backup, Archive, and Enterprise

applications coming into the Primary Data Domain System. From the Primary Data
Domain System, the data is replicated to the Disaster Recovery Data Domain
System. Data is coming into the Primary DD through Ethernet and state the options
such as option A, option B, or both Fibre Channel.
Primary Data Domain to DR Data Domain to DD CT to Public

Cloud
© Copyright
This scenario is the same as the previous scenario. The difference here is that data
goes from the Disaster Recovery Data Domain System to the Public Cloud.
Primary Data Domain to DR Data Domain and DD Cloud Tier
This scenario shows a direct connect from the Primary Data Domain System to the
Public Cloud and direct to the Disaster Recovery Data Domain System.
Primary Data Domain > Cloud-based DD VE > DD CT to

Public Cloud
This scenario show data coming from the Primary Data Domain System to the DD
VE Cloud and then to the Public Cloud.
Page
Primary Data Domain > Cloud-based DD VE on Object

Storage (Road Map)
In this scenario, the Primary Data Domain System sends to DD VE Cloud-based

Object Storage.
Primary Data Domain > Backup Appliance > Isolated

Recovery Vault
In this scenario, Primary Storage sends to the Backup appliance and then to the
Isolated Recovery System. It is isolated because it is online only to periodically
update the Isolated Recovery System.
© Copyright
ROBO (Remote Office/Branch Office) DD to Primary DD
Data coming from a Remote Office/Branch Office to the Primary DD system can
then be sent to any of the other scenario configurations.
Page
Case studies
Case studies
Case Study 1: Data Domain with Replication (NetBackup)
ABC Corp currently uses NetBackup to protect data within their environment.
They are experiencing capacity issues and new requirements that are directed from
corporate management.
Use the information that is provided to:
1. Design a solution that addresses the customer’s requirements•Document

required hardware and/or state the options such as option A, option B, or
both software.
2. Identify any licensing or configuration changes that are necessary to
accommodate the solution.
ABC Corp. has a moderately sized NetBackup environment that has been in place
for more than five years.
During the past two years, the environment has seen moderate growth and the
infrastructure has not grown to support it.
ABC Corp. is looking to upgrade their existing backup environment to resolve the
issues currently causing backup failures and better position themselves for future
growth and requirements.
ABC Corp. wants to address the current backup deficiencies in their environment.
They want to address new corporate guidelines requiring data be copied offsite
within 48 hours of initial backup. They are currently happy with their backup
software and are not looking to replace it.
They are interested in supplementing it and or state the options such as option A,
option B, or both modifying their design to better meet their requirements.
Requirements and Concerns:
© Copyright
Case studies
Slow tape speeds and insufficient number of drives and media causes
frequent failures and missed backup windows.
Only 10% of clients have more than one copy of backup data due to media
limitations. There is overhead associated with driving tapes frequently to DR
site.
They would prefer to improve the capability for offsite backups of a greater
number of clients.
Case Study 1: NetBackup Environment
Current Backup Environment:
* 250 clients consisting of Windows and Linux.
* Applications include database, Exchange, and web development servers.
* All databases are between 80 GB – 200 GB.
* All backups are currently sent to older LTO2 tape drives.
* High priority client backups are shipped offsite to a DR data center.
* All backups are retained for a maximum of 90 days.
Page
Case studies
Case Study 1: NetBackup Environment Solution
A solution that contains their current infrastructure while addressing all concerns
includes:
* Replace tape targets with Data Domain devices
* Replicate Data Domain devices between primary and DR locations to ensure that
data for all clients is maintained offsite.
* Repurpose tape as a target only for long-term retention if necessary
* Use DD Boost with NetBackup to improve backup performance
Summary:
While addressing all their concerns, a solution that best applies their current
infrastructure is to replace their tape targets with DD Boost devices. These devices
use replication between primary and DR location.
Also, they could repurpose existing tape library/drives for use only for data
requiring long-term retention.
Case Study 1: NetBackup Environment Solution
Displayed is an example high-level design of a suggested redesign for ABC Corps

NetBackup environment.
© Copyright
Case studies
Case Study 2: VMware
GH Corp currently uses DellEMC NetWorker to back up their entire environment.

They have recently invested heavily in virtualization with VMware. They would
prefer to use more advanced capabilities than the guest level backups they are
currently performing of all VMs.
Use the information that is provided to:

Design a solution that addresses the customer’s requirements.
Document required hardware and state the options such as option A, option B, or
both software
Identify any licensing or configuration changes that are necessary to accommodate

the solution.
GH Corp. has been using DellEMC NetWorker for many years as their sole backup
management and recovery (BMR) solution. They have recently invested heavily in
virtualizing their data centers. They are increasing the number of servers running
on VMs from 10% to 80%.
They are currently backing up all servers from a guest level and treating VMs the
same as physical hosts. With the new push to virtualize most of their environment,
they are interested in applying more advanced backup strategies for VMware. GH
Corp. is not opposed to changing their BMR product, however they are cost
conscious and would use as much of their existing environment as possible.
Also, they are interested in potential tape reduction given the high costs they
currently experience with tape management overhead.
Better to apply advanced capabilities for backing up virtualized clients:

Would prefer to include image level backup capabilities without losing file level
recovery or duplicating the backup process.
Use their existing infrastructure, where possible.
Reduce reliance on tape, where possible.
Page
Case studies
Case Study 2: VMware Environment

NetWorker server and two storage nodes, all running NetWorker 7.5.
Applications include Microsoft SQL and Microsoft Exchange, currently being

protected with NME and NMSQL modules.
100% Windows environment.
All backups are currently sent to older LTO3 tape drives.
All clients are backed up at a level full weekly and incremental daily. After per
month full backups are cloned to tape and sent offsite for long-term storage.
All file system backups are performed from a guest level.
Backup retention varies by client type, but ranges 45 through 90 days onsite and
one year offsite.
Case Study 2: VMware Solution
A solution that best applies their current infrastructure while addressing all
concerns includes:
© Copyright
Case studies
Upgrade the existing NetWorker environment, and use NetWorker VMware

Protection for image backups.
Replace tape targets with Data Domain devices.
Direct all backups to Data Domain targets and use tape only for long-term retention
of the monthly backups via cloning.
The most direct solution is to upgrade their existing NetWorker implementation to
support NetWorker VMware Protection for image backups.
After this is completed, physical, or virtual storage nodes can be used to perform
image and file level backups of clients. Employ NMM for Microsoft Exchange and
Microsoft SQL backups.
Also, use a Data Domain system to replace tape as the primary backup target. The
tape library could then be repurposed to provide a clone target only for long-term
retention.
This solution requires a NetWorker upgrade, Data Domain hardware, and

NetWorker licensing to support backup to disk if remaining with traditional
NetWorker licensing.
Case Study 3: NAS
CAB Inc. is a current Backup Exec customer that is expecting significant growth
within the environment. They are looking to move to an enterprise solution that can
address specific issues that they are facing. One issue is slow backups of some
dense file systems.
Use the information that is provided to: Design a solution that addresses the
customer’s requirements.
Document required hardware and/or or or state the options such as option A,

option B, or both software.
Identify any licensing or configuration changes that are necessary to accommodate

the solution.CAB Inc. currently runs Symantec Backup Exec in their environment
Page
Case studies
for all backups. While their existing server count is small, they are expecting
significant growth in the next 12 months.
They are currently experiencing issues with their existing backup infrastructure and
are looking to make a change to an enterprise solution. CAB Inc. has a small
VMware footprint and is looking to expand soon.
CAB Inc. is experiencing some specific issues with their existing BRM solution that
they must have addressed by any new solution. They have three servers that are
used as dense file servers. While the data sizes of these servers are all between
400 GB - 1 TB, they each contain between 4 -7 million files.
Backup times of these file systems are slow, less than 1 MB/s and backups often
take 20+ hours to complete causing frequently missed backup windows.

Backups of the six dense file servers take too long to complete:
Must reduce backup times of dense file servers.
Offsite backups are stored at the DR site three states away from the primary data
center.
Tape costs are growing significantly. CAB Inc. is interested in alternatives, however
corporate policy will not change to preclude full offsite backups from being on tape.
Getting tapes offsite is problematic. They would be interested in any solution that
would help with this issue.
Would prefer to be able to use VMware with new backup servers, if possible.
Focus of design should be made on performance of the backup system and

scalability to easily grow with the environment.
© Copyright
Case studies
Case Study 3: Current Backup Environment

Backup Exec server running on Windows, currently experiencing performance
issues.
Currently have 100 Linux and Windows clients with expected 100% growth in the
next 12 months.
Applications include Oracle and Informix.
All clients are backed up daily with full backups on the weekend and incrementals
daily.
All backups are currently sent to LTO3 tape drives.–Libraries are maintained at
both the primary and DR locations.
Corporate policy dictates that a copy of all full backups is kept offsite on tape.
Backup retention varies by type and server role; 30 days onsite and 1 through 3
Page
Case studies
year offsite.
Three 2-node Windows file server clusters are present hosting dense file systems:
Each server has 4 through 7 million files though data size is only between 400 GB
– 1 TB.
Case Study 3: NAS Solution 1
A solution that addresses all concerns includes:

New NetWorker 9.X environment to replace BackupExec
Potentially replace tape targets with Data Domain devices:

Both onsite and at the DR site with replication between the two sites
Use DD Boost to allow for clone-controlled replication.
Write data to Data Domain devices, and replicate to the remote site. Data can then
be cloned to tape. Implement block based backups (BBB) to address slow backups
of dense file servers.
The suggested solution includes a NetWorker 9.X server on a VM and two physical
storage nodes (one local and one remote at the DR site). The storage nodes would
do all the data movement leaving the NetWorker server just as a Management
Server.
Data could be written to DD Boost devices on the local storage node or to DD

Boost devices on dedicated storage nodes.
Backup data would then be replicated to the DR site. After data is replicated, clone
jobs could be run to write full backups to tape at the DR site on a weekly basis.
Because data at the remote site is tracked by NetWorker with clone-controlled
replication, data at the remote Data Domain system can be written to tape. This
process is without must traverse the WAN except for replication.
The NetWorker server can be virtualized and configured in a management-only

role. This configuration results in a better load distribution within the environment
and improved scalability for future expansion.
© Copyright
Case studies
Case Study 3: NAS Solution 2
Displayed is an example of a high-level design of the suggested redesign for the

environment.
Page
Data Protection
Data Protection
Data Protection
The proven exam DES-3611 is required to earn the Specialist - Technology

Architect, Data Protection Certification. The courses listed in the curriculum focus
on developing the your knowledge of designing Data Protection solutions using the
latest Dell EMC Data Protection products. These courses and the associated
certification exam will enable you to acquire and validate the skills necessary to
perform at a Data Protection Specialist level and become a trusted advisors for
your customers as you recommend and design data protection solutions.
Learning path for Internals is “DECS-TA Data Protection Technology Architect-

Internal”
Learning path for Partners is MR-7MM-SPSTA-DPS, “DECS-TA Data Protection

Technology Architect- Partner Only”
Technology Architect,
Data Protection
A. Dell EMC Data Protection Specialist Level Concepts (ODC)

B. Dell EMC Data Protection Solution Design Knowledge Check (ODC)
C. Dell EMC Data Protection Concepts (ODC)
D. Dell EMC Data Protection Solution Design Concepts (ODC)
E. Data Domain Solutions Design (ODC)
F. Designing Solutions using Dell EMC Data Protection Suite for Applications (ODC)
G. Integrated Data Protection Appliances Solutions Design (ODC)
H. Designing Solutions using Dell EMC NetWorker (ODC)
I. Designing Solutions using Dell EMC Avamar (ODC)
J. Designing Solutions using Dell EMC Recover Point (ODC)
K. Designing Solutions using Dell EMC Recover Point for VMs (ODC)
L. Designing Dell EMC Cloud Data Protection Solutions (ODC)
M. Designing Solutions using Dell EMC Isolated Recovery Solutions (ODC)
N. Dell EMC Data Protection Solution Design Challenge (ODC)
O. Dell EMC Data Protection Expert Role (ODC)
Information Storage and Management Data Protection and Management
A. Information Storage and Management A. Data Protection and Management (ODC)

(C, VC, ODC)
(C) - Classroom
(VC) - Virtual Classroom

(ODC) - On Demand Course
For more information, visit: http://dell.com/certification
© Copyright
© Copyright 2020 Dell Inc. Page 32

Data Domain Solutions Design: Downloadable Content

Uploaded by

Copyright:

Available Formats

Data Domain Solutions Design: Downloadable Content

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Data Domain Solutions Design: Downloadable Content

Uploaded by

Copyright:

Available Formats

DATA DOMAIN

Data Domain Solutions Design ................................................................................. 1

Data Protection Design Scenarios.......................................................................... 17

Case studies ............................................................................................................. 21

Data Domain Solutions Design

Internal Use - Confidential

Data Protection ........................................................................................................ 31

Data Domain Solutions Design

Data Domain Solutions Design

Data Domain Solutions Design

This section covers:

Technology Review Key Features

Data Domain Solutions Design

Restores create little or no contention with backup or other restore operations.

Data Domain Replication

Configuration and Management

The Data Domain Management Center is a virtual appliance-based solution for

Data Domain Solutions Design

These tuning issues are performance considerations internal to the DD system.

Local Compression option: Data Domain system uses a local compression

Data Domain Solutions Design

These tuning issues are more performance considerations internal to the DD

High Replication Load: High-bandwidth replication or many replication streams

Data Domain Solutions Design

Avamar/Data Domain Architecture

Here is what is contained in the Avamar/Data Domain Solution:

Data Domain Solutions Design

ProtectPoint/Data Domain Architecture

The ProtectPoint solution is made up of several component products, however its

Data Domain Solutions Design

Networker/Data Domain Architecture

Deduplication processing occurs on the Data Domain system. The NetWorker

A NetWorker Advanced File type Device (AFTD) accepts concurrent streams

Data Domain Solutions Design

This configuration brings several benefits to the overall solution around

Data Domain Best Practices

This section covers the following Data Domain best practices:

• Data Domain Sizing

Data Domain Sizing 2

Data Domain Solutions Design

Data Domain Sizing 3

These considerations are for sizing.

Data Domain Solutions Design

Selecting Data Domain Capacity

Retention policy is an important factor in determining the compression rate.

Data Domain Solutions Design

Compression rates depend on various variables so it is sometimes difficult to say

It is important to realize that challenging data types such as precompressed and

Data Domain Solutions Design

Selecting Burn Rate

In this example, 1 TB of data is backed up. A conservative compression rate of 5x

Data Domain Solutions Design

The 7-day postcompression burn rate can be used as a relatively accurate

Data Domain Solutions Design

Sizing Best Practices

Best practices are to be conservative in the assumptions and calculate a 15% to

Data Domain Solutions Design

Data Domain Solutions Design

Sizing results that are presented represent the minimum requirements.