DD Final

This module covers sizing, capacity and throughput planning and tuning.
In any backup environment, it is critical to plan capacity and throughput adequately.

Planning ensures your backups complete within the time required and are securely retained
for the needed times. Data growth in backups is also a reality as business needs change.
Inadequate capacity and bandwidth to perform the backup can cause backups to lag, or fail
to complete. Unplanned growth can fill a backup device sooner than expected and choke
backup processes.
The main goal in capacity planning is to design your system with a Data Domain model and
configuration that is able to store the required data for the required retention periods with
sufficient space remaining.
When planning for throughput requirements, the goal is to ensure the link bandwidth is
sufficient to perform daily and weekly backups to the Data Domain system within the
allotted backup window. Effective throughput planning takes into consideration network
bandwidth sharing, and adequate backup and system housekeeping timeframes (windows).
Copyright 2017 Dell Inc.. Data Domain System Administration 1

In this lesson, you become familiar with the testing and evaluation process that helps to
determine the capacity requirements of a Data Domain system:
Collecting information
Determining and calculating capacity needs
EMC Sales uses detailed software tools and formulas when working with its customers to
identify backup environment capacity and throughput needs. Such tools help systems
architects recommend systems with appropriate capacities and correct throughput to meet
those needs. This lesson discusses the most basic considerations for capacity and
throughput planning.

Using information collected about the backup system, you calculate capacity needs by
understanding the amount of data (data size) to be backed up, the types of data, the size
of a full (complete) backup, then number of copies of the data backed up, and the expected
data reduction rates (deduplication).
Data Domain system internal indexes and other product components use additional,
variable amounts of storage, depending on the type of data and the sizes of files. If you
send different data sets to otherwise identical systems, one system may, over time, have
room for more or less actual backup data than another.
Data reduction factors depend on the type of data being backed up. Some types of
challenging (deduplication-unfriendly) data types include:
pre-compressed (multimedia, .mp3, .zip, and .jpg)
pre-encrypted data
Retention policies greatly determine the amount of deduplication that can be realized on a
Data Domain system. The longer data is retained, the greater the data reduction that can
be realized. A backup schedule where retained data is repeatedly replaced with new data
results in very little data reduction.

The reduction factors listed in this slide are examples of how changing retention rates can
improve the amount of data reduction over time.
The reduction rates shown are approximate.
A daily full backup retained only for one week on a Data Domain system may result in a
compression factor of only 5x, while retaining weekly backups plus daily incrementals for up
to 90 days may result in 20x or higher reduction.
Data reduction rates depend on a number of variables including data types, the amount of
similar data, and the length of storage. It is difficult to determine exactly what rates to
expect from any given system. The highest rates are usually achieved when many full
backups are stored.
When calculating capacity planning, use average rates as a starting point for your
calculations and refine them after real data is available.

Calculate the required capacity by adding up the space required in this manner:
First Full backup plus.
Incremental backups (the number of days incrementals are runtypically 4-6) plus.
Weekly cycle (one weekly full and 4-6 incrementals) times the number of weeks data
is retained.
For example, 1 TB of data is backed up, and a conservative reduction rate is estimated at
5x (which may have come from a test or is a reasonable assumption to start with). This
gives 200 GB needed for the initial backup. With a 10 percent change rate in the data each
day, incremental backups are 100 GB each, and with an estimated compression on these of
10x, the amount of space required for each incremental backup is 10 GB.
As subsequent full backups run, it is likely that the backup yields a higher data reduction
rate. 25x is estimated for the data reduction rate on subsequent full backups. 1 TB of data
compresses to 40 GB.
Four daily incremental backups require 10 GB each, and one weekly backup needing 40 GB
yields a burn rate of 80 GB per week. Running the 80 GB weekly burn rate out over the full
8-week retention period means that an estimated 640 GB is needed to store the daily
incremental backups and the weekly full backups.
Adding this to the initial full backup gives a total of 840 GB needed. On a Data Domain
system with 1 TB of usable capacity, this means the unit operates at about 84% of
capacity. This may be okay for current needs. You might want to consider a system with a
larger capacity or that can have additional storage added, which might be a better choice to
allow for data growth.
Again, these calculations are for estimation purposes only. Before determining true
capacity, use the analysis of real data gathered from your system as a part of an EMC BRS
sizing evaluation.

While capacity is one part of the sizing calculation, it is important not to neglect the
throughput of the data during backups.
An assumption would be that the greatest backup need is to process a full 200 GB backup
within a 10-hour backup window. Incremental backups should require much less time to
complete, and we could safely presume that incremental backups would easily complete
within the backup window.
Dividing 200 GB by 10 hours yields a raw processing requirement of at least 20 GB per

hour.
Over an unrestricted 1 GB network with maximum bandwidth available (with a theoretical

270 GB per hour throughput), this backup would take less than 1 hour to complete. If the
network were sharing throughput resources during the backup time window, the amount of
time required to complete the backup would increase considerably.
It is important to note the effective throughput of both the Data Domain system and the
network on which it runs. Both points in data transfer determine whether the required
speeds are reliably feasible. Feasibility can be assessed by running network testing software
such as iperf.

This lesson applies the formulae from the previous two lessons to selecting the best Data
Domain system to fit specific capacity and throughput requirements.

The system capacity numbers of a Data Domain system assume a mix of typical enterprise
backup data (such as file systems, databases, mail, and developer files). The low and high
ends of the range are also determined by how often data is backed up.
The maximum capacity for each Data Domain model assumes the maximum number of
drives (either internal or external) supported for that model.
Maximum throughput for each Data Domain model is dependent mostly on the number and
speed capability of the network interfaces being used to transfer data. Some Data Domain
systems have more and faster processors so they can process incoming data faster.
Advertised capacity and throughput ratings for Data Domain products are best case results,
based on tests conducted in laboratory conditions. Your throughput will vary depending on
your network conditions.
The number of network streams you may expect to use depends on your hardware model.
Refer to the specific model Data Domain system guide to learn specific maximum supported
stream counts.

Standard practices are to be conservative in calculating capacity and throughput required
for the needs of a specific backup environment; estimate the need for greater throughput
and capacity rather than less. Apply your requirements against conservative ratings (not
the maximums) of the Data Domain system needed to meet requirements. Allow for a
minimum 20% buffer in both capacity and throughput requirements:
Required capacity divided by maximum capacity of a particular model times 100
equals the capacity percentage.
Required throughput divided by the maximum throughput of a particular model times
100 equals the throughput percentage.
If the capacity or throughput percentage for a particular model does not provide at least a
20% buffer, then calculate the capacity and throughput percentages for a Data Domain
model of the next higher capacity. For example, if the capacity calculation for a DD620
yields a capacity percentage of 91%, only a 9% buffer is available, so you should look at
the DD640 next to calculate its capacity.
Sometimes one model provides adequate capacity, but does not provide enough
throughput, or vice versa. The model selection must accommodate both throughput and
capacity requirements with an appropriate buffer.

In this example, the capacity requirement of 250 TB fills Model A to 88% of capacity.
Model B has a capacity of 428 TB. The capacity percentage estimated for Model B is 58%,
and the 42% buffer is more than adequate.

In this example 250 TB capacity is needed.
It appears by the capacity specifications that Model A does not meet this need with only
285 TB capacity. It leaves only a 12% buffer.
Model A with an additional shelf, offers 570 TB capacity. A 66 % buffer is clearly a better
option.
Model B is also a viable option with 428 TB capacity a 42 % buffer.

This calculation is similar to calculating the capacity buffer for selected models.
Select a model that meets throughput requirements with no more than 80% of the models
maximum throughput capacity.
In this example, the throughput requirement of 9 TB per hour would load Model A to close
to 85% of capacity, with a buffer of 15%.
A better selection is a model with higher throughput capability, such as Model B, rated with
12.6 TB per hour throughput and offering a 29% buffer in estimated throughput.

In summary, Model A with an additional shelf might meet the capacity requirement; Model
B is the minimum model that would meet the throughput performance requirement.
While Model A meets the storage capacity requirement, Model B is the best choice based
upon the need for greater throughput.
Another option is to consider implementing DD Boost with Model A to raise the throughput
rating.

This lesson covers basic throughput monitoring and tuning on a Data Domain System.
There are three primary steps to throughput:

Identifying potential bottlenecks that might reduce the data transfer rates during
backups and restores.
Displaying and understanding Data Domain system performance metrics.
Identifying and implementing viable solutions to resolve slower-than-expected
throughput issues.

Integrating Data Domain systems into an existing backup architecture can change the
responsiveness of the backup system. Bottlenecks can appear and restrict the flow of data
being backed up.
Some possible bottlenecks are: Backup Server
Clients Configuration
Disk Issues Load
Configuration Connectivity
Connectivity
Data Domain System
Network
Connectivity
Wire speeds
Configuration
Switches and routers
Log level set too high
Routing protocols and firewalls
As demand shifts among system resources such as the backup host, client, network, and
Data Domain system itself the source of the bottlenecks can shift as well.
Eliminating bottlenecks where possible, or at least mitigating the cause of reduced

performance through system tuning, is essential to a productive backup system. Data
Domain systems collect and report performance metrics through real-time reporting and in
log files to help identify potential bottlenecks and their causes.

If you notice backups running slower than expected, it is useful to review system
performance metrics.
From the command line, use the command system show performance.
The command syntax is:

system show performance [ {hr | min | sec} [ {hr | min | sec} ]]
For example:
system show performance 24 hr 10 min
This shows the system performance for the last 24 hours at 10 minute intervals. 1
minute is the minimum interval.
Servicing a file system request consists of three steps: receiving the request over the
network, processing the request, and sending a reply to the request.
Utilization is measured in four states:

ops/s: Operations per second.
load: Load percentage (pending ops/total RPC ops *100).
data (MB/s in/out): Protocol throughput. Amount of data the file system can read from
and write to the kernel socket buffer.
wait (ms/MB in/out): Time taken to send and receive 1MB of data from the file system
to kernel socket buffer.

An important section of the system show performance output is the CPU and disk
utilization.
CPU avg/max: The average and maximum CPU utilization; the CPU ID of the most-
loaded CPU is shown in the brackets.
Disk max: Maximum disk utilization over all disks; the disk ID of the most-loaded
disk is shown in the brackets.
If the CPU utilization shows 80% or greater, or if the disk utilization is 60% or greater for
an extended period of time, the Data Domain system is likely to run out of disk capacity or
is the CPU processing maximum. Check that there is no cleaning or disk reconstruction in
progress. You can check cleaning and disk reconstruction in the State section of the system
show performance report.
The following is a list of states and their meaning indicated in the system show performance
output:
C Cleaning
D Disk reconstruction
B GDA (also known as multinode cluster [MNC] balancing)
V Verification (used in the deduplication process)
M Fingerprint merge (used in the deduplication process)
F Archive data movement (active to archive)
S Summary vector checkpoint (used in the deduplication process)
I Data integrity
Typically the processes listed in the State section of the system show performance report
impact the amount of CPU utilization for handling backup and replication activity.

In addition to watching disk utilization, you should monitor the rate at which data is being
received and processed. These throughput statistics are measured at several points in the
system to assist with analyzing the performance to identify bottlenecks.
If slow performance is happening in real-time, you can also run the following command:
system show stats interval [interval in seconds]
Example:
system show stats interval 2
Adding 2 produces a new line of data every two seconds.
The system show stats command reports CPU activity and disk read/write amounts.
In the example report shown, you can see a high and steady amount of data inbound on
the network interface, which indicates that the backup host is writing data to the Data
Domain device. We know it is backup traffic and not replication traffic as the Repl column is
reporting no activity.
Low disk-write rates relative to steady inbound network activity are likely because much of
the incoming data segments are duplicates of segments already stored on disk. The Data
Domain system is identifying the duplicates in real time as they arrive and writing only
those new segments it detects.

If you experience system performance concerns, for example, you are exceeding your
backup window, or if throughput appears to be slower than expected, consider the
following:
Check the Streams columns of the system show performance command to make sure
that the system is not exceeding the recommended write and read stream count. Look
specifically under rd (active read streams) and wr (active write streams) to determine
the stream count. Compare this to the recommended number of streams allowed for
your system. If you are unsure about the recommended streams number, contact
Data Domain Support for assistance.
Check that CPU utilization (1 process) is not unusually high. If you see CPU
utilization at or above 80%, it is possible that the CPU is under-powered for the load it
is required to currently process.
Check the State output of the system show performance command. Confirm that
there is no cleaning (C) or disk reconstruction (D) in progress.
Check the output of the replication show performance all command. Confirm that
there is no replication in progress. If there is no replication activity, the output reports
zeros. Press Ctrl + c to stop the command. If replication is occurring during data
ingestion and causing slower-than-expected performance, you might want to separate
these two activities in your backup schedule.
If CPU utilization (1 process) is unusually high for any extended length, and you are
unable to determine the cause, contact Data Domain Support for further assistance.
When you are identifying performance problems, it is important to note the actual
time when poor performance was observed to know where to look in the system show
performance output chronology.

This problem is centered around a client trying to access a Data Domain system over a slow
network. There are multiple considerations to address solving the problem.

This module discussed how to size a Data Domain system for capacity and throughput
parameters. Topics included capacity and throughput planning, and how to select a Data
Domain system based on these parameters.

The module also covered the monitoring of CPU, Disk and throughput performance, and the
steps you can take to fine tune them in a Data Domain system.

This course covered how to administer a Data Domain system. Topics included
deduplication basics, Data Domain system and its technologies, verify hardware, manage
system access, upgrade Data Domain system, migrate storage, list licensed features,
monitor a Data Domain system, configure and manage network interfaces and data paths.

This course also covered how to access and copy data to a Data Domain system, customize
and manage Data Domain file system, describe capacity and throughput planning, describe
and configure VTL, DD Boost, data security features and Secure Multi-Tenancy.

Welcome to Data Domain Extended Retention Installation, Configuration, and Administration.
Copyright 2016 Dell Inc. or its subsidiaries. All Rights Reserved. Dell, EMC, and other trademarks are trademarks of Dell Inc. or
its subsidiaries. Other trademarks may be the property of their respective owners. Published in the USA.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. DELL EMC 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 DELL 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 DELL 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.
AccessAnywhere Access Logix, AdvantEdge, AlphaStor, AppSync ApplicationXtender, ArchiveXtender, Atmos, Authentica, Authentic Problems,
Automated Resource Manager, AutoStart, AutoSwap, AVALONidm, Avamar, Aveksa, Bus-Tech, Captiva, Catalog Solution, C-Clip, Celerra, Celerra
Replicator, Centera, CenterStage, CentraStar, EMC CertTracker. CIO Connect, ClaimPack, ClaimsEditor, Claralert ,CLARiiON, ClientPak,
CloudArray, Codebook Correlation Technology, Common Information Model, Compuset, Compute Anywhere, Configuration Intelligence, Configuresoft,
Connectrix, Constellation Computing, CoprHD, EMC ControlCenter, CopyCross, CopyPoint, CX, DataBridge , Data Protection Suite. Data Protection
Advisor, DBClassify, DD Boost, Dantz, DatabaseXtender, Data Domain, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, DLS ECO,
Document Sciences, Documentum, DR Anywhere, DSSD, ECS, elnput, E-Lab, Elastic Cloud Storage, EmailXaminer, EmailXtender , EMC Centera,
EMC ControlCenter, EMC LifeLine, EMCTV, Enginuity, EPFM. eRoom, Event Explorer, FAST, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony,
Global File Virtualization, Graphic Visualization, Greenplum, HighRoad, HomeBase, Illuminator , InfoArchive, InfoMover, Infoscape, Infra, InputAccel,
InputAccel Express, Invista, Ionix, Isilon, ISIS,Kazeon, EMC LifeLine, Mainframe Appliance for Storage, Mainframe Data Library, Max Retriever, MCx,
MediaStor , Metro, MetroPoint, MirrorView, Mozy, Multi-Band Deduplication,Navisphere, Netstorage, NetWitness, NetWorker, EMC OnCourse,
OnRack, OpenScale, Petrocloud, PixTools, Powerlink, PowerPath, PowerSnap, ProSphere, ProtectEverywhere, ProtectPoint, EMC Proven, EMC
Proven Professional, QuickScan, RAPIDPath, EMC RecoverPoint, Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, the RSA logo,
SafeLine, SAN Advisor, SAN Copy, SAN Manager, ScaleIO Smarts, Silver Trail, EMC Snap, SnapImage, SnapSure, SnapView, SourceOne, SRDF,
EMC Storage Administrator, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix, Symmetrix DMX, Symmetrix VMAX, TimeFinder,
TwinStrata, UltraFlex, UltraPoint, UltraScale, Unisphere, Universal Data Consistency, Vblock, VCE. Velocity, Viewlets, ViPR, Virtual Matrix, Virtual
Matrix Architecture, Virtual Provisioning, Virtualize Everything, Compromise Nothing, Virtuent, VMAX, VMAXe, VNX, VNXe, Voyence, VPLEX, VSAM-
Assist, VSAM I/O PLUS, VSET, VSPEX, Watch4net, WebXtender, xPression, xPresso, Xtrem, XtremCache, XtremSF, XtremSW, XtremIO, YottaYotta,
Zero-Friction Enterprise Storage.
Revision Date: January 2017
Revision Number: MR-1WP-DDEXRET
Copyright 2016 Dell Inc. Data Domain Extended Retention 1

This course covers installing, configuring, and managing a Data Domain system with the Extended
Retention option.
This material is intended for anyone responsible for implementing, managing, administrating and
supporting the product.
Upon successful completion of this training, you should be able to describe DD Extended Retention
features, functionality, and use cases. You should also be able to provide a high-level explanation of the
DD Extended Retention Architecture. Another objective of this course is to enable you to install, configure,
manage, and administer a Data Domain system with the extended retention option.

This module focuses on DD Extended Retention as a solution, features and benefits, system architecture,
hardware options, licensing requirements, and common use cases.

This lesson covers the need for long term retention of backup data, and the Data Domain Extended
Retention software.

There are several reasons why businesses keep certain sets of backup data for very long periods of time
such as 7 years, 30 years, or even longer. For example, a corporation or institution might need to comply
with company governance policies, industry requirements, legal mandates, and so on. Preserving
intellectual property would be another motivation.
The most common approach that businesses use to perform backup retention is to put select copies of
backup images, weekly fulls or monthly fulls to tape, and then keep it onsite or offsite to meet the retention
requirements. Tape is still a common solution for long-term retention of backup data. Data storage,
specifically long-term backup storage, is one of the last holdouts for tape media.

Tape is still common in data centers due to the perceived economic advantages. Tape cartridges are
inexpensive, but they make up just a small fraction of the total cost of ownership. Tape automation,
transport and storage space are expensive and ongoing. This is particularly true when upgrading and
replacing large tape libraries. Also, companies expend significant resources to manage the tape
infrastructure that could otherwise be creating business value.
Additionally, there are significant operational challenges with tape infrastructure. Accessing a retained file
stored on tape takes a significant amount of time, especially if it is offsite. In addition, the measured failure
rate for restoring data from tapes is relatively high. Also, offline tapes do not provide search-ability and
online information access. Finally, the risk of theft from data on tapes during transportation also poses
serious security challenges.
Data Domain has made very significant inroads in eliminating tape as the preferred media for short-term
backups for disaster recovery, but for long-term retention and despite all of its shortcomings, tape is still
the more common media.

Data Domain Extended Retention software enables long-term backup retention on Data Domain systems
without the need for tape. It is a software option only for supported Data Domain systems. Data Domain
Extended Retention software transparently incorporates two tiers of storage on a Data Domain system to
achieve cost-effective scalability while delivering the high throughput required to ingest hundreds of
terabytes of backup data.
With DD Extended Retention software, Data Domain systems are now positioned to provide cost-effective
long-term backup retention and completely eliminate tape from the infrastructure.

The two long term retention solutions for Data Domain system are Extended Retention and Cloud Tier.
However, customers can only leverage one of these.
Extended retention provides an internal tiering approach that enables cost-effective, long-term retention of
backup data on a DD system and minimizes reliance on tape. The internal two-tiered file system of a DD
Extended Retention-enabled DD system consists of an active tier and a retention tier.
Cloud Tier feature of Data Domain enables the movement of inactive data from an active tier of a Data
Domain system to a low-cost and a high-capacity object storage like a public, private, or hybrid cloud.
Conceptually, the cloud storage is treated as an additional storage tier (DD Cloud Tier) attached to the
Data Domain system, and data is moved between tiers as needed.

This lesson covers Extended Retention features and benefits, protocol support, replication flexibility, and
licensing.

The internal two-tiered file system of a DD Extended Retention-enabled system consists of an active tier
and a retention tier. The file system, however, appears as a single entity. Incoming data is first placed in
the active tier of the file system. The data (in the form of complete files) is later moved to the retention tier
of the file system, as specified by your individual Data Movement Policy. For example, the active tier might
retain weekly full and daily incremental backups for 90 days, while the retention tier might retain monthly
fulls for seven years.
The retention tier is comprised of a retention unit, which may draw storage from one or more shelves.
Note: From DD OS 5.5.1, only one retention unit per retention tier is allowed. However, systems set up
prior to DD OS 5.5.1 may continue to have more than one retention unit, but you cannot add any more
retention units to them.

Another benefit of DD Extended Retention software is it enables another tier of storage with a single
controller.
For example the DD9500 with DD Extended Retention software supports up to 864 TB of capacity in the
active tier, and the entire system can scale up to a total of 1.7 PB of usable capacity. Assuming backup
deduplication ratios that range from 10x to 50x, DD Extended Retention software could enable scalability
up to ~86 PB for long term retention of backups. Amortized across so many storage shelves, the cost of
the controller at scale becomes minimal.
DD Extended Retention provides a cost effective alternative to physical tape for long-term backup
retention eliminating the risk and cost of handling, storing, and managing thousands of tape cartridges.
The minimal day-to-day attention that Data Domain requires makes it a perfect consolidation platform.

Another unique feature that Data Domain system with DD Extended Retention software provides is the
fault isolation of retention units. Specifically, when a retention unit gets full, it is sealed off and no new data
is written to this unit. The sealed retention unit becomes a self-contained system to ensure long-term data
preservation.
If the Data Domain system experiences an issue where the retention unit is unavailable, the system
continues to operate with all unaffected components. Most other storage systems experiencing this kind of
major component failure beyond a RAID group would be completely unavailable and the customer would
likely be experiencing partial or total data loss. In the case of the Data Domain system with DD Extended
Retention, the system is up and available, and all unaffected data is accessible.
At this point, one of three things can happen:

If its a minor failure (cable, connector, fan, etc.), the devices can be reconnected or fixed, and the
retention unit would simply come back online.
If its a failure where the retention unit is no longer usable, a new unit can be seeded in the remote
site and sent back.
If the retention unit is completely lost, and no secondary disaster recovery system is present, the file
system can be removed and the system can continue to operate beyond the fault.
Fault isolation goes even further. If this catastrophe is larger in scope, and most of the system is affected a
secondary replica can be plugged into a brand new Data Domain system and all data that survived the
disaster and was salvaged will be available in the new system.
For fault isolation purposes, deduplication occurs entirely within the retention unit for DD Extended
Retention-enabled DD systems. There is no cross-deduplication between active and retention tiers, or
between different retention units (if applicable).

The active tier and retention tier in a DD Extended Retention software enabled DD system store their
corresponding logical set of storage shelves with RAID-6 protection.
The retention tier has its own deduplication index. New writes to the active tier do not check against
retention tier indices. With this design, data movement from the active tier to the retention tier can happen
transparently without any visible change in the namespace of the moved files. Externally, all the
manageable elements of the namespace look like a single Data Domain system.

Extended Retention-enabled DD systems support the protocols NFS, CIFS, DD Boost, VTL and NDMP.

Because the Data Domain system is designed as a storage of last resort in other words, a petabyte-
scale system that is the last stop for all data when it comes to protection and retention the Data Domain
system with DD Extended Retention feature also provides data integrity features and fault isolation
capabilities that ensure long-term data access and recoverability.
The system is protected by RAID 6functionality that enables the system to withstand dual disk failures
without interruption. Additionally, Data Domains Data Invulnerability Architecture continuously scrubs all
stored data, checking data integrity and preventing long-term deterioration from ever affecting the fidelity
of stored data.

Replication flexibility refers to MTree Replication and Managed File Replication where both types of
replication are supported from a source Data Domain system with DD Extended Retention license.
Replication is then enabled to a destination Data Domain system without a DD Extended Retention
license.
The destination Data Domain system must be running DD OS 5.5 or higher. This is applicable for data in
active tiers using CIFS, NFS or VTL protocols. Bi-directional replication is also supported.

Dell EMC Data Domain Encryption software allows the user to encrypt data at rest by using the compliant
libraries with standard 128-bit or 256-bit Advanced Encryption Standard (AES) algorithms. Depending on
IT security policies, the block cipher modes for the AES algorithm can be selected either as Cipher Block
Chaining (CBC) or Galois Counter Mode (GCM). DD Extended Retention is compatible with DD
Encryption and is supported on both the active tier and retention tier.
From DD OS 5.5.1, you can use the Encryption of Data at Rest feature on DD Extended Retention-
enabled DD systems, if you have an encryption license. Encryption is not enabled by default.

To reclaim space that has been freed up by data moved to the retention tier, you can use Space
Reclamation which runs in the background as a low-priority activity. It suspends itself when there are
higher priority activities, such as data movement and cleaning.
Once the retention period of data on the retention tier expires, the system will clean the space and
customers can reuse the freed space for newer data. When backup data is deleted from the retention tier,
segments referring to those files (if not referring to other files on the system) are unused and thus
available for cleaning.
Note: Sanitization is not supported for DD Extended Retention-enabled DD systems.

There are three licenses required to properly configure and enable a Data Domain system with DD
Extended Retention.
The first is the DD Extended Retention software option. This license enables the software features and
functionality for this type of configuration.
Two additional types of licensing are required to enable the hardware storage architecture of the system,
based on the system configuration. The licenses can be viewed or added using the System Manager.
There are also optional licenses concerning the locking of files for added security.
Data Domain Extended Retention leverages standard Data Domain system advantages, such as DD VTL,
DD Replicator, and DD Retention Lock.
Data Domain Retention Lock software provides immutable file locking and secure data retention
capabilities for customers to meet both corporate governance and compliance standards (such as SEC
17a-4(f)). DD Retention Lock comes in two editions Data Domain Retention Lock Governance edition
and Data Domain Retention Lock Compliance edition. Both editions provide the capability for IT
administrators to configure minimum and maximum retention periods at the MTree level and apply
retention policies at an individual file level. Files locked on the active tier will remain locked when migrated
over to the retention tier.

The shelf capacity license enables customers to incrementally add storage capacity. A separate shelf
capacity license is needed for each storage shelf, for shelves installed in both the active tier and the
retention tier. Shelf capacity licenses are specific to either an active or retention tier shelf. The appropriate
shelf capacity license is required for each new shelf added. The license is specific to an active or an
retention tier shelf and some differences remain between DD OS releases. It also differs for active and
extended retention tiers with DD Extended Retention.
The expanded-storage license allows for the upgrade of storage capacity for Data Domain systems. An
Expanded-Storage license is required to expand the active tier storage above the entry-level capacity,
depending on the controller model. An Expanded-Storage license also enables the upgrade of a 7-disk
system, such as DD160/DD620/DD640, to 12 disks.

This lesson covers Data Domain Extended Retention overview, supported hardware, data movement to
the retention tier, and scalable namespace.

This topic presents the basic architecture enabling its unique capabilities of the DD Extended Retention
Software on a Data Domain system.
Data Domain Extended Retention software transparently incorporates two tiers of storage on a Data
Domain system to achieve cost-effective scalability. Data initially lands in the active tier of the Data
Domain system that is optimized to deliver the high throughput required to ingest hundreds of terabytes of
backup data retained for operational recovery.
With DD Extended Retention software, the Data Domain system transparently incorporates a very large
second tier of storage, namely the retention tier, that is optimized for the long-term backup retention.
A periodic process, configured as a policy, moves aging data out of the active tier and into the retention
tier. It continues to do this until the retention unit is full.
One unique property of this architecture is that when full, the unit is sealed for fault isolation. The retention
unit becomes a completely self-contained unit of data preservation.
The active tier holds the short-term data for disaster recovery purposes, while the retention tier holds static
long-term backup data. This separation of data types is what allows the impressive scalability of the
retention tier, while still keeping the performance required for the active tier. With the scalability of the
retention tier, the average cost of the system per gigabyte becomes lower and lower as the system scales,
making Data Domain systems very cost-effective at scale.

Lets look at how an administrator would configure the Data Domain system enabled with DD Extended
Retention software.
The administrator can configure the data movement policy that moves data from the active tier to the
retention tier. This policy is configured for every use case or data stream coming into the Data Domain
system. This policy is based on the last-modified time of every file stored in the system and frequency of
data movement.
When the policy is enforced, data is moved out of the active tier, and into the retention unit(the unit that is
marked as ready target). Note that each file is only moved once. There is no need for files to be moved
again. This out-of-band data movement process capitalizes on more capacity-optimized compression
algorithms, so that data that is moved out of the active tier is recompressed and packed more tightly into
the retention tier as it is moved.
The data movement process can be scheduled to run at a specified time; it can be stopped, restarted, or
throttled.

A Data Domain system enabled with DD Extended Retention software presents one large, scalable file
system. The file system simply looks like a much larger Data Domain system to end users and
applications.
Of course, this file system can be completely or partially exposed as CIFS shares (for Windows), NFS
mount points (for UNIX/Linux), and VTL for open systems and IBM, through DD Boost for backup
applications, and NDMP.
An important point to note is that all incoming data is initially stored in the active tier, and it can land very
fast. Data can also be read from each tier without any read performance degradation, except when the
system approaches its maximum capacity. Data Domain systems enabled with DD Extended Retention
provide between 2 to 4 times the scalability of an equivalent Data Domain system without the DD
Extended Retention software option.
However, one trade-off for this capacity is that some of the data in the retention unit may not be readily
available in the memory of the controller. This data could be swapped out of memory, creating a slight
delay in accessing. The delay can be a matter of seconds.
By contrast, recalling a tape into a tape library can take hours or days, compared with a rare, low-
probability, less-than-a-minute delay in accessing the data in the retention units of a Data Domain system.

The DD Extended Retention software option is available on the hardware platforms shown in this table.
ES20s and ES30s provide various storage capacities depending on configuration.

This lesson covers customer profile and two use cases.

A typical customer profile for the DD Extended Retention solution might include the characteristics shown
here.

The main use case for Data Domain Extended Retention software is long-term retention of backups with
backup directly to the Data Domain system.
Data Domain systems allow easy integration using CIFS, NFS, VTL or DD Boost into existing
environments and supports all leading backup applications - including Dell EMC NetWorker, Veritas
NetBackup, IBM TSM and others.
By setting the active tier to be large, the Data Domain system can store short-term backup data for
disaster recovery purposes. The active tier needs to be sized for short-term disaster recovery. The
retention tier would be sized based on the retention policy.
Optionally, the configuration might include a Data Domain system at a secondary site for disaster recovery
purposes.

In this use case, the Data Domain system with DD Extended Retention software can be used as an
aggregation of long-term backups coming from other Data Domain systems in remote sites. Depending on
how much data is coming in, the active tier may not need to be as big as it would when backing up directly
to the system. Leveraging DD Boost software, the complexity of replicating data between systems and
implementing different retention periods on the replica can be eliminated and all management would be
done from the backup application hosting the DD Boost functionality.
Optionally, there could be a Data Domain systemin the second site for disaster recovery purposes.

This module covered DD Extended Retention as a solution, some of its features and benefits like cost
optimization, fault isolation and replication flexibility. It also discussed the basic system architecture,
hardware options, licensing requirements, and use cases.

This module focuses on how to install an extended retention system, the hardware and cabling processes,
and configuring Data Domain and data movement for Extended Retention.

Installation and configuration of Data Domain systems with Extended Retention follows the same high-
level workflow as with all other Data Domain systems.
The basic steps are:

First install hardware by defining the Data Domain system information for your site.
Then, perform initial system configuration and configure the system for data access.
Next, configure optional software.
Finally, perform the optional additional system configuration.

This lesson covers preparing the system for extended retention, SAS cabling connectors, SAS ports on
controllers, SAS ports on expansion shelves, and HBA to shelf cabling rules.

A Data Domain Extended Retention solution has many of the same components as a normal system.
However, there are some requirements, guidelines, and caveats associated with Extended Retention
systems.
If you are deploying an extended retention solution, then make sure you have a supported model Data
Domain system on hand or on order. Make sure that you know the location of the Serial Attached SCSI
High-speed Bus Adapters (HBAs) on the controller. This can differ from model to model. Also, ensure that
you know the kind of SAS connector required by the controller. New models of Data Domain systems are
upgraded and enhanced as technology improves. As a result, the connectors have a different form factor
on the newer systems.
Extended Retention requires more memory. Verify whether memory upgrade kits have been ordered if
needed.
There must be three types of licenses installed on the controller:
The first is the Data Domain Extended Retention license. This license enables the Extended retention
feature on the controller.
The next two license types are for disk capacity. You will need to install enough Data Domain Shelf
Capacity-Active-Tier licenses to support the amount of storage you wish to have in the active tier. You
will also need enough Data Domain Shelf Capacity-Archive-Tier licenses to support the storage space
you wish to allocate to the retention tier.
Also, when planning for extended retention pay close attention to the components:
Expansion Shelves
Extended retention currently supports two models of expansion shelves. These two models have different
flavors in terms of capacity and disk drive type. Make sure to specify an expansion shelf model that is
supported by the controller. Because some expansion shelves support SATA and SAS disk drives, you
must not only verify the expansion shelf that is supported by the controller, but that the drive type is also
supported.
Finally, you need to verify the location and type of SAS ports used by the expansion shelf.

Cables:
Cables are required to connect the controllers and expansion shelves. You need two types of cables. The
first type connects the controller to an expansion shelf. This cable must have connectors appropriate for
each device. Also, if the expansion shelves are not directly next to the controller, you may need a longer
cable.
You will also need cables to chain expansion shelves together. These cables require SAS connectors that
are appropriate for the expansion shelves. These cables are usually short because expansion shelves
tend to be installed right next to each other in the equipment rack.
Others:
Finally, you need to consider the number of racks needed for the equipment, the electrical power
consumed by the total solution, and the environmental controls such as air conditioning.

This slide shows the Extended Retention requirements for the Data Domain controllers such as DD860,
DD990, DD4200, DD4500 and DD6800.
Extended retention models differ from the standard controllers. In that they require additional RAM and
SAS HBAs.

This slide shows the Extended Retention requirements for the Data Domain controllers such as DD7200,
DD9300, DD9500, and DD9800.
Extended retention models differ from the standard controllers. In that they require additional RAM and
SAS HBAs.

Let us define a few terms that will be used when discussing Extended Retention, SAS cabling, and
expansion shelves.
The first term is set. Set describes a group of interconnected expansion shelves.
The second term is defined as loop or chain. Loop or chain refers to SAS cabling consisting of a primary
and secondary path.
And the third term is defined as string. A string is a single SAS cabling path. Sometimes it is used to
describe a cabling loop. So pay attention to the context in which this term is used.

The Data Domain system supports three types of Serial Attached SCSI (SAS) cable connectors. The
connectors are SFF-8644 (HD Mini SAS) and SFF-8088 (Mini SAS).
The SFF-8644 connector is required by newer Data Domain controllers. This includes the DD4200,
DD4500, DD6800, DD7200, DD9300, DD9500 and DD9800 controllers.
The SFF-8088 connector is required by the ES30 and DS60 expansion shelves. It is also required by
DD860 and DD990 Data Domain controllers.

There are SAS High-speed Bus Adapters (HBAs) installed in controllers that support expansions shelves.
Each of the SAS HBAs has at least two ports. One set of shelves is supported by two SAS ports.
One SAS HBA Port connects to the AH SAS Port on the first Expansion shelf in the set.
Another SAS HBA port connects to the BH SAS Port on the last expansion shelf in the set. If more than
one SAS HBA is installed in the system, then use a port on one HBA to connect to the AH port on an
expansion shelf, and a port on another HBA to connect the BH port on another expansion shelf.

Normally, the communication from a Data Domain system controller to a set of expansion shelves is
routed through one SAS HBA port. The other SAS HBA port connected to the same set is in a standby
state.
A cable break or SAS port failure can cause a loss of connectivity from the Data Domain system controller
to the expansion shelves.
If there is a cable or port fault, then DD OS reroutes communication to the expansion shelves affected by
the break through the other SAS HBA port connected to the same set of expansion shelves.

A faulty port on an expansion shelf can also result in a loss of connectivity.
If a port on an expansion shelf fails, then DD OS reroutes communication to the expansion shelves
affected by the fault through the other SAS HBA port connected to the same set of expansion shelves.

A SAS HBA fault causes every device in its associated connectivity chain to become inaccessible.
DD OS can re-route SAS connectivity through another HBA if there is one available and it is connected to
the same set of expansion shelves.

When planning how to allocate SAS ports on the Data Domain system controller, you need to answer a
few questions: Which SAS ports will connect to the Expansion Shelf SAS Interface A? Which SAS ports
will connect to the Expansion Shelf SAS Interface B? Which ES set is controlled by each port? How can
this all be done so that redundancy is maintained?
Before planning how to use the controllers SAS ports, check the documentation. The installation guides
have recommended deployment layouts that may fit your need. If none of the recommended layouts work,
then follow these steps to assign the Data Domain system controller's SAS ports.
1. First, identify the slot numbers into which the SAS interfaces are installed. When planning, keep the
numbering oriented in the same way as on the actual controller. This helps to avoid confusion.
2. Next, identify the port numbering scheme. In this case, the ports are numbered as 0 to 3 from bottom
to top.
3. Now, divide the ports into groups of two.
4. Next, reserve the lower-numbered port to the expansion shelf's SAS interface A. The higher-
numbered ports are to be connected to the expansion shelf's SAS interface B.
5. Now, identify the expansion shelf sets to be connected to the lowest-numbered ports. If possible,
assign the sets from left to right. These ports will be connected to the expansion shelves SAS
Interface A.
6. Finally, identify the expansion shelf sets to be connected to the next-lowest-numbered ports. If
possible, assign the sets from left to right starting with the second interface. By doing this, you provide
redundancy that protects against service interruption caused by the loss of an HBA. These connect to
the expansion shelves SAS Interface B.

The diagram in the slide provides an example of how an expansion port set may be connected to a
DD9500 or DD9800 Data Domain system controller.
When a DD9500 is configured for extended retention, it has SAS HBAs in slots 2, 3, 6, and 9.
Ports are identified as 3, 2, 1 and 0 from top to bottom.
Note: The graphic in the slide only shows the rear bottom-half of the controller.

The diagram on the screen provides an example of how an expansion port set may be connected to a
DD6800 or DD9300 Data Domain system controller.
When a DD6800 or DD9300 is configured for extended retention, it has SAS HBAs in slots 2 and 7.
Note: The graphic on the screen only shows the rear bottom-half of the controller.

The diagram in the slide provides an example of how an expansion port set may be connected to an
extended retention version of the DD4200, DD4500, or DD7200 Data Domain system controller.
When a DD4200 or DD7200 is configured for extended retention, it has SAS HBAs in slots 5, 6, 7, and 8.
Note: The graphic in the slide only shows the rear bottom-half of the back of the controller.

The diagram in the slide provides an example of how an expansion shelf set may be connected to the
extended retention version of the DD990 Data Domain system controller.
When a DD990 is configured for extended retention, it has SAS HBAs in slots 9, 8, 5, and 4.
Ports are identified as A, B, C, and D from top to bottom.

The diagram in the slide provides an example of how an expansion shelf set may be connected to the
extended retention version of the DD860 Data Domain system controller.
When a DD860 is configured for extended retention, it has SAS HBAs in slots 1, 2, and 3.
Ports are identified as D, C, B, and A from left to right.

The SAS ports on the DD ES30 Expansion Shelf useSFF-8088 (Mini SAS) connectors.
There are four connectors on an expansion shelf:
Two SAS connectors are mounted on Control Panel A, and two are mounted on Control Panel B.
The left-most connector on Control Panel A is a host connector. The host connector can be identified by a
circle symbol next to the port. Following the cable connected to this port should lead back to the controller.
The right-most connector on Control Panel A is an expansion connector. Following the cable connected to
this port leads to the next expansion shelf in the chain and away from the controller.
The right-most connector on Control Panel B is a host connector. Following the cable connected to this
port should lead back to the controller.
The left-most connector on Control Panel B is an expansion connector. Following the cable connected to
this port leads to the next expansion shelf in the chain and away from the controller.
The ES30 shelves use two circle markings () to identify a SAS HOST port. Two diamonds () identify
SAS EXPN ports.

The DS60 Expansion Shelf uses SFF-8088 (Mini SAS) connectors. It contains two Link Controller Cards
(LCC). The left-most controller card is LCC B and the right-most controller card is LCC A.
There are four SAS ports on each LCC. They are numbered as 3, 2, 1, and 0 from left to right. Data
Domain systems only use ports 0 and 2. Ports 1 and 3 are not supported and should contain a rubber
plug to prevent their inadvertent use.
Since no port is identified as the host or expansion port, consider port 0 to be the host port, and port 2 to
be the expansion (Expn) port.
Following the chain of cables connected to the host port leads back to the controller. Following the chain
of cables connected to the Exp'n port leads to the next expansion shelf in the chain and away from the
controller.

When planning for HBAs, pay close attention to adding shelves and cable length rules.
Adding Shelves:
The cabling and racking are designed so that shelves are added from the bottom up in a rack.
Cabling between adjacent shelves in a string is done with the 1 meter SAS cables that are delivered with
the shelves.
One cable runs from the B Controller Expansion port of the lower shelf to the B controller Host port of the
next higher shelf in the string.
Then a second cable runs from the A Controller HOST port of lower shelf to the A controller Expansion
port of the next higher shelf.
When adding shelves to an existing string, the cable is moved from the B controller Host port to the new
shelf. Then another 1 meter cable is added shelf-to-shelf.
Cable Lengths
The shelves are labeled as Vn.m, where V is volume numbered with n as the number of the string, and
the m as the number of the shelf in the string. For example, V3.2 refers to the second shelf in the third
string.
Please note that the cable length required for each HBA port to connect to the correct storage shelf port.
Beginning with the fourth string of expansion shelves, the required cable length increases from 2 to 5
meters.

This lesson covers an initial configuration of Extended Retention feature using Data Domain System
Manager.

Configuring Data Domain Extended Retention system is similar to configuring a non-extended retention
system with a few added or modified steps.

For systems shipped with DD OS 6.0, licenses have to be added and removed using ELMS. For
uploading ELMS licensing in the System Manager, go to Administration > Licenses and select Add. In the
Add Licenses window:
1. Select ELMS for the License type
2. Select a valid ELMS file
3. Click Apply
4. View the ELMS Licenses

For systems upgraded to DD OS 6.0 from 5.6 or 5.7, we use the legacy licensing process. The first thing
to configure for Extended Retention on a Data Domain system is to add the licenses appropriate for the
configuration. The same process can be used to add the Data Domain Extended Retention, Data Domain
Expansion Storage, Data Domain Shelf Capacity-Active Tier, and Data Domain Shelf Capacity-Archive
Tier licenses.
The process to add Extended Retention-related licenses are:
1. Select Administration > Licenses.
2. Click Add Licenses.
3. Enter one or more licenses, one per line, pressing the Enter key after each one.
4. Click Add when completed. If there are any errors, a summary of the added licenses and those not
added because of the error are listed. Select the erroneous License Key to fix it.
Every shelf in a DD Extended Retention-enabled DD system must have a separate capacity license.

Sometimes the Extended Retention-related licenses need to be removed. To do so, the process includes:
1. Navigate to the Administration > Licenses page.
2. Select the license you wish to remove.
3. Select Delete Selected Licenses.
4. Select OK after reading the warning dialog box and verifying the correct license that has been
selected.

If the file system has not been created on the Data Domain system or has been destroyed, then an
Extended Retention file system can be created through this process which includes:
1. Navigate to the Data Management > File System page in DDSM.
2. Select More Tasks > Create File System. The file system create dialogue box is displayed.
3. Select the option to Create a DD Extended retention file system.
4. Select Next. A new dialogue box appears.
5. Choose the option to select the size of the retention unit or Skip the configuration of the retention unit.
6. Select the option to enable the file system after it is created.
7. Select Next.

8. Verify the summary information if it is correct and select Finish.
9. After the file system is created, click OK.
The demonstration in the slide has shown the process which includes:
enabling the DD Extended Retention feature
creating the archive tier and retention tiers and,
allocating storage to both of them.

Now that the Data Domain system is licensed and the Extended Retention file system has been created, it
is time to configure storage. This section will add unallocated storage to the active tier or the retention tier.
Of course, the storage expansion shelves must be correctly cabled to the controller for this process to
work:
1. Navigate to the Hardware > Storage page in DDSM.
2. Select the Overview tab.
3. Select Configure Storage. The Configure Storage dialogue box is displayed.
4. Select the Expansion shelf to assign either to the active tier or the retention tier. If the Expansion
Shelves listed in the available storage area cannot be selected, then verify the appropriate capacity
licenses that have been installed.
5. Select the tier to which the expansion shelf should be assigned. The choices are Active Tier and
Retention Tier.
6. Select the Add to Tier button. The expansion shelf item is moved from the Available Storage list to the
target tier list.
7. Select OK. The system assigns the storage device to the appropriate tier.
8. Select OK if a warning is displayed about the need to expand storage. Add the expanded storage
license and expand the storage as needed.

The Active Tier storage status can be reviewed by:
1. Navigating to the Hardware > Storage page in DDSM.
2. Selecting the Overview tab.
3. Selecting the plus sign next to the Active Tier label to expand the section.

The Active Tier status section shows the disks in use along with their associated disk groups. Also shown
are the disks not in use.

You can review the Retention Tier storage status by following this process.
1. Navigate to the Hardware > Storage page in DDSM.
2. Select the Overview tab.
3. Select the plus sign next to the Retention Tier label to expand the section.

The Retention Tier status section shows the disks in use along with their associated disk groups. Also,
shown are the disks not in use.
The Disk Group column provides the name of the disk group that was assigned by the file system (for
example, dg1). A disk group identifies the disks that are part of a RAID. The disks in a disk group are not
restricted to a single expansion shelf, but may include disks from several shelves.
Disks Not In Use identifies disks that are recognized by the system but not assigned to the active tier or
retention tier.

This lesson provides an overview of how data is moved from the active tier to the retention tier. It also
covers how to schedule when data movement is performed, under which conditions, and how to manage
the movement.

The data movement feature on an extended retention system relocates data from the active tier to the
retention tier for long term storage.
The Data Movement process can be started manually or automatically through the use of Data Movement
policies.
Data Movement uses four attributes to govern the operation of the Data Movement process.
The data movement policy defines the age at which files are moved from the active tier to the retention
tier. Age refers to the amount of time since the file was last modified, not the amount of time since the file
was created. You may set a global value for all files in the system, and a value specific to an MTree. If
there is no threshold value assigned to an MTree, then the global threshold value is used.
A schedule is also part of the policy. This schedule determines when the data movement process is run.
Because the data movement process and the file system cleaning process are both resource intensive,
and to avoid these two processes from competing for scarce system resource, the policy can direct
cleaning to run right after the data movement process finishes.

To start the Data Movement process manually, follow these steps:
1. Using DDSM, navigate to the Data Management > File System page.
2. Click the Start button associated with the Data Movement Status line on the screen. The Start Data
Movement dialogue box appears.
The File System page for a DD Extended Retention system shows the status of data, as it is moved
from the active to the archive tier. The target unit in the archive tier is the recipient of the data. The
status includes when the data movement is completed, the number of files copied, and the amount of
data copied in GB.
Clicking the Data Movement Status Start button starts the data movement based on the defined data
movement policy.
If cleaning is already in progress, starting the data movement schedules the data movement to run
after the clean completes.
The data movement status is shown in the File System tab. The Start button is replaced by a Stop
button.
Clicking Stop stops the data movement. Click OK in the Stop Data Movement dialog box to confirm.
3. Click Start to proceed.
4. Click OK when the start Data Movement process completes.

The data movement policy is applied to all user data on the system. However, the policy's threshold value
can be overwritten on a per MTree basis. To create a Data Movement policy, follow this process:
1. Using DDSM, navigate to the Data Management > File System page.
2. Select the Configuration tab.
3. Scroll to the bottom of the page.
4. Click Edit to the right of Data Movement Policy. The Data Movement Policy dialog box opens.
5. Specify a system-wide default File Age Threshold value greater than or equal to 14 days.
6. Specify when data movement should take place. Dell EMC recommends you to schedule data
movement and file system cleaning every 14 days.
7. In the Data Movement Throttle section, specify the percentage of available resources, the system
uses for data movement. A value of 100% indicates that data movement will not be throttled.
8. Finally, it indicates if file system cleaning should be run after data movement completes. Dell EMC
recommends this option to be enabled and it is enabled by default.
9. Select OK.

The data movement policy throttles, schedules, and starts file system cleaning after data movement
settings are global. They are applied to all data on the system. However, the data movement feature
allows you to overwrite the default threshold setting and apply a new setting on a per MTree basis. To do
so, the process incudes.
1. Using DDSM, navigate to the Data Management > MTree page.
2. Select the target MTree from the MTree list.
3. Select the Summary tab.
4. If necessary, scroll down to the Data Movement Policy section. The current file age threshold
assigned to the target MTree is displayed.
5. Select Edit to change the threshold value for the target MTree. The Modify Age Threshold dialogue
box is displayed.
6. Configure the File Age Threshold. A value of None causes this MTree to be ignored by the Data
Movement process and no data is relocated from the Active Tier to the Retention Tier.
7. Select OK.

This slide shows an example of a data movement policy with an MTree-specific threshold.
The data movement policy is applied to all MTrees on the system. For the Daily-BU MTree, this works fine
because it holds incremental backup files whose worth only lasts until the next full backup. Because the
value of the data is short-lived, there is no need to retain these files for an extended period of time. The
global threshold value of None ensures that the files in the Daily-BU MTree will never be moved to the
retention tier.
The Full-BU MTree holds full backup files that are created every week. The data movement policy is also
assigned to this MTree. Unfortunately, the global threshold setting will not work for this MTree because
there is a need to retain the full backup files for an extended period of time. To address this issue, an
MTree-specific threshold of 14 days is created to override the threshold in the data movement policy.
A threshold of 14 days ensures that two full backups will be available on the active tier, while older full
backups will be on the retention tier.
Note: Ensure that the active tier is large enough to hold backup

The example in this slide shows that the data cannot be separated into Daily-BU and Full-BU MTrees. The
retention period of daily-incremental backups is eight weeks and the retention period of weekly full
backups is three years. In this case, set the age threshold to nine weeks. If it sets lower, then daily
incremental data would be moving as soon as it is to be deleted.

Avoid these common sizing errors:
Setting a data movement policy that is overly aggressive in which data is moved too soon.
Setting a data movement policy that is too conservative. Once the active tier fills up, no more data
can be written to the system.
Defining an undersized active tier such that the active tier fills up prematurely.
Caution: Avoid creating an overly aggressive movement policy to compensate for an undersized active
tier. Space is not always reclaimed in the archive tier. So moving files that are to be deleted or updated too
soon into the archive tier results in wasted space. When a unit is sealed, space can no longer be
reclaimed until all of the data in the archive unit expires.
When planning for data movement, pay close attention to the guidelines:
Cleaning:
Cleaning is performed on the active tier either as scheduled or by default immediately after files have been
moved from the active to the retention tier.
Snapshots:
Be aware of the caveats related to snapshots and file system cleaning:
Files in snapshots are not cleaned, even after they have been moved to the retention tier. Space cannot
be reclaimed until the snapshots have been deleted.
Dell EMC recommends the File Age Threshold for snapshots to be set to the minimum of 14 days.

The Data Movement Packing feature compacts data in the target partition after every time the Data
Movement process runs. This feature is enabled by default.
When this feature is enabled, the overall compression of the retention tier improves, but there is a slight
increase in migration time. The process to determine if this feature is enabled includes:
1. Navigate to Data Management > File System page with DDSM.
2. Select the Configuration tab.
3. The current value for Packing data during Retention Tier data movement is shown in the slide. The
acceptable values are either Enabled or Disabled.

The Space Reclamation feature on the retention tier enables customers to recover space for expired data
on the retention tier, and allows the reclaimed space to be used for storing new data. You can reclaim
space from deleted data in the retention tier by running space reclamation. Space reclamation also occurs
during file system cleaning. The process to manage the space reclamation feature includes:
1. Select Data Management > File System. Just above the tabs, Space Reclamation Status shows the
amount of space that is reclaimed after deleting data in the retention tier.
2. Select the start button to enable space reclamation. If space reclamation is disabled, then a Start
button is displayed. If it is enabled, then Stop and Suspend buttons are displayed. If space reclamation
is in a suspended state, then Stop and Resume buttons are displayed.
3. After the warning is displayed, click Start in order to proceed.
4. After space reclamation starts, select More Information for details on the status of the feature.
5. After reviewing the Space Reclamation Detailed Information dialogue box, select Close.

This module covered installation and configuration of Data Domain extended retention systems, their
hardware and cabling processes, and data movement configuration.

This module focuses on the Data Domain Operations such as garbage collection, compression, replication
and disaster recovery.

This lesson covers file system cleaning in the active tier and space reclamation in the retention tier of a
Data Domain Extended Retention system.

In a Data Domain Extended Retention system, file system cleaning is performed on the active tier either
as scheduled or by default, immediately after files have been moved from the active to the retention tier.
Files in snapshots are not cleaned, even after they have been moved to the archive tier. The space cannot
be reclaimed until the snapshots have been deleted. Set the retention for snapshots to less than two
weeks.

The space reclamation feature on the retention tier enables customers to recover space for expired data
on the retention tier, and allows the reclaimed space to be used for storing new data. Space reclamation
occurs as a background process that can be suspended, paused, re-started and is applicable to data
already stored on the retention tier. It has lesser priority over cleaning.
If space reclamation is running and if cleaning is manually started, space reclamation will be pre-empted
for the duration of cleaning and will resume once the higher priority activities complete.

Both CLI and the System Manager provide capabilities to start, stop, suspend, or resume the process and
report high level detailed status.
Note that once started, Space Reclamation will run until stopped. Also, since Space Reclamation is an
intensive process that uses a lot of system resources, it may be suspended from time to time by the
system to accommodate higher priority processes.

To take advantage of the space reclamation feature, Dell EMC recommends that you schedule data
movement and file system cleaning every two weeks. Also, update existing data movement schedules to
occur every two weeks. Schedule cleaning to run after data movement completes. Do not schedule
cleaning separately. Before changing the data movement schedule, provision storage in the active tier to
hold one additional week of data.

This lesson covers global compression, local compression and its guidelines in active and retention tier of
a Data Domain Extended Retention system.

Data Domain compresses data at two levels: global and local.
Global compression (deduplication) is the process by which Data Domain system removes redundant
data. It uses a SISL (Stream Informed Segment Layout) architecture to deduplicate data. Local
compression is the process of reducing the amount of space taken by data. It uses the compression
algorithms lz, gz, and gzfast. The default local compression setting is lz.

In Data Domain Extended Retention system, the storage is separated into two tiers; the active tier, and the
retention (archive) tier. They are two independent deduplicated domains. For fault isolation purposes,
deduplication occurs entirely within the retention unit for DD Extended Retention-enabled systems.
There is no cross-deduplication between active and retention tiers. Users can only inject data to the active
tier. Later using the data-movement feature the data can be migrated from the active tier to the archive
tier.

Local compression in the active tier uses the compression algorithms lz, gz, or gzfast. The default local
compression setting is lz. The retention tier by default uses the gz local compression algorithm to store
data, meaning it generally achieves higher overall data compression ratio when compared with the active
tier. Gz compression achieves 10% to 20% less than lz on average. However, some data sets achieve
much higher compression. Note that this causes an increase in resource utilization and decrease in
performance when reading data from the retention tier.
In the retention tier, using the data movement packing feature, data is compacted in the target partition
after every file migration. This feature is enabled by default. When this feature is enabled, the overall
compression of the retention tier improves, but there is a slight increase in migration time.
The local compression algorithm for subsequent data movement to the retention tier can be modified.

Both CLI and the System Manager provide capabilities to configure local compression types in active and
retention tier. Note that when modifying the local compression algorithm of the retention tier it will be
applied on subsequent data movement to the retention tier. In the active tier, it will be applied to
subsequent data written to active tier.

This lesson covers MTree Replication, DD Boost Managed File Replication, Collection Replication, and
Directory Replication.

Replication typically consists of a source DD system (which receives data from a backup system) and one
or more destination DD systems. Supported replication types depend on the data to be protected:
To protect data on a system as a source, a DD Extended Retention-enabled system supports collection

replication, MTree replication, and DD Boost managed file replication.
To protect data from other systems as a destination, a DD Extended Retention-enabled system

supports collection replication, MTree replication, DD Boost managed file replication, and directory
replication.

The basic topology for MTree replication with DD Extended Retention is depicted on this slide. In this
example, there is bi-directional replication between System A and System B and Unidirectional replication
from System C and System B. No data migration for MTrees are involved in ongoing MTree replication.
Note that a Data Domain System with DD Extended Retention license can be the destination for MTree
replication from any DD system.
This enables you to protect the data within the active tier of one system by replicating it to the active tier of
another controller with DD Extended Retention.
Note that although you can use MTree replication to protect data for certain MTrees on a controller with
DD Extended Retention, data movement must not be configured for those MTrees. This is applicable only
for those MTrees that need to stay only in the active tier.
Bi-directional replication is supported between systems that have the DD Extended Retention license. This
is applicable for data written via CIFS, NFS and VTL.

The basic topology for DD Boost managed file replication with DD Extended Retention is depicted in this
slide. In this example, there is bi-directional replication between System A and System B and
unidirectional replication from System C to System B. Data migration in the HR storage unit on System A
does not force data migration on the passive HR storage unit System B. Data migration on the passive HR
storage unit System B happens independently. Data migration can be configured on the passive Legal
storage unit on System B.
With DD Boost managed file replication, supported topologies are one-to-one, many-to-one, bi-directional,
one-to-many, and cascaded.
Note that with DD Boost 2.3 or later you can specify how multiple copies are to be made and managed
within the backup application.

The basic topology for collection replication with DD Extended Retention is depicted in this slide. In this
example, Data is written to System A and is stored in the Active tier and replicated to the Active tier of
System B. In system A, Data is moved to the Retention Tier as per policy. Data is then replicated to
Retention unit of System B.
Collection replication takes place between corresponding active tier and retention tier. If the active tier or
retention tier at the source fails, the data can be copied from the corresponding unit at the remote site onto
a new unit, which is shipped to the customer site as a replacement unit.

The requirements for setting up collection replication on systems with DD Extended Retention include the
following:
Both the source and destination systems must be configured as controllers with DD Extended
Retention enabled.
The file system must not be enabled on the destination until the retention unit has been added and
replication configured.
Only unidirectional replication is supported.
Both the source and destination systems need to have the same DD OS version.
Data migration policies are configured on the Source system.

This chart shows the basic topology for directory replication with DD Extended Retention. Start by
ingesting data to a directory on both System A and System B and then unidirectional directory replication
from System A and System B to System C. Set the data movement policies on System C for that MTree to
move to retention tier. There is no migration for the /backup directory data when involved in ongoing
directory replication.
With directory replication, the system with DD Extended Retention is used as a replication target and
supports one-to-one and many-to-one topologies from any Data Domain system.

Requirements for directory replication on systems with DD Extended Retention include the following:
Bidirectional directory replication is not supported.
A DD Extended Retention system cannot be a source of directory replication. It can only be a

destination.
Directory replication data sets cannot be moved to the archive tier (except for bulk ingest use case).

1. To review the configuration of the replication feature, navigate to the Replication > Automatic >
Summary tabs. The replication summary table provides you high-level information about the
configuration of each context.
2. Selecting a context causes the system to display detailed information about that context in the
Detailed Information section of the screen.

Remember to scroll down to see all detailed information pertaining to the selected context.
Since collection, MTree, and directory contexts have different requirements, the detailed information
shown- changes depending on the context type.

This lesson covers disaster recovery configurations, granular collection replication, and overall recovery
strategy.

A system with DD Extended Retention is equipped with tools to address failures in different parts of the
system.
A system with the DD Extended Retention software option is designed to remain available to service read
and write requests when a retention unit is lost. The file system may not detect that a retention unit is lost
until the file system restarts or tries to access data stored in the retention unit. After the file system has
detected that the retention unit is lost, it returns an error in response to requests for data stored in that unit.

1. If the active tier and the retention unit are lost and there is no replica available, contact Dell EMC
Support for assistance.
2. If data is lost and cannot be recovered from a replica, contact Dell EMC Support for assistance.

For customers needing a disaster recovery configuration to keep a second copy of all stored data in a
separate system that is protected from disasters and catastrophes in a remote site, Dell EMC Data
Domain Replicator software provides simple, fast, robust WAN-based disaster recovery for the enterprise.
It offers numerous replication types and policies and also supports a wide variety of topologies to meet the
needs of various deployments.
Between two Data Domain Extended Retention systems:
1. MTree replication can be configured between MTrees in Active Tier.
2. DD Boost Managed File Replication can be configured between storage units (SU).
3. Collection replication can be configured between the two Data Domain Extended Retention Systems.

In a failure situation, perform recovery actions in the following order:
Restore connection between the system controller and storage.
If the system controller is lost, replace it with a new system controller.
If there is loss of data and a replica is available, try to recover the data from the replica.
If a replica is not available, limit any loss of data by leveraging the fault isolation features of the DD
Extended Retention through Dell EMC Support.

The new source must be configured as a DD Extended Retention system. The file system must not be
enabled on the new source until the archive unit has been added and replication recovery has been
initiated.
1. Install the replication license on the new source.
2. Reset the authentication key on the destination.
3. Reconfigure replication on both the new source and destination.
4. Initiate recovery on the new source. The file system must not have been enabled on the new
source before this step.
5. Check the replication status.

This module covered configuration and monitoring of garbage collection process such as active tier
cleaning and space reclamation on retention tier. It also covered compression, replication types and
disaster recovery on an Data Domain Extended Retention system.

This module focuses on the requirements for upgrading Data Domain Extended Retention system
software. It also explain the upgrade procedures for Data Domain systems with Extended Retention.

This lesson covers the general requirements, caveats, and restrictions.

The first step in the upgrade process is to verify if the third-party applications that are used to manage
backups and interact with the Data Domain system are compatible with DD OS 6.0. This includes backup
applications, DD Boost-enabled applications, and archive applications.
There are number of documents available to assist in this endeavor. They include Data Domain Backup
Compatibility Guide, Data Domain Boost Version Compatibility Guide, and Data Domain Archive Product
Compatibility Matrix.
For more information, refer to Data Domain Software Compatibility website link as mentioned:
http://compatibilityguide.emc.com:8080/CompGuideApp/

The next step in the upgrade process is to verify the Data Domain system controller's compatibility with
the Extended Retention feature on DD OS 6.0.
As shown in the slide, DD OS 6.0 supports nine models for use with Extended Retention. The Extended
Retention capabilities must be migrated to a supported controller, if the current ER-enabled controller is
not listed in the compatibility matrix.
Also, the Data Domain system controller must have the appropriate amount of RAM as well as the
required number of Serial Attached SCSI (SAS) modules.

The next step is to verify the DD OS upgrade path. In order to upgrade to DD OS 6.0, the target system
must be running DD OS version 5.6.1.x, later releases of 5.6 or 5.7.x. This restriction is due to RPM
signing. While upgrading DD OS, it supports the ability to upgrade two release families at a time.
If the Data Domain system controller is running an earlier version of DD OS, then a multistep upgrade may
be required. In order to upgrade to release 6.0 from a release family earlier than 5.6, you will need to
upgrade in steps.
This slide shows some possible upgrade paths.
Be careful to review the release notes and upgrade instructions for every upgrade step.
For more information, visit the EMC Support site at http://support.emc.com/product.

Finally, you need to verify if the Data Domain system configuration is compatible with the Extended
Retention feature on DD OS 6.0.
If the configuration uses the replication feature, then few configuration parameters need to be verified.
First, verify that the system is not the replication source in a directory replication pair. An ER-enabled
system can only be a directory replication destination.
Next, verify if the collection replication is paired with a system that is also ER-enabled. Collection
replication on an ER-enabled system can only be used if both the source and destination are ER-enabled
systems.
Now, verify if replication parameter low bandwidth and optimization (LBO) are disabled on all contexts.
LBO is not supported on ER-enabled systems.

This lesson covers how to convert a Data Domain file system to a file system with the DD Extended
Retention Software option, and upgrading a DD Controller with the DD Extended Retention.

These are the steps to convert standard Data Domain to ER-enabled Data Domain:
1. Navigate to the Administration > Licenses page.
2. Verify if the Extended-Retention license is installed.

3. Use DDSM to navigate to the Data Management > File System page.
4. Select the More Tasks > Enable DD Extended Retention option. This option is available only if the
file system has not already been configured for DD Extended Retention. Be aware that after DD
Extended Retention has been enabled, it cannot be disabled without destroying the file system.
a. If the file system is already enabled (as a non-DD Extended Retention system), then you are
prompted to disable it. Click Disable to do so.
b. If prompted to confirm that you want to convert the file system for use by DD Extended Retention,
then click OK.
After a file system is converted into a DD Extended Retention file system, the file system page is
refreshed to include information about both the tiers, and there is a new tab labeled Retention Units.

5. Navigate to the Data Management > File System page.
6. Select the Summary tab.
7. Verify compression statistics that are displayed for the Active and Retention tiers.
8. Verify that there is a Retention Units tab.

The upgrade process is initiated by the system upgrade start command which must specify an rpm
file in the /ddvar/releases directory.
If the active tier is available, then the process upgrades the active tier and the retention unit, and puts the
system into a state that the previous upgrade has not been verified to be completed. This state is cleared
by the file system after it is enabled and verified that the retention tier has been upgraded. A subsequent
upgrade is not permitted until this state is cleared.
If the active tier is not available, then the upgrade process upgrades the system chassis and places the
system into a state where it is ready to create or accept a file system.
If a retention unit becomes available after the upgrade process has finished, then the unit is automatically
upgraded when it is plugged into the system or at the next system start.

This module covered the requirements to upgrade DD Extended Retention system software. It also
explained the upgrade procedures for Data Domain systems with Extended Retention.

This course covered DD Extended Retention features and functionality and its use cases. It also provided
a high-level explanation of the DD Extended Retention Architecture. It explained how to install, configure,
manage, and administer a Data Domain system with the extended retention option.
This concludes the training.

Data Domain Fundamentals
Copyright 2016 Dell Inc.

Course Overview
This course provides an introduction to Data Domain system. It includes an overview of the
Description Data Domain architecture, features, and functionality.
This course is intended for professionals who will be positioning, designing, deploying,
Audience managing and supporting a solution using Data Domain systems. It is also suitable for
anyone seeking to learn the basics of the Data Domain Operating System (DD OS).
Upon completion of this course, you should be able to:

Discuss the Data Domain solutions
Summarize the product architecture
Objectives List hardware and software options
Describe features and hardware/software modules
Describe management options, capabilities, and support features
Copyright 2016 Dell Inc

Module: Introduction to Data Domain
Upon completion of this module, you should be able to:
Describe Data Domain solution and its benefits
Describe common hardware features of a Data Domain system
Explain ELMS licensing features

Data Domain System Overview
This lesson covers the following topics:
Backup environments without Data Domain
Introducing Data Domain systems
Backup environments with Data Domain
Integration with existing environments

Backup Environments without Data Domain
Data Center Data Recovery Site

Challenges Clients
Primary
Storage
Speed DB 2
1 4
Backup Restore
Capacity Management Process
Server
Unix
Tape Transport
Tape
Cost Library
Servers 3

Introducing Data Domain Systems
Protection Storage for Backup and Archive Data
Scalability and Performance

Reduces storage required by 10-30x
Protects up to 86 PB of logical capacity in a single system
Completes backups fasterup to 59 TB per hour
Seamless Integration
Integrates with leading backup, archiving and enterprise applications
Reliable Access and Recovery

End-to-end data verification, fault detection, and self-healing
Efficient Resource Utilization

Sends only deduplicated data across the network to reduce bandwidth
required

Backup Environments with Data Domain
Clients Data Center Data Recovery Site
Backup
Management Primary Disaster Recovery
Server Data Domain System Data Domain System
DB
Unix
WAN
Servers

Integration with Existing Environments
Backup Applications
NFS CIFS
NDMP DD Boost
Archive Applications Ethernet
Replication
Fibre Channel
Virtual Tape
Library(VTL) Primary Disaster Recovery
Enterprise Applications Data Domain System Data Domain System
DD Boost

Common Hardware Features
Head unit and expansion shelves
Ports and connectivity
Hardware redundancy

Head Unit and Expansion Shelves
Rack mountable in 4-post racks
Hot-swappable disks, redundant hot-swappable fans, and

redundant hot-swappable power modules
DIMM modules for RAM
Battery-backed NVRAM card or Persistent RAM (PRAM)
Serial port and copper Ethernet ports
Front panel LEDs that provide system status indicators

Ports and Connectivity
Keyboard, monitor, and mouse connections
Serial console connection
Ethernet connections
Fiber channel connections

Hardware Redundancy

Current Data Domain Systems
Data Domain current hardware models
Mid range models
High-End DD9800 system
DD9500 and DD9800 comparison
Expansion shelves
SSD and FS15 shelf

Data Domain Current Hardware Models
Small Enterprise/ROBO Midsize Enterprise Large Enterprise

Speed (DD Boost): 4.2 TB/hr (16TB), 16.92 TB/hr (96 TB)
Data Domain
Virtual Edition Usable capacity: .5 TB 96 TB, Logical capacity: Up to 4.8 PB
Midsize Enterprise
Small Enterprise
/ROBO
DD2200 DD6300 DD6800 DD9300 DD9800
Speed (DD Boost) 4.7 TB/hr 24 TB/hr 32 TB/hr 41 TB/hr 68 TB/hr
Speed (other) 3.8 TB/hr 8.5 TB/hr 14 TB/hr 20 TB/hr 31 TB/hr

2.814.4 PB1 7.236 PB1 1050 PB1
Logical capacity 40860 TB 1.88.9 PB
8.443.2 PB2 21.6108 PB2 30150 PB2
Up to 288 TB1 Up to 720 TB1 Up to 1 PB1
Usable capacity Up to 17.2 TB Up to 178 TB
Up to 864 TB2 1 With DD
UpExtended
to 2.16Retention
PB2 softwareUp
option
to 3PB2
1 Total capacity on Active Tier only

2 Total capacity with DD Cloud Tier software for long-term retention
Mid Range Models (DD6300, 6800, 9300)
DD2500
DD4500
DD6800
DD6300
DD4200
DD7200
DD9300
High-End DD9800 System
DD9800 is similar to DD9500 in hardware
Provides more active tier space
Includes a standard SSD shelf
Supports memory expansion up to 768 GB

Comparing DD9500 and DD9800 Features (1 of 2)
FEATURE DD9500 DD9800

Rack Height 4U, supported in four-post racks only
Power 4 hot-swappable power units, 2 pairs of 1+1 redundant
Fans 8 hot-swappable fans, redundant
Internal drives 4 x 400 GB (base 10) hot-swappable solid state drives
SSD cache Optional 1 x 8 drive SSD shelf or 1 x 15 drive 1 x 8 drive SSD shelf or 1 x 15 drive SSD shelf
SSD shelf
NVRAM One 8-GB NVRAM module for data integrity during a power outage
I/O Module slots 11 I/O module (Fibre channel, Ethernet, and SAS) slots. Replace I/O modules are not hot-swappable.

Comparing DD9500 and DD9800 Features (2 of 2)
FEATURE DD9500 DD9800

Memory System with 256 GB of memory installed System with 256 GB of memory installed support
support up to 18 x 2 TB or 12 x 3 TB shelves up to 21 x 2 TB or 14 x 3 TB shelves adding up to
adding up to 432 TB of usable external capacity 504 TB of usable external capacity
System with 512 GB of memory installed System with 768 GB of memory installed support
support up to 30 x 2 TB or 24 x 3 TB shelves up to 42 x 2 TB or 28 x 3 TB shelves adding up to
adding up to 864 TB of usable external capacity 1008 TB of usable external capacity
Rack Mounting Rack mount kit included with each system. Adjustable between 24-36 in.
Fans 8 hot-swappable fans, redundant
Voltage 200-240 V~
Frequency: 50Hz to 60Hz
Note: Refer the Data Domain Hardware Overview and Installation Guide for a more detailed description

Expansion Shelves
Description ES30-SATA ES30-SAS ES30-60 DS60

# of Drives 15 15 15 15
Size of Drives 1, 2, 3 TB 2, 3 TB 4TB 3, 4TB SAS Drives

Spare Drives 1 1 2 1
DD6300 DD6300 DD6300

DD6800
DD6800 DD6800 DD6800
Compatible Systems DD9300
DD9300 DD9300 DD9300
DD9800
DD9800 DD9800 DD9800

SSD Shelf
Issues Solutions
Slow metadata and Low-latency Flash
data access Cache solution for new
high-end and midrange
Spindle consolidation systems
with dense drives
Improved Cache Tier to
reduces performance store DD file system
metadata clients
Benefits
Higher random IOPS with low latency
Overall system performance improvement

FS15 SSD Shelf
Functions as a metadata cache for active / ER Tier
Provides the same shelf configuration as ES30
Always used with DD9800
Used with new midrange systems only in high availability

configurations

Data Domain Virtual Edition (DD VE)
DD VE features
DD VE supported OS features

Why DD VE?
Agile
Deduplication
Flexible
Replication
Efficient
DD Boost
Scalable Capacity

DD VE Features
Category Description
Usable capacity 500GB-1TB
Hypervisor ESX versions 5.1, 5.5, 6.0
Protocols NFS, CIFS, DD Boost
Manageability DD System Manager and DD Management Center
Capacity used, total capacity available
Performance
Errors and Maintenance alerts
Replication DD VE to Physical DD, DD VE to DD VE, Physical DD to DD VE
Backup Software Support Networker, Avamar, vSphere Data Protection, NetBackup, Tivoli Storage Manager,
Backup Exec, Commvault, etc.
Support data reporting Autosupport usage data: replication, protocol performance, Hypervisor used, capacity,
status

DD VE Supported OS Features
Physical Data Optimized for Use New DD VE

Domain System with DD VE Features
DD Boost over Maximum Deployment
TCP stream count of Assessment
CIFS 20 Tool(DAT)
NFS 4 Mtrees ELMS licensing
DD Encryption DD System Virtual resource
Garbage Manager monitoring
Collection IPv4 and IPv6 RAID-On-LUN
DD Replication Virtual to protect
headswap against silent
data corruption

Licensing
ELMS overview
Licensing process

ELMS Overview
Electronically represents software license entitlements
Provides standard ordering, fulfillment and activation
Single license file used for each DD VE instance
Note: Licenses purchased for legacy Data Domain systems cannot be applied

Licensing Process
1 Identify license
authorization code in your
email
2
Deploy DD VE OVA file in Apply license file - must
xxx##
VMware apply to corresponding

node locking ID
3
Identify node locking ID
through DD System
Manager
4 In the ELMS portal:

Enter LAC
Activate capacity
Generate license file
Module Summary
Key points covered in this module:
Data Domain Solution
Benefits of Data Domain Solution
Common Hardware Features
ELMS Licensing

Module: Architecture and Technology
Overview
Describe Data Domain architecture and terminology
Describe Data Domain file structures and deduplication methods
Describe Stream-Informed Segment Layout (SISL) and Data Invulnerability

Architecture (DIA) process

Data Domain Data Paths
Data Path over Ethernet
Data Path over Fibre Channel

Data Path over Ethernet
Protocols supported over Ethernet:
Backup
NFS
CIFS Ethernet
DB
NDMP
DD Boost
Telnet/SHH
FTP/SFTP
HTTP/HTTPS
Unix
Ethernet
Servers

Data Path over Fibre Channel
Backup
Ethernet
DB
VTL
Unix
FC SAN
DD Boost
Servers
Note: Refer Data Domain Boost Compatibility Guide and Data Domain Boost Administrator Guide
Data Domain File Structures
/ddvar Administrative Files
MTrees User Data

/ddvar File System
Stores
-Core files
-Log files /ddvar
-Support bundles
-Upgrade packages /core
/log
Consists of administrative files
/support
Provides limited access to
sub-directories
/releases
Cannot rename or delete the

directory

Managed Trees File System
Destination directory for user data /data
/col1
Configuration of specific Mtree /backup
/HR
Configuration of directory export
levels
/Sales
Simplification of Data Domain /Support

features

Deduplication Basics
Deduplication Methods
Data Domain Deduplication Process

Deduplication Methods
Identifies and Eliminates redundant copies of data
Deduplication Types
File-based
Segment-based
Variable-length
Fixed-length segment
segment
File-Based
U A P L U A P L
P L A Q P L A Q
P L Q A P L A Q
Incoming Data Stored Data
Reference
Compressed
Incoming Data Stored Data Compressed
Original Instance Redundant copy
Data Domain Deduplication
New Data
DataPDomain
L implements
A Q inline
U deduplication
A P L P L A Q A
RAM
Data Deduplication occurs in RAM
Data isPanalyzed
L without
A diskQ access
U A A Q A
Disk seek30
time is reduced 33 13
New data compared to previously

stored data before it is written to disk
30 33 30 30 13
Deduplication Disk

Stream-Informed Segment Layout (SISL)
SISL Definition and Benefits
Deduplication using SISL

SISL Definition and Benefits
SISL- Stream-Informed Segment Layout
Implements inline deduplication
Identify segments on disk using fingerprints
Fast and efficient deduplication

Deduplication using SISL
P L A Q U T C B H A O A
1
1 Segment
P L A Q U T C B H A O A
2 Fingerprint 2
3 Filter
30 33 65 35 13
3
4 Compress 30 33 65 35 13
03 13 15 29 30
35 42 65 89 92
4
5 Write 33 13
33 13
A Q U A O A A Q U A O A
5
33 13
30 A Q U 65 35 A O A
Container

Data Invulnerability Architecture (DIA)
DIA Overview
DIA Technologies

DIA Overview
Stores Recheck
Stays Recovers
Correctly Correctly
Stays
Correctly
Correctly

Inline Data Verification Fault Avoidance and Continuous Fault Detection Recovery/Access
Containment and Self- Healing and Verification

DIA Technologies
Inline Data Verification

Verifies all file system data and metadata
End-to-end verification
Fault Tolerance and Containment

New Data never overwrites existing data
Fewer complex data structures
Fault Detection and Healing
Uses RAID 6 redundancy to heal faults
Periodically rechecks the integrity of the RAID stripes
File System Recovery

Data is written in a self-describing format
The file system can be recreated by scanning the logs and rebuilding
from metadata

Module Summary
Components of Data Domain Architecture such as Data Paths and File

Structures
Data Domain Technologies such as Deduplication, SISL, and DIA

Module: DD OS Features
Explain the protocols supported by Data Domain over both Ethernet and Fibre
Channel
DD Boost
VTL
Describe Data Domain features:

Data Domain Cloud Tier
BoostFS
Data Replication
Data Security
User Access feature
Secure Multi-Tenancy
DD Extended Retention and Retention Lock n

Lesson: Data Domain Protocols
DD Boost Features and Benefits
DD Boost Ecosystem
VTL

DD Boost Protocol
Private protocol. More efficient for backup than

CIFS/NFS
DD Boost
Distributes parts of deduplication process - speeds
backups by up to 50%
Enables more efficient resource utilization
Provides application control of Data Domain replication

process
Integrates with leading backup and enterprise
applications

Data Domain Boost Ecosystem
VDP Data
Greenplum SAP
Avamar NetWorker NetBackup Backup Exec vRanger NetVault Veeam Advanced Protector RMAN SAP DB2 SQL
HANA
Server
App
Backup
Server
DD Boost Supported over LAN
DD Boost Supported over SAN
DD Boost Supported over WAN

VTL Features and Benefits
Eliminates physical tape challenges
Integrates seamlessly into existing Fibre Channel SAN

environments
Allows simultaneous use of VTL with NAS, NDMP, and
DD Boost
Replicates virtual tape cartridges efficiently offsite, over
a wide area network (WAN)
Reduces RTO by eliminating the need for physical
tape handling

Data Replication
Data Replication Features and Benefits
Data Replication Types
Data Replication Topologies
Recipe Replication

Data Domain Replicator
Source DD
Automated, policy-based and encrypted replication
Reduces bandwidth requirements up to 99%

DD Replicator
Protects sensitive data when replicating over untrusted
networks
Destination DD
Accelerates time-to-disaster recovery (DR) readiness
Consolidates backup and archive data from hundreds

of remote sites
DD Replicator Leverages multiple replication topologies

Data Replication Types
Collection Directory MTree
For entire system For partial site, point-in-

For partial system
backup time backup
backup
Pool Managed
Used by DD Boost and is
Used for VTL operations controlled by the backup
software

Replication Topologies
source destination source/destination destination/source
1 to 1 bi-directional
source destination
destination source
1 to many
many to 1
source primary source primary

source/ destination
source/
destination destination
destination
cascaded
cascaded 1-to-many
Virtual Synthetic Workload
New Full Backup is synthesized from previous

Full backup and/or Incremental Backups
Only eight base files can be remembered
Portions of new Full Backup are present on
Data Domain system in previous generation backups
INCLUDE RPC sent through Boost and copy_refs

Offset andislength
used toofcopy common
the VS refs from
operation base
must be files
4MB
aligned to be remembered
Gen 0 INCLUDE
INCLUDE INCLUDE INCLUDE BASE file
Gen 1 TARGET file

Recipe Replication
Enhancement to Virtual Synthetic Replication (VSR)
Optimizes performance of Replication on Virtual Synthetic (VS)

workload
Works only on the VS workload
Works with MTree and Managed File Replications

DD Extended Retention and Retention Lock
DD Extended Retention Overview
DD Retention Lock Overview
DD Retention Lock Governance
DD Retention Lock Compliance

DD Extended Retention Overview
Backup Application
Separate tiers of storage for long-term
retention
Data
Fault isolation for access and Domain
Controller
recoverability of long-term data
Data
Eliminates reliance on tape Active Tier Retention Tier
(Short-Term Storage) (Long-Term Storage)
Granular replication for simplified

disaster recovery New data Old data
90 days 7 years
DD Retention Lock Overview
Archive
Software
Governance and compliance of archive data
Secure file locking of archive data at an individual

file level
Data that is locked cannot be overwritten, Backup Data

modified, or deleted
Archive Data
Integrates seamlessly with industry-leading Governance

archiving applications Archive Data
Compliance
Archive Data

DD Retention Lock Governance
By enabling DD Retention Lock Governance

edition on an MTree, IT administrators can :
Admin
Apply retention policies at an individual file level
Delete an archive file after retention period
expires
Update the default values of minimum
and maximum retention periods per
MTree
Extend the retention time of locked
archive files

DD Retention Lock Compliance
Ensures locked files cannot be deleted or overwritten under any circumstances
Retention lock compliance uses multiple

hardening procedures:
Secures the system clock from illegal updates

Requires dual sign-on for certain
administrative actions
Disables various avenues of access
where locked data, or the state of
retention attributes might be
compromised

Storage Migration
Migration Features
Migration from Expansion Shelves

Migration Features
Licensed Unaffected system Controlled resource

processes utilization
Increased
performance Reduces data
and capacity footprints

Migration from Expansion Shelves
New storage enclosures Existing storage enclosures
Migration happens at shelf level
Cannot shrink logical data

Cloud Tier
Cloud Tier Overview
Cloud Tier Encryption
Replication in Cloud Tier

Cloud Tier Overview
Transfers inactive data to Cloud Storage
Copies only unique and Deduplicated Data

Active
Supports DD Retention lock policies Tier
Cloud storage supported systems
Private
Public Hybrid
Cloud Tier
Cloud Tier Encryption
1 Encryption is enabled at three levels

System Level
2 Active
Tier Encryption of Data at Rest is by default
Active tier Level
Encryption status cannot be changed
Private Communication is secured over HTTP

3
Public Hybrid
Clout Tier Level

Replication with Cloud Tier
Active Supports Managed file and MTree replication

Active
Tier Tier
Do not affect Directory replication
Do not support Collection Replication
Private
Private Private
Public
Public Hybrid
Hybrid Public Hybrid
Source
Source Note: For system requirement, please refer to DD OS Target
Release Notes.
BoostFS
BoostFS Overview
BoostFS Features

BoostFS Overview
Mount point 1
Mount point 2
BoostFS
Operation results
Mount point 3
Client system
DD Boost
SDK
Third party applications

Benefits of BoostFS
Improves backup performance
Reduces bandwidth consumption
Reduces load on the servers
Provides access to DD Boost capabilities
Provides control to application owners

Lesson: Data Security
Data Domain Encryption
Data Sanitization

Data Domain Encryption
Encryption key rotation
Data Domain
Internally generated key Integrate with RSA DPM
Encryption
Inline encryption

Data Domain Encryption Types
Encryption of Data at Rest Encryption of Data in-flight
Protection
X
Protection against
Data
transferred
via DD
Uses
OpenSSL
against lost or intruder AES 256-bit
stolen data Eliminates Replicator
Encryption
exposure Software

Data Sanitization
Performed when sensitive data is written to a system which is not

approved
Remove all traces of deleted files without residual remains
System sanitization command enable admin to delete files at logical

level
sanitize command helps in resolving CMIs
System sanitization is often a government requirement

User Access Features
User Access Roles
User Account Security Enhancements
Secure Communications with Cloud

DD User Access Roles
Security
Admin User
Backup Operator None Limited-Admin

User Account Security Enhancements
Users with similar role levels cannot perform configuration change

operations on each other
Users on same level cannot perform operations on each other

Secure Communications with Cloud
CRL and CA certificate used for cloud provider identity verification
Private
Public Hybrid

Lesson: Secure Multi-Tenancy
Introduction to SMT
SMT Terminology
SMT Architecture
SMT Benefits

Introduction to Secure Multi-Tenancy
Enables secure isolation of many users and workloads on a shared system
Large Enterprise Service Providers

Cloud Model
(Private Cloud) (Public Cloud/Hybrid Cloud)
Local Backup
Local backup for multiple Hosted applications including backup
business units as a service
Replicated Backup
Remote offices with local
Disaster recovery as a service
backup
Remote Backup
Remote offices without local
Backup as a service over WAN
backup

SMT Terminology
I am the Data Domain
admin responsible for
managing the DD
systems.
I setup file-systems,
storage, networking,
replication, protocols,
responsible for monitor system health,
I amfor
Logical containers
scheduling and runningreplace failed hardware,
MTrees. Landlord
backup application foretc.
the tenant customer.
Contains important
information, suchI also
as manage tenant
units including
users, notification
groups, and otherconfiguring backup
protocol and monitoring
configuration elements.
resources and stats Tenant
Tenant within a tenant unit.
units
SMT Architecture
Landlord
Red Blue
Tenant User Tenant Admin
Blue
NFS B1
MTree B1
VTL Pool B2 VTL
B2
SU B3
R1 DD Boost
MTree B4
NFS
B3
R2 CIFS
VTL Red B4
R3 MTree R1
DD Boost VTL Pool R2
Blue
R4 SU R3 Red
CIFS
Tenant Admin
Red MTree R4
Blue
Tenant User

SMT Benefits
MTree 1
Unit R1
Tenant
Landlord
Red MTree 2
Data isolation Tenant User MTree 3
Unit B1
Tenant
MTree 21
MTree 22
Administrative isolation Red
Tenant Data Domain
System #1
Tenant Admins
Data path isolation Blue MTree 4
Unit R2
Tenant
Tenant User MTree 5
MTree 6
Metering and reporting Blue
Unit B2
Tenant
MTree 23
Tenant MTree 24
Data Domain
System #2

Module Summary
DD Boost
VTL
Data Domain Cloud Tier
BoostFS
Data Replication
Data Security
User Access feature
Secure Multi-Tenancy
DD Extended Retention and Retention Lock

Module: Data Domain Management
Overview
Describe the management of Data Domain system using Command Line

Interface (CLI)
Describe the management of Data Domain system using Graphical User

Interface (GUI)

Managing a Data Domain from the CLI
Direct Access
Remote Access

Direct Access
Serial Console
DB9 or Micro DB9
9600 baud
USB to RS232 adapter may
be required
Management
Keyboard and Monitor
USB
VGA
Note: Refer DD OS Command Reference Guide for using commands

Remote Access
Capabilities
IPMI SOL
LAN/WAN
Management
SSH/Telnet
Secure CRT
PuTTY

Managing a Data Domain from the GUI
Data Domain System Manager
Data Domain Management Center

Data Domain System Manager
Web based management
Simple configuration wizards
Resource usage and performance reporting
Single interface to manage one or more systems

Data Domain Management Center
Provides a scalable virtual appliance framework for centralized

management of multiple Data Domain devices
Grouping and Filtering

Module Summary
Data Domain system management using the Command Line Interface (CLI)
Data Domain system management using a Graphical User Interface (GUI)

Module: Data Domain Maintenance
Upon completion of this module you should be able to:
Describe DD support features
Identify where users can access support
Identify the benefits of MDU

EMC Secure Remote Service (ESRS)
ESRS
ConnectEMC support
High Availability Support

What is ESRS?
ESRS message types:
Customer environment
Device Dell EMC backend environment
state heartbeat polling
Web Servers
Data Domain
Connect Homes ServiceLink
Application
Servers
Remote
ESRS
Access Session Initiation
Virtual
Edition
User Authentication
Customer
Firewall
Firewall requests Firewall
Device Management synchronization

Public
Internet
Support
Analyst
(https)
Access Servers

ConnectEMC Support
Standardized method to transport system event files
Transmit messages using FTP or HTTPS
Configure network security only for ESRS gateway instead of

multiple systems
Support messages include- ASUP, alerts, alert-summary
Note: An eLicense is required if the system is a physical Data Domain system or DD VE.

High Availability Support
Configuration is similar to non-HA

systems, with the addition of the
HA Peer IP list box

Minimally Disruptive Upgrade (MDU)
MDU
Atomic vs MDU

Uses upgrade bundles
Upgrades only specific components
Upgrade bundles trigger an MDU
DD OS version changes like traditional

upgrades

Atomic vs MDU
Atomic Upgrade
Regular system upgrade

ddsh.rpm vtl.rpm upgrade.rpm openssh.rpm

Module Summary
DD support features
MDU and its benefits

Course Summary
Key points covered in this course:
Data Domain solution and hardware and software options
Physical architecture of a typical backup environment using Data Domain systems
Features and benefits of the Data Domain Operating System (DD OS)
Methods used for administering a Data Domain system
This concludes the training; proceed to the course assessment.

After launching the assessment, you must complete it before returning to the course.
The course will automatically move to your Transcript within 48 hours after passing the assessment.

Welcome to Data Domain Implementation with Application Software.
Copyright 2017 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 FITN ESS
FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license. The trademarks, logos, and
service marks (collectively "Trademarks") appearing in this publication are the property of EMC Corporation and other parties . Nothing contained in this
publication should be construed as granting any license or right to use any Trademark without the prior written permission of the party that owns the
Trademark.
EMC, EMC, the EMC logo, AccessAnywhere Access Logix, AdvantEdge, AlphaStor, AppSync ApplicationXtender, ArchiveXtender, Atmos, Authentica,
Authentic Problems, Automated Resource Manager, AutoStart, AutoSwap, AVALONidm, Avamar, Aveksa, Bus-Tech, Captiva, Catalog Solution, C-Clip,
Celerra, Celerra Replicator, Centera, CenterStage, CentraStar, EMC CertTracker. CIO Connect, ClaimPack, ClaimsEditor, Claralert ,CLARiiON, ClientPak,
CloudArray, Codebook Correlation Technology, Common Information Model, Compuset, Compute Anywhere, Configuration Intelligence, Configuresoft,
Connectrix, Constellation Computing, CoprHD, EMC ControlCenter, CopyCross, CopyPoint, CX, DataBridge , Data Protection Suite. Data Protection Advisor,
DBClassify, DD Boost, Dantz, DatabaseXtender, Data Domain, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, DLS ECO, Document Sciences,
Documentum, DR Anywhere, DSSD, ECS, elnput, E-Lab, Elastic Cloud Storage, EmailXaminer, EmailXtender , EMC Centera, EMC ControlCenter, EMC
LifeLine, EMCTV, Enginuity, EPFM. eRoom, Event Explorer, FAST, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony, Global File Virtualization, Graphic
Visualization, Greenplum, HighRoad, HomeBase, Illuminator , InfoArchive, InfoMover, Infoscape, Infra, InputAccel, InputAccel Express, Invista, Ionix,
Isilon, ISIS,Kazeon, EMC LifeLine, Mainframe Appliance for Storage, Mainframe Data Library, Max Retriever, MCx, MediaStor , Metro, MetroPoint,
MirrorView, Mozy, Multi-Band Deduplication,Navisphere, Netstorage, NetWitness, NetWorker, EMC OnCourse, OnRack, OpenScale, Petrocloud, PixTools,
Powerlink, PowerPath, PowerSnap, ProSphere, ProtectEverywhere, ProtectPoint, EMC Proven, EMC Proven Professional, QuickScan, RAPIDPath, EMC
RecoverPoint, Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, the RSA logo, SafeLine, SAN Advisor, SAN Copy, SAN Manager, ScaleIO
Smarts, Silver Trail, EMC Snap, SnapImage, SnapSure, SnapView, SourceOne, SRDF, EMC Storage Administrator, StorageScope, SupportMate, SymmAPI,
SymmEnabler, Symmetrix, Symmetrix DMX, Symmetrix VMAX, TimeFinder, TwinStrata, UltraFlex, UltraPoint, UltraScale, Unisphere, Universal Data
Consistency, Vblock, VCE. Velocity, Viewlets, ViPR, Virtual Matrix, Virtual Matrix Architecture, Virtual Provisioning, Virtualize Everything, Compromise
Nothing, Virtuent, VMAX, VMAXe, VNX, VNXe, Voyence, VPLEX, VSAM-Assist, VSAM I/O PLUS, VSET, VSPEX, Watch4net, WebXtender, xPression, xPresso,
Xtrem, XtremCache, XtremSF, XtremSW, XtremIO, YottaYotta, Zero-Friction Enterprise Storage.
Revision Date: January 2017
Revision Number: MR-1WP-DDIAS
Copyright 2016 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, Dell EMC NetWorker and Avamar, Veritas
NetBackup and Backup Exec, IBM Spectrum Protect and Oracle RMAN.
This module focuses on a number of key concepts involved in the implementation of Dell
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, backups over Ethernet and
Fibre Channel, and implementation workflows.
This lesson covers basic Data Domain concepts and terms and product-specific backup
terminology.
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. For a complete listing of all backup applications supported by Data Domain,
consult the Backup Compatibility Guide at
http://compatibilityguide.emc.com:8080/CompGuideApp.
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.
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.
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. Spectrum Protect
environments employ similar terminology.
These are some product-specific terms that apply to implementations of IBM Spectrum
Protect.
Backup and Archive clients (BA Clients) are computers and servers that send or retrieve
data from the Spectrum Protect Server.
The Spectrum Protect Servers main function is to coordinate movement of the backup &
archive data from the BA Clients to the storage media. The Spectrum Protect Database
keeps track of each new transaction in its recovery logs. In case of sudden outage of the
Spectrum Protect server, recovery logs are 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). Spectrum Protect allows
you to build a hierarchy of storage pools as destinations for specific backup, archive, and
migration data.
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 Clients, Media Agents,
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.
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 systems 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 NAS versus SAN environments, VTL in NetWorker, NetBackup/Backup
Exec, Spectrum Protect, and ProtectPoint 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 RESTORER-L180 or DDVTL 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 Spectrum Protect, configure FILE CLASS DEVICE via NFS (or CIFS)
exports from the Data Domain system. Note that you cannot use Spectrum Protects 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 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.
ProtectPoint requires both IP and Fibre Channel connections between various components.
Fibre Channel connections are needed between the read/write server and primary storage
for regular business operations. Fibre Channel connections are also needed between the
primary storage and the Data Domain in order to perform backups and recoveries.
The read/write server needs IP connections to the Data Domain to communicate and initiate
jobs on the Data Domain.
This lesson covers installation and configuration workflow, administration and operation
workflow, DD Boost and ProtectPoint workflows, 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 systems administrative console in order
to create a backup job.
Next, you run and monitor the backup job in the backup systems 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.
Configuring the DD Boost environment to utilize ProtectPoint for application backups and
restores can be summarized with a few additional steps:
First, install the ProtectPoint application agent. You must set up the configuration file to be
used for backups and restores with the database application agent. Customize a
configuration file template the software installation provides by setting specific parameters
in the file.
Next, install solutions enabler, if using VMAX3, to allow the agent to communicate with
primary storage. If using XtremeIO, ProtectPoint will use its own CLI included with the
application agent.
Then, complete the required application-specific configurations according to the appropriate

configuration instructions.
Next, ensure the primary storage is enabled for snapshots and external storage mounts. For
VMAX3, FAST.X provides the Federated Tier Storage (FTS) ability to attach external storage
and SnapVX for the local snapshot technology. For XtremIO 4.0, utilize the generation five
RecoverPoint appliance instead.
Finally, create vdisks on the Data Domain to serve as block storage devices for backups and
restores. Unique data is written to the vdisks by the primary storage snapshot technology.
Data Domain uses its fast-copy process to copy the data in the vdisk to a long term archive
location as a static image.
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
systems 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, Ethernet versus Fibre Channel
environments, and basic implementation workflow.
This module focuses on various options and procedures for Dell EMC Data Domain
implementation in a CIFS/NFS environment utilizing any of the common backup
applications.
Upon completion of this module, you will be able to install and implement in a CIFS/NFS
environment and administer and operate backup applications in a CIFS/NFS environment,
describe EMC recommended best practices for CIFS and NFS servers, and perform an NFS
implementation with IBM Spectrum Protect.
This lesson covers various options and procedures for Dell EMC Data Domain
implementation in a CIFS environment utilizing any of the common backup applications.
Upon completion of this lesson, 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.
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
All backup application software should have previously been installed. If necessary,
complete all installations according to the manufacturers instructions.
Start by installing the backup server component, then optionally install any media server
you may want to use, and finally install all the required backup client components.
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.
It is strongly recommended that you assign group and/or user and backup server name
when setting the permissions to make sure CIFS is only accessed via backup server for
security.
established, you will administer and operate the Data Domain system and backup servers in
order to validate the implementation with the steps shown.
Perform administrative tasks on the backup systems administrative console in order to

create a backup job.
One, run and monitor the backup job in the backup systems administrative console.
Two, perform operations to perform backup recovery for a client system.
Three, you can validate and analyze the backups within the Data Domain System Manager,
where you can view statistics and reports.
implementation in an NFS environment.
Upon completion of this lesson, you will be able to describe implementation for NFS,
describe Data Domain networking and NFS parameters, and describe backup server NFS
configurations.
All backup application software should have previously been installed during Step 1. If
necessary, complete all installations according to the manufacturers instructions.
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:
Establish an SSH session to the Data Domain system.
Run config setup to launch the installation wizard.
Configure networking parameters based on your environment.
Configure NFS parameters and set Backup Server List = *.
Set Backup Server List = *
If the Data Domain system is not on the network for example, if it doesnt 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.
Once the networking and NFS parameters procedure is completed, 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:

Create mount points (directories).
Mount Data Domain directories on the new mount points.
Modify /etc/fstab to mount directories at every boot.
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 IBM Spectrum Protect, overview of device class
configurations, and implementation procedures.
The goal is to integrate the Data Domain system using the NFS protocol to Spectrum
Protect 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.
Step 1 is to install the Spectrum Protect application. 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.
order to validate the implementation.
In Steps 1 and 2, perform administrative tasks such as creating a policy and configuring
backup clients.
IBM Spectrum Protect 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 IBM Spectrum Protect 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.
IBM Spectrum Protect allows disk type device classes to be defined as either FILE or DISK
type. FILE device classes are commonly used in IBM Spectrum Protect for virtual volume
management, however, most IBM Spectrum Protect 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 IBM Spectrum Protect to perform sequential read/write activity to files within
a filesystem. Incoming backup data is written to a file, and once a file is filled, a new
scratch file is automatically created by IBM Spectrum Protect and is filled with additional
incoming backup data.
Perform capacity planning and measurement to ensure the Data Domain Restorer capacity
is adequate for each folder.
The default IBM Spectrum Protect MaxCapacity value for a FILE device class is 2GB.
Depending on the operating system of the IBM Spectrum Protect server, maximum capacity
parameters vary. This parameter is sized between 200 and 400 GB for Data Domain
Restorer implementations.
The default Mount Limit value is 20 and the maximum value for this parameter is 4096. This
means that up to 4096 individual files can be opened at a single time. Each Data Domain
Restorer instance supports up to 20 concurrent I/O threads, so the default Mount Limit
value is recommended.
This lesson covers NAS best practices and Data Domain device types vs AFTD.
This table shows some of the Best Practices when implementing the Data Domain system as
a file system to NetWorker.
Best practice for AFTDs is to create one per pool on a storage node and not to place more
than one on a file system. The AFTD should be the only thing on the file system.
For optimal CIFS performance, consider breaking out AFTDs by retention period and data-
type. This lets you track compression at a more granular level, and lets you set up
individual replication contexts.
This table shows additional best practices when implementing the Data Domain system as a
file system to NetWorker.
Because CIFS AFTDs are single-threaded, throughput is limited to the capacity of a single
thread, typically 40 MBps. To work around this limit, you can set up multiple AFTDs and
direct simultaneous jobs to different AFTDs. Depending on the system size and the number
of Network Interface Cards, creating three to six AFTDs should yield good throughput.
During a backup operation, the NFS or CIFS share designated as the backup device receives
the save set directly from the client/storage node or backup server. In large environments
it is not likely that every client will have storage node software installed, or storage node
licenses available. For large numbers of clients, it is likely that a small number of storage
nodes serve as an aggregation point. The clients send their data to their associated storage
node, and the storage node backs up data to the share on the Data Domain system.
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:
Open REGEDIT and navigate to
\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\par
ameters.
In the Parameters folder add a new DWORD Value.
Set the Value name to SESSTIMEOUT.
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 specific procedures for tuning of TCP/IP parameters on Windows 2000/2003/2008
backup servers are shown here.
Using the Registry Editor, create two new registry entries, DefaultSendWindow and
DefaultReceiveWindow. Also, create a TCPWindowSize entry for the active network
interface.
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.
Add registry entries for different TCP/IP parameters and restart the Windows server.
For full details, download the CIFS and Data Domain Systems Tech Note from the EMC
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 Dell EMC NetWorker.
Enter the following command:
nfso -o nfs_use_reserved_ports=1
mount o timeo=600 {nfs_server}:/{export path} /{mountpoint}
This mount command does not persist across AIX reboots. For AIX 5.2 or later, use the p
option to mount the share permanently.
If you are using NFSv3, mount the NFS share using this command:
mount -V nfs -o llock,intr,hard,rsize=32768,wsize=32768,proto=tcp,
combehind,timeo=600,retrans=2 {nfs_server}:/{export path}/{mountpoint}
To show the list of file systems exported by the Data Domain Storage System:
nfs show clients
In addition, to optimize TCP/IP performance on the AIX host, apply the following
parameters:
Set large_send to no for each NIC interface
Other changes that will likely increase throughput:
# no -p -o sack=1
# no -p -o tcp_newreno=0
# chdev -l {ethernet_device_on_storage_node} -a rfc1323=1
# chdev -l {ethernet_device_on_storage_node} -a tcp_nodelay=1
# chdev -l {ethernet_device_on_storage_node} -a tcp_recvspace=262144
# chdev -l {ethernet_device_on_storage_node} -a tcp_sendspace=262144
# nfso p -o nfs_rfc1323=1
If you are using NFSv3, mount the NFS share using this command:
mount F nfs o rsize=32768,wsize=32768,hard {nfs_server}:/{export
path}/{mountpoint}
nfs show clients
HPUX NFS Additional Tuning Parameters:

Add the following line to the file /etc/rc.config.d/nfsconf:
NFS_CLIENT="1"
NUM_NFSIOD=24
Stop and restart the NFS daemons with the commands:
# /sbin/init.d/nfs.client stop
# /sbin/init.d/nfs.client start
In addition, to optimize TCP/IP performance on the HP-UX host, apply the following
parameters:
Set the TCP send and receive sizes for HP-UX 11.0 and 11i backup servers. To make the
changes persistent over system reboots, create a startup script that runs before the NFS
automount. The numbering in the script name and location depends on how startup
scripts are set up on your system, but as an example:
/sbin/rc3.d/S99dd. Enter the following two lines in the script:
ndd -set /dev/tcp tcp_recv_hiwater_def 262144
ndd -set /dev/tcp tcp_xmit_hiwater_def 262144
Mount the NFS share using this command:
mount -T nfs -o hard,intr,nfsvers=3,tcp,rsize=32768,wsize=32768,bg
{nfs_server}:/{export path}/{mountpoint}
nfs show clients
Mount the NFS share using this command:
mount -F nfs o hard,intr,vers=3,proto=tcp,rsize=32768,
wsize=32768{nfs_server}:/{export path}/{mountpoint}
nfs show clients
Solaris system settings to improve TCP/IP NFS performance:

Create a file /etc/rc3.d/S90ddr. Enter the following two lines in the file:
ndd -set /dev/tcp tcp_recv_hiwat 131072
ndd -set /dev/tcp tcp_xmit_hiwat 131072
In the file /etc/system, add the following lines:
set nfs:nfs3_max_threads=16
set nfs:nfs3_async_clusters=4
set nfs:nfs3_nra=16
set rpcmod:clnt_max_conns=1
set fastscan=131072
set handspreadpages=131072
set maxpgio=65536
Note that SUN T-processor (aka coolthreads) servers have notoriously bad NFS
performance. The only adequate resolution for this is to use Jumbo Frames.
This module covered how to install and implement Data Domain in a CIFS/NFS
environment, administer and operate backups in a CIFS/NFS environment, NFS tasks lists
for Spectrum Protect, and EMC Best Practices for CIFS/NFS servers.
This module focuses on various options and procedures for Dell EMC Data Domain
implementation in a VTL environment.
implementation with the DD Boost option in environments utilizing several common backup
applications.
To implement DD Boost, you first prepare both the Data Domain systems and the backup
application.
Step 1. Enable the Data Domain system for storage operations with DD Boost devices by
using the Data Domain CLI. Configuration can be done through the GUI as well.
Step 2. Configure the backup application for use with the Data Domain system by using the
backup application Console.
Continue with the DD Boost Implementation by verifying backup and clone functionality.
Step 3. Using the backup application Console, configure Backup Operations.
Step 4. Monitor backup activity.
Step 5. Verify files on Data Domain systems.
Step 6. Using the backup application Console, restore files from backup clone or client.
implementation in a VTL Fibre Channel environment.
To implement Data Domain as a VTL with NetWorker, you perform the steps detailed on this
slide.
In most environments, FC zoning and HBA card installation and configuration will have been

and operation.
This lesson covers SAN/VTL Best Practices.
The Data Domain Storage Systems can be configured with two or four 16-gigabit Fibre
Channel ports for target mode FC attach. All connections to these ports are made via a
Fibre Channel switch. Direct attachment of a device to these ports is also supported. The
following recommendations apply when connecting the Data Domain Storage System to a
backup server via a Fibre Channel switch:
When implementing a Data Domain VTL, use a Fibre Channel switch listed on the Data
Domain FC Switch Compatibility List for the software release that is applicable to the
specific Data Domain Storage System.
Because the Data Domain VTL provides LUN Masking capabilities, consider using port
zoning on the SAN switches.
Switch encryption solutions are not supported by the Data Domain Storage System.
Limit FC extended fabric (ISL link) configurations to three hops between the backup
server/storage node and the Data Domain Storage System.
EMC recommends the use of persistent binding at the operating system level. This will
prevent interruption of backup operations to the Data Domain Storage System and
difficult-to-diagnose problems after a system reboot.
EMC strongly recommends turning off multiplexing in NetWorker so that backup data
from multiple sources is not interleaved on the virtual tapes because this will
significantly impact deduplication ratios.
This module covered how to install and implement Data Domain in a DD Boost/VTL
environment, administer and operate backups in a DD Boost/VTL environment, and EMC
Best Practices for SAN/VTL.
This module focuses on a number of key concepts involved in the implementation of Dell
EMC Data Domain systems with application software.
Upon completion of this module, you should be able to install and implement a Data
Domain system in a VTL environment, administer and operate a Data Domain system in a
VTL environment, and implement a Data Domain system as NAS with IBM Spectrum Protect
using EMC recommended best practices.
implementation in a VTL environment.
Upon completion of this lesson, 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, administrators can perform the Steps
detailed on this slide. In Step 1 and 2, install or configure the HBA card. In most
environments, FC zoning and HBA card installation and configuration will have been

and operation.
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.
and backup servers.
Steps 2 and 3 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
order to validate the implementation. These steps are typically performed by
Implementation Engineers.
The first few steps is to perform administrative tasks on the backup systems administrative
console in order to create a backup job.
Next, run and monitor the backup job in the backup systems administrative console.
In Step 3, You can also perform operations to perform backup recovery for a client system.
And finally, in Step 4, you can validate and analyze the backups within the Data Domain
System Manager, where you can view statistics and reports.
This task is similar to the previous task list. To implement DD Boost, you first prepare both
the Data Domain systems and the backup application. In Step 1, prepare the Data Domain
systems for DD Boost by enabling DD Boost and set the user. Then create the storage unit
and CIFS share. In Step 2, configure system A for Backup and system B for Backup clone.
This slide continues with the DD Boost Implementation by verifying backup and clone
functionality. Step 3 is to configure the backup/clone operations. In step 4, the backup
management functionality allows the user to monitor activity. In Step 5, you can verify
files on Data Domain systems A and B. Lastly, Step 6 shows how the user can restore files
from the backup clone.
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 lesson covers Data Domain implementation as SAN/VTL with IBM Spectrum Protect
best practices.
The workflow for a VTL implementation varies.
Steps 1 and 2 is about HBA configuration and zoning. However, in most environments, FC
zoning and HBA card installation and configuration will have been previously completed.

and operation.
The goal is to integrate the Data Domain system using the NFS protocol to Spectrum
Protect 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.
Step 1 is to install the Spectrum Protect application. 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.
order to validate the implementation.
In Steps 1 and 2, perform administrative tasks such as creating a policy and configuring
backup clients.
IBM Spectrum Protect 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 Spectrum Protect 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.
Spectrum Protect allows disk type device classes to be defined as either FILE or DISK type.
FILE device classes are commonly used in Spectrum Protect for virtual volume
management, however, most Spectrum Protect 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 Spectrum Protect to perform sequential read/write activity to files within a
filesystem. Incoming backup data is written to a file, and once a file is filled, a new
scratch file is automatically created by Spectrum Protect and is filled with additional
incoming backup data.
Perform capacity planning and measurement to ensure the Data Domain system capacity is
adequate for each folder.
The default Spectrum Protect MaxCapacity value for a FILE device class is 2GB. Depending
on the operating system of the Spectrum Protect server, maximum capacity parameters
vary. This parameter is sized between 200 and 400 GB for Data Domain Restorer
implementations.
The default Mount Limit value is 20 and the maximum value for this parameter is 4096. This
means that up to 4096 individual files can be opened at a single time. Each Data Domain
system instance supports up to 20 concurrent I/O threads, so the default Mount Limit value
is recommended.
This module covered how to install and implement Data Domain in a VTL environment,
administer and operate a Data Domain system in a VTL environment, and implement Data
Domain system as NAS with IBM Spectrum Protect using EMC recommended 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 a few of the specific
backup software products mentioned in this course by visiting the manufacturers site.
For product information, including overviews, data and specification sheets, and white
papers, visit EMCs website at www.emc.com.
For product downloads, documentation, knowledgebase 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, maintenance, 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 Dell EMC NetWorker and Avamar,
EMC ProtectPoint, Veritas NetBackup, Veritas Backup Exec, IBM Spectrum Protect, Oracle
Recovery Manager (RMAN), and Commvault Simpana.
Welcome to Data Domain System Administration.
Copyright 2017 Dell Inc. or its subsidiaries. All Rights Reserved. Dell, EMC, and other trademarks are trademarks
of Dell Inc. or its subsidiaries. Other trademarks may be the property of their respective owners. Published in the
USA.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. DELL EMC 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 DELL 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 DELL 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.
AccessAnywhere Access Logix, AdvantEdge, AlphaStor, AppSync ApplicationXtender, ArchiveXtender, Atmos, Authentica, Authentic Problems, Automated Resource Manager,
AutoStart, AutoSwap, AVALONidm, Avamar, Aveksa, Bus-Tech, Captiva, Catalog Solution, C-Clip, Celerra, Celerra Replicator, Centera, CenterStage, CentraStar, EMC
CertTracker. CIO Connect, ClaimPack, ClaimsEditor, Claralert ,CLARiiON, ClientPak, CloudArray, Codebook Correlation Technology, Common Information Model, Compuset,
Compute Anywhere, Configuration Intelligence, Configuresoft, Connectrix, Constellation Computing, CoprHD, EMC ControlCenter, CopyCross, CopyPoint, CX, DataBridge ,
Data Protection Suite. Data Protection Advisor, DBClassify, DD Boost, Dantz, DatabaseXtender, Data Domain, Direct Matrix Architecture, DiskXtender, DiskXtender 2000, DLS
ECO, Document Sciences, Documentum, DR Anywhere, DSSD, ECS, elnput, E-Lab, Elastic Cloud Storage, EmailXaminer, EmailXtender , EMC Centera, EMC ControlCenter,
EMC LifeLine, EMCTV, Enginuity, EPFM. eRoom, Event Explorer, FAST, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony, Global File Virtualization, Graphic
Visualization, Greenplum, HighRoad, HomeBase, Illuminator , InfoArchive, InfoMover, Infoscape, Infra, InputAccel, InputAccel Express, Invista, Ionix, Isilon, ISIS,Kazeon, EMC
LifeLine, Mainframe Appliance for Storage, Mainframe Data Library, Max Retriever, MCx, MediaStor , Metro, MetroPoint, MirrorView, Mozy, Multi-Band
Deduplication,Navisphere, Netstorage, NetWitness, NetWorker, EMC OnCourse, OnRack, OpenScale, Petrocloud, PixTools, Powerlink, PowerPath, PowerSnap, ProSphere,
ProtectEverywhere, ProtectPoint, EMC Proven, EMC Proven Professional, QuickScan, RAPIDPath, EMC RecoverPoint, Rainfinity, RepliCare, RepliStor, ResourcePak,
Retrospect, RSA, the RSA logo, SafeLine, SAN Advisor, SAN Copy, SAN Manager, ScaleIO Smarts, Silver Trail, EMC Snap, SnapImage, SnapSure, SnapView, SourceOne,
SRDF, EMC Storage Administrator, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix, Symmetrix DMX, Symmetrix VMAX, TimeFinder, TwinStrata, UltraFlex,
UltraPoint, UltraScale, Unisphere, Universal Data Consistency, Vblock, VCE. Velocity, Viewlets, ViPR, Virtual Matrix, Virtual Matrix Architecture, Virtual Provisioning, Virtualize
Everything, Compromise Nothing, Virtuent, VMAX, VMAXe, VNX, VNXe, Voyence, VPLEX, VSAM-Assist, VSAM I/O PLUS, VSET, VSPEX, Watch4net, WebXtender, xPression,
xPresso, Xtrem, XtremCache, XtremSF, XtremSW, XtremIO, YottaYotta, Zero-Friction Enterprise Storage.
Revision Date: March 2017
Course Number: MR-1XP-DDSADMIN
Copyright 2017 Dell Inc. Data Domain System Administration 1

This course covers the knowledge and skills needed for configuring and maintaining Data Domain
systems.

This module focuses on some of the key features of the Data Domain Operating System (DDOS )
including deduplication, SISL and DIA, protocols used by DD OS, and how to access a Data Domain
system for administrative tasks.

This lesson covers a hardware overview of Data Domain, including current hardware models. An overview
of DD Virtual Edition is also presented here.

Dell EMC Data Domain storage systems are traditionally used for disk backup, archiving, and disaster
recovery. An Dell EMC Data Domain system can also be used for online storage providing the user with
additional features and benefits.
A Data Domain system can connect to your network via Ethernet or Fibre Channel connections.
Data Domain systems consist of three components: a controller, disk drives, and enclosures to hold the
disk drives.
Data Domain systems use Serial Advanced Technology Attachment (SATA) disk drives and Serial
Attached SCSI (SAS) drives.

Here is the current Data Domain family. The Data Domain family includes systems for small to large
enterprise organizations.
By reducing storage requirements by 10 to 30x and archive storage requirements by up to 5x, Data
Domain systems can help significantly minimize the storage footprint for small enterprise/ROBO (Remote
Office/Branch Office) environments and scaling all the way up to large enterprise environments.
The models currently shipping with DD OS 6.0 are:

DD2200
DD6300
DD6800
DD9300
DD9800
Also available are the ES30 and DS60 expansion shelves that can be added to most Data Domain
systems for additional storage capacity.

This is the basic topology of a typical Data Domain implementation.
The Data Domain system (controller and any additional expansion shelves) is connected to storage
applications by means of VTL via Fibre Channel, or CIFS or NFS via Ethernet.
In the exploded view diagram, the Data Domain controller sits at the center of the topology implemented
through additional connectivity and system configuration, including:
Expansion shelves for additional storage, depending on the model and site requirements
Media server Virtual Tape Library storage via Fibre Channel
LAN environments for connectivity for Ethernet based data storage, for basic data interactions,
and for Ethernet-based system management

Storage configuration features allow you to add and remove storage expansion enclosures from the
active, retention, and cloud tiers. Storage in an expansion enclosure (which is sometimes called an
expansion shelf) is not available for use until it is added to a tier.
For both active and retention tiers, DD OS 5.2 and later releases support ES30 shelves. DD OS 5.7 and
later support, DS60 shelves.

The FS15 SSD shelf is a solid state expansion shelf used exclusively for the metadata cache in the active
or extended retention tiers of a Data Domain system.
It uses the same form factor as the earlier ES30 expansion shelves and offers different quantities of 800
GB SAS solid state drives depending on the capacity of the active tier.
With a DD9800, the FS15 can be configured as required with either 8 or 15 disks.
When configured for high availability the DD6800 requires 2 or 5 disks and DD9300 models require 5 or 8
disks..
The FS15 SSD shelf is always counted in the number of ES30 shelf maximums but since it is only used
for metadata, it does not affect capacity.
The SSD shelf for metadata is not supported for ER and Cloud Tier use cases.

What is Data Domain Virtual Edition or DD VE?
Just like a traditional Data Domain appliance, DD VE is a data protection appliance, with one primary
difference. It has no Data Domain hardware tied to it. DD VE is an all software only virtual deduplication
appliance that provides data protection in an enterprise environment. It is intended to be used as a cost
effective solution in customer remote and branch offices.
DD VE 3.0 is supported on Microsoft Hyper-V and VMWare ESXi versions 5.1, 5.5 and 6.0.

This lesson covers a software overview of Data Domain, including deduplication fundamentals, SISL, DIA,
the Data Domain file system and supported protocols.

The latest Data Domain Operating System (DD OS ) has several features and benefits, including:
Support for backup, file archiving, and email archiving applications
Simultaneous use of VTL, CIFS, NFS, NDMP, and Dell EMC Data Domain Boost protocols
Data Domain Secure Multi-tenancy (SMT) is the simultaneous hosting, by an internal IT department or
an external provider, of an IT infrastructure for more than one consumer or workload (business unit,
department, or Tenant).
SMT provides the ability to securely isolate many users and workloads in a shared infrastructure, so
that the activities of one Tenant are not apparent or visible to the other Tenants.
Conformance with IT governance and regulatory compliance standards for archived data

There are many powerful features and capabilities to the Data Domain system. They are all concerned
with backing up data and taking up as little storage space as possible. They are also concerned with the
speed of the backup process and maintaining the reliability and integrity of the data that is backed up and
stored.

Deduplication is similar to data compression, but it looks for redundancy of large sequences of bytes.
Sequences of bytes identical to those previously encountered and stored are replaced with references to
the previously encountered data.
This is all hidden from users and applications. When the data is read, the original data is provided to the
application or user.
Deduplication performance is dependent on the amount of data, bandwidth, disk speed, CPU, and
memory or the hosts and devices performing the deduplication.
When processing data, deduplication recognizes data that is identical to previously stored data. When it
encounters such data, deduplication creates a reference to the previously stored data, thus avoiding
storing duplicate data.

Deduplication typically uses hashing algorithms.
Hashing algorithms yield a unique value based on the content of the data being hashed. This value is
called the hash or fingerprint, and is much smaller in size than the original data.
Different data contents yield different hashes; each hash can be checked against previously stored
hashes.

There are three Deduplication methods:
File-Based is one method.
Fixed-Length and Variable-Length are the other two methods and are Segment-Based.

In file-based deduplication, only the original instance of a file is stored. Future identical copies of the file
use a small reference to point to the original file content. File-based deduplication is sometimes called
single-instance storage (SIS).
File-based deduplication enables storage savings. It can be combined with compression (a way to
transmit the same amount of data in fewer bits) for additional storage savings. It is popular in desktop
backups. It can be more effective for data restores. It doesnt need to re-assemble files. It can be included
in backup software, so an organization doesnt have to depend on a vendor disk.
File-based deduplication results are often not as great as with other types of deduplication (such as block-
and segment-based deduplication). The most important disadvantage is there is no deduplication with
previously backed up files if the file is modified.
File-based deduplication stores an original version of a file and creates a digital signature for it (such as
SHA1, a standard for digital signatures). Future exact copy iterations of the file are pointed to the digital
signature rather than being stored.

Fixed-length segment deduplication (also called Fixed block-based deduplication) reduces data storage
requirements by comparing incoming data segments (also called fixed data blocks or data chunks) with
previously stored data segments. It divides data into a single, fixed length (for example, 4 KB, 8 KB, 12
KB, or larger).
Fixed-length segment deduplication reads data and divides it into fixed-size segments. These segments
are compared to other segments already processed and stored. If the segment is identical to a previous
segment, a pointer is used to point to that previous segment.
For data that is identical (does not change), fixed-length segment deduplication reduces storage
requirements.
When data is altered the segments shift, causing more segments to be stored. For example, when you
add a slide to a Microsoft PowerPoint deck, all subsequent blocks in the file are rewritten and are likely to
be considered as different from those in the original file, so the deduplication effect is less significant.
Smaller blocks get better deduplication than large ones, but it takes more resources to deduplicate.
In backup applications, the backup stream consists of many files. The backup streams are rarely entirely
identical even when they are successive backups of the same file system. A single addition, deletion, or
change of any file changes the number of bytes in the new backup stream. Even if no file has changed,
adding a new file to the backup stream shifts the rest of the backup stream. Fixed-sized segment
deduplication backs up large numbers of segments because of the new boundaries between the
segments.

Variable-length segment deduplication evaluates data by examining its contents to look for the boundary
from one segment to the next. Variable-length segments are any number of bytes within a range
determined by the particular algorithm implemented.
Unlike fixed-length segment deduplication, variable-length segment deduplication uses the content of the
stream to divide the backup or data stream into segments based on the contents of the data stream.
When you apply variable-length segmentation to a data sequence, deduplication uses variable data
segments when it looks at the data sequence. In this example, byte A is added to the beginning of the
data. Only one new segment needs to be stored, since the data defining boundaries between the
remaining data were not altered.
Eventually variable-length segment deduplication will find the segments that have not changed, and
backup fewer segments than fixed-size segment deduplication. Even for storing individual files, variable
length segments have an advantage. Many files are very similar to, but not identical to, other versions of
the same file. Variable length segments will isolate the changes, find more identical segments, and store
fewer segments than fixed-length deduplication.

With Data Domain inline deduplication, incoming data is examined as soon as it arrives to determine if a
segment is new or unique or a duplicate of a segment previously stored. Inline deduplication occurs in
RAM before the data is written to disk. Around 99% of data segments are analyzed in RAM without disk
access.
The process is shown in this slide, as follows:

Inbound segments are analyzed in RAM.
The stream is divided into segments, and each segment is given a unique ID.
If a segment is redundant, a reference to the stored segment is created.
If a segment is unique, it is compressed and stored.
Inline deduplication requires less disk space than post-process deduplication. With post-process
deduplication, files are written to disk first, then they are scanned and compressed.
There is less administration for an inline deduplication process, as the administrator does not need to
define and monitor the staging space.
Inline deduplication analyzes the data in RAM, and reduces disk seek times to determine if the new data
must be stored. Writes from RAM to disk are done in full-stripe batches to use the disk more efficiently,
reducing disk access.

When the deduplication occurs where data is created, it is often referred to as source-based deduplication,
whereas when it occurs where the data is stored, it is commonly called target-based deduplication.
Source-based deduplication
Occurs where data is created.
Uses a host-resident agent, or API, that reduces data at the server source and sends just changed
data over the network.
Reduces the data stream prior to transmission, thereby reducing bandwidth usage.
DD Boost is designed to offload part of the Data Domain deduplication process to a backup server
or application client, thus using source-based deduplication.
Target-based deduplication
Occurs where the data is stored.
Is controlled by a storage system, rather than a host.
Provides an excellent fit for a virtual tape library (VTL) without substantial disruption to existing
backup software infrastructure and processes.
Works best for high change-rate environments.

Dell EMC Data Domain SISL Scaling Architecture is also called:
Stream-Informed Segment Layout (SISL) scaling architecture
SISL scaling architecture
SISL architecture
SISL technology
SISL architecture helps to speed up Data Domain systems.
SISL is used to implement Dell EMC Data Domain inline deduplication. SISL uses fingerprints and RAM to
identify segments already on disk.
SISL architecture provides fast and efficient deduplication by avoiding excessive disk reads to check if a
segment is on disk:
99% of duplicate data segments are identified inline in RAM before they are stored to disk.
Scales with Data Domain systems using newer and faster CPUs and RAM.
Increases new-data processing throughput-rate.

SISL does the following:
Segment
The data is split into variable-length segments.
Fingerprint
Each segment is given a fingerprint, or hash, for identification. It compares against other hashes in
the Summary Vector Array. It does not compare all hashes.
Filter
The summary vector and segment locality techniques identify 99% of the duplicate segments in
RAM, inline, before storing to disk. If a segment is a duplicate, it is referenced and discarded. If a
segment is new, the data moves on to step 4.
Compress
New segments are grouped and compressed using common algorithms: lz, gz, gzfast, or off/no
compression (lz by default).
Write
Writes data (segments, fingerprints, metadata and logs) to containers stored on disk.

Dell EMC Data Domain Global Compression is the Dell EMC Data Domain trademarked name for
deduplication. It identifies previously stored segments and cannot be turned off.
Local compression compresses segments before writing them to disk. It uses common, industry-standard
algorithms (for example, lz, gz, and gzfast). The default compression algorithm used by Data Domain
systems is lz.
Local compression is similar to zipping a file to reduce the file size. Zip is a file format used for data
compression and archiving. A zip file contains one or more files that have been compressed, to reduce file
size, or stored as is. The zip file format permits a number of compression algorithms. Local compression
can be turned off.

Dell EMC Data Domain Data Invulnerability Architecture (DIA), is an important Dell EMC Data Domain
technology that provides safe and reliable storage. It provides this through end-to-end verification, fault
avoidance and containment as well as fault detection and healing. This technology ensures reliable file
system recovery.

The end-to-end verification check verifies all file system data and metadata. The end-to-end verification
flow:
Writes request from backup software.
Analyzes data for redundancy.
Stores new data segments.
Stores fingerprints.
Verifies, after backup I/O, that the Data Domain OS (DD OS) can read the data from disk and
through the Data Domain file system.
Verifies that the checksum that is read back matches the checksum written to disk.
If the checksum read back does not match the checksum written to disk, the system will attempt to
reconstruct the data. If the data can not be successfully reconstructed, the backup will fail and an alert will
be issued.
Since every component of a storage system can introduce errors, an end-to-end test is the simplest way to
ensure data integrity. End-to-end verification means reading data after it is written and comparing it to
what was sent do disk, proving that it is reachable through the file system to disk, and proving that data is
not corrupted.

When the DD OS receives a write request from backup software, it computes a huge checksum over the
constituent data. After analyzing the data for redundancy, it stores the new data segments and all of the
checksums. After the I/O has selected a backup and all data is synced to disk, the DD OS verifies that it
can read the entire file from the disk platter and through the Data Domain file system, and that the
checksums of the data read back match the checksums of the written data.
This ensures that the data on the disks is readable and correct and that the file system metadata
structures used to find the data are also readable and correct. This confirms that the data is correct and
recoverable from every level of the system. If there are problems anywhere, for example if a bit flips on a
disk drive, it is caught. Mostly, a problem is corrected through self-healing. If a problem cant be corrected,
it is reported immediately, and a backup is repeated while the data is still valid on the primary store.

Data Domain systems are equipped with a specialized log-structured file system that has important
benefits.
1. New data never overwrites existing data. (The system never puts existing data at risk.)
Traditional file systems often overwrite blocks when data changes, and then use the old block address.
The Data Domain file system writes only to new blocks. This isolates any incorrect overwrite (a software
bug problem) to only the newest backup data. Older versions remain safe.
As shown in this slide, the container log never overwrites or updates existing data. New data is written to
new containers. Old containers and references remain in place and safe even when software bugs or
hardware faults occur when new backups are stored.
There are fewer complex data structures.
2. In a traditional file system, there are many data structures (for example, free block bit maps and
reference counts) that support fast block updates. In a backup application, the workload is primarily
sequential writes of new data. Because a Data Domain system is simpler, it requires fewer data structures
to support it. New writes never overwrite old data. This design simplicity greatly reduces the chances of
software errors that could lead to data corruption.

The system includes non-volatile RAM (NVRAM) for fast, safe restarts.
The system includes a non-volatile RAM (NVRAM) write buffer into which it puts all data not yet safely on
disk. The file system leverages the security of this write buffer to implement a fast, safe restart capability.
The file system includes many internal logic and data structure integrity checks. If a problem is found by
one of these checks, the file system restarts. The checks and restarts provide early detection and recovery
from the kinds of bugs that can corrupt data. As it restarts, the Data Domain file system verifies the
integrity of the data in the NVRAM buffer before applying it to the file system and thus ensures that no data
is lost due to a power outage.
For example, in a power outage, the old data could be lost and a recovery attempt could fail. For this
reason, Data Domain systems never update just one block in a stripe. Following the no-overwrite policy,
all new writes go to new RAID stripes, and those new RAID stripes are written in their entirety. The
verification-after-write ensures that the new stripe is consistent (there are no partial stripe writes). New
writes never put existing backups at risk.

Continuous fault detection and healing provide an extra level of protection within the Data Domain
operating system. The DD OS detects faults and recovers from them continuously. Continuous fault
detection and healing ensures successful data restore operations.
Here is the flow for continuous fault detection and healing:

The Data Domain system periodically rechecks the integrity of the RAID stripes and container logs.
The Data Domain system uses RAID system redundancy to heal faults. RAID 6 is the foundation for
Data Domain systems continuous fault detection and healing. Its dual-parity architecture offers
advantages over conventional architectures, including RAID 1 (mirroring), RAID 3, RAID 4 or RAID
5 single-parity approaches.
RAID 6:
Protects against two disk failures.
Protects against disk read errors during reconstruction.
Protects against the operator pulling the wrong disk.
Guarantees RAID stripe consistency even during power failure without reliance on NVRAM or
an uninterruptable power supply (UPS).
Verifies data integrity and stripe coherency after writes.
By comparison, after a single disk fails in other RAID architectures, any further simultaneous
disk errors cause data loss. A system whose focus is data protection must include the extra
level of protection that RAID 6 provides.

During every read, data integrity is re-verified.
Any errors are healed as they are encountered.
To ensure that all data returned to the user during a restore is correct, the Data Domain file system stores
all of its on-disk data structures in formatted data blocks. These are self-identifying and covered by a
strong checksum. On every read from disk, the system first verifies that the block read from disk is the
block expected. It then uses the checksum to verify the integrity of the data. If any issue is found, it asks
RAID 6 to use its extra level of redundancy to correct the data error. Because the RAID stripes are never
partially updated, their consistency is ensured and thus so is the ability to heal an error when it is
discovered.
Continuous error detection works well for data being read, but it does not address issues with data that
may be unread for weeks or months before being needed for a recovery. For this reason, Data Domain
systems actively re-verify the integrity of all data every week in an ongoing background process. This
scrub process finds and repairs defects on the disk before they can become a problem.

The Dell EMC Data Domain Data Invulnerability Architecture (DIA) file system recovery is a feature that
reconstructs lost or corrupted file system metadata. It includes file system check tools.
If a Data Domain system does have a problem, DIA file system recovery ensures that the system is
brought back online quickly.
This slide shows DIA file system recovery:

Data is written in a self-describing format.
The file system can be recreated by scanning the logs and rebuilding it from metadata stored with
the data.
In a traditional file system, consistency is not checked. Data Domain systems check through initial
verification after each backup to ensure consistency for all new writes. The usable size of a traditional file
system is often limited by the time it takes to recover the file system in the event of some sort of
corruption.
Imagine running fsck on a traditional file system with more than 80 TB of data. The reason the checking
process can take so long is the file system needs to sort out the locations of the free blocks so new writes
do not accidentally overwrite existing data. Typically, this entails checking all references to rebuild free
block maps and reference counts. The more data in the system, the longer this takes.
In contrast, since the Data Domain file system never overwrites existing data and doesnt have block
maps and reference counts to rebuild, it has to verify only the location of the head of the log (usually the
start of the last completed write) to safely bring the system back online and restore critical data.

Two main components of the Data Domain file system are the administrative files, the ddvar and the file
storage, MTree.

Data Domain system administrative files are stored in /ddvar. This directory stores system core and log
files, generated support upload bundles, compressed core files, and .rpm (Red Hat package manager)
upgrade package files.
The ddvar file structure keeps administrative files separate from storage files.
You cannot rename or delete /ddvar, nor can you access all of its sub-directories.

An MTree is a logical partition of the Data Domain file system. They act as a destination directory for
deduplicated data. MTree operations can be performed on a specific MTree as opposed to the entire file
system.
The MTree file structure:

Uses compression.
Implements data integrity.
Reclaims storage space with file-system cleaning. You will learn more about file-system cleaning
later in this course.
MTrees provide more granular space management and reporting. This allows for finer management of
replication, snapshots, and retention locking. These operations can be performed on a specific MTree
rather than on the entire file system. For example, you can configure directory export levels to separate
and organize backup files.
You can add subdirectories to MTree directories. You cannot add anything to the /data directory. /col1
can not be changed - however MTrees can be added under that. The backup MTree
(/data/col1/backup) cannot be deleted or renamed. If MTrees are added, they can be renamed and
deleted. You can replicate directories under /backup.

Here is a reference table of MTree Limits for specific Data Domain systems, DD OS versions, supported
configurable MTrees and supported concurrently active MTrees.

All Data Domain systems can be configured as storage destinations for leading backup and archiving
applications using NFS, CIFS, Boost, or VTL protocols:
Network File System (NFS) clients can have access to the system directories or MTrees on the Data
Domain system.
Common Internet File System (CIFS) clients also have access to the system directories on the Data
Domain system.
Dell EMC Data Domain Virtual Tape Library (VTL) is a disk-based backup system that emulates the
use of physical tapes. It enables backup applications to connect to and manage DD system storage
using functionality almost identical to a physical tape library. VTL (Virtual Tape Library) is a licensed
feature, and you must use NDMP (Network Data Management Protocol) over IP (Internet Protocol) or
VTL directly over FC (Fibre Channel).
Data Domain Boost (DD Boost) software provides advanced integration with backup and enterprise
applications for increased performance and ease of use. DD Boost distributes parts of the deduplication
process to the backup server or application clients, enabling client-side deduplication for faster, more
efficient backup and recovery. DD Boost software is an optional product that requires a separate
license to operate on the Data Domain system.

This lesson covers connecting Data Domain through different data paths.

Data paths specifies how a Data Domain system fits into a typical backup environment.
Data Domain data paths, which include NFS, CIFS, DD Boost, NDMP, and VTL over Ethernet or Fibre
Channel.

Data Domain systems connect to backup servers as storage capacity to hold large collections of backup
data. This slide shows how a Data Domain system integrates non-intrusively into an existing storage
environment. Often a Data Domain system is connected directly to a backup server. The backup data flow
from the clients is simply redirected to the Data Domain device instead of to a tape library.
Data Domain systems integrate non-intrusively into typical backup environments and reduce the amount
of storage needed to back up large amounts of data by performing deduplication and compression on data
before writing it to disk. The data footprint is reduced, making it possible for tapes to be partially or
completely replaced.
Depending on an organizations policies, a tape library can be either removed or retained.
An organization can replicate and vault duplicate copies of data when two Data Domain systems have the
Data Domain Replicator software option enabled.

A data path is the path that data travels from the backup (or archive) servers to a Data Domain system.
Data Domain systems use Ethernet and Fibre Channel.
An Ethernet data path supports the NFS, CIFS, NDMP, and DD Boost protocols that a Data Domain
system uses to move data.
In the data path over Ethernet, backup and archive servers send data from clients to Data Domain
systems on the network via the TCP(UDP)/IP.
You can also use a direct connection between a dedicated port on the backup or archive server and a
dedicated port on the Data Domain system. The connection between the backup (or archive) server and
the Data Domain system can be Ethernet or Fibre Channel, or both if needed. This slide shows the
Ethernet connection.

If the Data Domain virtual tape library (VTL) option is licensed, and a Fibre Channel Host Bus Adapter
(HBA) is installed on the Data Domain system, the system can be connected to a Fibre Channel system
attached network (SAN). The backup or archive server sees the Data Domain system as one or multiple
VTLs with up to 512 virtual linear tape-open LTO-1, LTO-2, LTO-3, LTO-4, or LTO-5 tape drives and
20,000 virtual slots across up to 100,000 virtual cartridges.
VTL requires a fibre channel data path. DD Boost uses either a fibre channel or Ethernet data path.

This lesson covers the Command Line Interface (CLI), Data Domain System Manager and Data Domain
Management Center.

There are 3 ways to interface with Data Domain administration. You can use the Command Line (CLI),
the System Manager GUI, or the Data Domain Management Center.

The Dell EMC Data Domain command line interface (CLI) enables you to manage Data Domain systems.
To initially access the Data Domain system, the default administrators username and password will be
used. The default administrator name is sysadmin. The initial password for the sysadmin user is the
system serial number.
After the initial configuration, use the SSH or Telnet (if enabled) utilities to access the system remotely and
open the CLI.
The DD OS Command Reference Guide provides information for using the commands to accomplish
specific administration tasks. Each command also has an online help page that gives the complete
command syntax. Help pages are available at the CLI using the help command. Any Data Domain system
command that accepts a list (such as a list of IP addresses) accepts entries separated by commas, by
spaces, or both.

Prior to DD OS 5.7 you could manage multiple DD Systems from within System Manager. Now, System
Manager only allows another system to be managed for Replication.
DD System Manager provides a single, consolidated management interface that allows for configuration
and monitoring of many system features and system settings. Note the Management options. As we
progress through the course we will use some of the Management options.
Also notice the information contained in the Footer: DDSM OS Model User Role.
Multiple DD Systems are now managed with Data Domain Management Center.
You can access the System Manager from many browsers:

Microsoft Internet Explorer
Google Chrome
Mozilla Firefox

Starting with DD OS 5.7, System Manager no longer allows management of multiple DD systems except
for replication. Data Domain Management Center supports management of multiple DD systems. A
maximum of 100 DD systems can be added to a DD Management Center. It also allows multiple
simultaneous users.
It can be accessed on Microsoft Windows:

Microsoft Internet Explorer 9, 10, or 11; Mozilla Firefox 30 and higher; Google Chrome
On Apple OS X:
Mozilla Firefox 30 and higher; Google Chrome

The Data Domain Management Center provides capacity and replication resource management, health
and status monitoring, template-based reporting of aggregated data, customizable grouping and filtering of
managed systems via activity monitoring dashboards that support multiple user roles.
The Data Domain Management Center can monitor all Data Domain platforms. The Data Domain
Management Center can monitor systems running DD OS version 5.1 and later.
The Data Domain Management Center includes an embedded version of the System Manager that can be
launched, providing convenient access to a managed Data Domain system for further investigation of an
issue or to perform configuration.

This lab covers the steps necessary to access a Data Domain system.

This module focused on some of the key features of the Data Domain Operating System (DD OS).
Deduplication improves data storage because it is performed inline. It looks for redundancy of large
sequences of bytes. Sequences of bytes identical to those previously encountered and stored are
replaced with references to the previously encountered data.
SISL gives Data Domain deduplication speed. 99% of duplicate data segments are identified inline in
RAM before they are stored to disk. This scales with Data Domain systems using newer and faster
CPUs and RAM.
DIA provides safe and reliable storage because of:

End-to-end verification
Fault avoidance and containment
Continuous fault detection and healing
File system recovery
There are 3 ways to interface with Data Domain administration. You can use the Command Line (CLI),
the System Manager GUI, or the Data Domain Management Center.

This module focuses on administration issues of verifying hardware, managing system
access, monitoring a Data Domain system and defining license features.

This lesson covers verifying hardware. As part of setting up a Data Domain system, you
should verify that your hardware is installed and configured correctly.

We will use Data Domain System Manager to verify system information.

Selecting Maintenance > System from the System Manager displays three panels, System,
Upgrade Packages Available on Data Domain System and Upgrade History.
The System panel shows the Model Number, DD OS version, System Uptime and System
and Chassis serial numbers. On a new installation, this screen can be used to verify the
configuration that was ordered.

Hardware Storage presents Overview, Enclosures, Disks and Reconstruction information.

The Overview tab on the Active Tier displays information on Disks in Use and Disks Not in
Use.

The Overview tab on the Addable Storage refers to systems with optional enclosures. This
section shows the disks and enclosures that can be added to the system.
Failed/Foreign/Absent Disks (Excluding Systems Disks) displays the disks that are in a failed
state; these cannot be added to the system Active or Retention tiers.

The Enclosures tab displays a table summarizing the details of the enclosures connected to
the system.

The Disks tab displays the Disk State table displaying information on each of the system
disks. You can filter the disks viewed to display all disks, disks in a specific tier, or disks in a
specific group.
Note that if you have trouble determining which physical disk corresponds to a disk
displayed in the table, you can use the beacon feature to flash an LED on the physical disk.
Also note Fail and Unfail disks options next to Beacon.
Disk fail functionality allows you to manually set a disk to a failed state to force
reconstruction of the data stored on the disk. Disk Unfail functionality allows you to take a
disk in a failed state and return it to operation

Reconstruction will display any disk that is reconstructing in response to a disk fail
command or by direction from RAID/SSM.

The Hardware Chassis panel displays a block drawing of each enclosure in a system,
including the chassis serial number and the enclosure status. Within each block drawing are
the enclosure components, such as disks, fans, power supplies, NVRAM, CPUs, and
memory. The components that appear depend upon the system model.
On systems running DD OS 5.5.1 and later, the system serial number is also displayed. On
newer systems, such as DD4500 and DD7200, the system serial number is independent of
the chassis serial number and remains the same during many types of maintenance events,
including chassis replacements. On legacy systems, such as DD990 and earlier, the system
serial number is set to the chassis serial number.
Chassis view shows Top View, Back View, and Enclosures. Shown here is the Top View and
a mouse rollover on the components results in a pop-up with specific information on the
component. Shown is a rollover pop-up on the Power Supplies.

Here is a Rear View of the chassis. A rollover on the NVRAM produces this pop-up
information.

This lab covers verifying the hardware of the Data Domain system.

This lab covers the performance of an initial setup of a Data Domain system.

This lesson covers user privileges, administration access and user administration.

Role-based access control (RBAC) is an authentication policy that controls which DD System
Manager controls and CLI commands a user can access on a system.
A sysadmin is the default admin user. An admin can configure and monitor the entire Data
Domain system. Most configuration features and commands are available only to admin role
users. The limited-admin role can configure and monitor the Data Domain system with
some limitations. Users who are assigned this role cannot perform data deletion operations,
edit the registry, or enter bash or SE mode.
The user role can monitor the system, change their own password, and view system status.
The user role cannot change the system configuration.
The Security role is for a security officer who can manage other security officers, authorize
procedures that require security officer approval, and perform all tasks supported for user-
role users. Only the sysadmin user can create the first security officer and that first account
cannot be deleted. After the first security officer is created, only security officers can create
or modify other security officers.
The Backup-operator role can perform all tasks permitted for user role users, create
snapshots for MTrees, import, export, and move tapes between elements in a virtual tape
library, and copy tapes across pools.
The role of None is used for DD Boost authentication and tenant-users. A None role can log
in to a Data Domain system and can change their password, but cannot monitor or
configure the primary system.
The Tenant Admin role can be appended to the other (non-tenant) roles when the Secure
Multi-Tenancy (SMT) feature is enabled. A tenant-admin user can configure and monitor a
specific tenant unit as well as schedule and run backup operations for the Tenant.
The Tenant User role can be appended to the other (non-tenant) roles when the SMT
feature is enabled. It enables a user to monitor a specific tenant unit and change the user
password.
Administration> Access > Local Users is used to create and manage users. The Local
Users tab will show the current list of users and their assigned roles.
Managing users enables you to name the user, grant them privileges, make them active,
disabled or locked, and find out if and when, they were disabled. You can also find out the
users last login location and time.
Note: To comply with security policies it is also important to know that the Data Domain
usernames/roles can be tied into Active Directory or an LDAP service.

To create new users in the System Manager, go to the General tab, enter User, Password,
Verify Password, and Select Role. Click Force Password Change box if you want the user to
select their own password on their first login this is usually a best practice.
Management Role is the role assigned to the user, which can be admin, user, security,
backup-operator, or none.
Note: Only the sysadmin user (the default user created during the DD OS installation) can
create the first security-role user. After the first security-role user is created, only security-
role users can create other security-role users.
Force Password Change - Select this checkbox to require that the user change the
password during the first login when logging in to DD System Manager or to the CLI with
SSH or Telnet.

The Advanced tab in Create User allows the setting of the Password Aging Policy. This
allows setting the time for a password to expire, requiring the user to reset their password.
This is considered a best practice.
The Disable Date options allow for the creation of temporary user accounts often used for
contractors who need temporary access.
Maximum Days Between Change -The maximum number of days between password
changes that you allow a user. Default is 90.
Warn Days Before Expire - The number of days to warn the users before their password
expires. Default is 7.
Disable Days After Expire - The number of days after a password expires to disable the user
account. Default is Never.

Managing administration access protocols enables you to view and manage how other
administrators and users access a Data Domain system. This access can be configured
through the System Manager at Administration > Access > Administrator Access.
The Administrator Access tab displays the configuration status for the IP protocols that can
be used to access the system. FTP and FTPS are the only protocols that are restricted to
administrators.
FTP/FTPS provides access to a Data Domain system through an FTP or FTPS
connection.
HTTP/HTTPS provides access to a Data Domain system through an HTTP HTTPS, or
both, connection.
SSH provides access to a Data Domain system through an SSH connection.
SCP provides access to securely copy files to and from a Data Domain system.
Telnet Provides access to a Data Domain system through a Telnet connection.

This lab covers adding users to a Data Domain system.

This lab covers configuring administrative access on a Data Domain system.

This lesson covers the basics of monitoring a Data Domain system, including log file
locations, settings, and alerts.

From System Manager go to Maintenance > Logs to display log files. The other graphic
shows the structure of the Log directory.
The Data Domain system logs system status messages hourly. Log files can be
bundled and sent to Data Domain Support to provide the detailed system information that
aids in troubleshooting any system issues that may arise.
The Data Domain system log file entries contain messages from the alerts feature,
autosupport reports, and general system messages. The log directory is /ddvar/log.
Only a sample of the log files or folders are listed on this slide. The /ddvar folder contains
other log files that you cannot view.
Every Sunday morning, the Data Domain system automatically opens new messages and
audit log files and renames the previous files with an appended number of 1 through 9,
such as messages.1. Each numbered file is rolled to the next number each week. For
example, at the second week, the file messages.1 is rolled to messages.2. If a file
messages.2 already existed, it rolls to messages.3. An existing messages.9 is deleted
when messages.8 rolls to messages.9.

The Autosupport feature generates a report called an ASUP. The ASUP shows system
identification information, consolidated output from a number of Data Domain system
commands, and entries from various log files. Extensive and detailed internal statistics
appear at the end of the report.
This report is designed to aid EMC Data Domain Support in debugging system problems. An
ASUP is generated every time the file system is started.
You can configure email addresses to receive the daily ASUP reports. The default time for
sending the daily ASUP is 06.00 a.m, and it is configurable. When sending ASUPs to EMC,
you have the option to select the legacy unsecure method or the ConnectEMC method,
which encrypts the information before transmission.
The ASUP displays System Alert messages. When a System Alert message is generated it
is automatically sent to EMC and any specific recipients that have been configured.

Autosupport reports (ASUP) can be accessed through the System Manager > Support >
Autosupport tab. The autosupport reports are in the bottom section of the screen. The
system retains 14 Autosupport reports, aging out the oldest.
Autosupport requires SMTP service to be active (on TCP port 25) on the Data Domain
system and pointing to a valid email server.
The Scheduled auto support option allows disabling the sending of the ASUP.
The Subscribers option allows adding or deleting the alert emails to recipients.
The Channel option allows using standard (unencrypted) ASUP and alert emails or
encrypted emails to the recipients.

Delivery management defines how alerts and autosupport reports are sent to EMC. By
default, alerts and autosupport reports are sent to EMC Data Domain Customer Support
using the standard (unsecure) email.
The ConnectEMC method sends messages in a secure format using FTP or HTTPS.
ConnectEMC is configured through the CLI.
When the ConnectEMC method is used with an EMC Secure Remote Support (ESRS)
gateway, one benefit is that one gateway can forward messages from multiple systems, and
this allows you to configure network security for only the ESRS gateway instead of for
multiple systems. Also, a usage intelligence report is generated.
ESRS Virtual Edition (VE) Gateway, which is installed on an ESX Server, provides automated
connect home and remote support activities through an IP-based solution enhanced by a
comprehensive security system.
Note: DD OS 6.0 uses EMC Secure Remote Support version 3 (ESRSv3). Upgrading a
system running DD OS 5.X to DD OS 6.0 removes the existing ConnectEMC configuration
from the system. After the upgrade is complete, reconfigure ConnectEMC manually.

The Alert feature generates event and summary reports that can be distributed to
configurable email lists and to EMC Data Domain support.
Event reports are sent immediately and provide detailed information on a system event.
The distribution lists for event alerts are called notification groups. Notification groups can
be configured to include one or more email addresses as well as the types and severity level
of the event reports sent to those addresses.
For example, you might configure one notification group for those who need to know about
critical events and another group for those who monitor less critical events. Another option
is to configure groups for different technologies. For example, one group can receive
emails about all network events and another group to receive messages related to storage
issues.
Summary reports are sent daily and provide a summary of the events that occurred during
the last 24 hours. Summary reports do not include all the information provided in event
reports.

Alert groups can be added in System Manager by going to Health > Alerts>
Notifications> Add. Notification groups allows flexibility in notifying the people
responsible for maintaining the system. Individual subscribers can be targeted for specific
types of alerts. Instead of sending alerts to every subscriber for every type of problem, a
sysadmin can configure groups of contacts related to types of issues. For example, you
might configure one notification group for those who need to know about critical events and
another group for those who monitor less critical events. Another option is to configure
groups for different technologies. For example, one group can receive emails about all
network events and another group to receive messages related to storage issues.
You can also use the command line interface (CLI) to configure alerts:
alerts notify-list create <group-name>
Creates a notification list and subscribes to events belonging to the specified list of
classes and severity levels.
alerts notify-list add <group-name>
Adds to a notification list and subscribes to events belonging to the specified list of
classes and severity levels.
alerts notify-list del <group-name>
Deletes members from a notification list, a list of classes, a list of email addresses.
alerts notify-list destroy <group-name>
Destroys a notification list
alerts notify-list reset
Resets all notification lists to factory default
alerts notify-list show
Shows notification lists configuration
alerts notify-list test
Sends a test notification to alerts notify-list

When troubleshooting problems, Data Domain Customer Support may ask for a support
bundle, which is a tar-g-zipped selection of log files with a README file that includes
identifying autosupport headers. To create a support bundle in System Manager, go to
Maintenance > Support > Support Bundles.
Select Generate Support Bundle. It will take a few minutes for the bundle to be
created.
Right -click the link to download the bundle to your PC.
Email the file to Data Domain support at support@datadomain.com.
Note: If the bundle is too large to be emailed, use the EMC/Data Domain support site to
upload the bundle.
You can also generate support bundles from the command line:
support bundle create {files-only <file-list> | traces-only} [and-upload [transport

{http|https}]]
Compress listed files into bundle and upload if specified.
support bundle create default [with-files <file-list>] [and-upload [transport

{http|https}]]
Compress default and listed files into bundle and upload if specified.

The Simple Network Management Protocol (SNMP) is an open-standard protocol for
exchanging network management information, and is a part of the Transmission Control
Protocol/Internet Protocol (TCP/IP) protocol suite. SNMP provides a tool for network
administrators to monitor and manage network-attached devices, such as Data Domain
systems, for conditions that warrant administrator attention.
An SNMP manager is required. Usually this is a third-party application that needs an SNMP
agent to monitor and respond to queries. The SNMP agent becomes the Data Domain
system.
From an SNMP perspective, a Data Domain system is a read-only device with one
exception: a remote machine can set the SNMP location, contact, and system name on a
Data Domain system.
To configure SNMP using the System Manager, go to Administration > Settings > SNMP
and make sure Enable is selected.
SNMP Properties an SNMP system location is a description of where the Data Domain
system is located and an SNMP system contact.
Regarding SNMP V3, V2c, Configurations, the Data Domain system SNMP agent accepts
queries for Data Domain-specific information from management systems using SNMP v1,
v2c, and v3. SNMP V3 provides a greater degree of security than v2c and v1 by replacing
clear text community strings (used for authentication) with user-based authentication using
either MD5 or SHA1. Also, SNMP v3 user authentication packets can be encrypted and their
integrity verified with either DES or AES.

You can configure the Data Domain system to send system log events to a remote
server. Remote logging with syslog sends system messages to customer's syslog server
using UDP port 514.
The CLI command for Remote Logging is log host. Some examples of this command
are:
Enable remote logging with log host enable.
Add a log host with log host add <host>.
Verify (show) configuration with log host show.
The Data Domain Syslog configuration requirements are:

IP address of the Syslog server.
Use of the Data Domain log commands to enable the feature, add the syslog
server, and verify configurations.

This lab covers finding and evaluating log files on a Data Domain system.

This lab covers the remote monitoring of a Data Domain System.

This lesson covers the basics of adding licensed features to, and removing optional licenses
from, a Data Domain system.

Prior to DD OS 6.0, a Data Domain would be licensed using keys for each feature, and new
features are licensed by adding new keys onto the system.
Starting with this release, licensing is being moved to EMCs ELMS (Electronic Licensing
Management System) which provides a standardized method to license all EMC-products
electronically. By using ELMS, Data Domain uses a single file to license the system. The file
contains all licenses and is used for the system it is entitled to.
Both CAPACITY-SSD and Cloud Tier capacity are available exclusively through ELMS. All
other licenses can be added to the system using either the DD Licensing system or using
ELMS.

Archive Store licenses Data Domain systems for archive use, such as file and email
archiving, file tiering, and content and database archiving.
Controller COD enables an on-demand capacity increase for 4 TB DD2200 systems to 7.5
TB or 13.18 TB. An increase to 13.18 TB also requires the EXPANDED-STORAGE license.
CloudTier-Capacity enables a Data Domain system to move data from the active tier to low-
cost, high-capacity object storage in the public, private, or hybrid cloud for long-term
retention.
DD Boost enables the use of a Data Domain system with the following applications: EMC
Avamar, EMC NetWorker, Oracle RMAN, Dell vRanger, Veritas, and Backup Exec. The
managed file replication (MFR) feature of DD Boost also requires the DD Replicator license.
Encryption allows data on system drives or external storage to be encrypted while being
saved and locked when moving the system to another location.
Expanded Storage allows Data Domain system storage to be expanded beyond the level
provided in the base system.
Extended Retention licenses the Extended Retention storage feature. Formerly known as DD
Archiver.
I/OS an I/OS license is required when VTL is used to backup systems in the IBM i operating
environment. Apply this license before adding virtual tape drives to libraries.

Replication adds the Data Domain Replicator for replication of data from one Data Domain
system to another.
Retention Lock Governance protects selected files from modification and deletion before a
specified retention period expires.
Retention Lock Compliance allows you to meet the strictest data retention requirements
from regulatory standards such as SEC17a-4.
Capacity Active enables a Data Domain system to expand the active tier storage capacity to
an additional enclosure or a disk pack within an enclosure.
Capacity Archive enables a Data Domain system to expand the archive tier storage capacity
to an additional enclosure or a disk pack within an enclosure.
Storage Migration for DD Systems enables migration of data from one enclosure to another
to support replacement of older, lower capacity enclosures.
VTL (Virtual Tape Library) enables the use of a Data Domain system as a virtual tape library
over a Fibre Channel network. This license also enables the NDMP Tape Server feature,
which previously required a separate license.
HA-ACTIVE-PASSIVE enables the High Availability feature in an Active-Standby

configuration. You only need to purchase one HA license; the license runs on the active
node and is mirrored to the standby node.

The customer decides what license is needed. The ELMS creates a LAC letter, the letter
provides a link to the ELMS portal.
To complete the ELMS license, the Locking ID (or serial number) must be provided since
the license is generated only for that system. Once all the required fields are filled out, the
output is the ELMS license, which can be added onto the Data Domain using either the CLI
or the GUI.
All DD shipped with 6.0 requires ELMS licensing. For upgrades, the administrator has the
option to upgrade to ELMS using the conversion tool or continue with the keys-based
license.

In the CLI, these three commands help manage licensing on the DD.
Note that elicense reset will wipe the license off the DD. Be sure to save the license
information in case it is needed.

This lesson covers the upgrading process for a Data Domain system.

A GA (General Availability) release is available as a download on the Dell EMC Data
Domain Support website and is intended for production use by all customers. Any customer
running an earlier Data Domain operating system release, GA release or non-GA release,
should upgrade to the latest GA release.
Data Domain recommends that you track Data Domain OS releases deployed in your
backup environment. It is important that the backup environment run the most current,
supported releases. Minimize the number of different deployed release versions in the same
environment. As a general rule, you should upgrade to the latest GA release of a particular
release family. This ensures you are running the latest version that has achieved our
highest reliability status.
Any upgrade packages, regardless of where they are in the release cycle, that are available
for your organization can be downloaded from the EMC/Data Domain support site.
There is no down-grade path to a previous version of the Data Domain operating system
(DD OS). The only method to revert to a previous DD OS version is to destroy the file
system and all the data contained therein, and start with a fresh installation of your
preferred DD OS.
Caution: REVERTING TO A PREVIOUS DD OS VERSION DESTROYS ALL DATA ON

THE DATA DOMAIN SYSTEM.

It is not always essential, but suggested, to maintain a Data Domain system with the
current versions of the OS. With the newest version of the Data Domain operating system,
you can be sure that you have access to all features and capabilities your system has to
offer.
When you add newer Data Domain systems to your backup architecture, a newer version of
DD OS is typically required to support hardware changes such as remote-battery NVRAM,
or when adding the newer ES30 expansion shelf.
Data Domain Support recommends that systems paired in a replication configuration all
have the same version of DD OS.
Administrators upgrading or changing backup host software should always check the
minimum DD OS version recommended for a version of backup software in the Backup
Compatibility Guide. This guide is available in the EMC Data Domain support portal. Often,
newer versions of backup software are supported only with a newer version of DD OS.
Always use the version of the Data Domain operating system recommended by the backup
software used in your backup environment.
No software is free of flaws, and EMC Data Domain works continuously to improve the
functionality of the DD OS. Each version release has complete Release Notes that identify
bug fixes by number.

DD OS 6.0 is the next release after DD OS 5.7 , if you are more than two release versions
behind, contact Dell EMC Data Domain Support for advice on the intermediate versions to
use for your stepped upgrade.
Make sure you allocate appropriate system downtime to perform the upgrade. Set aside
enough time to shut down processes prior to the upgrade and for spot-checking the
upgraded system after completing the upgrade. The time to run an the actual upgrade
should take no longer than 45 minutes. Adding the time to shut down processes, and to
check the upgraded system, might take 90 minutes or more to complete the upgrade.
Double this time if you are upgrading more than two release families.
For replication users: Do not disable replication on either side of the replication pair. After it
is back online, replication automatically resumes service.
You should upgrade the destination (replica) before you upgrade the source Data Domain
system.
Be sure to stop any client connections before beginning the upgrade.

If any applications or hardware devices on which your Data Domain system configuration
relies are not compatible with the DD OS version to which you want to upgrade, do not
perform the upgrade. Consider upgrading to a different and compatible DD OS version, or
schedule your upgrade after the application's or hardware device's compatibility with the
desired DD OS version has been verified.
If you are upgrading to a new version of DD OS that requires you to perform multiple
separate upgrades, such as from 5.4 to 5.6 and then from 5.6 to 6.0, you must insure that
the first upgrade is complete before starting the second upgrade. Be sure to follow all of the
upgrade instructions for the each upgrade process, and verify that the process is complete
before initiating a subsequent upgrade. Be aware that certain versions of DD OS disallow
upgrades if those versions themselves are not completely upgradable on the given
platforms.

The DD OS upgrade pre-check is part of the upgrade process which determines whether the
system is in an upgradable state. The aim of the pre-check is to detect potential problems
early and fail the upgrade rather than leave the system in an unusable state.

When the upgrade pre-check has been successful, select Perform System Upgrade to
begin the process.

This module covered these key points.

Upon completion of this module, you will be able to manage the Data Domain system's network interfaces.
This includes the Ethernet interface and IP Configuration. You will also learn to manage the software-
based link aggregation, link failover, and VLAN network interfaces. Finally, you'll learn how to configure
the various components associated with the fibre channel network interface.

This lesson covers managing network interfaces, configuring an Ethernet interface, IPv6 support, and
managing network settings and routes.

You can manage the configuration of the Data Domain system's networking components through System
Manager or the CLI.
For example, you can manage the configuration of the Ethernet components. This includes Network
Interface Cards (NICs), Link Failover, Link Aggregation, Virtual LANs (VLANs), and Virtual Network
Interfaces.
Available IP configuration settings include IP addresses, IP Aliases, and IP routes.
The Domain Name Service (DNS) configuration is also accessible through the user interface. The Host
name, Domain Name, Local Host File, Search Domains, and dynamic DNS configuration are all
configurable.

You can manage the Data Domain system using Data Domain System Manager (DDSM) and command
line interface (CLI). When using DDSM, navigate to the Hardware > Ethernet screen.
From here you can select the interfaces, settings, or routes tab as appropriate.

Selecting the interfaces tab causes the system to display interface related information. The output from
this screen is organized into four sections - command buttons, interface table, interface details, and IPMI
information.

The Interfaces table presents summary information about the interface in columns that identify the
contents.
You can filter the number of interfaces displayed in the interface table by name or by interface type.
The Interface column shows the name of each interface associated with the selected Data Domain
system. Physical interface names start with eth. Virtual interface names start with veth.
The Enabled column indicates whether or not the interface is enabled. Select Yes to enable the interface
and connect it to the network. Select No to disable the interface and disconnect it from the network.
The DHCP column indicates if the interface is configured to use DHCP. This column displays a value of
Yes, No, or not applicable.
The IP Address column shows the IP address associated with the interface. If the interface is configured
through DHCP, an asterisk appears after this value.
The Netmask column shows the netmask associated with the interface. The display uses the standard IP
network mask format. If the interface is configured through DHCP, an asterisk appears after this value.
The Link column indicates whether or not the interface currently has a live Ethernet connection.
The Additional Info column lists additional settings for the interface, such as the bonding mode.

The Interface Details section of the screen displays comprehensive information about the selected
interface.
You can view the details of an interface by selecting its associated row in the Interface table.
The Intelligent Platform Management Interface (IPMI) section of the screen indicates if IPMI health and
management monitoring is configured for the interface. You can view more information about IPMI
interfaces by selecting the View IPMI Interfaces hot link. This hot link takes you to the Maintenance >
IPMI configuration tab.

You can also use view network interface settings using the command line interface (CLI).
Displayed are example CLI commands that provide most of the relevant information associated with
network interfaces. Use the help net show CLI command to obtain more information on these
commands.
The net show settings CLI command displays the interface's network settings.
The net show hardware CLI command displays the interface's hardware configuration.
The net show config CLI command displays the active network configuration.
The net show domainname CLI command displays the domain name associated with this device.
The net show searchdomain CLI command lists the domains that will be searched when only the host
name is provided for a configuration or command.
The net show dns CLI command lists the domain name servers used by this device.
The net show stats CLI command provides a number of different networking statistics. Use the help
net show command for more information.
The net show all CLI command combines the output of several other net show CLI commands. The
output from this command is quite long an will likely scroll off the screen.

To configure an Ethernet interface using the System Manager, follow these steps.
1. After navigating to the Data Domain System Manager Hardware > Ethernet > Interfaces tab, select an
interface from the interface table.
2. Click Configure. This causes the Configure Interface panel to appear.
3. Go to the IP settings section of the panel.
If you are using DHCP to assign an IP address, click Obtain using DHCP and identify if the DHCP
server will provide an IPv4 or IPv6 address.
If you wish to assign a static IPv4 address to the device, select Manually configure IP Address and
enter the IPv4 address and netmask in the appropriate fields.
If you are assigning an IPv6 address to the system, enter the IPv6 address and prefix in the IP
address field and leave the Netmask field empty.
Some older Data Domain systems do not support IPv6 on interface eth0a (eth0) or on any VLANs
created on that interface.
4. Go to the Speed and Duplex section of the panel.
Select the Autonegotiate Speed and Duplex option to allow the NIC to configure itself. The NIC's
configuration will be based upon the speed and duplex settings of the device at the other end of the
connection. Optical interfaces must be configured to Autonegotiate.
To set a static transfer rate, select the Manually Configure Speed/Duplex option. The speed and
duplex settings can be selected from the drop-down lists.
The available speed options are limited to the capabilities of the NIC so only the speed options
appropriate for the NIC are displayed.
By default, the speed for a copper interface is 10Mb.
Because 1000Mb and 10Gb line speeds require full-duplex, the half-duplex option is only available
only for 10Mb and 100Mb speeds.

5. If you need to configure the NIC's Maximum Transmission Unit (MTU) size, go to the MTU Settings
section of the panel and enter the MTU value.
Supported values are from 350 to 9000.
The MTU for interfaces with a configured IPv6 address is 1280. If you try to set the MTU lower than
1280 on an interface with an IPv6 address, an error message appears and the interface is removed
from service.
For 100 Base-T and gigabit networks, 1500 is the default MTU value. The Default button returns the
MTU setting to the default value.
Before you change the MTU value, make sure all devices in the network data path support the
proposed MTU size.
6. Enable or disable the Dynamic DNS Registration (DDNS) for Windows mode by selecting or
unselecting the checkbox.
DDNS Registration allows devices on a network to register the statically assigned IP address with
the DNS server.
DD System Manager only allows you to configure DDNS Registration for Windows mode. Use the
net ddns CLI command to configure UNIX mode DDNS Registration.
The DDNS Registration feature must be enabled and the interface must be registered for this setting
to take effect. Navigate to the Hardware > Ethernet > Interfaces tab and click the DDNS
Registration button to verify the DDNS Registration settings. More information can be found in the
Registering a DDNS section of the DD OS Administration Guide.
This option disables DHCP for this interface.
7. Click Next. This causes the Configure Interface Settings summary panel to be displayed.
8. To implement the configuration, review the Configure Interface Settings summary panel and click
Finish. This causes the configuration progress panel to be displayed. After the network interface
configuration process completes, Click OK.

You can also configure an Ethernet interface by using the CLI. Displayed are a number of common
network configuration tasks along with related sample CLI commands.
Refer to the documentation or the help net config CLI command to obtain more information.

1. To view the IP Name settings for the Data Domain system, select the Hardware menu item.
2. Then select the Network menu item after it displays.
3. Finally, select the Settings tab.
From here, you can manage the host name, domain name, domain search list, host mappings (local host
file), and the DNS server list.

On the Hardware > Ethernet > Settings screen, the Hosts Settings section displays the Data Domain
system's host name. The host name is shown as a Fully Qualified Domain Name (FQDN) - which means
the host name and domain name are displayed as a single string. The host name is the part of the string
that ends before the first dot.
The domain name is shown beneath the host name. The domain name is appended to the host name to
produce the system's fully-qualified domain name.
The Search Domain List section displays the search domains used by the Data Domain system when a
host name (not a fully qualified domain name) is entered into the system as a configuration parameter or
as an argument to a command.
When a host name is used in this way, the system attempts to determine the correct domain name to
associate with the provided host name by appending each of the listed search domains to the host name.
The system uses the fully qualified domain name if it is discovered. If none of the domain names yield the
correct fully qualified domain, the system returns an error.
The Host Mappings section shows local name to IP address mappings. Unlike the mappings provided by
the DNS server, these name mappings only apply to this system.
The DNS List displays the IP addresses of the DNS servers used by this system. An asterisk (*) indicates
the DNS server addresses were assigned through DHCP.

You can use the CLI to view IP Name settings. Displayed are example CLI commands that provide the
same information shown on the Data Domain System Manager Hardware > Ethernet > Settings tab.
Refer to the documentation or the help net show and help net hosts CLI commands to obtain more
information on these commands.

1. To configure the Data Domain system's host name or domain name using the System Manager,
navigate to the Hardware > Ethernet > Settings tab and click Edit in the Host Settings section. This
causes the Configure Host input panel to appear.
2. If you wish for the host name and domain name to be configured by the DHCP server, choose the
Obtain Settings using DHCP option.
If you wish to configure a static host name and domain name, choose the Manually configure host
option and enter the host name and domain name.
3. After configuring the host settings, select OK.

1. To add a domain to the search domain list, navigate to the Hardware > Ethernet > Settings tab and
click Edit in the Search Domains List section. This causes the Configure Search Domains input panel
to appear.
2. Click the green plus icon to display the Add Search Domain input panel.
3. Enter the new domain name in the Search Domain field.
4. Select OK to add the name to the search domain list. You may add more search domains by
selecting the green plus icon again.
5. To remove a domain name from the list, select the name from the search domain list.
6. Next, select the red x icon. This removes the domain name from the search domain list.
7. Once the search domain list is complete, select OK to save the list to the system.

You can add local IP address to name mappings by using the host mapping feature.
This feature allows the users of the system to specify locally configured names (aliases) in place of IP
addresses for CLI commands and other system parameters.
Host name mapping is typically used when a target system does not have a DNS entry and the IP
address is difficult to remember.
When using this feature, you create a list of names that are mapped to a single IP address.
1. To create a new host mapping list, navigate to the Hardware > Ethernet > Settings tab and select Add
in the Host Mapping section. This causes the Add Hosts input panel to appear.
2. In the IP address field, add the address of the station to which you wish to map names.
3. Select the green plus icon to display the Add Host input panel.
4. Enter a name to associate with the target IP address.
5. Select OK to add the name to the Host Name list. You can associate more host names with the IP
address by selecting the green plus icon again.
6. If in an entry you just added to the host name list is incorrect, you can quickly delete it by first select
the host name from the Host Name list.
7. And then selecting the red x icon. This removes the name from the Host Name list.
8. Once the Host Name list is complete, select OK to save the list to the system.

1. To delete an existing host mapping, navigate to the Hardware > Ethernet > Settings tab and select the
target host mapping from the Host Mapping section.
2. Click Delete. This causes the Delete Hosts panel to appear.
3. Verify the correct IP address is displayed and select Delete.
4. Click Close after the delete process completes.

1. To edit an existing host mapping, navigate to the Hardware > Ethernet > Settings tab and select the
host mapping to edit.
2. Click Edit. This causes the Add Hosts input panel to appear.
3. You cannot edit the IP address field, but you can add more host names to the list by selecting the
green plus icon to display the Add Host input panel.
4. Enter the additional host name.
5. Select OK to add the name to the Host Name list.
6. To quickly delete an entry, select the host name from the Host Name list.
7. Click the red x icon. This removes the name from the Host Name list.
8. Once the Host Name list modification is complete.
9. Select OK to save the edited list to the system.

You can also configure IP name settings through the CLI. Displayed are a number of common IP Name
configuration tasks along with related sample CLI commands.
Refer to the documentation or the help net set, help net hosts, and help net reset CLI commands to
obtain more information.

Data Domain systems do not generate or respond to any of the network routing management protocols
(RIP, EGRP/EIGRP, and BGP) in any way. The only routing implemented on a Data Domain system is
based on the internal route table, where the administrator may define a specific network or subnet used by
a physical interface (or interface group).
Data Domain systems use source-based routing, which allows the sender of the packet to specify the
route or interface that a packet must in order to reach the destination.
Navigate to Hardware > Ethernet > Routes to view or configure the IP routes on the Data Domain system.

1. Go to the top of the Hardware > Ethernet > Routes tab to review the address of the IPv4 Default
Gateway.
2. To configure the default gateway, click the Edit button associated with the Default IPv4 Gateway. The
Configure Default IPv4 Gateway dialog box appears.
3. If the system is to receive the default gateway from the IPv4 DHCP server, select the Use DHCP
value option.
4. If the system is to be configured with a static IPv4 address, select the Manually Configure option and
enter the gateway address when the Gateway input box becomes available.
5. Click OK. The system processes the information and returns you to the Routes tab.

The process for configuring the IPv6 Default Gateway is exactly the same as for configuring the IPv4
default gateway with the exception of the IP addressing scheme being used.
1. Go to the top of the Hardware > Ethernet > Routes tab to review the address of the IPv6 Default
Gateway.
2. To configure the default gateway, click the Edit button associated with the Default IPv6 Gateway. The
Configure Default IPv6 Gateway dialog box appears.
3. If the system is to receive the default gateway from the IPv6 DHCP server, select the Use DHCP
value option.
4. If the system is to be configured with a static IPv6 address, select the Manually Configure option and
enter the gateway address when the Gateway input box becomes available.
5. Click OK. The system processes the information and returns you to the Routes tab.

Static routes define the data path to destination hosts or networks.
1. After navigating to the Hardware > Ethernet > Routes tab, you can configure a static route by clicking
the Create button in the Static Routes area.
2. In the Create Routes dialog, select the interface you want to host the static route.
3. Click Next. The destination panel is displayed.
4. Specify the destination. To specify a destination network, select Network and enter the network
address and netmask or prefix for IPv6 addresses. To specify a destination host, select Host and
enter the hostname or IP address of the destination host.
Note: This is not the IP of any interface. The interface is selected in the initial dialog, and it is used for
routing traffic.
5. As an option, specify the gateway to use to connect to the destination network or host.
6. Review the configuration and click Next. The create routes Summary page appears.
7. Click Finish. After the process is completed, click OK. The new route specification is listed in the
Route Spec table.

You can also view and configure routes through the CLI. Displayed are a number of commands that
enable you to view and configure various routing parameters.

This lab covers viewing the network settings on a Data Domain system.
1. Ethernet Hardware Settings
2. IP Address Configuration
3. Domain Name Parameters

This lesson covers link failover and aggregation concepts and components, supported topologies, and link
failover and aggregation overview and configuration.

There are a number of concepts that are covered in this part of the training. These concepts include
components, bonding mode types, topologies, and load balancing.
In this section of the training, components are defined as parts of the system that must be configured or
managed.
Bonding modes define the methods and protocols used to control the physical links between systems.
Bonding is a term used by Linux community to describe the grouping of interface together to act as one
interface to the outside world. Other analogous terms include link bundling, EtherChannel (from Cisco),
Trunking, Port Trunking, Port aggregation, NIC bonding, and Load balancing. Link aggregation and link
faliover are two type of bonding supported by Data Domain system.
Topologies show the connections and relationships between systems.
The bonding hash defines the methods used to balance transmissions over the physical links. Balancing
is typically done to obtain better physical link utilization.

The components needed to implement link failover or link aggregation are the system software, a virtual
interface, the operation defined by the virtual interface, and physical network interfaces.
The system software sends and receives data to and from the virtual interface in the same way it would as
if the virtual interface was a physical network interface.
The virtual network interface provides the system software with a way to access the underlying
aggregated link connection, link failover connection, or VLAN. It appears to the system as a normal
physical network interface. A virtual interface can also be viewed as a container to hold physical
interfaces.
The virtual interface operation is the component that performs the functions defined by the virtual interface
type (bonding mode). This component processes data according to rules associated with the interface
type.
Finally, there are physical network interfaces. These components are responsible for actually transmitting
and receiving data over the network. Of course, there are physical interfaces on the connected devices as
well.
If configuring link failover, the interfaces on the connected device do not require any special configuration
other than normal Ethernet network configuration.
If configuring link aggregation, the interfaces on the connected device must be setup with a compatible
bonding type, mode, and hash.

When using link failover or link aggregation, it is important to remember that links are controlled point-to-
point. That means that whatever protocol is used to control the operation of the links, it only operates from
the Data Domain system to the directly connected device. This directly connected device can be a switch,
a server, or even a network gateway or router.
Link control does not extend beyond the directly connected device. If the media or application server is
not directly connected to the Data Domain system, the operation of its physical links are not managed by
the failover or aggregation functions. Of course, a loss of connectivity would still be detected by higher
level protocols.

Topologies provide a map of the network and essentially defines its terrain. With a map of the topology,
you can see how devices are physically or logically inter-connected. In the context of link failover and link
aggregation, we will discuss three common topologies - direct connect, LAN connect, and remote connect.

In the direct connect topology, the Data Domain system is directly connected to the application, media, or
backup server. In this case, the connected server must be configured with a compatible bonding
configuration - including type, mode, and hash.
The physical Ethernet connections must follow existing guidelines which typically means all interfaces
have the same speed and duplex settings. Some configurations allow the links in the bundle to have
different media types.
The direct connect topology may be used for any type of bonding mode, but is most often used with round
robin because it provides the most fair traffic distribution between the two links. Even though round robin
is more susceptible to out-of order packet transmission, this problem is minimized by the fact that traffic
destined for other devices is not going to be contending for the resources provided by these links.

A LAN connect topology may also be referred to as a switch connect topology.
In this topology, the Data Domain system is directly connected to a layer 2 switch. The physical Ethernet
links between the Data Domain system and the layer 2 switch must have the same speed and duplex
settings.
The bonding configuration must also be compatible between the Data Domain system and the layer 2
switch. This includes the bonding type, mode, and hash.
Also, the Data Domain system and the server are on the same subnet. This means that there is no router
between the Data Domain system and the server.
The server is also connected to a layer 2 switch, but that doesn't mean it is connected to the same switch
as the Data Domain system.
Because link aggregation and link failover are point-to-point protocols and not end-to-end, the physical
network link configuration of the server is unrelated to the configuration of the Data Domain system in this
topology. It is required that the server and switch have compatible physical network and bonding
configurations, but not required for the server and Data Domain system to also have the same level of
compatibility. In fact, as shown on the screen, the configuration of the Data Domain system's physical
links can be completely different from the server's.

In a remote connect topology, the server is in a different subnet than the Data Domain system. All traffic
to and from the server must go through a gateway. Because of this, all packets will contain the MAC
addresses of the gateway and Data Domain system. Remember this when selecting a bonding hash.

Link failover provides improved network stability and performance by identifying backup interfaces that
can support network traffic when the primary interface is not operating. This ensures the Data Domain
system remains connected to the network.
The failover-enabled virtual interface represents a primary physical network interface and a group of
secondary physical network interfaces.
The system makes the primary interface the active interface whenever the primary interface is operational.
A configurable Down Delay failover option allows you to configure a failover delay in 900 millisecond
intervals. The failover down and up delays guard against multiple failovers when a network is unstable. By
default, a link must be up or down continuously for 29700 milliseconds (29.7 seconds) before the system
activates a standby link or restores the primary link.
If the carrier signal is lost, the active interface is changed to another standby interface. An address
resolution protocol (ARP) is sent to indicate that the data must flow to the new interface. The interface can
be on the same switch, on a different switch or directly connected.

A virtual network interface must be created in order for link failover to work. The system uses this virtual
interface as an access point to the link failover function.
When you create the virtual network interface, you identify how the bonded links are to be used. In this
case, the virtual interface is used to identify primary and secondary failover links and to make them appear
to the operating system as a single network connection.
You can create as many virtual interfaces as there are physical interfaces. You can even create a link
failover connection with only one physical link.
To create a link failover virtual interface, follow these steps.
1. Navigate to the Hardware > Ethernet > Interfaces tab.
2. Disable the physical Ethernet interfaces you want to add to the failover link by selecting the interfaces
and choosing No from the Enabled menu.
A physical network interface that is part of a virtual interface is seen as disabled for other network
configuration options.
Each physical interface can belong to one virtual interface.
The number and type of cards installed on the system determines the number of physical Ethernet
interfaces available.
3. If an error is displayed warning about the dangers of disabling the interface, verify the interface is not
in use and click OK.
4. From the Create menu, select the Virtual Interface option. The Create Virtual Interface dialog box
appears.

5. On the create Virtual Interface dialogue box, specify a virtual interface name in the veth text box.
The virtual-name must be in the form vethx where x is a number.
X can be any number from 0 to 9999 however, EMC recommends a maximum number of 99
because of name length limitations.
The virtual interface name can include the VLAN and IP Alias. The complete virtual name format is
vethXX.VLAN:ALIAS. An example would be veth56.3999:199. The maximum length of the entire
name, including VLAN ID, alias, and the dot and colon separators is 15 characters.
Special characters are not allowed.
A system can support multiple mixed failover and aggregation virtual interfaces, subject to some
restrictions.

6. From the General tab, select the Failover as the bonding type.
7. Select the interfaces that will be part of the failover configuration by clicking the checkbox
corresponding to the interface.
Physical network interfaces or virtual link aggregation interfaces can be added to a link failover
virtual interface.
Virtual interfaces must be created from identical physical interfaces. For example, all copper, all
optical, all 1 Gb, or all 10 Gb. However, 1 Gb interfaces support bonding a mix of copper and
optical interfaces. This applies to virtual interfaces across different cards with identical physical
interfaces, except for Chelsio cards. For Chelsio cards, only failover is supported, and that is only
across interfaces on the same card.
Bonded physical interfaces can be connected to the same or different switches.
All interfaces in a virtual interface must be on the same physical network.
Network switches used by a virtual interface must be on the same physical network.
10 Gb CX4 Ethernet card, which are restricted to one primary interface and one failover interface
from the same card, and
There is no special failover configuration required on the switch. Since the Data Domain system is
the device that manages the failover, a normal Ethernet configuration of the switch should work.
Only one interface in a group can be active at a time.
On the DD4200, DD4500, and DD7200 systems, the ethMa interface does not support failover or
link aggregation.

8. Select the primary interface.
A primary interface must be specified as a part of the virtual failover link.
All other interfaces are designated as secondary standby interfaces.
The primary interface is active if it is available and the virtual interface is enabled.
If the primary interface goes down and multiple interfaces are still available, the next interface is
randomly selected.
9. Click Next and the Create Virtual Interface dialog box appears.

10. Enter an IP address and netmask for the virtual interface.
11. Specify the speed and duplex options that will be applied to all physical interfaces that are associated
with the virtual interface.
12. If necessary, configure the MTU. Verify the MTU settings with the network administrator before
modifying the configuration.
13. Click Next. A panel with the summary of the configuration should now appear.
14. Review configuration
15. Click Finish
16. Observe as the virtual interface is created.
17. Click OK after the virtual interface creation process is completed. If there are errors, address them
and reconfigure the interface. Observe as the virtual interface is created.
and reconfigure the interface.

1. Disable and configure the physical network interfaces that will be included in the virtual interface.
a. To disable the physical interfaces, issue the net config <ifname> down CLI command against
each one.
b. To configure each physical network interface's Ethernet parameters, use the autoneg or duplex
and speed options of the net config <ifname> CLI command. Ensure all physical interfaces, on
the both Data Domain system and the connected device, are configured the same.
If you are using different media types, check the documentation to verify this is allowed with
your hardware.
Other than configuring the Ethernet parameters, there is no other configuration required on the
connected device.
2. Create the virtual interface and configure it for link failover bonding mode.
a. Use the net create virtual CLI command to create the virtual interface.
b. Use the net modify CLI command with the bonding failover arguments to configure a virtual
interface for link failover bonding mode.
c. Use the net config CLI command to provide the virtual interface with an IP address and netmask.
3. Add the physical network interfaces to the virtual interface and select a primary link.
a. Use the net failover add CLI command to add the physical interfaces to the virtual interface.
b. Use the net failover modify CLI command to select the primary link.
4. Enable the virtual interface and verify its configuration.

a. Use the net config <virtual-ifname> up CLI command to enable the virtual interface. This step is
usually unnecessary, but do it just in case.
b. Use the net failover show CLI command to verify the configuration of the virtual interface.

Link aggregation increases network throughput and treats a bundle of multiple network links as a single
path. Each added physical network link increases network throughput by the speed of the link. For
example, three 1 Gbps links can be bundled together (aggregated) to provide 3 Gbps of potential
throughput.
The Data Domain link aggregation feature is between the local system and the connected network device.
The device connected to the Data Domain system can be a switch, router, or server.
Link aggregation also provides link failover. If one of the physical network links in the bundle should fail,
the other links continue to service the Data Domain system's network connection.
A virtual network interface must be created in order for link aggregation to work. The system uses this
virtual interface as an access point to the link aggregation bundle.
When you create the virtual network interface, you identify how the bonded (bundled) links are to be used.
In this case, the virtual interface is used to aggregate multiple physical links and make them appear as a
single network connection.
You can create as many virtual interfaces as there are physical interfaces.

To create a link aggregation virtual interface, follow these steps.
1. After verifying the device connected to the Data Domain system support compatible link aggregation
bonding methods, navigate to the Hardware > Ethernet > Interfaces tab.
2. Disable the physical Ethernet interfaces you want to add to the aggregation link by selecting the
interfaces and choosing No from the Enabled menu.
A physical network interface that is part of a virtual interface is seen as disabled for other network
configuration options.
Each physical interface can belong to one virtual interface.
The number and type of cards installed on the system determines the number of physical Ethernet
interfaces available.
Changes to disabled Ethernet interfaces flush routing table. Schedule interface changes during
downtimes. Reconfigure routing rules and gateways afterwards.
3. If an error is displayed warning about the dangers of disabling the interface, verify the interface is not
in use and click OK.
4. From the Create menu, select the Virtual Interface option. The Create Virtual Interface dialog box
appears.

5. On the create Virtual Interface dialogue box, specify a virtual interface name in the veth text box. The
link aggregation virtual-interface name guidelines are the same as the link failover virtual-interface
name guidelines.
6. From the General tab, select Aggregate as the bonding type.
7. Specify the bonding mode. The bonding mode must be compatible with the link aggregation method
supported by the system directly connected to the physical interfaces that are part of the bundle. The
available bonding modes are round robin, Balanced, and Link Aggregation Control protocol (LACP).
Round robin bonding mode is typically used by Linux systems. It transmits packets in sequential
order from the first available link through the last link in the bundle. This provides the best
distribution across the bonded interfaces. Normally this would be the best bonding mode to use, but
throughput can suffer because of packet ordering.
LACP bonding mode is similar to Balanced, except for the control protocol that communicates with
the other end and coordinates which links in the bond are available. It provides heartbeat failover.
LACP was originally defined in IEEE 802.3ad. 802.3ad was subsequently incorporated into the
IEEE 802.1AX-2008 specification which was in turn superseded by IEEE 802.1AX-2014.
Balanced bonding mode sends data over the interfaces as determined by the selected hash
method. All associated interfaces on the switch must be grouped into an EtherChannel (trunk).
EtherChannel is the bonding method defined by Cisco systems.

8. If the Bonding mode is LACP or Balanced, choose the bonding hash algorithm. The options are XOR-
L2, XOR-L2L3, or XOR-L3L4.
The XOR-L2 bonding hash selects the link over which to transmit a frame by using an XOR hash of
the source and destination Layer 2 (MAC) addresses. Using this method means that all traffic
destined for the same MAC address uses the same link in the bundle. For example, all traffic sent
to the default gateway uses the same link in the bundle regardless of the IP address of the ultimate
destination.
The XOR-L2L3 bonding selects the link over which to transmit a frame by using an XOR hash of the
source and destination Layer 2 and Layer 3 (IP) addresses. Using this method means that all traffic
destined for the same MAC address and IP address uses the same link in the bundle. Even so,
traffic sent to the default gateway for routing may use different links in the bundle if the traffic is
ultimately destined for different IP addresses. This also means that all traffic sent to the same IP
address through the same gateway will use the same link in the bundle.
The XOR-L3L4 bonding selects the link over which to transmit a frame by using an XOR hash of the
source and destination Layer 3 (IP) addresses and TCP or UDP port numbers. Using this method
means that all traffic destined for the same IP address and the same application connection uses
the same link in the bundle. This bonding hash method probably utilizes the links in the bundle to
the fullest, but also requires the most CPU power to process.
9. Select an interface to add to the aggregate configuration by clicking the checkbox corresponding to
the interface. Link aggregation not supported on 10 Gb single-port optical NICs, DD2500 ethMe and
ethMf interfaces, and DD4200, DD4500, DD7200 ethMA NICs.
10. Click Next and the Create Virtual Interface dialog box appears.

11. Enter an IP address and netmask for the virtual interface.
12. Specify the speed and duplex options that will be applied to all physical interfaces associated with the
virtual interface.
13. If necessary, configure the MTU. Verify the MTU settings with the network administrator before
modifying the configuration.
14. Click Next. A panel with the summary of the configuration should now appear.
15. Review the configuration summary.
16. If you are satisfied with the configuration, click Finish.
17. Observe as the virtual interface is created.
and reconfigure the interface.

1. Disable the physical interfaces using the net config <ifname> down CLI command.
2. Configure the Ethernet parameters on each physical NIC port using the net config <ifname> CLI
command. Ensure member ports, on the Data Domain system and the connected device, are
configured the same.
If you are including NIC ports with different media types in the virtual interface, check the
documentation to verify this is allowed with your hardware.
Verify the device connected to the Data Domain system supports compatible link aggregation
bonding mode and hash settings.
3. Create a virtual interface, using the net create virtual CLI command.
4. Configure link aggregation bonding using the net modify CLI command with the bonding aggregate
argument.
5. Add a physical NIC port to the virtual interface using the net aggregate add CLI command. The
bonding mode and hash must be configured when adding the first physical interface. They cannot be
configured later.
6. Assign an IP address and netmask to the virtual interface using the net config CLI command.
7. Enable the virtual interface using the net config <virtual-ifname> up CLI command.
8. Verify the configuration of the virtual interface using the net aggregate show CLI command. The net
aggregate show CLI command does not provide any output unless the virtual interface is up and
enabled.

Link aggregation performance is impacted by link and switch speed, the amount of information the Data
Domain system can process, out-of-order packets, the number of clients, and the number of streams.
The speed of the network switch or network link impacts performance when the amount of data has
exceeded the switch's capacity. Normally, a network switch can handle the speed of each connected link,
but it may lose some packets if all of the packets are coming from several ports that are concentrated on
one uplink running at maximum speed. In most cases, this means you can use only one switch for port
aggregation coming out of a Data Domain system. Some network topologies allow for link aggregation
across multiple switches.
Out-of-order packets can impact performance due to the processing time needed to reorder the packets.
Round robin link aggregation mode could result in packets arriving at the destination out-of-order. The
receiving device must reorder the data stream. This adds overhead that may impact the throughput speed
enough that the link aggregation mode causing the out-of-order packets should not be used.
The number of clients can also impact performance. In most cases, either the physical or OS resources
cannot drive data at multiple Gbps. Also, due to hashing limits, you need multiple clients to push data at
multiple Gbps.
The number of streams (connections) per client can significantly impact link utilization depending on the
hashing used.

This lesson covers virtual local area network (VLAN) and Internet protocol (IP) alias interfaces. First, you
will learn more about these interfaces and how they differ. Then, you will learn how to enable and disable
them using the System Manager.

VLANs and IP aliases are two methods of managing network traffic.
VLANs provide the segmentation services normally provided by routers in LAN configurations.
VLANs address issues such as scalability, security, and network management.
Routers in VLAN topologies provide broadcast filtering, security, address summarization, and traffic-
flow management.
Switches may not bridge IP traffic between VLANs as doing so would violate the integrity of the VLAN
broadcast domain.
By using VLANs, one can control traffic patterns and react quickly to relocations. VLANs provide the
flexibility to adapt to changes in network requirements and allow for simplified administration.
Partitioning a local network into several distinctive segments in a common infrastructure shared across
VLAN trunks can provide a very high level of security with great flexibility to a comparatively low cost.
Quality of Service schemes can optimize traffic on trunk links.
VLANs could be used in an environment to provide easier access to local networks, to allow for easy
administration, and to prevent disruption on the network.
IP aliasing is associating more than one IP address to a network interface. With this, one node on a
network can have multiple connections to a network, each serving a different purpose.

When you create a VLAN interface on a Data Domain system, you are essentially adding a 802.1Q tagged
virtual port to a physical interface. All Ethernet frames transmitted through the VLAN interface are tagged
with the assigned VLAN ID. Any frames received by the physical interface are directed to the VLAN
interface if they are tagged with the appropriate VLAN ID.
No IP address is required on the underlying network or virtual interface when you create a VLAN interface.
Unlike the VLAN interface, Network and Virtual Interfaces require untagged ports. Make sure to configure
the connected switch to support both packet types and all VLAN IDs configured on the Data Domain
system's physical interface.

To create a VLAN interface using DDSM, follow these steps.
2. In the interfaces table, select the interface to which you want to add the VLAN.
3. Click the Create button.
4. From the Create menu, select the VLAN... option. The Create VLAN Interface dialog box appears.

5. In the Create VLAN panel, specify a VLAN ID by entering a number in the VLAN Id field. The VLAN ID
can be any number from 1 to 4094. VLAN ID numbers 0 and 4095 are reserved by the IEEE. The
base interface and VLAN ID are used together to create the VLAN interface name. In the example on
screen, the VLAN Interface name is eth0b.1010.
6. Specify an IPv4 or IPv6 addresses along with the netmask or prefix.

7. If needed, specify the MTU setting.
The VLAN MTU must be less than or equal to the MTU defined for the physical or virtual interface to
which it is assigned.
If the MTU defined for the supporting physical or virtual interface is reduced below the configured
VLAN value, the VLAN value is automatically reduced to match the supporting interface.
If the MTU value for the supporting interface is increased above the configured VLAN value, the
VLAN value is unchanged.
To select the default MTU value (1500), click Default.
To select a different setting, enter the setting in the MTU box. DD System Manager does not accept
an MTU size that is larger than that defined for the physical or virtual interface to which the VLAN is
assigned.
8. Specify Dynamic DNS Registration option.

Dynamic DNS (DDNS) is a protocol that registers local IP addresses on a Domain Name System
(DNS) server. In this release, DD System Manager supports Windows mode DDNS. To use UNIX
mode DDNS, use the net ddns CLI command.
DDNS must be registered to enable this option.
9. Click Next. The Create VLAN summary page appears.
10. Review the configuration settings.
11. Click Finish.
12. Observe the user interface as the system configures the VLAN.
13. After successful completion of the VLAN interface configuration, click OK.

An IP alias assigns an additional IP address to a physical interface, a virtual interface, or a VLAN. An IP
alias interface does not operate as an independent interface. DD OS does not generate statistics for the
IP alias. Statistics are only provided for the base interface. The only function of an alias interface is to add
an additional IP address to the base interface.
Up to 100 IP aliases are supported. However, the recommended total number of IP aliases, VLAN,
physical, and virtual interfaces that can exist on the system is 80. Although up to 100 interfaces are
supported, as the maximum number is approached, you might notice slowness in the display.

The name of an IP alias interface name is derived from the base interface - which can be physical, VLAN,
or virtual - and the IP alias ID - which is assigned by the system administrator.
The format of an IP alias interface name is the base interface name, followed by a colon character (:),
which is then followed by the IP alias ID.
Using this format as a reference, we know that the ifname eth5a:35 refers to an IP alias assigned to the
physical interface and the IP alias's ID is 35.
The interface name veth4:26 refers to an IP alias assigned to virtual interface 4 and its ID is 26.
The IP alias interface name eth5a.82:162 is an IP alias assigned to VLAN 82, which in turn is assigned to
physical interface eth5a, and it the IP alias's ID is 162.
The acceptable IP alias ID values differ depending upon the user interface or CLI command used to create
the IP alias. If you use the Data Domain System Manager or the net create interface CLI command to
create the IP alias, IP Alias ID values from 1 to 4094 are supported. If you use the net config CLI
command, the IP Alias ID values from 1 to 9999 are supported.

To create an IP alias using DDSM, follow these steps.
2. In the interfaces table, select the interface to which you wish to add the IP alias. You may choose an
existing physical, VLAN, or virtual interface.
3. Click the Create button.
4. From the Create menu, select the IP Alias... option. The Create IP Alias dialog box appears.

5. Specify an IP alias ID by entering a number in the IP Alias Id box.
The IP Alias ID must be a number from 1 to 4094.
You cannot enter an IP Alias ID that is currently in use.
The IP alias name is created using a combination of the interface name, a colon character, and the
IP Alias ID. Using this format as a reference, we can tell that interface eth0a:1 is IP alias 1 applied
to the physical network interface eth0a. Also, we know that interface eth0a.20:4 is IP alias 4 and it
is applied to VLAN 20 on physical interface eth0a.
6. Enter an IPv4 and subnet mask or IPv6 address and prefix.
7. Specify Dynamic DNS Registration option.
Dynamic DNS (DDNS) is a protocol that registers local IP addresses on a Domain Name System
(DNS) server.
In this release, DD System Manager supports Windows mode DDNS.
To use UNIX mode DDNS, use the net ddns CLI command.
The DDNS must be registered to enable this option.
8. Click Next.
9. The Create IP Alias summary page appears.
10. Click finish.
11. Observe the user interface as the system configures the IP Alias.
12. After successful completion of the IP alias configuration, click OK.
13. Go to the interfaces table in the Hardware > Ethernet > Interfaces tab and select the newly configured
IP alias.
14. Review the details. As you can see, many of the details are inherited from the underlying base
interface.

To create an IP alias using the net config CLI command, use the following syntax:
net config <base-ifname>:<alias-id> <ipaddr> netmask <mask>
The base-ifname parameter expects a physical, VLAN , or virtual interface name.
The net config CLI command allows alias-id values from 1 to 9999. The alias-ID cannot be in use by
another alias.
On the screen are examples commands that show how the net config CLI command can be used to
assign an IP alias to physical, VLAN, and virtual interfaces.
To destroy or delete an IP alias using the net config CLI command, assign it IP address of 0.
Shown on screen are examples that demonstrate removing an IP alias from physical, VLAN, and virtual
interfaces by assigning the IP alias an IP address of 0 using the net config CLI command.

In this lesson, you will learn how to provide an overview of a fibre channel connection. You will also learn
how to configure a fibre channel port, endpoint, and initiator on a Data Domain system. You will also learn
how to describe N_Port ID Virtualization (NPIV) and how to manage VTL and DD Boost Groups.

Before you can start to configure a fibre channel connection for the Data Domain system, you will need to
verify some things.
1. First, is the FC switch properly zoned and communicating with the FC server and Data Domain
system?
2. Next, what is the server's WWPN? If needed, what is the server's IP address?
3. What name or alias do you wish to apply to the server? This name will be mapped to the WWPN on
the Data Domain system.
4. What is the Data Domain system's WWPN, IP address, and FC slot and port?

Fibre channel services, such as VTL and DD Boost, require the support of underlying components. These
components are grouped in the DDSM under the hardware configuration section. In this lesson, you will
learn how to manage the Fibre Channel HBA and Fibre Channel ports. You will also learn how to manage
the N_Port ID Virtualization (NPIV) feature, endpoints, initiators, and access groups. The order in which
these items will be covered is shown on the screen.

Before you start to configure the fibre channel hardware, verify the appropriate licenses have been
installed.
1. Navigate to the Administration > Licenses page of the Data Domain system manager.
2. Review the installed licenses.
3. Note: There is no fibre channel license.
4. However, services that require the support of fibre channel - such as VT L, DD boost, and I/OS - all
require licenses.

1. To use the Data Domain System Manager to review the fibre channel - or scsitarget - status, navigate
to the Hardware > Fibre Channel page.
2. Review the FC status shown at the top of the page.
The fibre channel status can only be changed through the CLI. Use the scsitarget enable CLI command
or the scsitarget disable CLI command to change the status.

Ports are discovered, and a single endpoint is automatically created for each port, at startup. The
properties of the base port depend on whether NPIV is enabled:
In non-NPIV mode, ports use the same properties as the endpoint, that is, the WWPN for the base port
and the endpoint are the same.
In NPIV mode, the base port properties are derived from default values, that is, a new WWPN is
generated for the base port and is preserved to allow consistent switching between NPIV modes. Also,
NPIV mode provides the ability to support multiple endpoints per port.
Ports must be enabled before they can be used. When you enable an FC port, any endpoints currently
using that port are also enabled. If the failback-endpoints feature is used, any fail-over endpoints that
use this port for their primary system address may be failed-back to the primary port from the
secondary port.
Disabling one or more SCSI target ports also disables any endpoints currently using that port. If
specified, the failover configured endpoints that use the target port(s) as their primary system address
will be failed-over if the secondary port is available. Endpoints that are already disabled by
administrative operation prior to a port being disabled are remembered as manually disabled. This
state will be restored when that port is later enabled.

1. To review the configuration of Fibre Channel ports, navigate to the Hardware > Fibre Channel >
Resources tab.
2. If necessary, click the plus sign (+) to expand the ports configuration summary table.
3. Review the configuration summary table
4. Select a port to view configuration details.
5. Review the configuration details.
The summary information includes the System Address, WWPN, WWNN and enabled status. Also
included are the NPIV status, the Fibre Channel Link status, and the operation status as well as the
number of endpoints configured on the system.
The detailed information section shows the Fibre Channel HBA Model, installed firmware version number,
port id, link speed, topology, and connection type.
System Address System address for port
WWPN Unique worldwide port name, which is a 64-bit identifier (a 60-bit value preceded by
a 4-bit Network Address Authority identifier), of the Fibre Channel (FC) port.
WWNN Unique worldwide node name, which is a 64-bit identifier (a 60-bit value preceded
by a 4-bit Network Address Authority identifier), of the FC node.
Enabled Port operational status; either Enabled or Disabled.
NPIV NPIV status; either Enabled or Disabled.
Link Status Link status: either Online or Offline; that is, whether or not the port is up and capable
of handling traffic.
Operation Status Operation status: either Normal or Marginal.
# of Endpoints Number of endpoints associated with this port.

To enable an FC port, follow this process.
1. After you navigate to the Hardware > Fibre Channel page, select More Tasks > Ports > Enable to
select the target ports. If all ports are already enabled, a message to that effect is displayed otherwise
the Enable ports dialogue box is displayed.
2. Select one or more ports from the list, and select Next.
3. After the confirmation, select next to continue to complete the port selection process.
4. Select the Failback endpoints option if you wish for endpoints that have been failed over to the
secondary port to be returned to this port if it is their primary port.
5. Select next to continue. The Enable Ports Status dialogue box appears.
6. Select Close if you do not wish to wait for the enable process to complete. A message is displayed
indicating the enable process will complete in the background.
7. Select OK to dismiss the information dialogue box.
8. Select Close if you wish to wait for the port enable process to complete. The dialogue box eventually
displays a completion message.
9. Select Close to dismiss the Enable Ports Status dialogue box.

Data Domain System Manager provides two methods to select and disable FC ports. The difference in
the methods is how the FC ports are selected. On screen is a walkthrough of the first port selection
process as well as the process to disable ports.
1. After you navigate to the Hardware > Fibre Channel > Resources tab, select More Tasks > Ports >
Disable... to select the target ports. If all ports are already disabled, a message to that effect is
displayed otherwise the Disable Ports dialogue box is displayed.
2. Select one or more ports from the list.
3. Select Next.
4. Select the Failover endpoints option if you wish for endpoints with this port configured as primary to
fail over to the secondary port.
5. Select next to continue. The Disable Ports Status dialogue box appears.
6. Wait for the disable process to complete and select Close to dismiss the Disable Ports Status dialogue
box.

1. After navigating to the Hardware > Fibre Channel > Resources tab, select the port to configure.
2. Select the Modify icon. The modify icon is represented by a pencil.
3. In the Configure Port dialog, select whether to automatically enable or disable NPIV for this port. This
option can only be modified if NPIV is globally enabled.
4. For Topology, select Default, Loop Only, Point to Point, or Loop Preferred.
5. For Speed, select 1, 2, 4, 8 or 16 Gbps, or auto.
6. Select OK.
7. Monitor the configuration process.
8. When the port configuration process completes, select Close.
The scsitarget port modify CLI command can also be used to configure the port. Modify options for SCSI
target ports.

Enabling NPIV
1. Navigate to the Hardware > Fibre Channel page.
2. Next to NPIV: Disabled, select Enable.
3. In the Enable NPIV dialog, you will be warned that all Fibre Channel ports must be disabled before
NPIV can be enabled. Also review any messages about correcting configuration errors and take
appropriate action. If you are sure that you want to enable NPIV, select Yes.
4. Monitor the Enable NPIV Status dialog box as NPIV is enabled.
5. Select Close when the NPIV enable process completes.
Disabling NPIV
Before you can disable NPIV, you must not have any ports with multiple endpoints.
1. Navigate to the Hardware > Fibre Channel page.
2. Next to NPIV: Enabled, select Disable.
3. In the Disable NPIV dialog, review any messages about correcting the configuration, and when ready,
select Yes.
4. Monitor the NPIV disable process.
5. When the NPIV disable configuration process completes, select Close.

1. To review the configuration of Fibre Channel endpoints, navigate to the Hardware > Fibre Channel >
Resources tab.
2. If necessary, click the plus sign (+) to expand the endpoint configuration summary table.
3. Review the configuration summary table
4. Select an endpoint to view configuration details.
5. Review the configuration details.
The summary information includes the endpoint name, WWPN, WWNN, system address currently in use
and if the address is primary or secondary, enabled status, and link status.
The detailed information section shows the primary system address, secondary system address, and if
FCP2 Retry is enabled.

If in non-NPIV mode, enabling an endpoint also enables the underlying port if it is currently disabled. In
NPIV mode, only the endpoint is enabled.
1. After navigating to the Hardware > Fibre Channel page, select More Tasks > Endpoints > Enable. If all
endpoints are already enabled, a message to that effect is displayed.
2. In the Enable Endpoints dialog, select one or more endpoints from the list.
3. Select Next.
4. Confirm the endpoints are correct and select Next. The Enable Endpoint Status dialogue box
appears.
5. Monitor the status of the Endpoint enable process.
6. Select Close when the process completes.
If in non-NPIV mode, disabling an endpoint also disables the underlying port if it is currently enabled. In
NPIV mode, only the endpoint is disabled.
1. After navigating to the Hardware > Fibre Channel page, select More Tasks > Endpoints > Disable... If
all endpoints are already disabled, a message to that effect is displayed.
2. In the Disable Endpoints dialog, select one or more endpoints from the list.
3. Select Next.
4. Confirm the endpoints are correct. If the endpoint is associated with an active service, a warning is
displayed. Select Disable and the Disable Endpoint Status dialogue box appears.
5. Monitor the status of the Endpoint disable process.
6. Select Close when the process completes.

1. After navigating to the Hardware > Fibre Channel > Resources tab, begin the Endpoint add process
by selecting the plus sign (+) to expand the endpoint configuration summary table if necessary.
2. Click the green plus icon to open the Add endpoint dialogue box.
3. In the Add Endpoint dialog, enter a Name for the endpoint. The endpoint name can be from 1 to 128
characters in length. The field cannot be empty or be the word all, and cannot contain the characters
asterisk (*), question mark (?), front or back slashes (/, \), or right or left parentheses [(,)].
4. For Endpoint Status, select Enabled or Disabled.
5. If NPIV is enabled, select a Primary system address from the drop-down list. The primary system
address must be different from any secondary system address.
6. If NPIV is enabled you can select the secondary address to use for fail over operations. If the
endpoint cannot be created, an error is displayed. Correct the error and retry. If there are no errors,
the system proceeds with the Endpoint creation process.
7. Monitor the system as the endpoint is created. The system notifies you when the endpoint creation
process has completed.
8. Select Close.

You may want to delete an endpoint if the underlying hardware is no longer available. However, if the
underlying hardware is still present, or becomes available, a new endpoint for the hardware is discovered
automatically and configured based on default values.
1. After navigating to the Hardware > Fibre Channel > Resources tab, begin the Endpoint delete process
by selecting the plus sign (+) to expand the endpoint configuration summary table if necessary.
2. Select the endpoint(s) you wish to remove from the system.
3. Select the delete icon represented by a red X. This icon is not active unless an endpoint is selected.
The Delete Endpoint dialogue box is displayed. If an endpoint is in use, you are warned that deleting it
might disrupt the system.
4. Verify the endpoints listed in the Delete Endpoint dialogue box are correct.
5. Click Delete.
6. Select Close when the endpoint delete process completes.

An initiator is the device that starts a SCSI session and sends SCSI commands. The initiator is usually a
backup server. On the Data Domain system, you must identify the initiators that are allowed to control the
system through SCSI commands. The worldwide port name (WWPN) assigned to an initiator's HBA port
is needed to identify an initiator to the Data Domain system.
An initiator name is an alias that maps to a initiator's WWPN. The Data Domain system uses the initiator
name to interface with the initiator for VTL activity.
Initiator aliases are useful because it is easier to reference a name than an eight-pair WWPN number
when configuring the system, including access groups.
For instance, you might have a host server with the name HP-1, and you want it to belong to a group HP-
1. You can name the initiator coming from that host server as HP-1. You can then create an access group
also named HP-1 and ensure that the associated initiator has the same name.
An initiator can be configured to support DD Boost over FC or VTL, but not both. A maximum of 1024
initiators can be configured for a Data Domain system.

To review the configuration of the fibre channel initiators, follow this process:
1. Select the Hardware > Fibre Channel > Resources tab.
2. Click the plus sign (+) at the top of the initiator section to expand the initiator configuration summary
table
3. Review the configuration of the initiators.
CLI Equivalent
scsitarget initiator show list ...
scsitarget initiator show detailed ...

Add an initiator to provide a Fibre Channel backup client with the ability to connect to the Data Domain
system.
1. After navigating to the Hardware > Fibre Channel > Resources tab, begin the Initiator Add process by
selecting the plus sign (+) to expand the endpoint configuration summary table if necessary.
2. Under Initiators, select Add (+ sign).
3. In the Add Initiator dialog, enter the WWPN for the device to be added to the system. Use the format
shown in the field.
4. Enter a Name for the initiator. This name is also called an Alias.
5. Select the Address Method:

1. Auto is used for standard addressing
2. Volume Set Addressing (VSA) is used primarily for addressing virtual buses, targets, and LUNs.
6. Select OK.
CLI Equivalent
# scsitarget group add My_Group initiator My_Initiator

1. After navigating to the Hardware > Fibre Channel > Resources tab, begin the Initiator delete process
by selecting the plus sign (+) to expand the initiator configuration summary table if necessary.
2. Verify the target initiator if offline and not a part of any access group. Otherwise, you will get an error
message, and the initiator will not be deleted.
You must delete all initiators in an access group before you can delete the access group.
If an initiator remains visible, it may be automatically rediscovered.
3. Select the target initiator from the initiator configuration summary table.
4. Select delete (red x).
5. A warning is provided in the Initiator Delete dialog box. Read the warning and Click OK if you wish to
proceed. Otherwise, click Cancel.
6. After the Delete Initiator process completes, Select OK.

In this module, you learned how to manage a Data Domain system's network interfaces. This included the
Ethernet interface and IP Configuration. You also learned to manage the software-based link aggregation,
link failover, and VLAN network interfaces. Finally, you learned how to configure the various components
associated with the fibre channel host bus adapter.

This module focuses on administration issues of configuring, managing and monitoring
CIFS, Common Internet Files System, and NFS, Network File System.

The Common Internet File System (CIFS) operates as an application-layer network protocol.
It is mainly used for providing shared access to files, printers, serial ports, and
miscellaneous communication between nodes on a network. When configured for CIFS
access a Data Domain system is able to communicate with MS Windows clients.
This lesson describes how to modify these settings and how to manage data access using
the Data Domain System Manager (DDSM) and the CLI.

The DD System Manager (DDSM) Protocols > CIFS indicates CIFS status. It can be
enabled or disabled.
Users with administrative privileges can perform major CIFS operations such as enabling
and disabling CIFS, setting authentication, managing shares, and viewing configuration and
share information. CIFS clients write data to a share.
The CLI command cifs status will show whether CIFS is enabled or disabled. To disable
CIFS, use the command cifs disable. To enable CIFS use cifs enable.

A Share enables a CIFS client to backup files to specified CIFS directory.
The /data/col1/backup directory is the default destination directory for compressed

backup server data. The /ddvar directory contains Data Domain system core and log files.
Clients, such as backup servers that perform backup and restore operations with a Data
Domain System, need access to the /data/col1/backup directory. Clients that have
administrative access need to be able to access the /ddvar directory to retrieve core and
log files.

By selecting a Share, we can see related detailed information. Here, we select the Share
Name backup and the Detailed Information including access settings is displayed. The
backup Share has Unlimited connections. Actually, there is a limit of 600 simultaneous
connections. However, the maximum number of connections supported is based on system
memory. Check the specifics of the Data Domain system.
Wildcard access to /data/col1/backup is assigned to all Clients, Users and Groups.
Selecting the Modify tab allows these settings to be altered.
The share name does not have to be the same name as the directory name. Here, the
share backup is the same name as the directory backup. It does not need to be the same
name if there is a preference. For example, you may create a path /data/col1/backup2
but prefer to call the share that points to backup2 as HR for easier identification of the
specific share assignment.

To create a Share, go to Shares > Create. A Data Domain system supports a maximum
number of 3000 CIFS shares.
The CLI command to create a Share is:
cifs share create share path path {max-connections max

connections | clients clients | users users | comment comment}
Note
The command accepts /backup as an alias for the default path /data/col1/backup
All other paths must be entered /data/col1/[folder name]

To create a Share go to Shares > Create. A Data Domain system supports a maximum
number of 3000 CIFS shares. The share name can be a maximum of 80 characters and
cannot contain any spaces or special characters like / ? <> ; , = or extended ASCII
characters.
In this example, our share name is HR. The directory name is /data/col1/backup2.
Client access needs to be assigned. To make a share available to all clients, use the
wildcard *. To make the Share available to only specific clients, use the client name or IP
address. It is not required to use both the name and the IP address.
Do not mix an * with client names or IP addresses. When an * is present in the list any
other client entries are not used.
In the Max Connections, the default value is Unlimited. A value of zero entered in the
adjacent option would have the same effect as Unlimited. Remember that there actually is
a limit of up to 600 simultaneous connections, but it is dependent on the specific Data
Domains system memory. Check the specifics of the Data Domain system being
configured.

Protocols > CIFS > Configuration allows you to view or modify the default CIFS
authentication settings. If the settings need to be changed, select Configure Options.

Configure Options allows you to modify three areas:
Restrict Anonymous Connections The default is disabled. Check Enable to restrict

anonymous connections.
Log Level Options are 1 5. One is the default system level that sends the least-
detailed level of CIFS-related log messages, five results in the most detail. Log messages
are stored in the file /ddvar/log/debug/cifs/cifs.log.
The higher the log level, the more likely it is to degrade system performance. Clicking the
Default in the Log Level sets the level back to 1.
Server Signing the options are: Enabled Disabled Required. The default is
Disabled. This feature is disabled by default because it degrades performance. When
enabled, it can cause a 29 percent (reads) to 50 percent (writes) throughput performance
drop, although individual system performance will vary.
Server Signing is a security mechanism in the CIFS protocol (a.k.a SMB Signing Server
Message Block was the original name of the CIFS protocol) and is also known as security
signatures. Server Signing is designed to help improve the security of the CIFS protocol by
having the communication digitally signed at the packet level. This enables the recipient of
the packets to confirm their point of origin and authenticity. This security mechanism in the
CIFS protocol helps avoid issues like tampering of packets. If the packet is changed from
the original packet that was sent by a CIFS client, it will be flagged as invalid by the Data
Domain server.

From a Windows client, you can access a CIFS share on a Data Domain system by going to:
1. Tools > Map Network Drive.
2. Select a drive letter type in the path to the shared folder enable Reconnect at
login and click on Connect using a different user name and Finish.
3. In the Connect As dialog, enter appropriate user credentials for the Data Domain
system, and click OK.
4. The new drive window will appear and can now accept backup files.

Protocols > CIFS will display the Connections information regarding the number of open
connections, open files, connection limit and open files limit per connection.
Selecting Connection Details will display specific information about Sessions and Open Files.
Sessions will display:
The computer IP address or computer name connected with DDR for the session.
The User indicates the user operating the computer and connected with the DDR.
The Open Files column refers to the number of open files for each session
The Connection Time shows the connection length in minutes.
Idle Time is the time since last activity of the user.
The Open Files section displays:
The User column which shows the name of the computer and the user on that computer.
The Mode column displays file permissions. The following values and their corresponding
permissions are:
0 No permission 1 Execute 2 Write 3 Execute and Write 4 Read
5 Read and Execute 6 Read and Write 7 All Permissions
The Locks column displays the number of file locks, if any.
Files displays the file location.
The CLI command cifs show stats will display basic statistics on CIFS activity and
performance.

This lab covers configuring CIFS on a Data Domain System.

This lesson covers the configuration and monitoring of NFS exports on a Data Domain
system.

The Network File System (NFS) is a distributed file system protocol. It allows a user on a
client computer to access files over a network in a manner similar to how local storage is
accessed. NFS, like many other protocols, builds on the Open Network Computing Remote
Procedure Call (ONC RPC) system. The Network File System is an open standard defined in
RFCs, allowing anyone to implement the protocol.
Network File System (NFS) clients can have access to the system directories or MTrees on
the Data Domain system:
The /ddvar directory contains Data Domain system, core, and log files.
The /data/col1 path is the top-level destination when using MTrees for compressed
backup server data.
Clients, such as backup servers that perform backup and restore operations with a Data
Domain system, need to mount an MTree under /data/col1. Clients that have
administrative access need to mount the /ddvar directory to retrieve core and log files.

To check the status of NFS in DDSM, go to Protocols > NFS. If it should be disabled, just
click on the Enable button.
In the CLI the command NFS Status will indicate if NFS is enabled or disabled. If it is not
active, NFS Enable will start the NFS server.

An Export must be created and specifies the path (directory) that NFS clients that can
access. The defaults settings are:
/backup
/data/ col1/backup
/ddvar
The Status column validates the path specified.
A Data Domain system supports a maximum number of 128 NFS exports and allows 900
simultaneous connections.
You have to assign client access to each export separately and remove access from each
export separately. For example, a client can be removed from /ddvar can still have access
to /data/col1/backup:
A single asterisk (*) as a wild card indicates that all backup servers are used as
clients.
Clients given access to the /data/col1/backup directory have access to the entire
directory.
Clients given access to a subdirectory under the /data/col1/backup have access
only to that subdirectory.

The default options for the Export path displayed in the graphic are:
rw - Enable read and write permissions (default value).
no_root_squash - Turn off root squashing. This is the default value.
Root squash is a reduction of the access rights for the remote superuser, the root,
when using authentication. It is a feature of NFS. So no_root_squash basically
means that the administrator has complete access to the path, the Export.
no_all_squash - Turn off the mapping of all user requests to the anonymous uid/gid
(default value).
secure - Require that requests originate on an Internet port that is less than
1024. Kerberos uses port 88.
nolog - The system will not log NFS requests. If enabled, this option may impact
performance.
In CLI the command nfs add path client-list [(option-list)] will add NFS clients to
an Export.
The options-list is comma or space separated, enclosed by parentheses. If no option is

specified, the default options are rw, root_squash, no_all_squash, and secure.

Kerberos is an authentication protocol which works on the basis of tickets to allow nodes
communicating over a non-secure network to prove their identity to one another in a secure
manner of mutual authenticationboth the user and the server verify each other's identity.
Kerberos uses UDP port 88 by default.
It can be configured in DDSM from the NFS screen. Configure will open Adminstration >
Access > Authentication

Here is the Administration > Access > Authentication screen that will appear after
selecting Kerberos Mode Configure from the NFS screen in DDSM.
Note the options.
If Disabled, NFS clients will not use Kerberos authentication and CIFS clients will default to
Workgroup authentication.
If Windows / Active Directory is enabled then both NFS and CIFS clients will use
Kerberos authentication.
Selecting UNIX will mean that only NFS clients will use Kerberos authentication. CIFS
clients will default to Workgroup authentication.

In DDSM Protocols > NFS > Active Clients will display any NFS clients that have been
connected in the past 15 minutes and their mount path.
You can use the CLI to monitor NFS client status and statistics with the following
commands:
nfs show active will List clients active in the past 15 minutes and the mount path
for each. Allow all NFS-defined clients to access the Data Domain system.
nfs show clients will list NFS clients allowed to access the Data Domain system and
the mount path and NFS options for each.
nfs show detailed-stats will display NFS cache entries and status to facilitate
troubleshooting.

This lab covers configuring NFS on a Data Domain System.

This module focused on administration issues of configuring, managing, and monitoring
CIFS, Common Internet Files System, and NFS, Network File System.

This module focuses on the MTree data structure and how to perform basic tasks to mange
data in a Data Domain file system.

This lesson covers an introduction to MTrees, their use and management.

MTrees (Management Trees) are actually specific directories/folders used to provide more
granular management of data so different types of data, or data from different sources, can
be managed and reported on, separately. Various backup operations are directed to
individual MTrees. For example, you can configure directory export levels and quotas to
separate and manage backup files by department such as HR or Sales.

MTrees are only created under /data/col1. /data/col1/backup is default MTree. These
directory names cannot be renamed or deleted.
Subdirectories can be created within user-created MTrees. the Data Domain system
recognizes and reports on the cumulative data contained within the entire MTree.

Increased granular reporting of space and deduplication rates is a benefit in case you
might have different departments or geographies backing up to the same Data Domain
system. Each department or geography could have their own independent storage location.
The term, snapshot, is a common industry term denoting the ability to record the state of a
storage device or a portion of the data being stored on the device, at any given moment,
and to preserve that snapshot as a guide for restoring the storage device, or portion
thereof. Snapshots are used extensively as a part of the Data Domain data restoration
process. With MTrees, snapshots can be managed at a more granular level.
Retention lock, is an optional feature used by Data Domain systems to securely retain
saved data for a given length of time and protecting it from accidental or malicious deletion.
Retention lock feature can now be applied at the MTree level.
Another major benefit is to limit the logical, pre-comp, space used by the specific MTree
through quotas.

A Data Domain system supports a maximum of MTrees and a maximum number of
concurrently active MTrees. Depending on the system, the maximum number of
configurable MTrees may or may not be the same as the number of concurrently active
MTrees.
For example, a DD 9800 running DD OS 6.0 supports 256 MTrees 256 concurrently active
MTtrees while a DD 9500 running OD 5.6 supports 100 MTrees and 64 concurrently active
MTrees. Refer to the Data Domain Operating System Administration Guide for specific
limits for various Data Domain Systems and versions of DD OS.
Be aware that, system performance might degrade if more than the recommended number
MTrees are concurrently engaged in read or write streams. The degree of degradation
depends on overall I/O intensity and other file system loads. For optimum performance,
constrain the number of simultaneously active MTrees. When possible, aggregate
operations on the same MTree into a single operation.

MTree quotas allow you to set limits on the amount of logical, pre-comp space used by
individual MTrees. Quotas can be set for MTrees used by CIFS, NFS, VTL, or DD Boost data.
There are two types of quotas:

Soft limit: When this limit is reached, an alert is generated through the system, but
operations continue as normal.
Hard limit: When this limit is reached, any data in the process of backup to this
MTree fail. An alert is also generated through the system, and an out of space error
(EMOSP for VTL) is reported to the backup app. In order to resume backup operations
after data within an MTree reaches a hard limit quota, you must either delete sufficient
content in the MTree, increase the hard limit quota, or disable quotas for the MTree.
You can set a soft limit, a hard limit, or both soft and hard limits. If you set both limits, the
soft limit must be less than the hard limit. The smallest quota that can be set is 1 MiB.
An administrator can set the storage space restriction for an MTree to prevent it from
consuming excess space.

To create an MTree in the System Manager:
Go to Data Management > MTree > Create.
A Create MTree dialog appears.
Type the name of the MTree you are creating in the MTree name field. Names are
case-sensitive.
Quota Settings are disabled by default. They can be set at the same time that an MTree is
created, or they can be set after creating the MTree. Quotas can be set and managed using
the System Manager or the CLI. The advantage of MTree operations is that quotas can be
applied to a specific MTree as opposed to the entire file system.
As data fills the MTree, Data Domain System Manager will display graphically and by
percentage the quota hard limit. You can view this display at Data Management > MTree.
The MTree display presents the list of MTrees, quota hard limits, daily and weekly pre-comp
and post-comp amounts and ratios.
The following CLI command can be used to create an Mtree :

mtree create <mtree-path>

To enable Quotas go to Data Management > Quota and select the Mtree to specify
Quotas.
You can also disable/enable quotas from the command line:

quota disable
Disables quota function.
quota enable
Enables quota function.
quota status
Shows status for quota function.

Selecting Configure Quota now opens the Quota Settings and allows the option to set
Soft or Hard limits on the selected MTree. Note that /data/col1/backup can only have a
Soft Limit set. It will not allow a Hard limit to be configured.
You can also set quotas from the CLI with the command:
quota set {all | mtrees <mtree-list> | storage-units <storage-unit-list>}
{soft-limit <n> {MiB|GiB|TiB|PiB} | hard-limit <n> {MiB|GiB|TiB|PiB} |
soft-limit <n> {MiB|GiB|TiB|PiB} hard-limit <n> {MiB|GiB|TiB|PiB}}
quota enable

When Quotas are set, the Data Management > Quota screen will display the values.

Data Management > MTree provides a summary of all configured MTrees, their quota
hard limits (if set), pre- and post-comp usage, as well as compression ratios for the last 24
hours, the last 7 days, and current weekly average compression. Select an MTree, and the
Summary pane presents current information about the selected MTree.
Note: The information on this summary page may be delayed by up to 10-15 minutes. For
immediate data select Update.
For real-time monitoring of MTrees and quotas, the following commands can be used from
the command prompt:
mtree show compression <mtree_path> [tier {active | archive}] [summary | daily

| daily-detailed] {[last <n> { hours | days | weeks | months } | [start <date>
[end <date>]]}
Show MTree compression statistics.
quota capacity show {all | mtrees <mtree-list> | storage-units <storage-unit-

list> | tenant-unit <tenant-unit>}
List quotas for MTrees and storage-units.

Data Management > Mtree also provides a graphical representations of Space Usage and Daily Written
for an MTree at certain points in time.
In Space Usage by clicking on a specific point the graph will display the pre-comp written for that date and
time. This is the total amount of data sent to the MTree by backup servers. Pre-compressed
data on an MTree is what a backup server sees as the total uncompressed data held by an
MTree-as-storage-unit.
The Daily Written display shows the flow of data over the last 24 hours. Data amounts are
shown over time for pre and post-compression.
Pre-Comp Written is the total amount of data written to the MTree by backup servers.
Post-Comp Written is the total amount of data written to the MTree after compression has
been performed, as shown in GiBs.

Health > Alerts > will display MTree Quota alerts. They will be displayed in all the tabs
Current Alerts, Alerts History, Notification, and Daily Alert Summary.
Soft limit: When this limit is reached, an alert is generated through the system, but
operations continue as normal. The Severity level is Warning.
Hard limit: When this limit is reached, any data in the process of backup to this
MTree fail. An alert is also generated through the system, and an out of space error
(EMOSP for VTL) is reported to the backup app. In order to resume backup operations
after data within an MTree reaches a hard limit quota, you must either delete sufficient
content in the MTree, increase the hard limit quota, or disable quotas for the MTree.
The Severity level is Critical.
These alerts are also reported in the Home Dashboard > Alerts pane.

NFS and CIFS can access /data and all of the MTrees within /col1 by configuring normal
CIFS shares and NFS exports.

In this lab you will configure a Snapshot and recover data from that Snapshot.

This lesson covers an introduction to configuring, using, and monitoring snapshots.

Snapshot is a common industry term denoting the ability to record the state of a storage
device or a portion of the data being stored on the device, at any given moment, and to
preserve that snapshot as a guide for restoring the storage device, or portion thereof.
A snapshot primarily creates a point-in-time, read-only copy of the designated MTree of a

specific time. You can use a snapshot as a restore point.
A snapshot copy is made instantly and is available for use by other applications for data
protection, data analysis and reporting, and data replication. The original copy of the data
continues to be available to the applications without interruption, while the snapshot copy is
used to perform other functions on the data.
Snapshots enable better application availability, faster recovery, and easier back up
management of large volumes of data.
Snapshots continue to place a hold on the original data they reference even when the
backups have expired.
Snapshots are useful for saving a copy of Mtrees at specific points in time for instance,
before a Data Domain OS upgrade which can later be used as a restore point if files need
to be restored from that specific point in time.
You can schedule multiple snapshots at the same time or create them individually as you
choose.
The maximum number of snapshots allowed to be stored on a Data Domain system is 750
per MTree. You receive a warning when the number of snapshots reaches 90% of the
allowed number (675-749) in a given MTree. An alert is generated when you reach the
maximum snapshot count.

Snapshot copies only the metadata pointers to the production data for a specific point in
time. In this case, 22:24 GMT. The copy is extremely quick and places minimal load on the
production systems. The snapshot can be later used as a restore point, if needed.

When changes occur to the production data (in this case segments 1 and 2 are no longer
part of the file) and additional data is written (segments 5 and 6), then the file system
removes the pointers to the original data no longer in use and adds pointers to the new
data. The original data segments (1 and 2) are still stored, allowing the snapshot metadata
pointers to continue to point to the data as saved at the specific point in time. Data is not
overwritten, but changed data is added to the system, and new pointers are written.
When changed production data is backed up, additional blocks are written, and pointers are
changed to access the changed data. The snapshot maintains pointers to the original, point-
in-time data. All data remains on the system as long as pointers reference the data.
Snapshots are a point-in-time view of a file system. They can be used to recover previous
versions of files, and also to recover from an accidental deletion of files.

As an example, snapshots for the MTree named backup are created in the system
directory /data/col1/backup/.snapshot. Each directory under /data/col1/backup also has a
.snapshot directory with the name of each snapshot that includes the directory. Each MTree
has the same type of structure, so an MTree named HR would have a system directory
/data/col1/HR/.snapshot, and each subdirectory in /data/col1/HR would have a .snapshot
directory as well.
Use the snapshot feature to take an image of an MTree, to manage MTree snapshots and
schedules, and to display information about the status of existing snapshots.

To create a Snapshot in the System Manager:
Go to Data Management > Snapshots
Select an MTree from the Selected MTree dropdown list:
If snapshots are listed, you can search by using a search term in the Filter By
Name or Year field.
You can modify the expiration date, rename a snapshot or immediately expire any
number of selected snapshots from the Snapshots pane.
Click Create and a snapshot dialog appears. This allows the the snapshot to be
named, and an expiration date set. If you do not set a date, the snapshot will not
release the data to which it is pointing until you manually remove the snapshot.
The CLI command that will create a Snapshot is:
snapshot create <snapshot> mtree <mtree-path> [retention {<date> | <period>}]

In the System Manager, create a schedule for a series of snapshots by doing the following:
From the Schedules tab, click Create.
Follow the Snapshot Schedule Wizard to define a name, naming pattern, the
schedule for recurring snapshot events, and the retention period before the snapshots
expire.
A summary window appears allowing you to approve the schedule.
Multiple Snapshots can be added to the same schedule.
You can also create and manage snapshot schedules using the command line:
snapshot schedule create <name> [mtrees <mtree-list>] [days <days>] time
<time> [,<time>...] [retention <period>] [snap-name-pattern <pattern>]

In the MTree summary page there is a section called MTree Replications and that section
contains Snapshot information.
The Snapshots pane in the MTree summary page allows you to see at-a-glance, the total
number of snapshots collected, expired, and unexpired, as well as the oldest, newest, and
next scheduled snapshot.
You can associate configured snapshot schedules with a selected MTree name. Click Assign
Snapshot Schedules, select a schedule from the list of snapshot schedules and assign it.
You can create additional snapshot schedules if needed.

In this lab you will configure a Snapshot and recover data from that Snapshot.

This lesson covers Fast Copy operations and their use in a Data Domain file system.

Fast Copy makes an alternate copy of your backed up data on the same Data Domain
system. Fast Copy is very efficient at making duplicate copies of pointers to data.
Sometimes, access to production backup data is restricted. Fast Copy gives access to all
data fast copied readable and writeable, making this operation handy for data recovery
from backups.
The difference between snapshots and fast copied data is that the Fast Copy duplicate is not
a point-in-time duplicate. Any changes that are made during the data copy, in either the
source or the target directories, will not be duplicated in the Fast Copy.
Note that Fast Copy is a read/write copy of a point-in-time copy at the time it was made
and a snapshot is read-only.
Fast Copy makes a copy of the pointers to data segments and structure of a source to a
target directory on the same Data Domain system.
You can use the Fast Copy operation to retrieve data stored in snapshots. In this example,
the /HR MTree contains two snapshots in the /.snapshot directory. One of these snapshots,
10-31-2016, is fast copied to /backup/Recovery. Only pointers to the actual data are
copied, adding a 1% to 2% increase in actual used data space. All of the referenced data is
readable and writable. If the /HR MTree or any of its contents is deleted, no data referenced
in the Fast Copy is deleted from the system.

To perform a Fast Copy from the System Manager:
Navigate to Data Management > File System > Fast Copy.
Enter the data source and the destination (target location).
Enter the pathname for the directory where the data to be copied resides.
If you want to copy a snapshot created in the finance MTree, to a destination named,
financeCopy in the /backup MTree, use the path to the given snapshot as the source
and the full path to the directory, financeCopy, in the destination field.]
Specifying a non-existent directory creates that directory. Be aware that the destination
directory must be empty or the Fast Copy operation will fail. You can choose to overwrite
the contents of the destination by checking that option in the Fast Copy dialog window.
You can also perform a Fast Copy from the command line. The following command copies a
file or directory tree from a Data Domain system source directory to a destination on the
Data Domain system: filesys fastcopy source <src> destination <dest>

The Fast Copy operation can be used as part of a data recovery workflow using a snapshot.
Snapshot content is not viewable from a CIFS share or NFS mount, but a Fast Copy of the
snapshot is fully viewable. From a Fast Copy on a share or a mount, you can recover lost
data without disturbing normal backup operations and production files.
Fast Copy makes a destination equal to the source, but not at a particular point in time. The
source and destination may not be equal if either is changed during the copy operation.
This data must be manually identified and deleted to free up space. Then, space
reclamation (file system cleaning) must be run to regain the data space held by the Fast
Copy. When backup data expires, a Fast Copy directory will prevent the Data Domain
system from recovering the space held by the expired data because it is flagged by the Fast
Copy directory as in-use.

In this lab you will configure Fast Copy and recover data from a Snapshot using Fast Copy.

This lesson covers an introduction to file system cleaning and its operation.

When your backup application expires data, the Data Domain system marks the data for
deletion. The data is not deleted immediately; it is removed during a cleaning operation.
The file system is available during the cleaning operation 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.
Depending on the amount of space the file system must clean, file system cleaning can take
from several hours to several days to complete.

Data invulnerability requires that data be written only into new, empty containers data
already written in existing containers cannot be overwritten. This requirement also applies
to file system cleaning. During file system cleaning, the system reclaims space taken up by
expired data so you can use it for new data.
The example in this figure refers to dead and valid segments. Dead segments are segments
in containers no longer needed by the system, for example, claimed by a file that has been
deleted and was the only/or final claim to that segment, or any other segment/container
space deemed not needed by the file system internally. Valid segments contain unexpired
data used to store backup-related files. When files in a backup are expired, pointers to the
related file segments are removed. Dead segments are not allowed to be overwritten with
new data since this could put valid data at risk of corruption. Instead, valid segments are
copied forward into free containers to group the remaining valid segments together. When
the data is safe and reorganized, the original containers are appended back onto the
available disk space.
Since the Data Domain system uses a log structured file system, space that was deleted
must be reclaimed. The reclamation process runs automatically as a part of file system
cleaning.
During the cleaning process, a Data Domain system is available for all normal operations, to
include accepting data from backup systems.
Cleaning does require a significant amount of system processing resources and might take
several hours, or under extreme circumstances days, to complete even when undisturbed.
Cleaning applies a set processing throttle of 50% when other operations are running,
sharing the system resources with other operations. The throttling percentage can be
manually adjusted up or down by the system administrator.

Using the Data Domain System Manager, navigate to Data Management > File System >
View Status of File System Services to see the Active Tier Cleaning Status. This
displays the time when the last cleaning finished. To begin an immediate cleaning session
select Start.
Access the Clean Schedule section by selecting Settings > Cleaning. This displays the
current cleaning schedule, and throttle setting. In this example, we can see the default
schedule - every Tuesday @ 6 a.m. and 50% throttle. The schedule can be edited.

Schedule cleaning for times when system traffic is lowest. Cleaning is a file system
operation that impacts overall system performance.
Adjusting the cleaning throttle higher than 50% consumes more system resources during
the cleaning operation and can potentially slow down other system processes.
Data Domain recommends running a cleaning operation after the first full backup to a Data
Domain system. The initial local compression on a full backup is generally a factor of 1.5 to
2.5. An immediate cleaning operation gives additional compression by another factor of
1.15 to 1.2 and reclaims a corresponding amount of disk space.
Any operation that shuts down the Data Domain file system or powers off the device (a
system power-off, reboot, or filesys disable command) stops the clean operation. File
system cleaning does not continue when the Data Domain system or file system restarts.

Encryption and gz compression requires much more time than normal to complete cleaning
as all existing data needs to be read, uncompressed, and compressed again.
Expiring files from your backup does not guarantee that space will be freed after cleaning. If
active pointers exist to any segments related to the data you expire, such as snapshots or
fast copies, those data segments are still considered valid and will remain on the system
until all references to those segments are removed.
Daily file system cleaning is not recommended as frequent cleaning can lead to increased
file fragmentation. File fragmentation can result in poor data locality and, among other
things, higher-than-normal disk utilization.
If the retention period of your backups is short, you might be able to run cleaning more
often than once weekly. The more frequently the data expires, the more frequently file
system cleaning can operate. Work with Dell EMC Data Domain Support to determine the
best cleaning frequency under unusual circumstances.
When the cleaning operation finishes, a message is sent to the system log giving the
percentage of storage space that was reclaimed.

This lab covers configuring file system cleaning and testing and monitoring file system
cleaning.

This lesson covers how to monitor Data Domain file system space useage.

When a disk-based deduplication system such as a Data Domain system is used as the
primary destination storage device for backups, sizing must be done appropriately.
Presuming the correctly sized system is installed, it is important to monitor usage to ensure
data growth does not exceed system capacity.
The factors affecting how fast data on a disk grows on a Data Domain system include:
The size and number of data sets being backed up. An increase in the number of
backups or an increase in the amount of data being backed-up and retained causes
space usage to increase.
The compressibility of data being backed up. Pre-compressed data formats do not
compress or deduplicate as well as non-compressed files and thus increase the
amount of space used on the system.
The retention period specified in the backup software. The longer the retention period,
the larger the amount of space required.
If any of these factors increase above the original sizing plan, your backup system could
easily overrun its capacity.
There are several ways to monitor the space usage on a Data Domain system to help
prevent system full conditions.

Data Management > File System > Summary displays current space usage and
availability. It also provides an up-to-the-minute indication of the compression factor.
The Space Usage section shows two panes.
The first pane shows the amount of disk space available and used by file system
components, based on the last cleaning.
Size: The amount of total physical disk space available for data.
Used: The actual physical space used for compressed data. Warning messages go to the
system log, and an email alert is generated when the use reaches 90%, 95%, and 100%.
At 100%, the Data Domain system accepts no more data from backup hosts.
Available: The total amount of space available for data storage. This figure can change
because an internal index may expand as the Data Domain system fills with data. The index
expansion takes space from the Available amount.
Cleanable: The estimated amount of space that could be reclaimed if a cleaning operation
were run.
The bottom pane displays compression information:
Pre-Compression: Data written before compression
Post-Compression: Storage used after compression
Global-Comp Factor: Pre-Compression / (Size after global compression)
Local-Comp Factor: (Size after global compression) / Post- Compression
Total-Comp Factor: Pre-Compression / Post-Compression
Reduction %: [(Pre-Compression - Post-Compression) / Pre-Compression]

Data Management > File System > Charts displays graphs depicting space usage and
consumption on the Data Domain system.
The Space Usage view contains a graph that displays a visual representation of data usage
for the system. The time frame choices are one week, one month, three months, one year,
and All. Custom date ranges can also be entered. The above graph is set for 7 days.
The lines of the graph denote measurement for:

Pre-comp Used (blue)The total amount of data sent to the Data Domain system by
backup servers. Pre-compressed data on a Data Domain system is what a backup
server sees as the total uncompressed data held by a Data Domain system-as-storage
unit. Shown with the Space Used (left) vertical axis of the graph.
Post-comp Used (red)The total amount of disk storage in use on the Data Domain
system. Shown with the Space Used (left) vertical axis of the graph.
Comp Factor (green)The amount of compression the Data Domain system has
performed with the data it received (compression ratio). Shown with the Compression
Factor (right) vertical axis of the graph.

The Consumption view contains a graph that displays the space used over time, shown in
relation to total system capacity.
It displays Post-Comp in red, Comp Factor in green, Cleaning in yellow, and Data Movement
in purple.
Data Movement refers to the amount of disk space moved to the archiving storage area.
The Archive license is required for this.
With the Capacity option greyed out, as shown on the slide, the scale is adjusted in order
to present a clear view of space used. In this example, ~9 GiB Post-Comp has been stored
on a 62.78 TiB Capacity and a Comp Factor of 79x.
This view is useful to note trends in space availability on the Data Domain system, such as
changes in space availability and compression in relation to cleaning processes.

The Consumption view with the Capacity option enabled, as shown on the slide, displays
the total amount of disk storage available for data on the Data Domain system. The amount
is shown with the Space Used (left) vertical axis of the graph.
Clicking the Capacity checkbox toggles this line on and off. The scale now displays Space
Used relative to the total capacity of the system, with a blue Capacity line indicating the
storage limit.
This view also displays cleaning start and stop data points. This graph is set for one week
and displays one cleaning event. The cleaning schedule on this Data Domain system is at
the default of one day per week.
This view is useful to note trends in space availability on the Data Domain system, such as
changes in space availability and compression in relation to cleaning processes.

Physical capacity measurement (PCM) provides space usage information for a subset of storage
space. From the DD System Manager, PCM provides space usage information for MTrees, but from the
command line interface you can view space usage information for Mtrees, Tenants, Tenant Units,
and pathsets.
For more information about using PCM from the command line, see the EMC Data Domain Operating
System Command Reference Guide.
At a system level, shared data is calculated only once. and is reported to each namespace that is
sharing the data subset along with their unique data.
Physical Capacity Measurement can answer questions like, how much physical space is each subset
using? How much total compression is each subset reporting? How does physical space utilization for
a subset grow and shrink over time? How can one tell whether a subset has reached its physical
capacity quota? And what proportion of the data is unique and what proportion is shared with other
subsets?
With IT as a service (ITAAS), Physical Capacity Measurement can be used to calculate chargeback
details for internal customers or billing details for third-party customers sharing space on a Data
Domain system.
Using physical capacity measurement, it is now possible to enforce data capacity quotas for physical
space use where previously only logical capacity could be calculated. These types of measurements
are essential for customer chargeback and billing.
Through physical capacity measurement, IT management can view trends in customers physical
storage, plan capacity needs, identify poor datasets, and identify accounts that might benefit by
migrating to a different storage space for growth purposes.
The Data Domain System Manager can configure and run physical capacity measurement operations
at the MTree level only.
The Data Domain Management Center version 1.4 and later is enhanced to perform all of the physical
capacity measurement operations except defining pathsets.

In the DD System Manager, when physical capacity measurement is enabled, you add
physical capacity measurement schedules, one, in the Data Management > MTree window
by, two, selecting an MTree then, three, clicking the Manage Schedules button.
Four, click the plus, pencil, or X button to add, edit, or delete a schedule, respectively.
When a measurement job completes, the results are graphed and are viewed under the
selected MTree in the Space Usage tab.

The Daily Written view contains a graph that displays a visual representation of data that
is written daily to the system over a period of time. The data amounts are shown over time
for pre- and post-compression amounts.
It is useful to see data ingestion and compression factor results over a selected duration.
You should be able to notice trends in compression factor and ingestion rates.
Global-Comp Factor refers to the compression of the files after deduplication.
Local-Comp Factor refers to the compression of the files as they are written to disk. The
default Local compression is lz. lz is the default algorithm that gives the best throughput.
Data Domain recommends the lz option.
Gzfast is a zip-style compression that uses less space for compressed data, but more CPU
cycles (twice as much as lz). Gzfast is the recommended alternative for sites that want
more compression at the cost of lower performance.
gz is a zip-style compression that uses the least amount of space for data storage (10% to
20% less than lz on average; however, some datasets get much higher compression). This
also uses the most CPU cycles (up to five times as much as lz). The gz compression type is
commonly used for nearline storage applications in which performance requirements are
low.
For more detailed information on these compression types refer to the Data Domain
Operating System Administration Guide.

This lesson covers Data Domain storage migration, its purpose, process, and how to
monitor migration status.

Storage migration supports the replacement of existing storage enclosures with new
enclosures that may offer higher performance, higher capacity, and a smaller footprint.
After new enclosures are installed, you can migrate the data from the older enclosures to
the new enclosures while the system continues to support other processes such as data
access, expansion, cleaning, and replication. The storage migration requires system
resources, but you can control this with throttle settings that give migration a relatively
higher or lower priority. You can also suspend a migration to make more resources available
to other processes, then resume the migration when resource demand is lower.
You can check the storage migration status in the Hardware > Storage tabs.
A license is required to use the storage migration feature.

Storage migration requires a single-use license and operates on system models running DD
OS version 5.7 or later. The destination enclosures must be supported on the system model
and must have at least as much usable capacity as the source enclosures they are
replacing.
Migration between enclosures with identical raw capacity can fail if the usable capacity on
the destination is less than that on the source. For example, enclosures with higher capacity
disk drives can have a proportionately larger usable capacity than that for enclosures with
smaller capacity disk drives. In this situation, a migration to the enclosures with smaller
drives might fail if data storage in the source enclosures is approaching full capacity.

Data migration is not supported for disks in the system controller.
Although the DD OS can be upgraded while a migration is taking place, we recommend that
you do not upgrade DD OS during the migration finalize phase.
Storage migration cannot start when the file system is disabled or while a DD OS upgrade is
in progress, another migration is in progress, or a RAID reconstruction is in progress.
All specified source enclosures must be in the same tier (active or archive). Further, there
can be only one disk group in each source enclosure, and all disks in the disk group must be
installed within the same enclosure.

After migration begins, the destination enclosures cannot be removed. Source enclosures
cannot be removed until migration is complete and finalized.
The storage migration duration depends on the system resources (which differ for different
system models), the availability of system resources, and the data quantity to migrate.
Storage migration can take days or weeks to complete depending on the scope of your data
backups.

To start migrating storage in Data Domain System Manager (DDSM) go to Hardware >
Storage > Overview > Migrate Data. If the Status states Storage operational this
indicates the Storage Migration license is installed.

Selecting Migrate Data gives two options: Estimate or Migrate. This estimate does more
than just give a time estimation for the duration of the migration. It performs checkpoints
that must be passed in order for migration to go forward.

The Existing Enclosures list displays the enclosures that are eligible for storage migration.
Select the checkbox for each of the enclosures to migrate. Click Next when you are ready to
continue.
In our example, we select an ES20 enclosure as the source for our migration.

Next, we select the new enclosure. We are going to migrate data from an ES20 enclosure
to an ES30 enclosure.
This screen also displays the storage license status and an Add Licenses button.
The Available Enclosures list displays the enclosures that are eligible destinations for
storage migration. We have selected an ES30 enclosure as our destination.
The license status bar represents all of the storage licenses installed on the system. The
green portion represents licenses that are in use, and the and clear portion represents the
licensed storage capacity available for destination enclosures. If you need to install
additional licenses to support the selected destination controllers, click Add Licenses.
For example, An Expanded-Storage license is required to expand the active tier storage
capacity beyond the entry capacity. Be aware that the capacity supported varies by Data
Domain model.

This Review Migration Plan gives an estimate of the 3 phases of the migration process.
The three phases are:

1. Prepare the system for migration.
2. Migrate the data.
3. Finalize the migration.
Remember that a Storage Migration can take hours, days, or weeks depending on the
amount of data being migrated.
The Storage Migration that was used to create these screens was taken from a Data
Domain system in a lab test environment. It does not represent the amount of data that
would be found in a real-life environment. This is why the times are fairly short for the
duration of a Storage Migration.

These are the preconditions that must be passed before a migration can begin.
P1. This system's platform is supported. Only Data Domain systems with 5.7 OS or greater
support Storage Migration.
P2. Source enclosures are not part of the head unit. Migration is not supported for disks in
the system controller.
P3. The Migration Storage license is installed.
P4. No other migration is in progress.
P5. Notice there is no P5 listed because this checks to see that the current migration
request is the same as the interrupted migration request. This would only apply if we had
paused the migration and then re-started it.
P6. Check the disk group layout on the existing enclosures. Storage migration requires that
each source enclosure contain only one disk group, and all the disks in the group must be in
that enclosure.
P7. Verify the final system capacity. The total system capacity after migration and the
removal of the source enclosures must not exceed the capacity supported by the DD
system model.
P8. Verify the replacement enclosures' capacity. The usable capacity of the destination
enclosures must be greater than that of the source enclosures.
P9. Source enclosures are in the same active tier or retention unit. The system supports
storage migration from either the active tier or the retention tier. It does not support
migration of data from both tiers at the same time.
P10. Replacement enclosures are addable to storage. All disks in each destination enclosure
must be of the same type (for example, all SATA or all SAS).
P11. No RAID reconstruction is occurring in the source controllers. Storage migration
cannot start while a RAID reconstruction is in progress.

Once the Preconditions have been checked, Migrate can be selected to start the process.
It is not necessary to run the Estimate first, but if the preconditions are not met, the
migration will be halted. It is recommended to run Estimate first so we will know that the
migration will run. We will also know the estimated duration of the migration and plan
accordingly.

Previously we had specified the source enclosure for the Estimate, now we are getting
ready for the actual migration. We select the ES20 as the source of the migration.

Previously we had specified the destination enclosure for the Estimate, now we are getting
ready for the actual migration. We select the ES30 as the migration destination.

Selecting Start will begin the migration process. The storage migration cannot be aborted.
It can however, be paused.

There are three stages of the Storage Migration process.
During the first stage, the progress is shown on the progress bar and no controls are
available.

During the second stage, data is copied from the source enclosures to the destination
enclosures and the progress is shown on the progress bar. Because the data copy can take
days or weeks to complete, controls are provided so that you can manage the resources
used during migration and suspend migration when resources are needed for other
processes.
You can click Pause to suspend the migration and later click Resume to continue the
migration.
The Low, Medium, and High buttons define throttle settings for storage migration
resource demands. A low throttle setting gives storage migration a lower resource priority,
which results in a slower migration and requires fewer system resources. Conversely, A high
throttle setting gives storage migration a higher resource priority, which results in a faster
migration and requires more system resources. The medium setting selects an intermediate
priority.
You do not have to leave this dialog open for the duration of the migration. To check the
status of the migration after closing this dialog, select Hardware > Storage and view the
migration status. To return to this dialog from the Hardware/Storage page, click Manage
Migration. The migration progress can also be viewed by selecting Health > Jobs.
When finished, it will display Migrate - Copy Complete.

When the stage two copy is complete, the migration process waits for you to click Finalize.
During this final stage, which takes 10 to 15 minutes, the filesystem is restarted and the
system is not available.
It is a good practice to start this stage during a maintenance window or a period of low
system activity.
No backups can occur during the Finalize stage.

The migration is completed once the file system has been restarted. The old enclosure is
now inactive.

Once Storage Migration has completed, the ES20 enclosure that we previously selected to
migrate from is no longer active.

Here are some things to consider before migrating data storage to for a Data Domain
system.
Storage migration is supported only in DD OS 5.7 and later versions.
Even when a Data Domain system is outfitted with a maximum recommended number of
shelves attached, the storage migration feature can accommodate additional, destination
shelves, but only for the purpose of data migration.
When migrating storage to new expansion shelves, all of the attached destination storage
becomes a part of the file system. The destination storage must be of a capacity within the
limits of the maximum capacity supported on the source Data Domain system. If there is
not enough capacity to support the amount of data found at the source or if the destination
file system size exceeds the maximum amount of storage allowed by the source system,
the storage migration feature reports the conflict during the pre-check phase and does not
allow the data transfer to the destination storage.
Storage migration supports extended retention, always within the same tier, either active or
archive.

MTrees can be configured so that different types of data, or data from different sources, can
be managed and reported on separately.
You can set limits on the amount of logical, pre-comp, space used by individual MTrees
using MTree hard and soft quotas.
Snapshots enable you to save a read-only copy of an MTree at a specific point in time.
Fast copy gives read/write access to all data fast copied, making this operation handy for
data recovery from snapshots.
The default time scheduled for File system cleaning is every Tuesday at 6 a.m. EMC
recommends running cleaning once per week at a time of low network activity.
Frequent cleaning, more than once per week, is not recommended. It can cause poor
deduplication and increased file fragmentation.

Use the Space Usage, Consumption, and Daily Written views in the File System tab to
monitor data ingestion and compression rates over time.
Total compression factor is the pre-compression rate divided by the post-compression rate.
Storage migration supports the replacement of existing storage enclosures with new
enclosures that may offer higher performance, higher capacity, and a smaller footprint.

Replication of deduplicated, compressed data offers the most economical approach to the automated
movement of data copies to a safe site using minimum WAN bandwidth. This ensures fast recovery in
case of loss of the primary data, the primary site or the secondary store.
This module covers the following lessons:

Data Replication
Configuring Replication
Monitoring Replication
Data Recovery

This lesson provides an overview of Data Domain replication including collection, directory, and MTree
replication. Replication seeding is also covered.

Replication consists of a source Data Domain system and one or more destination Data Domain systems. It provides
a secondary copy replicated (usually) to an offsite location for:
Disaster recovery
Remote office data protection
Multiple site tape consolidation
In a replication scenario, a local Data Domain system can be used to store backup data onsite for a short period,
such as 30, 60, or 90 days. Lost or corrupted files can be recovered easily from the local Data Domain system.
The replication process allows you to quickly copy data to another system (typically offsite) for a second level of
disaster recovery when the data on the local system is unavailable.
Replication occurs in real time and does not require that you suspend backup operations. Data is replicated after it
has been deduplicated and compressed on the source system.
The replication process only copies information that does not exist on the destination system. This technique reduces
network demands during replication because only unique data segments are sent over the network.
The replication process is designed to deal with network interruptions common in the WAN and to recover gracefully
with very high data integrity and resilience. This ensures that the data on the replica is in a state usable by
applications a critical component for optimizing the utility of the replica for data recovery and archive access.
If the local data becomes unavailable, the offsite replica may be used to ensure operations continue.
The data on the replica can be restored to the local site using a few simple recovery configuration and initiation
commands. The replication process allows you to quickly move data offsite (with no delays in copying and moving
tapes).
Replication is a software feature that requires an additional license. You need a replicator license for both the source
and destination Data Domain systems.

Together, the replication source and destination are called a pair. The connection that is defined between
the replication source and destination is a context. This means that a single replication pair can have
multiple replication contexts.
A Data Domain system can simultaneously be the source of some replication contexts and the destination
for other contexts.

A replication context can support multiple replication streams. The stream resource utilization within a
Data Domain system is roughly equivalent to a read stream (for a source context) or a write stream (for a
destination context).
The count of replication streams per system depends upon the processing power of the Data Domain
system on which they are configured. Smaller, less powerful systems can be limited to only 15 source and
20 destination streams, while the most powerful Data Domain system can handle over 200 streams.

Data Domain Replicator software offers four replication types.
Collection replication: This performs whole-system mirroring in a one-to-one topology, continuously

transferring changes in the underlying collection, including all of the logical directories and files of the Data
Domain file system. This type of replication is very simple and requires fewer resources than other types;
therefore it can provide higher throughput and support more objects with less overhead.
Directory replication: A subdirectory under /backup and all files and directories below it on a source
system replicates to a destination directory on a different Data Domain system. This transfers only the
deduplicated changes of any file or subdirectory within the selected Data Domain file system directory.
Directory replication can also be used to replicate a media pool if the pool is using backward-compatibility
mode.
MTree replication: This is used to replicate MTrees between Data Domain systems. Media pools can
also be replicated. By default (as of DD OS 5.3), MTrees (that can be replicated) are used when a media
pool is created.
It uses the same WAN deduplication mechanism as used by directory replication to avoid sending
redundant data across the network. The use of snapshots ensures that the data on the destination is
always a point-in-time copy of the source with file consistency, while reducing replication churn, thus
making WAN use more efficient. Replicating individual directories under an MTree is not permitted with
this type.
Managed File Replication: A fourth type, managed replication, belongs to Data Domain Boost
operations and is discussed later in this course.

Data Domain supports various replication topologies in which data flows from a source to a destination
over a LAN or WAN.
One-to-one replication is the simplest type of replication is from a Data Domain source system to a Data
Domain destination system. This replication topology can be configured with directory, MTree, or
collection replication types.
With bi-directional replication, data from a directory or MTree on System A is replicated to System B,
and from another directory or MTree on System B is replicated to System A.
With one-to-many replication, data flows from a source directory or MTree on a System A to several
destination systems. You could use this type of replication to create more than two copies for increased
data protection, or to distribute data for multi-site usage.
With many-to-one replication MTree or directory replication data flows from several source systems to a
single destination system. This type of replication can be used to provide data recovery protection for
several branch offices at the corporate headquarters IT systems.
Cascaded replication: In a cascaded replication topology, a source directory or MTree is chained among
three Data Domain systems. The last hop in the chain can be configured as collection, MTree, or directory
replication, depending on whether the source is directory or MTree.
For cascaded configurations, the maximum number of hops is two, that is, three DD systems.
For example, the first DD system replicates one or more MTrees to a second DD system, which then
replicates those MTrees to a final DD system. The MTrees on the second DD system are both a
destination (from the first DD system) and a source (to the final DD system). Data recovery can be
performed from the non-degraded replication pair context.

A destination Data Domain system must have available storage capacity that is at least the size of the
expected maximum size of the source directory. Be sure that the destination Data Domain system disk
space to handle all data from replication sources. Also, verify there is enough network bandwidth to
support the expected replication traffic.
The source must exist.
The destination must not exist.
The destination will be created when a context is built and initialized.
After replication is initialized, ownership and permissions of the destination are always identical to those of
the source.
You can usually replicate only between machines that are within two releases of each other, for example,
from 5.6 to 6.0. However, there may be exceptions to this (as a result of atypical release numbering), so
review the user documentation.
The Data Domain file system must be enabled or, based on the replication type, will be enabled as part of
the replication initialization.
In the replication command options, a specific replication pair is always identified by the destination.
Both systems must have an active, visible route through the IP network so that each system can resolve
its partner's host name.
During replication, a Data Domain system can perform normal backup and restore operations.

Collection replication replicates the entire /data/col1 area from a source Data Domain system to a
destination Data Domain system. Collection replication uses the logging file system structure to track
replication. Transferring data in this way means simply comparing the heads of the source and destination
logs, and catching-up, one container at a time, as shown in this diagram. If collection replication lags
behind, it continues until it catches up.
Collection replication is the fastest and lightest type of replication offered by the DD OS. There is no on-
going negotiation between the systems regarding what to send. Collection replication is mostly unaware of
the boundaries between files. Replication operates on segment locality containers that are sent after they
are closed.
With collection replication, all user accounts and passwords are replicated from the source to the
destination. However, as of DD OS 5.5.1.0, other elements of configuration and user settings of the DD
system are not replicated to the destination; you must explicitly reconfigure them after recovery.
If the Data Domain system is a source for collection replication, snapshots are also replicated.
Because there is only one collection per Data Domain system, this is specifically an approach to system
mirroring. Collection replication is the only form of replication used for true disaster recovery. The
destination system cannot be shared for other roles. It is read-only and shows data only from one source.
After the data is on the destination, it is immediately visible for recovery.

The DD system to be used as the collection replication destination must be empty before configuring
replication. After replication is configured, this system is dedicated to receive data from the source system.
The destination immediately offers all backed up data, as a read-only mirror, after it is replicated from the
source.
The destination system is a read-only system. It can only accept data from the replication process. No
data, including snapshots and files, can be written to the destination system except through the replication
process. If you must write data to the destination, you must first disable replication by breaking the
replication context. Unfortunately, if the context has been broken, a resync cannot be performed.
Collection replication supports Retention Lock Compliance. Of course, it must be licensed on both
systems.
Data Domain Replicator software can be used with the optional Encryption of Data at Rest feature,
enabling encrypted data to be replicated using collection replication. Collection replication requires the
source and target to have the exact same encryption configuration because the target is expected to be an
exact replica of the source data. In particular, the encryption feature must be turned on or off at both
source and target and if the feature is turned on, then the encryption algorithm and the system
passphrases must also match.
Encryption parameters are checked during the replication association phase. During collection replication,
the source system transmits the encrypted user data along with the encrypted system encryption key. The
data can be recovered at the target, because the target machine has the same passphrase and the same
system encryption key.

With directory replication, a replication context pairs a directory, under /data/col1/backup and all files and
directories below it on a source system with a destination directory on a different system. The source and
destination directories can be on different levels under the ../backup directory.
Directory replication operates based upon filesystem activity. When activity occurs on the system, such
as a new directory, change of permissions, file rename, or file closed, the source system communicates
the update to the destination. In cases where file closures are infrequent, the Data Domain source system
forces the data transfer periodically.
If there is new user file data to be sent, the source first creates a list of file segment IDs in the file. The
source then sends this list to the destination system. The destination system examines the list of segment
IDs to determine which are missing. The destination then sends a list of the missing segments to the
source. The source now sends the missing segments to the destination. In this way, bandwidth between
the source and destination system is used more efficiently.

Directory replication supports 1-to-1, bi-directional, many-to-one, one-to-many, and cascaded topologies.
If the Data Domain system is a source for directory replication, snapshots within that directory are not
replicated. You must create and replicate snapshots separately.
Directory replication can receive backups from both CIFS and NFS clients as long as separate directories
are used for each. Do not mix CIFS and NFS data in the same directory.
The directory replication source cannot be the parent or the child of a directory that is already being
replicated.

When replication is initialized, a destination directory is created automatically if it does not already exist.
In a directory replication pair, the destination is always read-only. The destination can only receive data
only from the source system and directory. If you need to write to the destination directory outside of
replication, you must first break (delete) the replication context between the two systems. Breaking the
context is also referred to as deleting the link.
The destination directory can coexist on the same system with other replication destination directories,
replication source directories, and other local directories.

MTree replication enables the creation of disaster recovery copies of MTrees at a secondary location.
With the exception of the /data/col1/backup directory, MTree replication can be applied to any MTree
under the /data/col1.
MTree replication copies the data segments associated with the entire MTree structure. This means that
all metadata, file data, and everything else related to the MTree is replicated.
MTree replication uses snapshots to determine what to send to the destination.

1. First, the MTree replication source creates periodic snapshots.
2. The source compares the latest snapshot against the snapshot that was used for the last
replication transfer and creates a delta list of segment IDs that were not included in the last
snapshot.
3. The source transmits this delta list to the destination.
4. The destination examines the delta list and sends back a list of what it still needs.
5. The source transmits the of needed data segments to the destination.
The destination Data Domain system does not expose the replicated data until all of the data for that
snapshot has been received. This ensures the destination is always a point-in-time image of the source
Data Domain system. Because the directory tree structure is part of the data included in the snapshot,
files do not show out of order at the destination. This provides file-level consistency. Snapshots are also
replicated.
MTree uses the same WAN deduplication mechanism as used by directory, and collection, replication to
avoid sending redundant data across the network. It also supports the same topologies that directory
replication supports.

Replication is a major feature that takes advantage of MTree structure on the Data Domain system. MTree
structure and flexibility provides greater control over its data being replicated. Careful planning of your
data layout will allow the greatest flexibility when managing data under an MTree structure.
MTree replication works only at the MTree level. If you want to implement MTree replication, you must
move data from the existing directory structure within the /backup MTree to a new or existing MTree, and
create a replication pair using that MTree.
For example, suppose that a Data Domain system has shares mounted in locations under /backup as
shown in the directory-based layout.
If you want to use MTree replication for your production (prod) data, but are not interested in replicating
any of the development (dev) data, the data layout can be modified to create two MTrees: /prod and /dev,
with two directories within each of them. The old shares would then be deleted and new shares created for
each of the four new subdirectories under the two new MTrees. This would look like the structure shown in
the MTree-based layout.
The Data Domain system now has two new MTrees, and four shares as earlier. You can set up MTree
replication for the /prod MTree to replicate all of your production data and not set up replication for the /dev
MTree as you are not interested in replicating your development data.

General
MTree replication is supported from DD Extended Retention systems to non-DD Extended
Retention systems if both are running DD OS 5.5 or later.
Retention Lock Compliance is supported with MTree replication, by default. If Retention Lock is
licensed on a source, the destination must also have a Retention Lock license, or replication will fail.
To avoid this situation, you must disable Retention Lock on the MTree. If Retention Lock is enabled
on a replication context, a replicated destination context will always contain data that is Retention
Locked.
MTree replication supports 1-to-1, bi-directional, one-to-many, many-to-one, and cascaded
replication topologies.
Remember, the number of MTrees allowed on a system is dependent upon the Data Domain
system model in use. Also, there is a limit to the number of active MTrees supported on a system.
The active MTree limit is also based upon the Data Domain system model.
Source
Data can be logically segregated into multiple MTrees to promote greater replication performance.
Replicating directories under an MTree is not permitted. Therefore, a directory below the root of an
MTree cannot be the replication source.

Destination
If the context is configured, the destination MTree is kept in a read-only state and can receive data
only from the source MTree.
A destination Data Domain system can receive backups from both CIFS clients and NFS clients as
long as they are in separate MTrees.
Snapshots
Snapshots must be created on source contexts.
Snapshots cannot be created on a replication destination.
Snapshots are replicated with a fixed retention of one year; however, the retention is adjustable on
the destination and must be adjusted there.
VTL
Replicating VTL tape cartridges (or pools) simply means replicating MTrees or directories that
contain VTL tape cartridges. Media pools are replicated by MTree replication, as a default.
A media pool can be created in backward-compatibility mode and can then be replicated via
directory-based replication. You cannot use the pool:// syntax to create replication contexts using
the command line. When specifying pool-based replication in DD System Manager, either directory
or MTree replication will be created, based on the media pool type.

If the source Data Domain system has a high volume of data prior to configuring replication, the initial
replication seeding can take some time over a slow link. To expedite the initial seeding, you can bring the
destination system to the same location as the source system to use a high-speed, low-latency link.
After data is initially replicated using the high-speed network, you then move the system back to its
intended location.
After data is initially replicated, only new data is sent from that point onwards.
All replication topologies are supported for this process.

This lesson shows how to configure replication using DD System Manager, including low-bandwidth
optimization (LBO), encryption over wire, using a non-default connection port, and setting replication
throttle.

REPL Context URLs
The CLI, system logs, and other facilities use a replication URL to identify the endpoints of a context on
the replication source and destination systems. On screen are some example replication URL contexts.
The replication context type is identified in the part of the URL known as the scheme. The scheme is also
referred to as the protocol or prefix portion of a URL.
A URL scheme of "dir" identifies a directory replication context. An "mtree" URL scheme identifies an
MTree replication context. A URL scheme of col identifies a collection replication context.
The host-name portion of the URL the same as the output of the net show hostname CLI command. The
path is the logical path to the target directory or MTree. The path for a directory URL must start with
/backup and end with the name of the target directory. The path for an MTree URL starts with /data/col1
and ends with the name of the target MTree. The path is not part of a collection URL.
Reference
Uniform Resource Locator - http://en.wikipedia.org/wiki/Uniform_resource_locator

1. To review the configuration of the replication feature, navigate to the Replication > Automatic >
Summary tab. The replication summary table provides you high-level information about the
configuration of each context.
2. Selecting a context causes the system to display detailed information about that context in the
Detailed Information section of the screen.

Remember to scroll down to see all detailed information pertaining to the selected context.
Since collection, MTree, and directory contexts have different requirements, the detailed information
shown changes depending on the context type.

Before you can configure replication between two systems using DDSM, you must first enable the
destination Data Domain system to be managed by the source system. This process is called adding a
system.
1. When you add a partner system, first make sure the partner system being added is running a
compatible DD OS version.
2. Next, navigate to Replication > Automatic > Summary tab.
3. Select Manage Systems. The Manage System Dialogue box appears listing the devices this Data
Domain system is currently configured to manage.
4. Select the add icon which is represented by the green plus sign (+). The Add System dialogue box
appears.
5. Enter the partner system's host name and the password assigned to the sysadmin user.

6. If the connection to the partner system must be made through a proxy or by using a custom port
number, expand the More Options sections to configure this information. The default port used to
connect to the proxy is 3009.
The source system transmits data to a destination system listen port. As a source system can have
replication configured for many destination systems (each of which can have a different listen port),
each context on the source can configure the connection port to the corresponding listen port of the
destination.
7. Select OK when the information for the partner system is complete. Select OK. The Verify Certificate
dialogue box appears.

8. After verifying the information on the screen, select OK. If the system certificate is not verified, the
Verify Certificate dialog shows details about the certificate. Check the system credentials. Select OK if
you trust the certificate, or select Cancel.
9. If the system was successfully added, DDSM returns to the Manage Systems dialogue box and the
newly added partner system is listed.
10. Select Close.

If the partner system is unreachable after adding it to DD System Manager, make sure that there is a route
from the managing system to the system being added. If a hostname (either a fully qualified domain name
(FQDN) or non-FQDN) is entered, make sure it is resolvable by both systems. Configure a host name for
the source and destination replication system, ensure a DNS entry for the system exists, or ensure an IP
address to hostname mapping is defined.
If you identify the systems using an IPv6 addresses are supported only when adding a DD OS 5.5 or later
system to a management system using DD OS 5.5 or later.

To create a replication pair and context, follow these steps.
1. First , navigate to the Replication > Automatic > Summary tab.
2. Next, select Create Pair. The Create Pair Dialogue box appears.
3. Select the Create tab.
4. Select the replication direction for the context. If the device being configured is the source for the
context, select Outbound. If the device being configured is the destination in the context, select
Inbound.
5. Now, select the replication type.

1. To create a replication pair with a collection context, select collection from the dropdown Replication
Type field.
2. Provide the destination system's hostname.
3. If the destination system is not listed in the dropdown menu, add it at this time by selecting the Add
System hyperlink.
4. Select OK to initiate the configuration process.
5. If the file system on the replication source is enabled, a warning is displayed. Select OK to continue
or Cancel to go back.
6. Monitor the system as the replication context is created.
7. After the Create Pair process completes, select Close.

1. To create a replication pair with a directory context, select Directory from the dropdown Replication
Type field.
System hyperlink.
4. Provide the name of the source directory.
5. Provide the name of the destination directory. The source and destination directories must be under
the /data/col1/backup directory MTree. The source and destination directories are not required to be
on the same directory level.
6. Select OK implement the configuration.
7. Monitor the system as it verifies the destination system is qualified as a destination for a directory
replication context.

1. To create a replication pair with an MTree context, select MTree from the dropdown Replication Type
field.
System hyperlink.
4. Provide the name of the source MTree.
5. Provide the name of the destination MTree. The source and destination MTrees must be directly
under /data/col1/ in the filesystem. The source and destination MTrees are required to be at the same
directory level.
6. Select OK implement the configuration.
7. Monitor the system as it verifies the destination system is qualified as a destination for an MTree
replication context.

The listen port is the TCP port the replication destination system monitors for incoming connections. This
is a global setting. All contexts for which this system is a destination monitor this port.
This means all replication source systems must be configured to connect to this particular port value.
On the right side of the screen are three replication source systems. All are supposed to connect to the
single replication destination on the left side of the screen.
Because the replication destination has a default listen port value of 2051, each replication source needs
to have a corresponding connection port value of 2051. The top two systems are configured correctly, but
the bottom right system has an incorrect connection port value that prohibits it from successfully
replicating to the destination system.
You can modify the listen port option if the default connection between the replication and source are
impacted by a firewall configuration or other network issues.
The connection port is the TCP port the source system uses to communicate to the replication destination.
The connection port is configured per context. It is not a global setting. The default value for the
connection port is 2051.

1. When using DDSM, you can specify a non-default Listen port value by first navigating to the
Replication > Automatic > Advanced Settings tab on the system.
2. Verify the current Listen Port value.
3. Select Change Network Settings. The Network Settings dialogue box appears.
4. Enter the new Listen Port value or select Default if you wish to change the Listen Port value back the
default value.
5. Click OK when finished.

When using DDSM, you can specify a non-default connection port value when you create the context, or
the value can be modified after the context is created.
1. If you are creating a context with a non-default value, navigate to the Replication > Automatic >
Summary tab on the source system.
2. Select Create Pair to create a new replication pair.
3. Complete the configuration of the Create Pair > Create tab.
4. Select the Advanced tab.
5. Select the checkbox Use Non-default Connection Host.
6. Change the Connection Port to a new value.

1. If you are changing an existing context to contain a non-default connection value, navigate to the
Replication > Automatic > Summary tab on the source system.
2. Select a context from the context summary table.
3. Select Modify Settings to modify an existing replication pair.
4. Select the checkbox Use Non-default Connection Host.
5. Change the Connection Port to a new value.
6. Click Next to continue with the context modification process.

Low bandwidth optimization (LBO) is an optional mode that enables remote sites with limited bandwidth to
replicate and protect more of their data over existing networks.
LBO can reduce WAN bandwidth utilization. It is useful if file replication is being performed over a low-
bandwidth WAN link.
LBO reduces bandwidth utilization by providing additional compression during data transfer.
Only enable LBO for replication contexts that are configured over WAN links with less than 6 Mb per
second of available bandwidth.
Do not use LBO if maximum file system write performance is required.
LBO can be applied on a per-context basis to all file replication jobs on a system.
Additional tuning might be required to improve LBO functionality on your system. Use bandwidth and
network-delay settings together to calculate the proper TCP buffer size, and set replication bandwidth for
replication for greater compatibility with LBO.
LBO is enabled on a per-context basis. LBO must be enabled on both the source and destination Data
Domain systems. If the source and destination have incompatible LBO settings, LBO will be inactive for
that context.

Replication without deduplication can be expensive, requiring either physical transport of tapes or high
capacity WAN links. This often restricts it to being feasible for only a small percentage of data that is
identified as critical and high value.
Reductions through deduplication make it possible to replicate everything across a small WAN link. Only
new, unique segments need to be sent. This reduces WAN traffic down to a small percentage of what is
needed for replication without deduplication. These large factor reductions make it possible to replicate
over a less-expensive, slower WAN link or to replicate more than just the most critical data.
Delta compression is a global compression algorithm that is applied after identity filtering. The algorithm
looks for previous similar segments using a sketch-like technique that sends only the difference between
previous and new segments. In this example, segment S1 is similar to S16. The destination can ask the
source if it also has S1. If it does, then it needs to transfer only the delta (or difference) between S1 and
S16. If the destination doesnt have S1, it can send the full segment data for S16 and the full missing
segment data for S1.
Delta comparison reduces the amount of data to be replicated over low-bandwidth WANs by eliminating
the transfer of redundant data found with replicated, deduplicated data. This feature is typically beneficial
to remote sites with lower-performance Data Domain models.

Create Context with LBO enabled
When using DDSM, you can enable LBO when you create the context, or the LBO setting can be modified
after the context is created.
1. If you wish to create a context with LBO enabled, navigate to the Replication > Automatic >
Summary tab on the source system.
5. Select the checkbox Use Low Bandwidth Wire.

Modify LBO on Existing Context
1. If you wish to change the LBO setting on an existing context, navigate to the Replication >
Automatic > Summary tab on the source system.
3. Select Modify Settings to modify an existing replication context.
4. Enable or disable the Use Low Bandwidth Optimization checkbox.

You can enable the encryption over wire feature on a replication context to secure replication traffic
between source and destination. Use this feature if you are concerned about security of the link between
the two systems.
It is important to note, when configuring encrypted file replication, that it must be enabled on both the
source and destination Data Domain systems. Encrypted replication uses the ADH-AES256-SHA cipher
suite and can be monitored through the Data Domain System Manager.
When you enable the encryption over wire option on a replication context, the system must first process
the data it reads from the disk. If you have the data at rest encryption feature enabled, the source system
must decrypt the data before it can be processed for replication. Otherwise, the data is simply read from
the source system.
Prior to transmitting the data to the destination system, the replication source encrypts the data using the
encryption over wire algorithm.
When the replication destination system receives the replication traffic, it must decrypt it using the
encryption method employed by the replication feature.
If the data at rest encryption feature is enabled on the destination Data Domain system, the data must be
encrypted by the destination using the method specified by the data at rest encryption feature.
If the data at rest encryption feature is not enabled, the destination system writes the data to the disk using
normal processes.

Create Context with Encryption Over Wire
When using DDSM, you can enable the encryption over wire feature when you create the context. You
can also modify the encryption over wire setting after the context is created.
1. If you wish to create a context with Encryption over Wire enabled, navigate to the Replication >
Automatic > Summary tab on the source system.
5. Select the checkbox Enable Encryption Over Wire.

Modify the Encryption Over Wire Setting on Existing Contexts
1. If you wish to change the Encryption Over Wire setting on an existing context, navigate to the
Replication > Automatic > Summary tab on the source system.
3. Select Modify Settings to modify an existing replication context.
4. Enable or disable the Enable Encryption Over Wire \checkbox.

To modify the amount of bandwidth used by a network for replication, you can set replication throttle for
replication traffic.
The Throttle Settings area shows the current settings for any Temporary Overrides. If an override is
configured, this section shows the throttle rate, or 0 which means all replication traffic is stopped. The
throttle Settings area also shows the currently configured Permanent Schedule. You should see the time
for days of the week on which scheduled throttling occurs.
1. To add throttle settings, navigate to the Replication > Automatic > Advanced Settings tabs.
2. Select the Add Throttle Setting button. The Add Throttle Setting dialog box appears.
3. Set the days of the week that throttling is active by clicking the checkboxes next to the days.
4. Set the time that throttling starts with the Start Time selectors for the hour, minute and A.M./P.M.
5. In the Throttle Rate area, Click the Unlimited radio button to set no limits.
6. Enter a number in the text entry box (for example, 20000) and select the rate from the drop-down
menu (bps, Bps, Kibps, or KiBps).
7. Select the 0 Bps (Disabled) option to disable all replication traffic.
8. Click OK to set the schedule.
9. Select to override the current throttle configuration, select Set Throttle Override. The throttle override
dialogue box appears.
10. If you select the Clear at next scheduled throttle event checkbox, the throttle schedule will return to
normal at that time. If you do not select this option, the override throttle stays in affect until you
manually clear it.
11. Select OK to invoke the Throttle Override setting. The overrides schedule is shown in the Throttle
Settings Permanent Schedule area.

You can also configure replication from the command line. When using the command line, some
commands such replication add and replication break need to be run on both the source and destination
systems.
replication enable {<destination> | all}
Enables replication.
replication disable {<destination> | all}
Disables replication.
replication add source <source> destination <destination>
[low-bw-optim {enabled | disabled}]
[encryption {enabled | disabled}]
[propagate-retention-lock {enabled | disabled}]
[ipversion {ipv4 | ipv6}]
[max-repl-streams <n>]
[destination-tenant-unit <tenant-unit>]
Creates a replication pair.
replication break {<destination> | all}
Removes the source or destination DD system from a replication pair.
replication initialize <destination>
Initialize replication on the source (configure both source and destination first).
replication modify <destination> {source-host | destination-host} <new-host-name>
replication modify <destination> connection-host <new-host-name> [port <port>]
Modifies connection host, hostname, encryption, and LBO.

You can enable LBO from the command line. The low-bw-optim enable or disable directive can be
included in the command line when you add or modify a context. Since LBO is disabled by default, there
is no need to use the disabled option when adding a context.
# replication add low-bw-optim enabled
# replication modify low-bw-optim enabled
# replication modify low-bw-optim disabled
The Encryption Over Wire feature can also be controlled from the command line. The encryption enable
or disable directive can be included in the command line when you add or modify a context. Since
Encryption over the wire is disabled by default, there is no need to use the disabled option when adding a
context.
# replication add encryption enabled
# replication modify encryption enabled
# replication modify encryption disabled
Modify the connection port using the following command syntax:

# replication modify <destination-REPL-URL> connection-host hostname port <new-port-number>
Note, you must first disable the context before the connection port can be modified.
Modify the listen port using the following command syntax:
# replication option set listen-port <port>
# replication option reset listen-port

You can also use the command line to enable and modify throttle settings:
replication throttle add <sched-spec> <rate>

Add a throttle schedule.
replication throttle add destination <host> <sched-spec> <rate>

Add a destination specific throttle.
replication throttle del <sched-spec>

Delete a throttle schedule.
replication throttle reset {current | override | schedule | all}

Reset (to default) throttle configuration.
replication throttle set current <rate>

Set a current override.
replication throttle set override <rate>

Set a permanent override.
replication throttle show [KiB]

Show throttle configuration.

This lesson covers the Replication Reports provided by the Data Domain system.

Data Domain System Manager allows you to generate reports to track space usage on a Data Domain
system for a period of up to two years back. In addition, you can generate reports to help understand
replication progress. You can view reports on file systems daily and cumulatively, over a period of time.
There are two types of replication reports provided by the Data Domain system; the Replication status
report and the Replication Summary report.
The Replication Status report displays three charts that provide the status of the current replication job
running on the system. This report is used to provide a snapshot of what is happening for all replication
contexts to help understand the overall replication status on a Data Domain System.
The Replication summary report provides performance information about a system's overall network in-
and-out usage for replication, as well as per context levels over a specified duration. You select the
contexts to be analyzed from a list.

Create a new replication status report when you want to evaluate file system or replication data collected
in the past.
1. Select Reports > Management. The information panel displays a new report area and a list of saved
reports.
2. Click Replication: Status report in the New Report area.
3. Select the target system from the dropdown menu.
4. Click Create. After the report is created, it appears in the Saved Reports section of the screen.
5. Select the newly created report.
6. Select View to display the report. If the report does not display, verify the option to block pop-up
windows is enabled on your browser.

The replication status report generates a summary of all replication contexts on a given Data Domain
system with the following information:
ID: the context number or designation or a particular context. The context number is used for
identification; 0 is reserved for collection replication, and directory replication numbering begins at 1.
Source > Destination: The path between both Data Domain systems in the context.
Type: The type of replication context, will be Directory, MTree, or Collection.
Status: Error or Normal.
Sync as of Time: Time and date stamp of the most recent sync.
Estimated Completion: The estimated time at which the current replication operation should be
complete.
Pre-Comp Remaining: The amount of storage remaining pre-compression (applies only to
collection contexts).
Post-Comp Remaining: The amount of storage remaining post-compression (applies only to
directory, MTree, and collection contexts).
Destination: The destination system name.
Space Availability (GiB): The total amount of storage available.
If an error exists in a reported context, a section called Replication Context Error Status is added to the
report. It includes the ID, source/destination, the type, the status, and a description of the error.

Create a new replication Summary report using the following process:
1. Select Reports > Management. The information panel displays a new report area and a list of saved
reports.
2. Click Replication: Summary report in the New Report area.
3. Select the appropriate options from the various menus.
4. Click Create. After the report is created, it appears in the Saved Reports section of the screen.
5. Select the newly created report.
6. Select View to display the report. If the report does not display, verify the option to block pop-up
windows is enabled on your browser.

The Replication Summary report provides performance information about a systems overall network in-
and-out usage for replication, as well as per context levels over a specified duration. You select the
contexts to be analyzed from a list.
Network In (MiB): The amount of data entering the system. Network In is indicated by a thin green line.
Network Out (MiB): The amount of data sent from the system. Network Out is indicated by a thick
orange line.
Time: The date on which the data was written.
Pre-Comp Remaining (MiB): The amount of pre-compressed data to be replicated. Pre-Comp

Remaining is indicated by a blue line.

This lesson covers recovering data from an off-site replica and resynchronizing recovered data.

If source replication data becomes inaccessible, it can be recovered from the replication destination. The
source must be empty before recovery can proceed. Recovery can be performed for all replication
topologies, except for MTree replication.
Onsite Data Domain systems are typically used to store backup data onsite for short periods such as 30,
60, or 90 days, depending on local practices and capacity. Lost or corrupted files are recovered easily
from the onsite Data Domain system since it is disk-based, and files are easy to locate and read at any
time.
In the case of a disaster destroying onsite data, the offsite replica is used to restore operations. Data on
the replica is immediately available for use by systems in the disaster recovery facility. When a Data
Domain system at the main site is repaired or replaced, the data can be recovered using a few simple
recovery configuration and initiation commands.
If something occurs that makes the source replication data inaccessible, the data can be recovered from
the offsite replica. During collection replication, the destination context must be fully initialized for the
recover process to be successful.
Note: If a recovery fails or must be terminated, the replication recovery can be aborted.
If source replication data becomes inaccessible, it can be recovered from the replication destination. The
source must be empty before recovery can proceed. Recovery can be performed for all replication
topologies, except for MTree replication.

Verify the directory has been recreated on the source, but is empty.
1. Navigate to the Replication > Automatic > Summary tab
2. Select More > Start Recover... to display the Start Recover dialog box.
3. Select Directory from the Replication Type menu.
4. Select the host name of the system to which data needs to be restored from the System to recover to
menu.
5. Select the host name of the system that will be the data source from the System to recover from
menu.
6. Select the context to restore from the context list.
7. To change any host connection settings, select the Advanced tab.
8. Select OK to start the recovery.
Note: If a recovery fails or must be terminated, the replication recover can be aborted. Recovery on the
source should be restarted again as soon as possible by restarting the recovery.
1. Click the More menu and select Abort Recover. The Abort Recover dialog box appears, showing the
contexts that are currently performing recovery.
2. Click the checkbox of one or more contexts to abort from the list.
3. Click OK.

Resynchronization is the process of recovering (or bringing back into sync) the data between a source and
a destination replication pair after a manual break. The replication pair are resynchronized so both
endpoints contain the same data. Resynchronization is available for MTree, directory, and pool replication,
but not for collection replication.
Resynchronization can be used to convert a collection replication to directory replication. This is useful
when the system is to be a source directory for cascaded replication. A conversion is started with a
replication resynchronization that filters all data from the source Data Domain system to the destination
Data Domain system. This implies that seeding can be accomplished by first performing a collection
replication, then breaking collection replication, then performing a directory replication resynchronization.
Resynchronization can also be used to re-create a context that was lost or deleted.
Also, use resynchronization when a replication destination runs out of space and the source system still
has data to replicate.

To Resynchronize a context, follow this process:
1. On the source and destination systems:
a. Navigate to the Replication > Automatic > Summary tab
b. select the target context
c. delete the context by selecting the Delete Pair button.
2. Select the replication From either the replication source or replication destination system, select More
> Start Resync to display the Start Resync dialog.
3. Select the Replication Type to be resynced: Directory, MTree, or Pool. If resyncing an MTree
replication, the source and destination must have a common snapshot, so do not delete existing
snapshots before a resyncing the source and destination.
4. Select the replication source system details.
5. Select the replication destination system host name from the Destination System menu.
6. Enter the replication source path in the Source Path text box.
7. Enter the replication destination path in the Destination Path text box.
8. To change any host connection settings, select the Advanced tab.
9. Select OK.
This process adds the context back to both the source and destination DDRs and start the resync process.
The resync process can take between several hours and several days, depending on the size of the
system and current load factors.

In this lab, you will configure replication on a Data Domain system.
Also covered in this module was replication seeding and the resynchronizing of recovered data.

This module covered replication as a method for storing a real-time, offsite replica of backup data and how
replicated date is used to restore operations when backup data is lost. Data replication types include,
collection, MTree, and directory.

This module focuses using virtual tape library (VTL) with Data Domain including planning, configuration,
and management.

This lesson provides an overview of VTL function, benefits, and terms.

The EMC Data Domain Virtual Tape Library (VTL) service provides a disk-based backup system that
emulates the use of physical tapes. This feature enables backup applications to connect to and manage
DD system storage using functionality almost identical to a physical tape library.
A virtual tape library appears to the backup software as a SCSI robotic device or changer. Virtual tape
drives are accessible to backup software in the same way as physical tape drives. Once drives are
created in the VTL, they appear to the backup software as SCSI tape drives.
A Fibre Channel (FC) equipped host connecting to a Storage Area Network (SAN) can communicate with
a Fibre Channel equipped Data Domain system. When properly zoned, the host can send its backups
using the FC protocol directly to the VTL-enabled Data Domain system.
Data Domain systems support backups over the SAN via Fibre Channel. The backup application on the
backup host manages all data movement to and from Data Domain systems. An FC switch is not needed
when a direct connection from the backup host to the Data Domain system is used.
When disaster recovery is needed, tape pools can be replicated to a remote Data Domain system using
the Data Domain replication process.
To protect data on tapes from modification, tapes can be locked using Retention Lock Governance
software.
The VTL service provides a network interface to the Data Domain file system. The VTL service can be
active along-side CIFS, NFS, and DD Boost services - which also provide network interfaces into the file
system.
VTL has been tested with, and is supported by, specific backup software and hardware configurations. For
more information, see the appropriate Backup Compatibility Guide on the EMC Online Support Site.

A Data Domain VTL offers a simple integration, leveraging existing backup policies. A Data Domain VTL
can leverage existing backup policies in a backup system currently using a strategy of physical tape
libraries.
Data Domain systems simultaneously support data access methods through Data Domain Virtual Tape
Library over Fibre Channel, remote Network Data Management Protocol (NDMP) access over Ethernet for
network-attached storage (NAS), Network File System (NFS) and Common Internet File System (CIFS)
file service protocols over Ethernet, and EMC Data Domain Boost. This deployment flexibility and simple
administration means users can rapidly adjust to changing enterprise requirements.
A Data Domain VTL eliminates the use of tape and the accompanying tape-related issues (large physical
storage requirement, off-site transport, high time to recovery, and tape shelf life) for the majority of
restores. Compared to normal tape technology, a Data Domain VTL provides resilience in storage through
the benefits of Data Invulnerability Architecture (DIA) (end-to-end verification, fault avoidance and
containment, continuous fault detection and healing, and file system recoverability).
Data Domain systems configured for VTL reduces storage space requirements through the use of Data
Domain deduplication technology.
Disk-based network storage provides a shorter Recovery Time Objective (RTO) by eliminating the need
for handling, loading, and accessing tapes from a remote location.

Different tape library products may package some components in different ways, and the names of some
elements may differ among products, but the fundamental function is basically the same. This next section
provides the definition used by the EMC Data Domain VTL feature.
A Barcode is a unique ID for a virtual tape. Barcodes are assigned when the user creates the virtual tape
cartridge. A unique ID for a virtual tape that is assigned when the user creates the virtual tape cartridge.
A tape is a cartridge holding magnetic tape used to store data long term. The backup software creates
virtual tapes which to act the same as physical tape media. Tapes are usually represented in a system as
grouped data files. Tapes - virtual and real - can be moved between a long term retention vault to a
library. They can also move within a library across drives, slots, and CAPs.
A tape is also called a cartridge.
A pool is a collection of tapes that maps to a directory on a file system, used to replicate tapes to a
destination. Note: Data Domain pools are not the same as backup software pools. Most backup software,
including EMC NetWorker, has its own pooling mechanism.

Tapes also go into devices. The devices show here are a changer and a tape drive.
A tape drive is the device that records backed-up data to a tape cartridge. In the virtual tape world, this
drive still uses the same Linear Tape-Open (LTO) technology standards as physical drives.
There are additional generations of LTO, but only LTO -1, -2, -3, -4, and -5 are currently supported by
Data Domain systems. Depending on the multiplex setting of the backup application, each drive operates
as a device that can support one or more data streams.
A Changer (Tape Backup Medium Changer) is the device that handles the tape between a tape library and
the tape drive. In the virtual tape world, the system creates an emulation of a specific type of changer.
Although no tapes are physically moved within the Data Domain VTL system, the virtual tape backup
medium changer must emulate the messages your backup software expects to see when tapes are
moved to and from the drives. Selecting and using the incorrect changer model in your VTL configuration
causes the system to send incorrect messages to the backup software, which can cause the VTL system
to fail.
A cartridge access port (CAP) enables the user to deposit and withdraw tape cartridges (volumes) in an
autochanger without opening its door. In a VTL, a CAP is the emulated tape enter and eject point for
moving tapes to or from a library. The CAP is also called a mail slot.
A slot is a storage location within a library. For example, a tape library has one slot for each tape that the
library can hold.

A library is a collection of magnetic tape cartridges used for long-term data backup. A virtual tape library
emulates a physical tape library with tape drives, changer, CAPs, and slots (cartridge slots). A library is
also called an autoloader, tape silo, tape mount, or tape jukebox.
A tape vault is a holding place for tapes not currently in any library. Tapes in the vault eventually have to
be moved into the tape library before they can be used.

An initiator is the device that starts a SCSI session and sends SCSI commands. The initiator is usually a
backup server. On the Data Domain system, you must identify the initiators that are allowed to control the
system through SCSI commands. The Data Domain system needs the WWPN to determine which fibre
channel traffic is from an authorized initiator. When you identify the initiator, you can also provide a name,
or alias, that maps to a the initiators WWPN. The name makes it easier to manage the initiator through
the DD OS user interface.
An Access Group, or VTL Group, is a collection of initiators and the drives and changers they are allowed
to access. An access group may contain multiple initiators, but an initiator can exist in only one access
group.

This lesson covers a simplified overview of the evaluation and planning for VTL configuration on a DD
system.
Typically, any production Data Domain system running VTL has been assessed, planned, and configured
by Data Domain implementation expert prior to implementation and production.

Make sure the system has the capacity to support your VTL application. Verify the Data Domain system
can provide the number of tapes, drives, libraries, slots, and read and write streams needed by the VTL
application.
The information presented in this lesson provides the current capacities for the various features in a Data
Domain VTL configuration. Your backup host may not support these capacities. Refer to your backup host
software support for correct sizing and capacity to fit your software.
Understand that the Data Domain VTL is scalable and should accommodate most configurations.
Standard practices suggest creating only as many tape cartridges as needed to satisfy backup
requirements, and enough slots to hold the number of tapes you create. Creating additional slots is not a
problem. The key in good capacity planning is to not be excessive beyond the system needs and add
capacity as needed.
For further information about the definitions and ranges of each parameter, consult the DD OS System
Administration Guide and the most current VTL Best Practices Guide. Both are available through the Data
Domain Support Portal.

In setting up a virtual tape library (VTL) on a Data Domain system, you must be aware of the capacity of
the system. The configuration of the VTL depends on the tape drive technology and changer model you
are emulating. Efficiencies are dictated by the processing power and storage capacity of the Data Domain
system used to provide the VTL. Larger, faster systems allow more streams to write to a higher number
of virtual tape drives, thus providing faster virtual tape backups.
Data Domain systems support a maximum I/O block size of 1MB in size.
All systems are currently limited to a maximum of 64 library instances, (64 concurrently active VTL
instances on each Data Domain system).
The maximum numbers of slots in a library is 32,000. There can be a maximum of 64,000 slots in the
Data Domain system. You cannot have more tapes than you have slots.
The Data Domain system supports 100 cartridge access ports (CAPs) per library and a maximum of
1000 CAPs in the system.
Tapes can be created to support a maximum of 4 TiB in size.

Depending on the amount of memory and number of CPU cores, a Data Domain system can have
between 64 and 1080 tape drives per system.
A Data Domain system with 59 or fewer CPU cores can support up to 540 drives.
A Data Domain system with 60 or more CPU cores can support up to 1080 drives.
Note: These are some of the maximum capacities for various features in a VTL configuration for the larger
Data Domain systems. Check the VTL Best Practices Guide for recommendations for your system and
configuration.

The VTL (Virtual Tape Library) feature has very specific requirements, such as proper licensing, interface
cards, user permissions, sizing, etc.

Make sure you understand the requirements and capabilities of the backup software. EMC strongly
recommends that backup software be set to use a minimum record (block) size of 64 KiB or larger.
Larger sizes usually give faster performance and better data compression. Depending on your backup
application, if you change the size after the initial configuration, data written with the original size might
become unreadable.
Also, verify the backup software can support one of the Changers and drives supported by the Data
Domain system. As of this writing, the Data Domain systems emulate the StorageTek L180 ,
RESTORER-L180, IBM TS3500, IBM I2000, Quantum I6000. The L180 is the default changer. The Data
Domain system emulates a number of Linear Tape-Open drives, including the IBM LTO-1, LTO-2, LTO-
3, LTO-4, and LTO-5 tape drives. It also emulates the HP LTO-3 and LTO-4 tape drives. The default
tape drive emulation is the IBM-LTO-5.
In a physical tape library setting, multiplexing sending data from multiple clients interleaving the data
onto a single tape drive simultaneously is a method to gain efficiency by sending data from multiple
clients to a single tape drive.
Multiplexing was useful for clients with slow throughput since a single client could not send data fast
enough to keep the tape drive busy.
With Data Domain VTL, multiplexing causes existing data to land on a Data Domain system in a different
order each time a backup is performed. Multiplexing makes it nearly impossible for a system to recognize
repeated segments, thus ruining deduplication efficiency. Do not enable multiplexing on your backup host
software when writing to a Data Domain system.
To increase throughput efficiency and maintain deduplication-friendly data, establish multiple data streams
from your client system to the Data Domain system. Each stream will require writing to a separate virtual
drive.

All fibre channel connections to a Data Domain system should be through a Fibre Channel switch or by
direct attachment of an initiator.
Refer to the DD OS Backup Compatibility Guide to verify initiator's FC HBA hardware and driver are
supported.
Upgrade initiator HBA to the latest supported version of firmware and software.
Dedicate the initiator's Fibre Channel port to Data Domain VTL devices.
Verify the speed of each FC port on the switch to confirm that the port is configured for the desired rate.
Consider spreading the backup load across multiple FC ports on the Data Domain system in order to
avoid bottlenecks on a single port.
The VTL service requires an installed FC interface card or VTL configured to use NDMP over Ethernet.
If the VTL communication between a backup server and a DD system is through an FC interface, the DD
system must have an FC interface card installed. Notice that whenever an FC interface card is removed
from (or changed within) a DD system, any VTL configuration associated with that card must be updated.
If the VTL communication between the backup server and the DD system is through NDMP, no FC
interface card is required. However, you must configure the Tape Server access group. Also, when using
NDMP, all initiator and port functionality does not apply.

When you establish fabric zones via FC switches, the best way to avoid problems with VTL configurations
is to include only one initiator and one target port in one zone. Avoid having any other targets or initiators
in any zones that contain a gateway target FC port.
Only initiators that need to communicate with a particular set of VTL target ports on a Data Domain
system should be zoned with that Data Domain system.

DD VTL License
VTL is a licensed feature.
An additional license is required for IBM i systems the I/OS license.
Adding a VTL license through the DD System Manager automatically disables and enables the VTL
feature.
Only one license is needed to back up to a Data Domain configured for VTL.
User Access
Make sure to plan which users will have access to the VTL features and plan to give them the appropriate
access to the system. For basic tape operations and monitoring, only a user login is required. To enable
and configure VTL services and perform other configuration tasks, a sysadmin login is required.

The number of slots and drives in a VTL are governed by the number of CPU cores and the amount of
memory (RAM and VRAM) on a DD system. For example, a system with 36 cores and up to 128 GB of
RAM and 4 GB of NVRAM can support up to 270 drive maximum. The same system would also support
up to 540 backup write streams.
Depending on the configuration and overall performance limits of your particular Data Domain system you
might need to adjust the overall number of drives assigned for VTL.
See the current Data Domain Operating System Administration Guide for details.
Slot counts are typically based on the number of tapes are used over a retention policy cycle.

Choosing the optimal size of tapes for your needs depends on multiple factors, including the specific
backup application being used, and the characteristics of the data being backed up. In general, its better
to use a larger number of smaller capacity tapes than a smaller number of large capacity tapes, in order to
control disk usage and prevent system full conditions.
When choosing a tape size, you should also consider the backup application being used. For instance,
Hewlett Packard Data Protector supports only LTO-1 /200 GB capacity tapes.
Data Domain systems support LT0-1, LTO-2, LTO-3, LTO-4 and LTO-5 formats.
LTO-1: 100 GB per tape
LTO-5: 1.5 TiB per tape
If the data you are backing up is large, (over 200 GB, for example), you may want larger-sized tapes since
some backup applications are not able to span across multiple tapes.
The strategy of using smaller tapes across many drives gives your system greater throughput by using
more data streams between the backup host and Data Domain system.
Larger capacity tapes pose a risk to system full conditions. It is more difficult to expire and reclaim the
space on data being held on a larger tape than on smaller tapes. A larger tape can have more backups on
it, making it potentially harder to expire because it might contain a current backup on it.

All backups on a tape must be expired, by policy or manually, before the space in the cartridge can be
relabeled and made available for reuse.
If backups with different retention policies exist on a single piece of media, the youngest image will prevent
file system cleaning and reuse of the tape. You can avoid this condition by initially creating and using
smaller tape cartridges in most cases, tapes in the 100GB to 200GB range.
Expired tapes are not deleted, and the space occupied by that tape is not reclaimed until it is relabeled,
overwritten, or deleted. Consider a situation in which 30% of your data is being held on a 1TB tape. You
could delete half of that data (500 GB) and still not be able to reclaim any of the space because the tape is
still holding unexpired data.
Unless you are backing up larger-size files, backing up smaller files to larger-sized tapes will contribute to
this issue by taking longer to fill a cartridge with data. Using a larger number of smaller-sized tapes can
reduce the chances of a few young files preventing cleaning older data on a larger tape.
When deciding how many tapes to create for your VTL configuration, remember, that creating more tapes
than you actually need might cause the system to fill up prematurely and cause unexpected system full
conditions. In most cases, backup software will use blank tapes before recycling tapes. It is a good idea to
start with a tape count less than twice the available space on the Data Domain system.

When a tape is created, a logical, eight-character barcode is assigned that is a unique identifier of a tape.
When creating tapes, the administrator must provide the starting barcode. The barcode must start with six
numeric or uppercase alphabetic characters (from the set {0-9, A-Z}). The barcode may end with a two-
character tag for the supported LT0-1, LT0-2, LT0-3, LTO-4 and LTO-5 tape types.
A good practice is to use either two or three of the first characters as the identifier of the group or pool in
which the tapes belong. If you use two characters as the identifier, you can then use four numbers in
sequence to number up to 10,000 tapes. If you use three characters, you are able to sequence only 1,000
tapes.
Note: If you specify the tape capacity when you create a tape through the Data Domain System Manager,
you will override the two-character tag capacity specification.

NDMP (Network Data Management Protocol) is an open-standard protocol for enterprise-wide backup of
heterogeneous network-attached storage. NDMP was co-invented by Network Appliance and PDC
Software (acquired by Legato Systems, Inc., and now part of EMC).
Data Domain systems support backups using NDMP over TCP/IP via standard Ethernet as an alternate
method. This offers a VTL solution for remote office/back office use.
Backup servers configured only with Ethernet can also back up to a Data Domain VTL when used with an
NDMP tape server on the Data Domain system. The backup host must also be running NDMP client
software to route the server data to the related tape server on the Data Domain system.
When a backup is initiated, the host tells the server to send its backup data to the Data Domain VTL tape
server. Data is sent via TCP/IP to the Data Domain system where it is captured to virtual tape and stored.

All peripheral equipment must emulate IBM equipment, including IBM tape libraries and devices, when
presented to the operating system.
Additionally, the hardware drivers used by these systems are embedded in the Licensed Internal Code
(LIC) and IBM i operating system. LIC PTFs, or program temporary fixes, are IBM's method of updating
and activating the drivers. In most cases, hardware configuration settings cannot be manually configured,
as only IBM, or equipment that emulates IBM equipment is attached, requiring only fixed configuration
settings.
Fibre Channel devices can be connected directly to host (direct attach) through arbitrated loop (FC-AL)
topology or through a switched fabric (FC-SW) topology. Please note that direct connect is not supported
on Power5 hardware, Virtual I/O Server, and 5761/5704 IOAs. The Fibre Channel host bus adapters or
IOAs (input/output adapters) can negotiate at speeds of 2 Gbps, 4 Gbps, and 8 Gbps in an FC-SW
environment without any configuration on the operating system other than plugging in the cable at the
host. Fibre Channel IOPs and IOAs are typically installed by an IBM business partner.
Virtual Libraries
Data Domain VTL supports one type of library configuration for IBM i use. This is an IBM TS3500
configured with IBM LT0-3, LTO-4, or LTO-5 virtual tape drives. Virtual library management is done from
the Virtual Tape Libraries tab. From Virtual Tape Libraries > More Tasks > Library > Create, you can set
the number of virtual drives and the number of slots.
A special VTL license that supports IBM i use is required. This special license supports other VTL
configurations as well, but the standard VTL license does not directly support IBM i configurations. Add the
i/OS license to the Data Domain system before creating a VTL to have the correct IBM i configuration.
IBM i virtual libraries are not managed any differently from other operating systems.
Refer to the Virtual Tape Library for IBM System i Integration Guide for current configuration instructions
available in the support portal for all configuration and best practices information when using VTL in an
IBM i environment.

In this lesson, you learn how to manage VTL access groups. This includes being able to describe the
purpose of a VTL access group and how to review.

Access groups hold a collection of initiator WWPNs (worldwide port names) or aliases and the drives and
changers they are allowed to access.
Access group configuration allows initiators (in general backup applications) to read and write data to
devices in the same access group. Access groups let clients access only selected LUNs (media changers
or virtual tape drives) on a system. A client set up for an access group can access only devices in its
access group.
An access group may contain multiple initiators, but an initiator can exist in only one access group.
A VTL preconfigured VTL access group named TapeServer lets you add devices that will support NDMP
(Network Data Management Protocol)-based backup applications.
Avoid making access group changes on a Data Domain system during active backup or restore jobs. A
change may cause an active job to fail. The impact of changes during active jobs depends on a
combination of backup software and host configurations.

1. To review the configuration of the Fibre Channel Access Groups, select the Hardware > Fibre
Channel > Access Group tab.
2. Displayed on the screen is a table containing summary information about the DD Boost Access
Groups and the VTL access groups. Note the information includes the name of the group, the type of
service the group supports, the endpoint associated with the group, the names of the initiators in the
group, and the number of devices (disks, changers, LUNs) in the group. Note the groups that contain
initiators and devices.
3. The total number of groups configured on the system is shown at the bottom of this section.
4. Select the View VTL Groups hyperlink to navigate the Data Domain System Manager Protocol > VTL
page where there is more information and configuration tools.

To review the LUNs in an access group, you can select the View VTL Groups hyperlink on the Hardware >
Fibre Channel > Access Groups tab. Or you can Navigate to Protocols > VTL page directly.
1. Select the Protocols > VTL menu item in DDSM.
2. Select the Access Group menu item. Click the plus sign (+) to expand the list if necessary.
3. Select an access group from the Access Groups list.
4. Select the LUNs tab.
5. Review a summary of the various LUNs in the selected access group.

To review the Initiators in an access group, you can select the View VTL Groups hyperlink on the
Hardware > Fibre Channel > Access Groups tab. Or you can Navigate to Protocols > VTL page directly.
1. Select the Protocols > VTL menu item in DDSM.
3. Select an access group from the Access Groups list.
4. Select the Initiators tab.
5. Review a summary of the various initiators in the selected access group.

1. Navigate to the Protocols > VTL Page in DDSM.
2. Select the Access Group menu item.
3. Select the top-level groups folder. If you do not select this folder, the More Tasks > Group > Create...
item will not be available.
4. Select the More Tasks > Group > Create... item. The Create Access Group dialogue box appears.

5. Enter the group name in the Group Name field of the Create Access Group dialogue box. The group
name can be up to 128 characters in length.
6. From the Initiator list, select the Initiators you wish to add to this VTL Access Group. You may add
your initiator later, as you are not required to add one at this time.
7. Select Next. The Access group devices dialogue box now appears.

The Create Access Group > Devices dialogue box appears. Since this is a new group, the device list
should be empty.
8. Click the Add Icon, represented by the green plus sign, to add the devices. The Add Device dialogue
box appears.
9. Select the library that contains the devices you wish to add to the VTL Access Group. You can add
devices from multiple different libraries.
10. Select the devices to add to the group from the list.
11. In the Start Address field, enter the LUN number you wish to assign to the first device.
12. In the Primary and Secondary Endpoints area, select an option to determine from which ports the
selected device will be seen. The following conditions apply for designated ports:
all The checked device can be seen by initiators that are connecting through a through the
secondary port.
none The checked device is not seen by any device through any port.
select The checked device is to be seen by initiators connecting from one of the selected ports.
Select the checkboxes of the appropriate ports. If only primary ports are selected, the checked
device is visible only from primary ports. If only secondary ports are selected, the checked device is
visible only from secondary ports. Secondary ports can be used if the primary ports become
unavailable.
The switchover to a secondary port is not an automatic operation. You must manually switch the
VTL device to the secondary ports if the primary ports become unavailable.
The port list is a list of physical port numbers. A port number denotes the PCI slot and a letter
denotes the port on a PCI card. Examples are 1a, 1b, or 2a, 2b. A drive appears with the same
LUN on all the ports that you have configured.
13. When you are finished selecting devices for addition to the group, Click Ok.

To Delete a VTL Access Group, you must first make sure the access group is empty and contains no
initiators or devices. Use the configure (modify) process to delete these objects from an access group.
1. Navigate to the Protocols > VTL page in DDSM to start the delete process.
3. Select the target access group access group from the Access Groups list.
4. Select the More Tasks > Configure Menu Item.
5. Make sure there are no initiators selected.
6. Click Next.

6. Since all devices must be deleted, select every device in the Access Group.
7. Click the delete icon - the red x - to remove the selected devices.
8. When the Modify Access Group Dialogue box is redisplayed, verify all devices have been deleted from
the devices list.
9. Click Next. The Modify Access Group > Summary dialogue box is displayed.

10. Verify the summary information.
11. If you are satisfied with the output, click Finish.
12. After the Modify Access process completes, click OK.

Now that you've removed all objects from the access group, you can delete the access group itself.
13. Verify the Protocols > VTL > Access Groups tab is active.
14. Select the target VTL Access group.
15. Select the More Tasks > Delete... menu item. The Delete Group Dialogue box with a list of VTL
Access groups is displayed.
16. Select the access group you wish to delete.
17. Click Next.
18. Verify the Correct Access group is targeted for deletion.
19. Click Submit.
20. After the Delete Groups process completes, select Close.

This lesson covers the steps you take to create a library and tapes..

The System Manager Configuration Wizard walks you through the initial VTL configuration, using the VTL
configuration module. Typically, the Configuration Wizard is run initially by the EMC installation team in
your environment.
To open the System Manager Configuration Wizard, go to the System Manager, and select Maintenance
> More Tasks > Launch Configuration Wizard.
Navigate to the VTL configuration, and click No until you arrive at the VTL Protocol configuration section.
Select Yes to configure VTL.
The wizard steps you through library, tape, initiator, and access group configuration.
Manual configuration is also possible. Manually configuring the tape library and tapes, importing tapes,
configuring physical resources, setting initiators, and creating VTL access groups are covered in the
following slides.

1. To configure VTL with DDSM, launch a supported web browser and connect to the target Data
Domain system using either HTTP or HTTPS.
2. Navigate to the Protocols > VTL page to manage the VTL service. Once you navigate to this page,
you will see that the page is subdivided into sections.
The options under the Virtual Tape Libraries section enable you to manage the VTLs and their associated
devices.
The options under the Access Group section enable you to define the devices an individual initiator can
access.
The Resources section allows you to view the configuration of endpoints and initiators. To configure these
devices, you must navigate to the Hardware > Fibre Channel menu.

The VTL service controls the operation of the Virtual Tape Library feature. It must be enabled in order to
take advantage of this feature.
The VTL service provides the environment for virtual devices to exist. You may think of it as a virtual data
center.
The VTL service requires installation of an EMC Data Domain Virtual Tape Library (VTL) license before it
can be enabled.
If the VTL is going to provide virtual IBM i devices, an EMC Data Domain I/OS (for IBM i operating
environments) license is also required.

1. After navigating to the Protocols > VTL page using DDSM, expand the Virtual Tape Libraries section.
2. Select the VTL Services item. The state of the VTL service and VTL licenses are displayed. You will
not see the state of the service unless the VTL Service item is selected.
3. Verify the VTL license has been installed. If the license has not been installed, select the Add License
hyperlink and install the VTL license at this time.
4. Verify an I/OS license has also been installed if the VTL is in an IBM environment. This license must
be installed before any VTLs or tape drives are created.
5. After all required licenses have been installed, select the enable button to Enable the VTL service.
The VTL status should show as Enabled: Running and the Enable button changes to Disable.

The VTL consists of four specific virtual objects. They are the changer, slots, cartridge access ports, and
tape drives.
When you create the VTL, you can only have one changer and you must identify the changer's model.
You must provide the number of slots your VTL contains. You can specify a quantity between 1 and
32,000.
You must also assign cartridge access ports (CAPs) to the VTL. Values from 0 to 100 are acceptable.
Finally, you must also provide the quantity and model of the tape drives in the VTL.
Even though tapes are used by the VTL, they are not an integral part of the VTL itself. The same is true
for tape pools.

1. After navigating to the Data Management > VTL page with DDSM, expand the Virtual Tape Libraries
menu.
2. Expand the VTL Service menu item.
3. Next, select the Libraries menu item. The contents of the More Tasks menu is dependent upon the
item selected in the left side menu, so you must ensure the correct item is selected.
4. Select More Tasks > Library > Create... menu item. The Create Library dialogue box is displayed.
5. Enter the values appropriate for your application. If the VTL is properly planned, you should know the
values to enter.
6. Select OK to start the Create Library process.
7. Select OK after the Create Library process completes.

DD System Manager provides the ability to review the configuration of the VTL and its components.
Select the Virtual Tape Libraries > VTL Service > Libraries menu item to view summary information
relating to all VTLs.
Select the Virtual Tape Libraries > VTL Service > Libraries > {library-name} menu item to view summary
information on the selected VTL. The number and disposition of tapes in the VTL is also shown. If no
tapes are associated with the VTL, there is nothing in the Tapes section.

Selecting the VTL's Changer menu item provides detailed related information. This includes the changer's
vendor, product ID, revision number, and serial number. Of course, these are all attributes you would
expect to find with a physical tape drive.
Selecting the VTL's Drives menu item provides detailed related information for all drives. This includes the
drive number, vendor, product ID, revision number, serial number, and status. If a tape is in the drive, the
tape's barcode is displayed along with the name of the tape pool to which the tape belongs.

The system provides the tools you would expect to manage tapes. They include the ability to create and
delete tapes. The VTL service also provides the ability to import and export tapes from and to the vault. If
needed, you can move tapes within the VTL between the slots, drives, and CAPs. Finally, the system
enables you to search for specific tapes.
The system also provides tools to manage tape pools. You can create, delete, or rename tape pools.

To create tapes, follow this process.
1. After navigating to the Data Management > VTL page with DDSM, expand the Virtual Tape
Libraries menu and select the VTL that will hold the tapes. By doing this, the tapes you create will be
added directly to the VTL. There will be no need to import them after they are created.
2. Now, select More Tasks > Tapes > Create... to open the Create Tapes dialogue box.
3. Provide the information about the tapes you are creating. Refer to your implementation planning, to
find the number, capacity, and starting barcode for your tape set. You may select the Default tape
pool or a pool that you have created to hold the tapes.
4. Select OK when you are ready to create the tapes. The create tape process starts.
5. Once the Create Tapes process completes, select OK. You can now verify if the tapes have been
successfully created.

Select the Tape menu item associated with the VTL to review the tapes that are currently assigned to it.
The tapes will be in a slot, drive, or cap.

To create a tape pool, follow this process.
1. After navigating to the Data Management > VTL page with DDSM, expand the Pools menu on the
left side of the screen.
2. Select the Pools menu item from the list.
3. Now, select More Tasks > Pool > Create... to open the Create Pool dialogue box.
4. Provide a name for the Pool. Use a name that will identify the type of data that is on the tape. For
example, you could name the pool EngBkupPool to signify that it contains tapes relevant to
engineering backups.
5. Click the backwards compatibility checkbox to create the older-style tape pool under
/data/col1/backup/. If you do not check this box, the system creates a newer style tape pool that
leverages the MTree structure.
6. Select OK when you are ready to create the tape pool.

When you create a tape pool, either an MTree is created under /data/col1/ or a directory is created under
/data/col1/backup. In older versions of software, MTrees were not used and tape pools were created in
the directory /backup.
You can examine the list of MTrees on the system to view the MTrees associated with VTL.
When you enable VTL, the Default MTree-based tape pool is created.

When tapes are created, they can be added directly to a VTL or to the vault. From the vault, tapes can be
imported, exported, moved, searched, and removed. Importing moves existing tapes from the vault to a
library slot, drive, or cartridge access port (CAP). The number of tapes you can import at one time is
limited by the number of empty slots in the library.
To import tapes:
1. Select Data Management > VTL > VTL Service > Libraries.
2. Select a library and view the list of tapes, or click More Tasks.
3. Select Tapes > Import...
4. Enter the search criteria about the tapes you want to import and click Search.
5. Select the tapes to import from the search results.
6. Choose the target location for the tapes.
7. Select Next to beginning the importation process.

The Data Domain system supports using the Network Data Management Protocol (NDMP) to access the
VTL.
The NDMP must be enabled separately from the VTL service. The NDMP service is managed through
CLI.
NDMP allows the VTL to be accessed through Ethernet.
Without NDMP, the VTL can only be accessed through Fibre Channel.
NDMP on a Data Domain system does not require a Fibre Channel HBA.
In fact, NDMP does not use a Fibre Channel HBA if one is installed.

In order for a client computer to access VTL devices through NDMP, it must have client software that
implements the NDMP protocol.
The NDMP-client computer must also log in to a user account on the Data Domain system.
Two types of user accounts allow you to access the Data Domain system's VTLs through NDMP: a
standard DDOS user account and an NDMP user account.
If a standard DDOS user account is employed, the password is sent over the network as plain text. This,
of course, is unsecure.
The NDMP feature on the Data Domain system allows you to add a user specifically for NDMP access.
Password encryption can be added to the NDMP user for added security.

To make the Data Domain system's VTL devices accessible to the NDMP clients, the devices must be
members of the TapeServer Access Group.
Only devices in TapeServer Group available through NDMP.
Devices in TapeServer Group cannot be in other VTL access groups.
Initiators cannot be added to the Tapeserver group.
For more information on NDMP, see http://ndmp.org.

The following steps configure NDMP on the Data Domain system.
1. Enable the NDMP daemon by typing the CLI command # ndmpd enable.
2. Verify that the NDMP daemon sees the devices created in the TapeServer access group
Note: you must first create a VTL per the instructions discussed earlier in this module, then assign
the access group, TapeServer, before performing this step. Enter the command:
# ndmpd show devicenames.
The VTL device names appear as a table as shown in this slide.

3. Add an NDMP user for the ndmpd service. Enter the command,
# ndmpd user add ndmp.
When prompted, enter and verify the password for this user.
Verify the created user by entering the command, # ndmpd user show. The username appears
below the command.
4. Check the options for the ndmpd daemon. Enter the command ndmpd option show all. A table
showing the names of the options appears as shown in this slide.
Note that the authentication value is set to text. That means your authentication to the ndmp
daemon is transmitted as plain text: this is a possible security risk.

5. Set the ndmpd service authentication to MD5. Enter the command, ndmpd option set
authentication md5.
6. Verify the service.

This module described the VTL topology using Data Domain Systems. Also covered were ways to identify
requirements when planning a VTL, and steps to configure VTL in a Data Domain system.

This module discusses how DD Boost incorporates several features to significantly reduce backup time
and manage replicated data for easier access in data recovery operations.

This lesson provides an overview of DD Boost function, benefits and features.

DD Boost is a private protocol that is more efficient than CIFS or NFS. DD Boost has a private, efficient
data transfer protocol with options to increase efficiencies.
The application host is aware of, and manages replication of backups created with DD Boost. This is
called Managed File Replication.
Distributed segment processing (DSP) is an optional feature of DD Boost. It shares portions of the
deduplication process with the application host, improving data throughput.
DSP distributes parts of the deduplication process to the NetWorker storage node using the embedded
DD Boost Library (or, for other backup applications, using the DD BOOST plug-in), moving some of the
processing normally handled by the Data Domain system to the application host. The application host
performs a comparison of the data to be backed up with the library and looks for any unique segments.
Thus it sends only unique segments to the Data Domain system.

Advanced load balancing and link failover via interface groups
To improve data transfer performance and increase reliability, you can create a group interface using the
advanced load balancing and link failover feature. Configuring an interface group creates a private
network within the Data Domain system, comprised of the IP addresses designated as a group. Clients
are assigned to a single group by specifying client name (client.emc.com) or wild card name (*.emc).
Benefits include:
Potentially simplified installation management.
A system that remains operational through loss of individual interfaces.
Potentially higher link utilization.
In-flight jobs that fail over to healthy links, so jobs continue uninterrupted from the point of view of
the backup application.

Virtual synthetics
DD Boost in DD OS 5.2, and higher, supports optimized synthetic backups when integrated with backup
software. Currently, EMC NetWorker and Symantec NetBackup are the only supported software
applications using this feature.
Optimized synthetic backups reduce processing overhead associated with traditional synthetic full
backups. Just like a traditional backup scenario, optimized synthetic backups start with an initial full
backup followed by incremental backups throughout the week. However, the subsequent full backup
requires no data movement between the application server and Data Domain system. The second full
backup is synthesized using pointers to existing segments on the Data Domain system. This optimization
reduces the frequency of full backups, thus improving recovery point objectives (RPO) and enabling single
step recovery to improve recovery time objectives (RTO). In addition, optimized synthetic backups further
reduce the load on the LAN and application host.
Benefits include:
Reduces the frequency of full backups
Improves RPO and RTO
Reduces load on the LAN and application host
Both low bandwidth optimization and encryption of managed file replication data are replication optional
features and are both supported with DD Boost enabled.

DD Boost currently supports interoperability with the listed products on various backup host platforms and
operating systems. The interoperability matrix is both large and complex. To be certain a specific platform
and operating system is compatible with a version of DD Boost, consult the EMC DD Boost Compatibility
Guide found in the Support Portal at https://support.emc.com.

To store backup data using DD Boost, the Data Domain system exposes user-created disk volumes called
storage units (SUs) to a DD Boost-enabled application host. In this example, an administrator created an
SU named exchange_su. As the system completes the SU creation, an MTree is created. Creating
additional storage units creates additional MTrees under /data/col1. Access to the SU is OS independent.
Multiple applications hosts, when configured with DD Boost, can use the same SU on a Data Domain
system as a storage server.
Storage units can be monitored and controlled just as any data managed within an MTree. You can set
hard and soft quota limits and receive reports about MTree content.

If you recall, the deduplication on a Data Domain system is a five-step process where the system:
1. Segments data to be backed up.
2. Creates fingerprints of segmented data.
3. Filters the fingerprints and notes references to previously stored data.
4. Compresses unique, new data to be stored.
5. Writes the new data to disk.
In normal backup operations, the backup host has no part in the deduplication process. When backups
run, the backup host sends all backup data to allow the Data Domain system to perform the entire
deduplication process on all of the data.

Distributed segment processing (DSP) shares deduplication duties with the backup host. With DSP
enabled the backup host:
Segments the data to be backed up.
Creates fingerprints of segment data and sends them to the Data Domain system.
Optionally compresses data to be backed up.
Sends only the requested unique data segments to the Data Domain system.
The Data Domain system:

Filters the fingerprints sent by the backup host and requests data not previously stored.
Notes references to previously stored data and writes new data.
The main benefits of DSP are:

More efficient CPU utilization.
Improved utilization of network bandwidth. Less data throughput is required to send with each
backup.
Less time to restart failed backup jobs. If a job fails, the data already sent to the Data Domain
system does not need to be sent again reducing the load on the network and improving the overall
throughput for the failed backups upon retry.
Distribution of the workload between the Data Domain system and the DD Boost aware application.
DD Boost can operate with DSP either enabled or disabled. DSP must be enabled or disabled on a per-
system basis; individual backup clients cannot be configured differently than the Data Domain system.

With regards to network speed, DSP allows use of existing 1 GbE infrastructure to achieve higher
throughput than is physically possible over 1 GbE links.
With application hosts, use DSP if your application hosts are underutilized and can accommodate the
additional processing assignment.
The network bandwidth requirements are significantly reduced because only unique data is sent over the
LAN to the Data Domain systems.
Consider DSP only if your application hosts can accommodate the additional processing required by its
share of the DSP workflow.

DD Boost integration enables the backup application to manage file replication between two or more Data
Domain systems configured with DD Boost software. It is a simple process to schedule Data Domain
replication operations and keep track of backups for both local and remote sites. In turn, recovery from
backup copies at the central site is also simplified because all copies are tracked in the backup software
catalog.
The Data Domain system uses a wide area network (WAN)-efficient replication process for deduplicated
data. The process can be optimized for WANs, reducing the overall load on the WAN bandwidth required
for creating a duplicate copy.

This example shows managed file replication with DD Boost. The example is specific to an EMC
NetWorker environment. Symantec and other backup applications using DD Boost will manage replication
in a similar manner.
In this environment, a backup server is sending backups to a local Data Domain system. A remote Data
Domain system is set up for replication and disaster recovery of the primary site.
1. The NetWorker storage node initiates the backup job and sends data to the Data Domain system.
Backup proceeds.
2. The Data Domain system signals that the backup is complete.
3. Information about the initial backup is updated in the NetWorker media database.
4. The NetWorker storage node initiates replication of the primary backup to the remote Data
Domain system through a clone request.
5. Replication between the local and remote Data Domain systems proceed.
6. When replication completes, the NetWorker storage node receives confirmation of the completed
replication action.
7. Information about the clone copy of the data set is updated in the NetWorker media database.
Replicated data is now immediately accessible for data recovery using the NetWorker media database.

Standard MTree replication and Managed File Replication can operate on the same system
Note: Managed File Replication can be used only with DD Boost Storage Units.
While it is acceptable for both standard MTree replication and managed file replication to operate on the
same system, be aware that managed file replication can be used only with MTrees established with DD
Boost storage units.
Be mindful not to exceed the total number of MTrees on a system. The MTree limit is a count of both
standard MTrees, and MTrees created as DD Boost storage units. Note that the limit is dependent on the
Data Domain System and the DD OS version.
Also, remember to remain below the maximum total number of replication pairs (contexts) recommended
for your particular Data Domain systems.

For Data Domain systems that require multiple 1 GbE links to obtain full system performance, it is
necessary to set up multiple backup servers on the Data Domain systems (one per interface) and target
the backup policies to different servers to spread the load on the interfaces. Using the DD Boost interface
groups, you can improve performance on 1 Gb Ethernet ports.
The Advanced Load Balancing and Link Failover feature allows for combining multiple Ethernet links into a
group. Only one of the interfaces on the Data Domain system is registered with the backup application.
DD Boost software negotiates with the Data Domain system on the interface registered with the backup
application to obtain an interface to send the data. The load balancing provides higher physical throughput
to the Data Domain system compared to configuring the interfaces into a virtual interface using Ethernet-
level aggregation.
The links connecting the backup hosts and the switch that connects to the Data Domain system are
placed in an aggregated failover mode. A network-layer aggregation of multiple 1 GbE or 10 GbE links is
registered with the backup application and is controlled on the backup server.
This configuration provides network failover functionality from end-to-end in the configuration. Any of the
available aggregation technologies can be used between the backup servers and the switch.
An interface group is configured on the Data Domain system as a private network used for data transfer.
The IP address must be configured on the Data Domain system and its interface enabled. If an interface
(or a NIC that has multiple interfaces) fails, all of the in-flight jobs to that interface transparently fail-over to
a healthy interface in the interface group (ifgroup). Any jobs started subsequent to the failure are routed to
the healthy interfaces. You can add public or private IP addresses for data transfer connections.
Note: Do not use 1GbE and 10 GbE connections in the same interface group.

A synthetic full or synthetic cumulative incremental backup is a backup assembled from previous backups.
Synthetic backups are generated from one previous, traditional full or synthetic full backup, and
subsequent differential backups or a cumulative incremental backup. (A traditional full backup means a
non-synthesized, full backup.) A client can use the synthesized backup to restore files and directories in
the same way that a client restores from a traditional backup.
During a traditional full backup, all files are copied from the client to a media server and the resulting
image set is sent to the Data Domain system . The files are copied even though those files may not have
changed since the last incremental or differential backup. During a synthetic full backup, the previous full
backup and the subsequent incremental backups on the Data Domain system are combined to form a
new, full backup. The new, full synthetic backup is an accurate representation of the clients file system at
the time of the most recent full backup.
Because processing takes place on the Data Domain system under the direction of the storage node, or
media server, instead of the client, virtual synthetic backups help to reduce the network traffic and client
processing. Client files and backup image sets are transferred over the network only once. After the
backup images are combined into a synthetic backup, the previous incremental and/or differential images
can be expired.
The virtual synthetic full backup is a scalable solution for backing up remote offices with manageable data
volumes and low levels of daily change. If the clients experience a high rate of change daily, the
incremental or differential backups are too large. In this case, a virtual synthetic backup is no more helpful
than a traditional full backup. To ensure good restore performance, it is recommended that you create a
traditional full backup every two months, presuming a normal weekly full and daily incremental backup
policy.
The virtual synthetic full backup is the combination of the last full (synthetic or full) backup and all
subsequent incremental backups. It is time-stamped as occurring one second after the latest incremental.
It does NOT include any changes to the backup selection since the latest incremental.

Synthetic backups can reduce the load on an application server and the data traffic between an application
server and a media server. Synthetic backups can reduce the traffic between the media server and the
DD System by performing the Virtual Synthetic Backup assembly on the DD System.
You might want to consider using virtual synthetic backups when:

Your backups are small, and localized, so that daily incrementals are small (<10% of a normal, full
backup).
The Data Domain system you are using has a large number of disks (>10).
Data restores are infrequent.
Your intention is to reduce the amount of network traffic between the application server, the media
servers and the Data Domain system.
Your media servers are burdened and might not handle DSP well.
It might not be appropriate to use virtual synthetic backups when:

Daily incremental backups are high, or highly distributed (incremental backups are > 15% of a full
backup).
You are backing up large, non-file system data (such as databases)
Data restores are frequent
The Data Domain system is small or has few disks
Your media server handles DSP well
Restore performance from a synthetic backup is typically worse than a standard full backup due to poor
data locality.

DD Boost over FC enables new use cases via Fibre Channel transport:
Leverages existing FC infrastructure
Using FC as the transport is transparent to backup application.
DD Boost over FC presents Logical Storage Units (LSUs) to the backup application and removes a
number of limitations inherent to tape and VTL:
Enables concurrent read and write; Not allowed per virtual tape.
Backup image is smallest unit of replication or expiration vs. Virtual tape cartridge, which results in
efficient space management.

Simplified Management:
No access group limitations, simple configuration using very few access groups.
Manage backup images, as opposed to tape cartridges.
Advanced Load Balancing and Failover:
Path management, load balancing and Failover is done by plug-in / DD OS.
No need for expensive multi-pathing IO (MPIO) Software.
Replication is still over an IP network.

This lesson covers how to configure the Data Domain system so that backup applications can access the
system using DD Boost.

Data Domain Boost configuration is the same for all backup environments.
On each of the Data Domain systems:

1. License DD Boost on all Data Domain systems.
2. Enable DD Boost on all Data Domain systems.
3. Set a backup host as a client by hostname (the configuration does not accept IP addresses in this
case). Define a Data Domain local user as the DD Boost User.
4. Create at least one storage unit. You must create one or more storage units for each Data Domain
system enabled for DD Boost.
Network Note
Open the following ports if you plan to use any of the related features through a network firewall:
UDP 2049 (enables NFS communication)
TCP 2051 (enables file replication communication)
TCP 111 (enables RPC portmapper services comms)
For the backup host:

1. License the backup software for DD Boost as required by the software manufacturer.
2. Create devices and pools through the management console/interface.
3. Configure backup policies and groups to use the Data Domain system for backups with DD Boost.
4. Configure clone or duplicate operations to use Data Domain managed replication between Data
Domain systems.

DD Boost access groups - called scsitarget groups in the CLI - identify initiators and the drives and
changers they can access.
Initiators can read and write to devices in its access group, but not to devices in other DD Boost access
groups.
Initiators can only belong to one access group.
Initiators assigned to DD Boost access groups cannot be assigned to VTL access groups on the same
Data Domain system.
Avoid making access group changes during backup or restore operations.

1. To review the configuration of the Fibre Channel Access Groups, select the Hardware > Fibre
Channel > Access Group tab.
2. Displayed on the screen is a table containing summary information about the DD Boost Access
Groups and the VTL access groups. Note the information includes the name of the group, the type of
service the group supports, the endpoint associated with the group, the names of the initiators in the
group, and the number of devices (disks, changers, LUNs) in the group. Note the groups that contain
initiators and devices.
3. The DD Boost and VTL access groups are distinguished from one another by the Service type.
4. The total number of groups configured on the system is shown at the bottom of this section.
5. Select the View DD Boosts Groups hyperlink to navigate the Data Domain System Manager Protocol
> DD Boost page where there is more information and configuration tools.

6. Verify the system navigated to Protocols > DD Boost > Fibre Channel tab in system manager.
7. Review the configuration of the DD Boost Access Groups.

1. To manage DD Boost access groups, navigate to the Protocols > DD Boost page in DDSM.
2. Select the Fibre Channel tab.
3. Click the plus icon to create a new group.
4. Enter the group name in the Group Name field of the Create Access Group dialogue box. The group
name can be up to 128 characters in length. The name must be unique. Duplicate names are not
allowed.
5. From the Initiator list, select the Initiators you wish to add to this access group. You may add your
initiator later, as you are not required to add one at this time.
6. Select Next. The Create Access Group > Devices dialogue box now appears.
7. Enter the number of devices. The range is from 1 to 64 devices.
8. Select which endpoints to include.
9. Click Next. The Create Access Group > Summary dialogue box now appears.
10. Review the contents of the dialogue box.
11. Once you are satisfied, select Finish to create the DD Boost Access Group.
12. When the indicates the DD Boost Access Group creation process has completed, click OK.

The DD Boost feature is built-into the Data Domain operating system. Unlock the DD Boost feature on
each Data Domain system with separate license keys. If you are planning not to use Managed File
Replication, the destination Data Domain system does not require a DD Boost license.
For Dell/EMC Networker, Dell/EMC Avamar and Dell vRanger users, the Data Domain Boost library is
already included in recent versions of software. Before enabling DD Boost on Veritas Backup Exec, and
NetBackup, a special OST plug-in must be downloaded and installed on the backup host. The plug-in
contains the appropriate DD Boost Library for use with compatible Symantec product versions. Consult
the most current DD Boost Compatibility Guide to verify compatibility with your specific software and Data
Domain operating system versions. Both the compatibility guide and versions of OpenStorage (OST) plug-
in software are available through the Dell EMC Data Domain support portal at: http://support.emc.com.
A second destination Data Domain system licensed with DD Boost is needed when implementing
centralized replication awareness and management.
Enable DD Boost by navigating in the Data Domain System Manager to Protocols > DD Boost >
Settings. If the DD Boost Status reads Disabled, click the Enable button to enable the feature.
You can also enable DD Boost from the command line interface using the ddboost enable command.
You can use the ddboost status command to verify whether DD Boost is enabled or disabled on your
system.

Add DD Boost Clients and Users by navigating to Protocols > DD Boost > Settings.
In the Allowed Clients area, click the green plus button to allow access to a new client using the DD
Boost protocol on the system. Add the client name as a domain name since IP addresses are not allowed.
An asterisk (*) can be added to the Client field to allow access to all clients. You can also set the
Encryption Strength and Authentication Mode when setting up allowed clients.
To add a DD Boost user for the system, click the green plus button in the Users with DD Boost Access
section. In the Add User window, select from the list of existing users or add a new user.
You can also add users and clients using the command line:
ddboost set user-name <user-name>
Set DD Boost user.
ddboost access add clients <client-list>
Add clients to DD Boost access list.
Consult the Data Domain Operating System Command Reference Guide for more detailed information on
using the ddboost commands to administer DD Boost.

Create a storage unit by navigating to Protocols > DD Boost > Storage Units.
Click the plus sign to open the Create Storage Unit dialog. Name the storage unit, select a DD Boost
user, and set any quota settings you wish.
Under the Storage Unit tab, you can view information about a storage unit such as the file count, full path,
status, quota information and physical capacity measurements.
The command line can also be used to create and manage storage units:
ddboost storage-unit create <storage-unit-name>
Create storage-unit, setting quota limits.
ddboost storage-unit delete <storage-unit-name>
Delete storage-unit.
ddboost storage-unit show [compression] [<storage-unit-name>]
List the storage-units and images in a storage-unit.

You can rename, delete and undelete storage units by navigating to Protocols > DD Boost > Storage
Units.
To rename or modify a storage unit, click the pencil icon. This will open the Modify Storage Unit dialog
allowing you to change the name, the DD Boost User and the quota settings.
You can delete one or more storage units by selecting them from the list and clicking the red X icon. Any
deleted storage units can be retrieved using the Undelete Storage Unit item under the More Tasks button.
Deleted storage units can only be retrieved if file system cleaning has not taken place between the time
the storage unit was deleted and when you would like to undelete the storage unit.
You can also rename, delete and undelete storage units from the command line:
ddboost storage-unit create <storage-unit> user <user-name>
Create a storage unit, assign tenant, and set quota and stream limits.
ddboost storage-unit delete <storage-unit>
Delete a specified storage unit, its contents, and any DD Boost assocaitions.
ddboost storage-unit rename <storage-unit> <new-storage-unit>
Rename a storage-unit.
ddboost storage-unit undelete <storage-unit>
Recover a deleted storage unit.

To set various DD Boost options, such as Distributed Segment Processing, Virtual Synthetics, Low
Bandwidth Optimization, or File Replication Encryption, navigate to Protocols > DD Boost > Settings,
click the More Tasks button and select Set Options.
You can also set DD Boost options from the command line:
ddboost option reset
Reset DD Boost options.
ddboost option set distributed-segment-processing {enabled | disabled}
Enable or disable distributed-segment-processing for DD Boost.
ddboost option set virtual-synthetics {enabled | disabled}
Enable or disable virtual-synthetics for DD Boost.
ddboost option show
Show DD Boost options.

DD Boost over Fibre Channel can be configured in the System Manager from Protocols > DD Boost >
Fibre Channel. Here you can enable DD Boost over Fibre Channel, edit the server name and add DD
Boost Access Groups.
You can also configure and manage DD Boost over Fibre Channel from the command line:
ddboost option set fc {enabled | disabled}
Enable or disable fibre-channel for DD Boost.
ddboost fc dfc-server-name set <server-name>
DDBoost Fibre-Channel set Server Name.
ddboost fc dfc-server-name show
Show DDBoost Fibre-Channel Server Name.
ddboost fc group add <group-name> initiator <initiator-spec>
ddboost fc group add <group-name> device-set
Add initiators or DDBoost devices to a DDBoost FC group.
ddboost fc group create <group-name>
Create a DDBoost FC group.
ddboost fc group show list [<group-spec>] [initiator <initiator-spec>]
List configured DDBoost FC groups.
ddboost fc status
DDBoost Fibre Channel Status.

This lab covers how to configure DD Boost on a Data Domain system.

This lesson covers the use of various backup applications with DD Boost.

DD Boost provides NetWorker with visibility into the properties and capabilities of the Data Domain
system, control of the backup images stored in the system, and efficient wide area network replication to
remote Data Domain systems.
After you configure a Data Domain system for the DD Boost environment, you can configure NetWorker
resources for devices, media pools, volume labels, clients, and groups that will use the DD Boost devices.
Keep the following NetWorker considerations in mind:
Each DD Boost device appears as a folder on the Data Domain system. A unique NetWorker
volume label identifies each device and associates the device with a pool.
NetWorker uses the pools to direct the backups or clones of backups to specific local or remote
devices.
NetWorker uses Data Protection policy resources to specify the backup and cloning schedules
for member clients. Dell EMC recommends that you create policies that are dedicated solely to
DD Boost backups.
Dell EMC recommends that you use the Device Configuration Wizard, which is part of the NetWorker
Administration GUI, to create and modify DD Boost devices. The wizard can also create and modify
volume labels and the storage pools for DD Boost devices.
After the wizard creates a DD Boost device, you can modify the device configuration by editing the device
resource that is created by the wizard.

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.

DD Boost increases aggregate throughput, substantially reduces backup windows, and improves the Dell
vRanger backup server efficiency. In addition, DD Boost is transparent to Dell vRanger because the DD
Boost plug-in on the Dell vRanger backup server handles the deduplication processing.
Once vRanger is installed, add the DD Boost instance to vRanger as a repository. Any backup written to
this repository will be deduplicated according to the Data Domain configuration.

Veritas NetBackup: DD Boost for Symantec NetBackup OpenStorage enhances the integration between
NetBackup and Data Domain systems. It distributes part of the deduplication process to the media server,
improving backup throughput up to 50 percent, reducing media server loads 80 percent to 90 percent, and
decreasing LAN bandwidth requirements 20 percent to 40 percent. It also enables advanced load
balancing and failover at the Ethernet link layer.
DD Boost for NetBackup has two components. The DD Boost Library is embedded in the OpenStorage
plug-in that runs on the NetBackup Media servers. The DD Boost server is built into DD OS and runs on
Veritas Backup Exec: The combination of a Data Domain system and DD Boost for Symantec Backup
Exec creates an optimized connection to provide a tightly integrated solution. DD Boost for Symantec
Backup Exec offers operational simplicity by enabling the media server to manage the connection
between the backup application and one or more Data Domain systems.
With Symantec Backup Exec, the OST plug-in software must be installed on media servers that need to
access the Data Domain system. Backup Exec is not supported with DD Boost over Fibre Channel.

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.
Implementing DD Boost for RMAN requires installing the DD Boost plug-in on the Oracle server, and then
the DD Boost plug-in interfaces between the Oracle Media Management Layer (MML) API (Also known as
the Simple Backup to Tape API) and DD Boost. The Oracle MML API allows backup applications to
interface with Oracle RMAN.

This module discussed how DD Boost incorporates several features to significantly reduce backup time
and manage replicated data for easier access in data recovery operations.

In this module, you learn about security and protecting your data with a Data Domain
system.
This module contains the following lessons:
Data Domain Retention Lock
Data Sanitization
Encryption of Data at Rest

As data ages and becomes seldom used, EMC recommends moving this data to archive
storage where it can still be accessed, but no longer occupies valuable storage space.
Unlike backup data, which is a secondary copy of data for shorter-term recovery purposes,
archive data is a primary copy of data and is often retained for several years. In many
environments, corporate governance and/or compliance regulatory standards can mandate
that some or all of this data be retained as-is. In other words, the integrity of the archive
data must be maintained for specific time periods before it can be deleted.
The Data Domain (DD) Retention Lock feature provides unchangeable file locking and
secure data retention capabilities to meet both governance and compliance standards.
Therefore, DD Retention Lock ensures that archive data is retained for the length of the
policy with data integrity and security.
This lesson presents an overview of Data Domain Retention Lock, its configuration and use.

EMC Data Domain Retention Lock is an optional, licensed software feature that allows
storage administrators and compliance officers to meet data retention requirements for
archive data stored on a Data Domain system. For files committed to be retained, DD
Retention Lock software works in conjunction with the applications retention policy to
prevent these files from being modified or deleted during the applications defined retention
period, which can be for up to 70 years. It protects against data management accidents,
user errors and any malicious activity that might compromise the integrity of the retained
data. The retention period of a retention-locked file can be extended, but not reduced.
After the retention period expires, files can be deleted, but cannot be modified. Files that
are written to a Data Domain system, but not committed to be retained, can be modified or
deleted at any time.
DD Retention Lock comes in two, separately licensed, editions:

DD Retention Lock Governance edition maintains the integrity of the archive data
with the assumption that the system administrator is generally trusted, and thus any
actions taken by the system administrator are valid as far as the data integrity of the
archive data is concerned.
DD Retention Lock Compliance edition is designed to meet strict regulatory
compliance standards such of those of the United States Securities and Exchange
Commission. When DD Retention Lock Compliance is installed and deployed on an
EMC Data Domain system, it requires additional authorization by a Security Officer for
system functions to safeguard against any actions that could compromise data
integrity.

The capabilities built into Data Domain Retention Lock are based on governance and
compliance archive data requirements.
Governance archive data requirements:

Governance standards are considered to be lenient in nature allowing for flexible
control of retention policies, but not at the expense of maintaining the integrity of the
data during the retention period. These standards apply to environments where the
system administrator is trusted with his administrator actions.
The storage system has to securely retain archive data per corporate governance standards
and must meet the following requirements:
Allow archive files to be committed for a specific period of time during which the
contents of the secured file cannot be deleted or modified.
Allow for deletion of the retained data after the retention period expires.
Allow for ease of integration with existing archiving application infrastructure through
CIFS and NFS.
Provide flexible policies such as allow extending the retention period of a secured file,
revert of locked state of the archived file, etc.
Ability to replicate both the retained archive files and retention period attribute to a
destination site to meet the disaster recovery (DR) needs for archived data.

As discussed in the Basic Administration module, a security privilege can be assigned to
user accounts:
In the System Manager, when user accounts are created.
In the CLI, when user accounts are added.
This security privilege is in addition to the user and admin privileges. A user assigned the
security privilege is called a security officer. The security officer can run a command via the
CLI called the runtime authorization policy.
Updating or extending retention periods, and renaming MTrees, requires the use of the
runtime authorization policy. When enabled, runtime authorization policy is invoked on the
system for the length of time the security officer is logged in to the current session.
Runtime authorization policy, when enabled, authorizes the security officer to provide
credentials, as part of a dual authorization with the admin role, to set-up and modify both
retention lock compliance features, and data encryption features as you will learn later in
this module.
Note: The security officer is the only user that is permitted to change the security officer
password. Contact support if the password is lost or forgotten.

Enable DD Retention Lock Governance, Compliance, or both on the Data Domain
system. (You must have a valid license for DD Retention lock Governance and/or
Compliance.)
Enable MTrees for governance or compliance retention locking using the System
Manger or CLI commands.
Commit files to be retention locked on the Data Domain system using client-side
commands issued by an appropriately configured archiving or backup application,
manually, or using scripts.
(Optional) Extend file retention times or delete files with expired retention periods
using client-side commands.

After an archive file has been migrated onto a Data Domain system, it is the responsibility
of the archiving application to set and communicate the retention period attribute to the
Data Domain system. The archiving application sends the retention period attribute over
standard industry protocols.
The retention period attribute used by the archiving application is the last access time - the
atime. DD Retention Lock allows granular management of retention periods on a file-by-file
basis. As part of the configuration and administrative setup process of the DD Retention
Lock, a minimum and maximum time-based retention period for each MTree is established.
This ensures that the atime retention expiration date for an archive file is not set below the
minimum, or above the maximum, retention period.
The archiving application must set the atime value, and DD Retention Lock must enforce it,
to avoid any modification or deletion of files under retention of the file on the Data Domain
system. For example, Symantec Enterprise Vault retains records for a user-specified
amount of time. When Enterprise Vault retention is in effect, these documents cannot be
modified or deleted on the Data Domain system. When that time expires, Enterprise Vault
can be set to automatically dispose of those records.
Locked files cannot be modified on the Data Domain system even after the retention period
for the file expires. Files can be copied to another system and then be modified. Archive
data retained on the Data Domain system after the retention period expires is not deleted
automatically. An archiving application must delete the remaining files, or they must be
removed manually.

You can configure DD Retention Lock Governance using the System Manager or by using
CLI commands. System Manager provides the capability to modify the minimum and
maximum retention period for selected MTrees. In the example above, the Modify dialog is
for the MTree /data/col1/IT.
To configure retention lock:

1. Select Data Management > MTree.
2. Select the MTree you want to edit with DD Retention Lock.
3. Click the Summary tab and scroll down to the Retention Lock area.
4. Click Edit.
5. Check the box to enable retention lock.
6. Enter the retention period or select Default.
7. Click OK.

The DD Retention Lock Compliance edition meets the strict requirements of regulatory
standards for electronic records, such as SEC 17a-4(f), and other standards that are
practiced worldwide.
DD Retention Lock Compliance, when enabled on an MTree, ensures that all files locked by
an archiving application, for a time-based retention period, cannot be deleted or overwritten
until the retention period expires. This is archived using multiple hardening procedures by
requiring dual sign-on for certain administrative actions. Before engaging DD Retention
Lock Compliance edition, the System Administrator must create a Security Officer role. The
System Administrator can create the first Security Officer, but only the Security Officer can
create other Security Officers on the system.
Some of the actions requiring dual sign-on include:

Extending the retention periods for an MTree.
Renaming the MTree.
Deleting the Retention Lock Compliance license from the Data Domain system.
Securing the system clock from illegal updates - DD Retention Lock Compliance
implements an internal security clock to prevent malicious tampering with the
system clock. The security clock closely monitors and records the system clock.
If there is an accumulated two-week skew within a year between the security
clock and the system clock, the Data Domain file system (DDFS) is disabled and
can be resumed only by a security officer.

In this lesson, you learn the function of data sanitization and how to run a command from
the CLI to sanitize data on a Data Domain system.

Data sanitization is sometimes referred to as electronic shredding.
With the data sanitization function, deleted files are overwritten using a DoD/NIST-
compliant algorithm and procedures. No complex setup or system process disruption is
required. Existing data is available during the sanitization process, with limited disruption to
daily operations. Sanitization is the electronic equivalent of data shredding. Normal file
deletion provides residual data that allows recovery. Sanitization removes any trace of
deleted files with no residual remains.
Sanitization supports organizations (typically government organizations) that:

Are required to delete data that is no longer needed.
Need to resolve (remove and destroy) classified message incidents. Classified
message incident (CMI) is a government term that describes an event where data of a
certain classification is inadvertently copied into another system that is not certified
for data of that classification.
The system sanitize command erases content in the following locations:

Segments of deleted files not used by other files.
Contaminated metadata.
All unused storage space in the file system.
All segments used by deleted files that cannot be globally erased, because some
segments might be used by other files.
Sanitization can be run only by using the CLI.

When you issue the system sanitize start command, you are prompted to consider the
length of time required to perform this task. The system advises that it can take longer
than the time it takes to reclaim space holding expired data on the system (filesys clean).
This can be several hours or longer, if there is a high percentage of space to be sanitized.
During sanitization, the system runs through five phases: merge, analysis, enumeration,
copy, and zero.
Merge: Performs an index merge to flush all index data to disk.
Analysis: Reviews all data to be sanitized. This includes all stored data.
Enumeration: Reviews all of the files in the logical space and remembers what data
is active.
Copy: Copies live data forward and frees the space it used to occupy.
Zero: Writes zeroes to the disks in the system.
You can view the progress of these five phases by running the system sanitize watch
command.
Related CLI commands:

# system sanitize abort
Aborts the sanitization process.
# system sanitize start
Starts sanitization process immediately.
# system sanitize status
Shows current sanitization status.
# system sanitize watch
Monitors sanitization progress.

This lab covers how to configure DD Boost on a Data Domain system.

In this lesson, you learn about the features, benefits, and function of the encryption of data
at rest feature.
You also learn about the purpose of other security features, such as file system locking, and
when and how to use this feature.

This lesson covers changing the encryption passphrase as well as disabling the encryption.
Also covered is file system locking and unlocking.

Data encryption protects user data if the Data Domain system is stolen, or if the physical
storage media is lost during transit, and eliminates accidental exposure of a failed drive if it
is replaced. In addition, if an intruder ever gains access to encrypted data, the data is
unreadable and unusable without the proper cryptographic keys.
Encryption of data at rest:

Enables data on the Data Domain system to be encrypted, while being saved and
locked, before being moved to another location.
Is also called inline data encryption.
Protects data on a Data Domain system from unauthorized access or accidental
exposure.
Requires an encryption software license.
Encrypts all ingested data.
Does not automatically encrypt data that was in the system before encryption was
enabled. Such data can be encrypted by enabling an option to encrypt existing data.
Furthermore, you can use all of the currently supported backup applications described in
the Backup Application Matrix on the Support Portal with the Encryption of Data at Rest
feature.

There are two available key management options:
Starting with DD OS 5.2, an optional external encryption key management capability
has been added, the RSA Data Protection Manager (DPM) Key Manager. The
preexisting local encryption key administration method is still in place. You can choose
either method to manage the Data Domain encryption key.
The Local Key Manager provides a single encryption key per Data Domain system.
A single internal Data Domain encryption key is available on all Data Domain systems.
The first time Encryption of Data at Rest is enabled, the Data Domain system randomly
generates an internal system encryption key. After the key is generated, the system
encryption key cannot be changed and is not accessible to a user.
The encryption key is further protected by a passphrase, which is used to encrypt the
encryption key before it is stored in multiple locations on disk. The passphrase is user-
generated and requires both an administrator and a security officer to change it:
The RSA DPM Key Manager enables the use of multiple, rotating keys on a Data
Domain system.
The RSA DPM Key Manager consists of a centralized RSA DPM Key Manager Server and
the embedded DPM client on each Data Domain system.
Note: As this course was being written we received notice that RSA DPM will be
replaced in the near future by RSA SecurID. No details were available. Check with Dell
EMC support for details when it does become available.

With the encryption software option licensed and enabled, all incoming data is encrypted
inline before it is written to disk. This is a software-based approach, and it requires no
additional hardware. It includes:
Configurable 128-bit or 256-bit advanced encryption standard (AES) algorithm with
either:
Confidentiality with cipher-block chaining (CBC) mode.
Or
Both confidentiality and message authenticity with Galois/Counter (GCM) mode.
Encryption and decryption to and from the disk is transparent to all access protocols:
DD Boost, NFS, CIFS, NDMP tape server, and VTL (no administrative action is required
for decryption).

Procedures requiring authorization must be dual-authenticated by the security officer and
the user in the admin role.
For example, to set encryption, the admin enables the feature, and the security officer
enables runtime authorization.
A user in the administrator role interacts with the security officer to perform a command
that requires security officer sign off.
In a typical scenario, the admin issues the command, and the system displays a message
that security officer authorizations must be enabled. To proceed with the sign-off, the
security officer must enter his or her credentials on the same console at which the
command option was run. If the system recognizes the credentials, the procedure is
authorized. If not, a Security alert is generated. The authorization log records the details of
each transaction.

With encryption active in the Data Domain system, the Encryption tab within the File
System section of the Data Domain System Manager shows the current status of system
encryption of data at rest.
The status indicates Enabled, Disabled, or Not configured. In the slide, the encryption
status is Not configured.
To configure encryption:
1. Click Configure.

You are prompted for a passphrase. The system generates an encryption key and uses the
passphrase to encrypt the key. One key is used to encrypt all data written to the system.
After encryption is enabled, the passphrase is used by system administrators only when
locking or unlocking the file system, or when disabling encryption. The current passphrase
size for DD OS 5.7 is 256 characters.
Caution: Unless you can reenter the correct passphrase, you cannot unlock the file system
and access the data. The data will be irretrievably lost.
2. Enter a passphrase and then click Next.
3. Choose the encryption algorithm and then click Next:
Configurable 128-bit or 256-bit Advanced Encryption Standard (AES) algorithm
with either:
Confidentiality with Cipher Block Chaining (CBC) mode.
Both confidentiality and message authenticity with Galois/Counter (GCM)
mode.
In this configuration window, you can optionally apply encryption to data
that existed on the system before encryption was enabled.
4. Select whether you will obtain the encryption key from the Data Domain system or
an external RSA Key Manager. Click Finish. Note that the system needs to be
restarted for the new configuration to start.

Only administrative users with security officer credentials can change the encryption
passphrase.
To change the existing encryption passphrase:
1. Disable the filesystem
2. Run system passphrase change

Only administrative users with security officer credentials can disable encryption. The CLI
command is filesys encryption disable.
In the above example, sysadmin is logged in. Notice we are asked for the security
Username and Password.
Also note the filesystem must be restarted to effect this change.

Use file system locking when an encryption-enabled Data Domain system and its external
storage devices (if any) are being transported. Without the encryption provided in file
system locking, user data could possibly be recovered by a thief with forensic tools
(especially if local compression is turned off). This action requires two-user authentication
a sysadmin and a security officer to confirm the lock-down action.
File system locking:

Requires the user name and password of a security officer account to lock the file
system.
Protects the Data Domain system from unauthorized data access.
Is run only with the file system encryption feature enabled. File system locking
encrypts all user data, and the data cannot be decrypted without the key.
A passphrase protects the encryption key, which is stored on disk, and is encrypted by
the passphrase. With the system locked, this passphrase cannot be retrieved.
Allows only an admin, who knows the set passphrase, to unlock an encrypted file
system.

Before you can lock the file system, encryption must be enabled and the file system must
be disabled.
To lock the file system:

In the passphrase area on the Administration tab, enter the current passphrase (if
one existed before) followed by a new passphrase that locks the file system for
transport. Repeat the passphrase in the Confirm New Passphrase field.
Click OK to continue.
After the new passphrase is entered, the system destroys the cached copy of the
current passphrase. Therefore, anyone who does not possess the new passphrase
cannot decrypt the data.
Caution: Be sure to take care of the passphrase. If the passphrase is lost, you will
never be able to unlock the file system and access the data. There is no backdoor
access to the file system. The data is irretrievably lost.
Click Disable on state line of the File System section
Click Lock File System on the status line of the File System Lock section.
Enter the security officer credentials.
Enter the current and new passphrase to re-encrypt the encryption keys.
Shut down the system using the system poweroff command from the command line
interface (CLI).
Caution: Do not use the chassis power switch to power off the system. There
is no other method for shutting down the system to invoke file system
locking.

This module focuses on some of the data security features of the Data Domain operating
system including retention locks, sanitization, and encryption of data at rest.

This module focuses on some of the data security features of the Data Domain operating
system including retention locks, sanitization, and encryption of data at rest.

This module focuses on secure multi-tenancy features, setup, and access.

This lesson covers an introduction to secure multi-tenancy, its features, architecture, and
benefits and implementation considerations.

Secure Multi-Tenancy is built to deliver protection storage as a service for large
enterprises and service providers who are looking to offer Data Domain as a service in a
private or public cloud.
With SMT, a Data Domain system is able to logically isolate data for up to 32 tenants, which
will restrict each tenants visibility and read/write access to only their data (contained in
their MTrees). In addition, secure multi-tenancy enables management and monitoring by
tenant to enable chargeback, trending, and other reporting.
This diagram shows a simplified architecture of an individual tenant unit residing on a single
Data Domain system (here named, DD System 1). Starting with DD OS 5.5, a tenant unit is
created using the command line interface.
Note that NFS and CIFS MTrees, VTL pools, and DD Boost storage units are each logically
isolated by MTree within a single tenant unit and are securely accessed by tenant client
applications using protocol-specific security.

The secure multi-tenancy for Data Domain feature allows enterprises and service
providers to deliver data protection-as-a-service. Specifically, this feature enables
enterprises to deploy Data Domain systems in a private cloud and enables service
providers to deploy Data Domain systems in a hybrid/public cloud.
Allows for different cloud models for protection storage:

Local Backup, Backup-as-a-Service (BaaS) for hosted applications
Replicated Backup, Disaster Recovery-as-a-Service (DRaaS)
Remote Backup, BaaS over WAN
Secure multi-tenancy for Data Domain systems is a feature that enables secure isolation of
many users and workloads on a shared system. As a result, the activities of one tenant are
not visible or apparent to other tenants. This capability improves cost efficiencies through a
shared infrastructure while providing each tenant with the same visibility, isolation, and
control that they would have with their own stand-alone Data Domain system.
A tenant may be one or more business units or departments hosted onsite for an
enterprise or large enterprise (LE). A common example would be Finance and Human
Resources sharing the same Data Domain system. Each department is unaware of the
presence of the other on the system. A tenant might also be one or more external
applications that are hosted remotely by a service provider (SP) on behalf of a client.

SMT components, also known as management objects, provide security and isolation
within a shared infrastructure. SMT components are initially created by the admin during
the basic provisioning sequence, but can also be created manually as needed.
A tenant-unit is a partition of a Data Domain system that serves as the unit of

administrative isolation between tenants. A tenant is responsible for scheduling and
running the backup application for the tenant customer and for managing their own
tenant-units including configuring backup protocols and monitoring resources and stats
within their tenant-unit.
Multiple roles with different privilege levels combine to provide the administrative isolation
on a multitenant Data Domain system. The Tenant Admin and Tenant User are restricted
only to certain tenant-units on a Data Domain system and allowed to execute a subset of
the commands that a Data Domain system administrator is allowed.
The landlord is the storage admin or the Data Domain Administrator. The landlord is
responsible for managing the Data Domain system. The landlord sets up the file systems,
tenant units, tenant roles, storage, networking, replication, and protocols. They are also
responsible for monitoring overall system health and replace any failed hardware as
necessary.

A tenant object can be created within the DD OS environment. The tenant object allows
tenant units to be grouped together by the same tenant. Shown here, the same tenant
spans two Data Domain systems where the other tenant units belong to the same tenant
might reside. The tenant unit uses the same universally unique identified (UUID) recognized
by both systems.
Storage-units are MTrees configured for use with the DD Boost protocol. Data isolation
is achieved by creating a storage-unit and assigning the storage-unit to a DD Boost user.
The DD Boost protocol only permits access to storage-units assigned to DD Boost users
connected to the Data Domain system.
MTrees reside on logical partitions of the file system and offer the highest degree of
management granularity, meaning users can perform operations on a specific MTree
without affecting the entire file system. MTrees are assigned to tenant-units and contain a
tenant-unit's individualized settings for managing and monitoring SMT. A tenant-unit may
comprise one or more MTrees. Tenant units can also span multiple Data Domain systems.

Logical data isolation allows providers to spread the capital expenditure and operational
expenditure of a protection storage infrastructure across multiple tenants. Data isolation is achieved
by using separate DD Boost users for different MTrees or by using the access mechanisms of NFS,
CIFS, and VTL.
A tenant-unit is a logical partition in a Data Domain system isolating one tenants data from another.
Tenant Admins may only administer the tenant units that belong to them providing administrative
isolation.
The DD Boost protocol allows creation of multiple DD Boost users on a Data Domain system. With
that, each tenant is assigned one or more DD Boost user credentials that can be assigned access
privileges to one ore more MTrees in a tenant unit defined for a particular tenant. This allows secure
access to different tenant datasets using their separate DD Boost credentials by restricting access and
visibility.
Similarly, for other protocols such as CIFS, NFS and VTL the native protocol level access control
mechanisms can be used to provide data path isolation.
Mutual isolation is a security feature that ensures local users, management groups, and remote IPs
associated with one tenant in an SMT environment are not associated with another tenant. When
configuring tenants, users, tenant units, or protocol that transfers data such as replication and DD
Boost, mutual isolation ensures data and administrative isolation across tenants.
Through metering and reporting a provider (Landlord) has information to ensure they are running
a sustainable business model. The need of such reporting in a multi-tenant environment is even
greater when the provider to tracks usage on a shared asset such as a Data Domain system.
With secure multi-tenancy, the Landlord has the capability to track and monitor usage of various
system resources. Similarly, the Tenant User can access metrics via tenant self-service. The tenant-
view of the metrics is restricted to resources that are assigned to a particular Tenant User.
Different metrics can be extracted from the Data Domain system using SNMP. The SNMP MIB provides
relationships of the different metrics to the tenant unit thereby allowing grouping the metrics on a per
tenant basis.

In this simple example, two companies, Acme and Bigsys, share the same Data Domain
system. Tenant units and individual data paths are logically and securely isolated from
each other and are managed independently. Tenant users can backup using their
application servers to Data Domain storage in secure isolation from other tenants on the
Data Domain system.
Tenant administrators can perform self-service fast copy operations within their tenant
units for data restores as needed. Tenant administrators are able to monitor data capacity
and associated alerts for capacity and stream use.
The landlord, responsible for the Data Domain system monitors and manages all tenants in
the system and has visibility across the entire system. They set capacity and stream quotas
on the system for the different tenant units, and report on tenant unit data.

Security for replication operations is an example of mutual isolation. To perform
replication in an SMT environment, the system also provides security to maintain the
integrity of the replication between the sites. There are two security modes to enforce this:
Default and Strict.
When no security mode is selected, the system provides a default security mode. Default
security mode allows replication as long as the source and destination do not belong to
different tenants.
Shown here, the source MTree belongs to Tenant A, therefore replication can only occur on
the destination system with Tenant A. Failure occurs when the specified destination is
Tenant B.

When replication is running, while using strict-mode security, the source and destination
MTrees must belong to the same tenant or the replication fails.
Shown here, Tenant A is present on both the source and destination Data Domain. When
Tenant A names Tenant-Unit-A1.1 as the source and Tenat-Unit-A2.1 as the destination,
the replication protocol checks to make sure both tenant units belong to the same tenant.
Upon confirmation the replication proceeds.
Tenant A proceeds to set up a new replication pair naming Tenant-Unit-A1.2 as the source
and Tenant-Unit-B2.2 as the destination. The protocol checks the ownership of both source
and destination. Upon confirming that each tenant unit belongs to a different tenant, the
replication fails.

Stream limits are set per tenant for replication data. The maximum number of streams
allowed during replication is controlled by the destination Data Domain system by the
service provider for each tenant.
Capacity quotas are also set on the replication destination to make sure individual tenants
do not consume storage beyond a set limit on the Data Domain system they are sharing.
Even before replication to a destination begins, the capacity quota is set through the
command line for any future replication MTrees. This prevents any single tenant from
consuming all available space on a system and creating a full storage condition that
prevents other tenants from adding data to their own spaces.
Capacity quota and replication stream limits are set by the service provider owning the
destination.

The Data Domain OS allows administrators to configure specific network clients for
tenants using local and remote IPs to eliminate potential security problem with tenants
accessing the system over the network. Local and Remote IPs create a layer of network
isolation using access validation.
Shown here, Tenant A has multiple tenant units on the Data Domain system and uses Client
A to log in and manage those units. An unauthorized user wants to access and manage
tenant-units belonging to Tenant A using a different client, Client B.
Normally, the unauthorized client could do so by simply providing the username and
password used by Tenant A. By assigning a local IP to Tenant A, their tenant-units can then
only be accessed by the client using the configured local IP. Without a local IP associated
with Client B, the unauthorized user cannot access the Data Domain system.
By configuring a set of remote IP, the tenants can only be accessed from a client connecting
from a defined set of configured remote IPs. An authorized user with a username and
password without a remote IP assigned to their client will not gain access to the system.
This form of network isolation creates an association between the management IP and a
tenant unit. It provides a layout of network isolation using access validation. Setting local
and remote IPs is only for self-service sessions.

In order to create SMT objects, the Multitenancy page in Data Domain Management Center
is leveraged. The page is displayed with a summary of a configured Tenant Unit configured
including tenant, tenant unit, associated MTrees, Storage Units, VTP Pools, and so on.

Before configuring a multitenant environment on a Data Domain system, it is important to
be aware of these considerations:
SMT requires the system run DD OS 5.5 or higher. To access all SMT features, run the
most current version of DD OS.
SMT provides secure logical isolation not physical isolation. Tenant data on a system
securely co-mingles with other tenant data and shares deduplication benefits of all data
on the system.
SMT supports NFS, CIFS, DD Boost, VTL, and replication protocols.
SMT supports Extended Retention and Retention Lock Governance Edition.
Retention Lock Compliance Editions still function on systems configured with secure
Multi-tenancy, but not at the tenant level. If enabled, function and management of
MTrees are severely impaired. For tenant-level Compliance Lock deployment, it is
recommended the tenant use separate Data Domain systems.
SMT supports a single CIFS active directory per system.
SMT requires that landlords create replication contexts.
SMT does not currently allow management of system-wide parameters at the tenant-unit
level. For instance, depending on the model, a Data Domain system running DD OS 6.0
is limited to the current level of 32 to 256 maximum, concurrently active MTrees. If
multiple tenants choose to run operations simultaneously on the same DD system, the
threshold of multiple active MTrees could be crossed. The same should be considered
with multiple clients employing a number of NFS connections. A current maximum of 900
simultaneous NFS connections is allowed system-wide, tenants could possibly run into
this limit when sharing the number of allowed NFS connections in a multi-tenant
environment.

This lesson covers secure multi-tenancy setup and configuration including the use of
various protocols.

In order to take advantage of SMT, it must be set up and configured by the Landlord. The
Multitenancy page is located in the Data Domain Management Center under Administration.
There are two sections: one provides a listing of all the tenants and tenant units in the data
center and the other provides a detailed overview of either the selected tenants or tenant
units. In this slide All Tenants is selected and the detailed overview displays the number of
tenants, tenants units and host systems that are configured in this Data Domain
Management Center (DDMC).
When All Tenants is selected, new tenants can be created by clicking the green Plus sign.
A Create Tenant window appears. You complete creation by entering a tenant name and
the administrators email address.
When a single tenant is selected, new tenant units can be created by clicking the green Plus
sign.

In the Create Tenant Unit window, you can create a Tenant Unit and provision either
manually or automatically. You can also create an empty Tenant Unit where storage storage
can be provisioned later.
Complete a few pages with specific information to use for a customized tenant unit
including the host system size, a tenant unit name, security mode, the use of a new or
existing MTree or Storage Unit.
Shown here are two pages, one represents the page requesting the administrator to choose
how storage is provisioned for the Tenant Unit, and the second indicates the current
storage capacity, the future size, and how long it takes the system to grow.
The following slides do not represent the process step-by-step, but do show some of the
key information about the Tenant Unit.

Provide a tenant unit name and management IP addresses of a remote client and local DD
MC. The security setting for the tenant unit is also selected on this screen. Use Strict
Security Mode is selected by default to enforce strict security at both source and
destination sides during a replication. By removing the checkmark, default mode is then
enabled to check both source and destination side of a replication to ensure they do not
belong to the same tenant.

There are four network-related attributes you can configure for increased security.
First, the tenant unit hostname. Just as you are able to set a hostname on an entire Data
Domain system, you can configure a unique hostname for each tenant unit. In order for the
hostname to resolve to the specific tenant unit, you must assign it to an IP address within
that tenant unit.
Second, local data access IP addresses to a tenant unit for isolated data access
purposes. They act as server or local data access IP addresses. Local data access IPs must
be unique IP addresses; you may not assign the same IP to more than a single tenant unit.
Third, remote data access IP addresses are the client IP address or subnets that are
assigned a tenant unit for data access. Unlike the local data access IP, a remote data access
IP may be shared within the same tenant.
The last network attribute is the default gateway that can be configured for tenant units
belonging to the same tenant.

In this diagram a Data Domain system has a tenant unit, tu1. You can set a hostname for
that tenant unit, in this case, tu1hn.
As long as the hostname resolves to correct IP address in DNS or in the client local
/etc/hosts file, here it is IP1. Clients can connect to the tenant unit using only its hostname.

SMT data access isolation is a safeguard used to prevent access from unauthorized local
IP addresses.
Based on the originating IP that the data operation request comes from, SMT data access
isolation restricts the operation access to only a set of storage objects.
In the diagram, local IP1 is allowed access to storage objects in tenant unit 1 (tu1) but not
allowed access to storage objects in tenant unit 2.
Similarly, local IP2 and 3 are allowed access to objects in tu2 but is denied when attempting
to access objects in tu1.
To achieve this level of isolation, you have to add a local data access IP address to the
tenant unit. The SMT data access isolation check performs checks in the I/O path to ensure
access to the selected objects is allowed by the local IP being used.

When configuring data access isolation, consider the following points: a local data access IP
address must first be configured and running on the Data Domain system before it can be
added to a tenant unit. Second, a local data access IP is unique to a single tenant unit and
may not be shared among other tenant units. Third, IP ranges and subnets are not
supported as local data access IPs. If you want to add a range of IP addresses, you must
add them individually.
Leased IP addresses such as DHCP addresses may not be used as local data access IPs.
Leased IP addresses would be difficult to track and enforce when trying to isolate data
access by IP.
Lastly, tenant unit local data IPs cannot be used to access non tenant data.

Dynamic interface groups, or DIGs, distributes backup-application client connections across
available links on the Data Domain system while maintaining data path isolation. When an
error is encountered on a link, the dynamic interface groups configuration initiates a failover
to another link within the isolated VLAN.
The way to make SMT tenant units work with DIGs is to configure all of the IP addresses in
the DIG as local data access IP addresses within the tenant unit.
When properly configured, the SMT tenant unit can take full advantage of any link the DIG
provides.
On the left side of this diagram, there is a configuration in the DNS or /etc/hosts where
tu1hn resolves to IP1 and tu1hn-failover resolves to IP2. This configuration is specifically for
DD Boost ifgroup configuration. In order for ifgroups to work properly, two hostnames are
required within DD Boost.

Take a moment to review these considerations for configuring dynamic interface groups
with SMT tenant units on Data Domain systems.

As a part of data isolation within SMT, there is remote to local IP mapping, through a net
filter to ensure the local IP only receives network traffic from a specific remote IP.
Along with the SMT data access isolation protocol, a net filter or IP table restricts access by
blocking packets based on remote and local IP setup. In this diagram, client 1 is allowed
access to certain storage objects only through local IP1, If client 1 attempts to access
storage objects through local IP2, the net filter denies access using IP filtering and .
This further strengthens data isolation throughout SMT on a Data Domain system.

Here is a more detailed look at the network firewall.
On the right is a Data Domain system with two tenant units configured. Each tenant unit
has its own assigned local data IP. IP1 for tu1 and IP2 for tu2.
Each tenant unit has a firewall rule set to only allow traffic from certain client IP addresses.
If a tenant client requests access to data over an unassigned local data IP, based on the
rules, the firewall will disallow access.

There are two important considerations when configuring remote IPs for a tenant unit on
Data Domain systems. First, you may not share remote data access IPs among the different
tenants on the system. And note that tenant isolations checks are not performed if you
configure remote data access IPs with subnets and data ranges.

Unique default gateways help strengthen physical isolation of data between tenants. Data
packets from different tenants can be routed through different routers or gateways. This is
done by configuring one of more default gateways for each tenant unit within a Data
Domain system. The configured gateways are assigned to individual tenant-unit IP
addresses.

Here are some considerations when setting unique default gateways to tenant units.
Only targeted default gateways are configured with SMT. While there are other gateway
types configurable within a Data Domain system such as static, added, or DHCP, only
targeted gateways are supported with SMT.
You may not share the same default gateway among different tenants. These gateways
are intended to be unique per tenant.
Unique default gateways assigned to a tenant may not be used by non-SMT entities within

Soft and hard quotas are enabled or disabled by selecting the appropriate button in the
storage provisioning step of a Tenant Unit. The administrator has two options:
1. Select none to disable the quota.
2. Select a unit in MB, GB, TB or PB.
Quota management is performed for an MTree or Storage Unit during the creation or
modification of a Tenant Unit. Once quotas are configured, any objects within the Tenant
Unit are bound to their set capacity quotas.

Tenant Self-Service is enabled or disable in the Edit Tenant Unit window. By placing a
checkmark next to Enable Tenant Self-Service, the service is enabled; alternatively, by
removing the checkmark disables the service. If the service is enabled, it is recommended
to add local users or groups with specific role to monitor the resources within the tenant
unit. For users, the administrator can create either a new local user or add ddboost. For
roles, the administrator has two options: Tenant Admin or Tenant User.

The administrator has the option to select either:
Tenant User: has the privileges to monitor specific tenant units for important parameters
such as space usage, streams performance, alerts, and status of replication context and
snapshots.
Tenant Admin: gets all the privileges of a tenant user and can modify the recipient list of
alerts and also perform Data Domain fastcopy operations.

In an SMT configuration, backup and restores require client access to the CIFS shares
residing in the MTree of the associated tenant-unit. Data isolation is achieved using CIFS
shares and CIFS ACLs.

Listed here are additional commands to configure CIFS under SMT.

The DD CLI also has a function to list active and allowed NFS clients of a tenant-unit.
Through nfs show active and nfs show clients, you can now see all clients or only the
currently active NFS clients belonging to a particular tenant-unit.
These commands are available for both administrative users and self-service users. Self-
service users can only see the clients specific to their tenant-units.

DD VTL Tenant data isolation is achieved using DD VTL access groups to create a virtual
access path between a host system and DD VTL. The physical Fibre Channel connection
between the host system and DD VTL must already exist.
Placing tapes in the DD VTL allows them to be written to, and read by, the backup
application on the host system. DD VTL tapes are created in a DD VTL pool, which is an
MTree. Because DD VTL pools are MTrees, the pools can be assigned to Tenant Units. This
association enables SMT monitoring and reporting.

If a tenant-admin is assigned a Tenant Unit that contains a DD VTL pool, the tenant-admin
can run MTree-related commands to display read-only information. Commands can run only
on the DD VTL pool assigned to the Tenant Unit.
These commands include:
mtree list Shows a list of MTrees in the Tenant Unit
mtree show compression Shows statistics on MTree compression
mtree show performance Shows statistics on performance

The term multi-user DD Boost refers to multiple backup applications that share the same
Data Domain system in a service provider (SP) environment. Within an SP environment,
each backup application may have multiple DD Boost users, each defined by separate
usernames.
A storage-unit is an MTree configured for the DD Boost protocol. A user can be associated
with, or own, more than one storage-unit. Storage-units that are owned by one user
cannot be owned by another. The number of DD Boost usernames cannot exceed the
maximum number of MTrees (current maximum is 100).
Each backup application must authenticate using its DD Boost username and password.
After authentication, DD Boost verifies the authenticated credentials to confirm ownership
of the storage unit. The backup application is granted access to the storage- unit only if the
user credentials presented by the backup application match the usernames associated with
the storage-unit. If user credentials and usernames do not match, the job fails with a
permission error.
The procedure for creating a storage-unit is initially performed by the admin as prompted
by the configuration wizard. Instructions for creating a storage-unit manually are included
later in this chapter.

This lesson covers different techniques and tools for monitoring SMT on a Data Domain
system.

SMT management operations include monitoring tenant units and other objects such as
MTrees and Storage Units. Each MTree generates performance statistics for historical
database and real-time information. Data can be used by the Data Domain system
administrator as a chargeback metric.

DD MC is able to display statistical information of either the Tenant or the Tenant Unit. The
Tenant Details lightbox can be accessed under Administration -> Multitenancy, select
Tenant (or Tenant Unit), and click the I icon as seen in the slide. The Overview tab (1), is
the first to come up, it provides information about the Tenant including Tenant Name,
Administrator, Tenant Units and Systems. It also displays information about Health,
Capacity, Replication and Network Bytes Used. Besides the Overview tab, the Tenant
Details lightbox also have the following tabs:
Capacity (2): shows capacity overview details with a variable meter that shows the
quota (available, used and used percentage).
Replication (3): shows replication overview details that include the total number of
bytes replicated for Automatic Replication Pairs and On-Demand Replication Pairs.
Network Bytes Used (4): shows network overview details that include the last 24
hours of back-up, restored data and total inbound and outbound replication.
System Charts (5): shows the system charts for the DD system of a selected Tenant
Units associated with this Tenant.
For details explanation of what is included within each tab, please refer to the current Data
Domain Management Center User Guide.

Similar to the Tenant Details lightbox, there is a Tenant Unit Details lightbox. Within the
page, similar information is displayed except that the information is provided at the tenant
unit-level. The overview tab shows Tenant Unit details such as health, capacity, hard and
soft quotas, replication, and network throughput statistics and host system performance.
For details explanation of what is included within each tab, please refer to the current Data
Domain Management Center User Guide.

The SNMP management information base (MIB) is able to read the new information. The
snmpwalk command reflects these new objects and relationships. The overall objective of
this command is to let the software know of the DD system reporting status.
In DD MC, the Object ID is easily identified under Health -> Alerts.

Quotas are set initially when prompted by the SMT configuration wizard. Besides the DD
MC, various tasks can be performed through the Data Domain CLI. Landlords and Tenant
admins can collect usage statistics and compression ratios for MTrees associated with their
tenant-units using the following commands:
#mtree list List the Mtrees on a Data Domain system (when used by a landlord) or
within a tenant-unit (when used by a tenant-admin).
#mtree show stats Collect MTree real-time performance statistics.
#mtree show performance Collect performance statistics for MTrees associated with a
tenant-unit.
#mtree show compression Collect compression statistics for MTrees associated with a
tenant-unit.
#quota capacity show List capacity quotas for MTrees and storage-units.
Output may be filtered to display usage in intervals ranging from minutes months. The
results can be used by the landlord as a chargeback metric.
Quotas may be adjusted or modified by the Landlord after the initial configuration using the
#ddboost storage-unit modify command.

Physical Capacity Measurement measures and reports on space usage information for a
sub-set of storage space. From the DD System Manager, PCM provides space usage
information for MTrees but from the command line interface you can view space usage
information for MTrees, tenants, tenant units, and pathsets.
This feature extends into secure multi-tenancy environments for Tenant Admins and Tenant
Users.
Using the command line, Tenant Admins can create or destroy a pathset, add or delete
paths in a pathset, and modify a pathset.
Tenant Admins can start or stop a physical capacity measurement job, create, destroy and
modify a physical capacity measure schedule and enable or disable a physical capacity
measurement schedule.
Tenant Users may only view physical capacity measurement activities belonging to their
tenant units.
For more information about using PCM form the command line, see the EMC Data Domain
Operating System Command Reference Guide.

A Data Domain system generates events when it encounters potential problems with the
software or hardware. When an event is generated, an alert notification is sent immediately
via email to members designated in the notification list and to the Data Domain admin.
SMT Tenant alerts are specific to each tenant-unit and differ from Data Domain system
alerts. When tenant self-service is enabled, the Tenant-Admin can choose to receive alerts
about the various system objects he or she is associated with and any critical events, such
as an unexpected system shutdown. A Tenant-Admin may only view or modify notification
lists to which he or she is associated.

Every tenant unit has its own alert notification, and it can be accessed through the Data
Domain Management Centers Multitenancy page. A notification group can be managed by
using the Add, Edit and Delete appropriate to perform respective tasks. These tasks include
creating new notification groups, editing notification to add or remove email addresses in
the recipient list. The DD system will use the notification group to send reports for the
specific tenant units.

Status and usage templates can be added to generate reports for SMT by using the
Reports -> Management within DD MC. This slide shows the second page that appears in
the process of adding the template. Three inputs are required: a name, template and
section. The name is independent, but the sections available depend on the template
selected.
The Status template includes daily status for the tenant or tenant unit as it pertains to
capacity, replication, network bytes used.
The Usage Metrics template includes metrics for the tenant and tenant unit as it pertains
to logical and physical capacity and network bytes used.

The Add Report Template has two parts. In the first part you select either Tenant Unit or
Tenant to include in the report. The second part you select the time span and schedule
to report. The system creates a report as scheduled for the selected time period. Reports
are retained for the selected length of time as well.
Once the scope is defined, you can proceed to complete the template creation.
The DD system uses the Add Reports Template to generate and send reports to the
appropriate personnel. Ultimately, these reports can be used for chargebacks to the various
tenants of the system.

This module focuses on Data Domain Secure Multi-Tenancy. It includes provisioning,
management, and monitoring and reporting on various objects within a tenant and/or
tenant unit.


DD Final

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

DD Final

Uploaded by

Copyright:

Available Formats

This module covers sizing, capacity and throughput planning and tuning.

In any backup environment, it is critical to plan capacity and throughput adequately.

Copyright 2017 Dell Inc.. Data Domain System Administration 1

Copyright 2017 Dell Inc.. Data Domain System Administration 2

Copyright 2017 Dell Inc.. Data Domain System Administration 3

The reduction rates shown are approximate.

Copyright 2017 Dell Inc.. Data Domain System Administration 4

Copyright 2017 Dell Inc.. Data Domain System Administration 5

Dividing 200 GB by 10 hours yields a raw processing requirement of at least 20 GB per

Over an unrestricted 1 GB network with maximum bandwidth available (with a theoretical

Copyright 2017 Dell Inc.. Data Domain System Administration 6

Copyright 2017 Dell Inc.. Data Domain System Administration 7

Copyright 2017 Dell Inc.. Data Domain System Administration 8

Copyright 2017 Dell Inc.. Data Domain System Administration 9

Copyright 2017 Dell Inc.. Data Domain System Administration 10

Model B is also a viable option with 428 TB capacity a 42 % buffer.

Copyright 2017 Dell Inc.. Data Domain System Administration 11

Copyright 2017 Dell Inc.. Data Domain System Administration 12

Copyright 2017 Dell Inc.. Data Domain System Administration 13

There are three primary steps to throughput:

Copyright 2017 Dell Inc.. Data Domain System Administration 14

Some possible bottlenecks are: Backup Server

Disk Issues Load

Eliminating bottlenecks where possible, or at least mitigating the cause of reduced

Copyright 2017 Dell Inc.. Data Domain System Administration 15

The command syntax is:

Utilization is measured in four states:

Copyright 2017 Dell Inc.. Data Domain System Administration 16

Copyright 2017 Dell Inc.. Data Domain System Administration 17

Copyright 2017 Dell Inc.. Data Domain System Administration 18

Copyright 2017 Dell Inc.. Data Domain System Administration 19

Copyright 2017 Dell Inc.. Data Domain System Administration 20

Copyright 2017 Dell Inc.. Data Domain System Administration 21

Copyright 2017 Dell Inc.. Data Domain System Administration 22

Copyright 2017 Dell Inc.. Data Domain System Administration 23

Copyright 2017 Dell Inc.. Data Domain System Administration 24

Revision Date: January 2017

Revision Number: MR-1WP-DDEXRET

Copyright 2016 Dell Inc. Data Domain Extended Retention 1

Copyright 2016 Dell Inc. Data Domain Extended Retention 2

Copyright 2016 Dell Inc. Data Domain Extended Retention 3

Copyright 2016 Dell Inc. Data Domain Extended Retention 4

Copyright 2016 Dell Inc. Data Domain Extended Retention 5

Copyright 2016 Dell Inc. Data Domain Extended Retention 6

Copyright 2016 Dell Inc. Data Domain Extended Retention 7

Copyright 2016 Dell Inc. Data Domain Extended Retention 8

Copyright 2016 Dell Inc. Data Domain Extended Retention 9

Copyright 2016 Dell Inc. Data Domain Extended Retention 10

Copyright 2016 Dell Inc. Data Domain Extended Retention 11

At this point, one of three things can happen:

Copyright 2016 Dell Inc. Data Domain Extended Retention 12

Copyright 2016 Dell Inc. Data Domain Extended Retention 13

Copyright 2016 Dell Inc. Data Domain Extended Retention 14

Copyright 2016 Dell Inc. Data Domain Extended Retention 15

Copyright 2016 Dell Inc. Data Domain Extended Retention 16

Copyright 2016 Dell Inc. Data Domain Extended Retention 17

Note: Sanitization is not supported for DD Extended Retention-enabled DD systems.

Copyright 2016 Dell Inc. Data Domain Extended Retention 18

Copyright 2016 Dell Inc. Data Domain Extended Retention 19

Copyright 2016 Dell Inc. Data Domain Extended Retention 20

Copyright 2016 Dell Inc. Data Domain Extended Retention 21

Copyright 2016 Dell Inc. Data Domain Extended Retention 22

Copyright 2016 Dell Inc. Data Domain Extended Retention 23