Avamar Overview SRG
Avamar Overview SRG
Avamar Overview SRG
Copyright 1996, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 EMC Corporation. All Rights Reserved.
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF
ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
EMC2, EMC, Data Domain, RSA, EMC Centera, EMC ControlCenter, EMC LifeLine, EMC OnCourse, EMC Proven, EMC Snap, EMC SourceOne,
EMC Storage Administrator, Acartus, Access Logix, AdvantEdge, AlphaStor, ApplicationXtender, ArchiveXtender, Atmos, Authentica,
Authentic Problems, Automated Resource Manager, AutoStart, AutoSwap, AVALONidm, Avamar, Captiva, Catalog Solution, C-Clip, Celerra,
Celerra Replicator, Centera, CenterStage, CentraStar, ClaimPack, ClaimsEditor, CLARiiON, ClientPak, Codebook Correlation Technology,
Common Information Model, Configuration Intelligence, Configuresoft, Connectrix, CopyCross, CopyPoint, Dantz, DatabaseXtender, Direct
Matrix Architecture, DiskXtender, DiskXtender 2000, Document Sciences, Documentum, elnput, E-Lab, EmailXaminer, EmailXtender,
Enginuity, eRoom, Event Explorer, FarPoint, FirstPass, FLARE, FormWare, Geosynchrony, Global File Virtualization, Graphic Visualization,
Greenplum, HighRoad, HomeBase, InfoMover, Infoscape, Infra, InputAccel, InputAccel Express, Invista, Ionix, ISIS, Max Retriever,
MediaStor, MirrorView, Navisphere, NetWorker, nLayers, OnAlert, OpenScale, PixTools, Powerlink, PowerPath, PowerSnap, QuickScan,
Rainfinity, RepliCare, RepliStor, ResourcePak, Retrospect, RSA, the RSA logo, SafeLine, SAN Advisor, SAN Copy, SAN Manager, Smarts,
SnapImage, SnapSure, SnapView, SRDF, StorageScope, SupportMate, SymmAPI, SymmEnabler, Symmetrix, Symmetrix DMX, Symmetrix
VMAX, TimeFinder, UltraFlex, UltraPoint, UltraScale, Unisphere, VMAX, Vblock, Viewlets, Virtual Matrix, Virtual Matrix Architecture, Virtual
Provisioning, VisualSAN, VisualSRM, Voyence, VPLEX, VSAM-Assist, WebXtender, xPression, xPresso, YottaYotta, the EMC logo, and where
information lives, are registered trademarks or trademarks of EMC Corporation in the United States and other countries.
All other trademarks used herein are the property of their respective owners.
Copyright 2012 EMC Corporation. All rights reserved. Published in the USA.
Module 1 provides an introduction to the functions and features of the Avamar backup
solution. The objectives for this module are shown here. Please take a moment to read
them.
EMC Avamar is a comprehensive, client-server network backup and restore solution. With its
unique global data deduplication technology, Avamar addresses the data protection
challenges in todays IT environments.
The ever-increasing amount of data to backup presents a challenge to organizations facing
the demands of shorter backup windows, quicker restore responses, consistent backups of
remote sites, and regulatory requirements; all with the need to accomplish this with fewer
staff and tighter budgets.
Avamar meets these challenges by re-designing backup and restore as true disk-based
processes. Avamars patented global deduplication technology reduces the amount of
backup data by identifying unique data at the source. Avamar stores only one copy of this
common data across the backup network. This results in a dramatic reduction in the amount
of data that is moved across the network and stored in backup storage. The same data is
backed up as in traditional backup systems, but consumes significantly less network and
backup resources as only unique data is stored. And, by using standard IP network
technologies, dedicated backup networks are not required.
Avamar employs a scalable disk-based, server architecture built of modules that provide a
balance of connectivity, security, processing, and disk storage resources. Scheduled backup
and replication functionality enable efficient backup of remote sites and provide disaster
recovery of primary backup sites. Avamar provides a user-friendly interface for central
management of the entire backup system.
A high percentage of data that is retained on backup media by most backup solutions is
highly redundant. The typical backup process for most organizations consists of a series of
daily incremental backups and weekly full backups.
Daily backups are usually retained for a few weeks and weekly full backups are retained for
several months to several years. Because of this process, multiple copies of identical or
slowly-changing data are retained on backup media, leading to a high level of data
redundancy.
In an enterprise, a large number of operating systems, application files, and data files are
common across multiple systems. Identical files such as Word documents, PowerPoint
presentations, and Excel spreadsheets are stored by many users across an environment.
Backups of these systems will contain a large number of identical files.
Additionally, many users keep multiple versions of files that they are currently working on.
Many of these files differ only slightly from other versions, but are seen by backup
applications as new data that must be protected.
Backing up redundant data increases the amount of backup storage needed and can
negatively impact network bandwidth. Due to the need to manage backup versions and a
myriad of backup tapes, organizations are running out of backup window time and facing
difficulties meeting recovery objectives
Avamar differs from traditional backup and restore solutions by identifying and storing only
unique, sub-file data objects. Redundant data is identified at the source, drastically reducing
the amount of backup data that travels across the network to be stored and managed by the
backup host. When storing data objects, Avamar takes maximum advantage of inherent
hard-disk characteristics. Avamar also creates and stores trees that link all data objects
from a single backup. These trees are used to re-create files for restore.
There are several Avamar terms that will be used throughout the course:
Object: a single instance of deduplicated data. Objects are stored and managed within
stripes on the Avamar server.
Stripe: a unit of disk drive space managed by Avamar
Node: a self-contained, rack-mountable, network-addressable computer consisting of both
processing power and hard drive storage. Nodes run Avamar server software on the Linux
operating system. Hard disk storage may be internal to the node or implemented using an
external SAN array.
Server: a group of one or more nodes on a local, high-speed network
System: one or more Avamar servers and the network servers or desktop clients that back up
data to those servers
An Avamar backup is defined as a point-in-time copy of client data that can be restored as
individual files, selected directories, or entire file systems.
Initialization is the process of running a first backup from a client.
Restore is an operation that retrieves one or more file systems, directories, or files from an
existing backup and writes it to a designated location.
Encryption provides enhanced security during client/server data transfers and on the Avamar
server. As part of server installation, an Avamar server can be configured to encrypt all
backup data stored on the server. For Avamar client/server communication, Avamar supports
two levels of encryption: Medium and High. The administrator can also choose to turn off
client/server encryption entirely. The exact method and bit strength used in a given
circumstance depends on several factors, including client OS and Avamar server and client
versions. Please refer to the Avamar Product Security Manual for additional details.
Retention determines the length of time that a backup is available for restore. Avamar allows
you to specify how long a backup is retained; unused chunks from backups that have expired
are deleted from the system.
Replication is the process of storing a logical copy of Avamar server data on another Avamar
server to support future disaster recovery of the source server.
The three major components of an Avamar system are the Avamar server, Avamar backup
clients, and the Avamar Administrator.
The Avamar Server stores client backups and provides essential processes and services
required for client access and remote system administration. Avamar Administrator Server
(mcs) and Avamar Data Server (gsan) run on the Avamar server.
Avamar Client software runs on each computer or network server that is being backed up.
Avamar provides client software for various computing platforms. Each client consists of a
client agent and one or more plug-ins.
Avamar Administrator is a user management console software application that is used to
remotely administer an Avamar system from a supported Windows or client computer.
To ensure system integrity, Avamar provides systematic fault tolerance at the following
levels:
RAID (redundant array of independent disks) is a method of protection for disk data
corruption. RAID is a balance between performance and efficiency. Avamar servers are
protected by either RAID-1 or RAID-5, depending on the configuration. Avamar also has hotswap capability with minimum system impact for highest failure-rate components (more
than 90% of expected failures).
RAIN (redundant array of independent nodes) provides failover and fault tolerance across
nodes. RAIN provides uninterrupted functionality during node failure, replacement, and
reconstruction. In the unlikely event of a node failure, the backup data will be stored on the
remaining nodes and data for recoveries is reconstructed using parity. RAIN is used to replace
the failed node, reconstruct the data on the replacement node, and when expanding an
Avamar server, rebalance the capacity across all nodes.
Replication protects against data loss in the event of a server loss. Efficient, scheduled
replication (local or remote) ensures availability and redundancy of data if the primary server
is lost.
Checkpoints protect the server in the event of operational failures. They provide redundancy
across time. Checkpoints are a read-only snapshot of the Avamar server taken to facilitate
server rollbacks. They are created using hard-links to all the stripes. Regular checkpoint
validation, including auto-repair capability, is used to ensure data integrity.
High Availability Uplink and Dual Switches provide high availability in the event of hardware
failure.
Beginning with Avamar release 6.1, the Avamar server runs on SUSE Linux Enterprise Server
(SLES). RHEL was used in previous versions and is still supported for upgrades. The Avamar
server is capable of operating on server hardware with multiple processors.
Beginning with Avamar generation 4 hardware, four sizes of storage nodes are supported:
1.3 TB, 2.6 TB, 3.9 TB, and 7.8 TB of licensable capacity. Licensable capacity includes
deduplicated data plus RAIN parity protection. All storage nodes within an Avamar server
must be of the same size.
The two Avamar server editions provide the flexibility to meet different customer
requirements.
Avamar Data Store simplifies the purchase and deployment of Avamar by delivering a prepackaged solution consisting of Avamar server software installed onsite on pre-configured
and pre-tested Avamar-certified hardware. Deployment time at customer sites is reduced
since hardware stress tests and initial benchmark tests are performed before the hardware is
shipped. Avamar Data Store is available in several configurations as listed in the slide,
including multi-node and single-node servers and single expansion nodes. Avamar Data Store
is deployed by EMC-trained personnel.
The EMC Avamar Virtual Edition (AVE) allows the Avamar solution to be standardized on
VMware infrastructure. It is ideal for small, remote offices or small data centers, by lowering
the total cost of ownership through sharing the server and storage infrastructure and
reducing the cost of hardware support and maintenance.
AVE is a single-node non-RAIN Avamar server running as a virtual machine on a VMware ESX
Server. The licensed capacity sizes include: 0.5 TB, 1.0 TB, and 2.0 TB. Each of these capacity
versions has a set of requirements for memory, I/O, and storage. The choice of AVE version
to be deployed depends on the type of data in the environment to be backed up and the
expected daily change rate.
The VMware ESX Server is supplied by the customer. Installation of AVE on a virtual machine
is performed by EMC-trained personnel. The AVE benchmark test must be run to ensure that
server hardware and the virtual environment meet expected I/O performance benchmarks.
Also, the benchmark test helps to determine the impact of AVE on other virtual machines
running on the same physical server. AVE runs on Red Hat Enterprise Linux in contrast to the
physical Avamar server.
Note: For more information about Avamar Virtual Edition, including the currently supported
ESX server versions, please refer to the EMC Avamar Virtual Edition System Installation
Manual, available on EMC Powerlink. Training for AVE includes the eLearning course entitled
EMC Avamar Virtual Edition Overview.
Because Avamar architecture is extremely flexible and scalable, Avamar is an ideal solution
for distributed enterprises. Corporate backup policies can be implemented, enforced, and
managed throughout the organization from a central location. Avamar supports both local
area network and wide area network connections. There is minimal impact to network traffic
and performance as after initialization only changes travel over the networks.
You can backup both local and remote clients to a centralized Avamar server. As a centralized
backup system, Avamar protects critical branch data without the addition of hardware or
specially trained personnel at branch office sites.
For sites where recovery time objective requirements must be satisfied, a local Avamar
system may be employed to backup local data at the site and automatically replicate the
backup data to the central data center or disaster recovery site. Additionally, the central
Avamar server can be replicated to an offsite location for disaster recovery. All backup and
replication activity is managed from the central data center using the Avamar Enterprise
Manager and Administrator interfaces. Employing Avamar disk-based backup eliminates the
need to manage a complex tape system for backups, restores, and offsite security.
Avamar administration tools provide central administrative access to the Avamar system.
The Avamar Administrator is a graphical user interface (GUI) used to configure, monitor, and
manage an Avamar system from one or more Windows or Linux clients.
Avamar uses a PostgreSQL database to store various kinds of data, such as backup and
restore activities, events, defined groups and clients. This information is available for
reporting using third-party reporting tools such as Crystal Reports, MS Query, and Microsoft
Excel.
The Avamar Administrator Command Line Interface (CLI) is a Java application providing
command line access to the features and functions that are available via the GUI.
Client Manager is a graphical interface used to activate, manage, and analyze backup clients.
It is especially useful when dealing with a large number of clients.
The Avamar Enterprise Manager provides centralized access to the Avamar Administrator for
each Avamar system in an enterprise, as well as dashboard, reporting, and search
capabilities. With Enterprise Manager, backup administrators can monitor and manage all
Avamar servers in a distributed environment.
Deduplication is a key feature of the Avamar system. Deduplication ensures that each unique
object is stored only once in the Avamar storage system. Redundant backup data is
eliminated at the client, (or the source), and then drastically reduces the amount of data that
travels across the network to be stored and managed by the Avamar backup server. As long
as a data object is stored on the server, it is never re-sent to the server. This dramatically
reduces network traffic and enhances backup storage efficiency, guaranteeing the most
effective deduplication of the data.
Typically, deduplication commonality yields the following results:
The slide depicts a high level logical process and data flow of an Avamar backup. During a
scheduled backup or restore, the Avamar server generates a work order. The server then
either pages the client agent or the client agent checks in with the server to pick up the work
order.
1. On the client, the Avamar agent traverses each directory in the backup. For each file,
the agent checks the local file cache to see if the file has been backed up before.
2.
If there is no match in the file cache, the file is divided into variable-sized data objects
or chunks. The chunks are compressed and hashed. The hashes are used to quickly
determine if the chunks have previously been stored. The client compares each hash
with the entries in the local hash cache to see if the chunk has been stored before.
3.
If there is no match in the local hash cache, the client asks the Avamar Server if the
hash is present on the server due to its corresponding chunk having been stored
previously by a different client.
4.
If there is no match on the Avamar server, the hash and the corresponding data are
transferred to the Avamar server and stored. The client cache files are updated
accordingly.
This process is repeated for the rest of the files included in the backup.
Hashes are used to store and find data objects. Three types of hashes are created during a
backup: atomic, composite, and root. The hash created directly from a data chunk is referred
to as an atomic hash. Atomic hashes are combined into composites and hashed to create
composite hashes. All the composite hashes are combined and hashed once more to create
a single root hash for the backup.
When data is sent to the Avamar Server during a backup, data object storage is used to
manage the objects on the server. Both the chunk that has gone through the compression
process and its corresponding hash are stored. Part of the number of the hash is used as an
address to identify the location where the corresponding data chunk is stored on backup disk
storage. Because each hash is a random and unique number, data is automatically evenly
distributed across all available storage nodes and disks within an Avamar system. This type of
address is called an object address. It eliminates the need for a separate file level catalog.
Once an object has been stored, it cannot be deleted until the specified retention period has
expired and it is not used by any current backup. Storing data on disk, rather than on tape,
streamlines the process of searching for stored objects.
Data is stored using a complex hierarchical hashing file system with an indexing structure
consisting of the data elements grouped together by multiple levels of hashes, composites,
and root hashes. The root hash of each backup links to the data objects and hashes
comprising the backup at the point-in-time when the backup occurred.
Data objects are stored on Avamar disk storage in special files called data stripes. A single
data stripe can hold approximately 8,000 to 10,000 data objects. For new Avamar systems,
stripes hold approximately 30,000 objects.
Composite hashes are stored in separate stripes. Root hashes, as well as information about
the origin of the files (client, domain, etc.), are stored in the accounts stripes. On a RAIN
system, an additional stripe file contains RAIN parity data. This data is used to reconstruct
data for a failed node. These additional stripe files account for the RAIN overhead.
Avamar is ideally suited for protecting clients in virtual environments by reducing the amount
of backup data within and across the virtual machines. Both VMware and Hyper-V are
supported. Avamar 5.0 and above provides a high level of integration with VMware for
backing up virtual environments. Avamar provides the flexibility of implementing a virtual
machine backup solution in two ways. Avamar agents can be installed in the virtual machines
for guest level backups. Image level backups are also available to create a backup of the
virtual disk files.
VMware backups can be centrally configured, scheduled, and managed with Avamar
Administrator. Avamar Administrator also has the ability to browse the virtual machines in
the environment and display information for each machine as shown on the slide.
Data Domain systems can be used as storage for Avamar backup data. Backup data is sent
directly from the client to the Data Domain system using DDBoost technology. Backups can
then be managed through the Avamar system. This can provide faster backup and recovery,
especially for large active databases. Data Domain integration is supported for DB2,
Microsoft Exchange VSS, Hyper-V VSS, Microsoft SQL Server, Microsoft SharePoint VSS,
Oracle, SAP with Oracle, Sybase, and VMware image backup and restore.
Maintenance activities that are performed on the Avamar server are also performed on any
data stored on the Data Domain. This means that a backup that has expired or been deleted
on the Avamar server, will be deleted from the Data Domain. Avamar garbage collection,
checkpoints, rollbacks, and HFS checks and replication trigger similar processes on the Data
Domain system. More information on these maintenance activities are discussed later in this
course.
Resources related to Avamar include the guides, release notes, and training courses listed on
the slide. For a complete set of product information and documentation for Avamar, as well
as client and Administrator Console software, go to the Avamar secure web server at:
http://youravamarname.domain.com
Avamar documentation is also available via the EMC Powerlink web site at:
http://powerlink.emc.com
You can register for EMC Education Services training courses via the EMC Powerlink web site
as well.
These are the key points covered in this module. Please take a moment to review them.
In Module 2, you will learn how to perform backups and restores using Avamar interfaces.
The objectives for this module are shown here. Please take a moment to read them.
Avamar backup clients are the machines that contain the data to be backed up to the
Avamar server. They are networked computers or workstations accessing the Avamar server
via a network connection. Avamar clients are usually the file servers and database servers in
an IT environment.
Avamar Client software is installed and running on each client. Avamar provides client
software for various computing platforms.
For backing up databases, the Avamar client and a specialized database plug-in are installed
and run on the same machine. Databases supported with Avamar client software include:
Microsoft Exchange, Lotus Domino, Microsoft SQL, SharePoint, DB2, and Oracle.
System State can also be backed with Avamar using a specialized module that is utilized by
the backup client. This captures system settings, software installations, registry, networking
information and shares, and more. The backup of the system state can save time if a bare
metal recovery needs to be performed.
Domains are distinct zones within Avamar that are used to organize and manage backup
clients. They are used to manage administration access to groups of clients. By nesting
domains within domains to create a tree structure, you can create a hierarchy for managing
organizations and the clients in those organizations. The highest level domain is the root
domain, represented by the Avamar server in the hierarchy. When an Avamar client is added
to the Avamar server, it is assigned to a specific domain within the domain hierarchy. The
real power of domains is that they provide the ability to add specific users to specific levels
on the client tree.
Security within the Avamar system is implemented through the use of user accounts. Users
can be created at the root, domain, and client levels in the domain hierarchy. The level at
which a user account is added to the Avamar system, and the role assigned to the user,
determine the access and privileges accorded to that user. Actions performed by users are
tracked and maintained in an audit log. The slide lists the roles that can be assigned to users
at the following levels in the domain hierarchy.
Root users are created at the root domain. Root users can perform tasks for all domains in
the hierarchy and the clients within the domains.
Domain users are created at the Avamar domain level. Users at the domain level can
perform tasks for that domain, the clients assigned to the domain, and any domain/client
beneath the domain in the domain hierarchy.
Client users are created for an individual Avamar client. The tasks that a client user can
perform are limited to that specific client.
Avamar uses groups to implement various policies for automating backups and enforcing
consistent rules across a collection of clients. Backups are scheduled to run automatically by
configuring and enabling groups. A group consists of one or more clients that will be backed
up, and a group policy that is used to configure settings for the backup. The group policy
specifies a dataset, schedule, and retention for that group. Once a group is configured, the
Avamar server will automatically perform backups of the clients within the group according
to the schedule that was set for the group. The dataset settings for the group determine the
data from each client that is backed up, and the retention settings determine how long each
backup from the group is retained.
Avamar groups should not be confused with Avamar domains. Groups are used to create
automated backups for a set of clients, while domains are used to grant Avamar
administration rights to a set of clients and to organize and manage sets of clients.
Clients inherit the group policy settings by means of their membership in a specific group. An
Avamar user with Administrator privileges can configure persistent backup selections by
creating, modifying, and deleting datasets, schedules, and retention policies and assigning
them to a new or existing group and then assigning clients to the group.
Datasets define the persistent backup selections for the file systems, directories, or files to
be included in a backup. You can also narrow the scope by specifying certain content, such as
file types, to exclude or include. Datasets can be created at any domain level and can be
assigned to one or more groups and clients within the assigned domain.
The Schedule for a group determines when and how often a backup will automatically be
run. Schedules can be created at any domain level and can be assigned to one or more
groups within the assigned domain.
Retention Policies specify how long each backup from the group will be kept. Any backups
older than the specified retention are automatically dropped from the system. Retention
policies can be created at any domain level and can be assigned to one or more groups and
clients within the assigned domain.
On-demand backups by definition are run manually at the time that the backup request is
initiated. Avamar provides multiple ways for running on-demand backups from either the
client or server side. An administrator can run an on-demand backup using the mccli
command line, run a group backup from Avamar Administrators Policy view, or select items
to backup from Avamar Administrators Backup and Restore view, as shown on the slide. An
on-demand backup can also be initiated from the client side using the avtar CLI command.
You can manage backups from the Avamar Administrator Backup Management view. You can
list the backups run for a particular client by first selecting the client in the tree and then
choosing to list by date, date range, or retention type.
Options available from the Actions menu include changing the backup expiration date,
changing the retention tag, deleting a backup, viewing completed backup statistics, and
validating a backup. Validating a backup initiates a virtual restore of all files in the backup
but does not actually restore any files to the client file system. Deleting a backup
permanently deletes the backup from the system.
Note: that data referred to by other backups will not be candidates for deletion.
Avamar supports restoring one or more individual files, directories, or file systems from
backups stored on the Avamar server. There are two methods of initiating restores of client
data: from the Avamar server or from the client. Restores can be initiated from the Avamar
server using Avamar Administrator Backup and Restore or the mccli interface. Initiating
the restore from the Avamar client is accomplished by the Desktop/Laptop interface or the
avtar command.
Using the Avamar Administrator Backup and Restore view, the items to restore for a specific
client can be selected either from a list of all backups for a particular date or of all backups
containing a particular path. Restores can be performed using the Avamar Administrator by a
user with Administrator privileges. Restores can be directed to the original client, or
redirected to a different client.
If Desktop/Laptop is installed on the client machine, end-users can restore their own data.
Using the Desktop/Laptop GUI, users can search or browse for the desired files and initiate a
restore. Restores can only be performed to the client where the data originated; redirected
restores are not supported with Desktop/Laptop. This user initiated restore is quicker and
easier because no calls to IT need to be made. Unlike Avamars Web Restore, no additional
passwords are needed. Desktop/Laptop uses LDAP or Active Directory Authentication to
ensure that the user is authorized to access their data.
Avamar provides several ways to monitor backup activity while backups are in progress and
to report on backup status.
The Avamar Administrator Activity view provides a central facility to monitor backup and
restore progress and status. With the Activity Monitor, you can see a listing of all activity for
the last 72 hours, up to a maximum of 5,000 rows. You can also bring up activity logs and
cancel an activity in progress. Options from the Actions menu include filtering the activity
results display and viewing statistics for a selected activity.
Status information is also available on a Windows client with the Avamar Progress bar and
Work Order Status.
These are the key points covered in this module. Please take a moment to review them.
In Module 3, you will learn about the Avamar replication process, and Avamar maintenance
and monitoring activities.
The objectives for this module are shown here. Please take a moment to read them.
Avamar Replication is the process of logically copying backup data from one or more source
Avamar servers to a destination or target Avamar server. Replication always transmits data.
Data is pushed from the Avamar server executing the replicate command (source) to the
target server. As with the backup process, Avamar employs deduplication methodology at
the source Avamar server, transferring unique data only to the target server and encrypting
the data during transmission.
Replication can be configured and run with the Enterprise Manager, Avamar Administrator,
and the replicate utility interfaces. Replication is most often run on a scheduled basis,
but can also be run on-demand.
For a quick, system-wide monitoring of multiple Avamar servers, Avamar provides the
Enterprise Manager Dashboard and Server features. The Enterprise Manager is accessible
through any web browser and provides an overview of multiple Avamar servers and
centralized access to Avamar system administration for each Avamar server in an enterprise.
Information that is shown, includes server capacity, capacity forecasts, errors, backup
statistics, and reports. Each Avamar server can be selected to retrieve more detailed
information. A link to launch Avamar Administrator for each server is also included. The
Enterprise Manager Policy view lists policy information for each Avamar server being
monitored. Using the Enterprise Manager Reports view, you can run many preconfigured
reports, including reports of actual and forecasted server capacity utilization.
Further monitoring can be done from Avamar Administrator as shown in the following slides.
Client Manager is a graphical user interface accessible from a link in Enterprise Manager
which provides many functions for managing large amounts of clients. It provides the ability
to move multiple clients between domains or servers, to retire or delete multiple clients, and
to change backup groups of clients. The Client Manager is especially useful in large
environments as clients can be found easily through the use of search filters. Client Manager
can also be used to update client software and analyze backup statistics. Activation of
multiple clients can be achieved through this interface. Clients can be discovered through the
use of a directory service such as Active Directory and then activated.
Avamar activities and operational status are reported as events to the administrator server.
Examples of events include client registration and activation, and backup completion and
restore activity. The Avamar Administrator Event Monitor displays the most recent 5,000
system events during the past 24 hours. The listing can be filtered by event code, category,
type, severity, and domain. The report can be exported to a CSV file.
The Avamar Administrator Server view is a primary system status monitoring tool. With the
functions within the Server view, you can suspend or resume server activity, check server
capacity, review the health of nodes and disks, and manage checkpoints and hash file system
checks. The Server Monitor presents a summarized view of CPU, network and hard drive
performance statistics for each node.
Daily Avamar server maintenance activities include checkpoints, checkpoint validation, and
garbage collection. These server maintenance activities are run automatically.
A checkpoint is a read-only snapshot of the Avamar server taken to enable server rollbacks.
Checkpoints are created using hard-links to all the stripes.
A hash file system (HFS) check is an operation that validates the integrity of a checkpoint.
Once a checkpoint has passed an HFS check, it can be considered reliable enough to be used
for a system rollback.
Checkpoints are taken twice daily and validated once daily during the maintenance window.
Avamar administrators can also create and validate checkpoints at any time, as well as delete
checkpoints that are not needed in order to reclaim additional server storage capacity.
Garbage collection is the process of deleting unused chunks from backups that have expired.
Garbage collection requires a quiet system in order to run. While garbage collection is
running, the system is placed in a read-only condition. Garbage collection is run once a day
during the blackout window.
Avamar uses three operational windows to perform various system activities. These windows
can be customized to start and end at times to meet site requirements.
The backup window is when the majority of backups are performed. Backups should be
scheduled to run during this time. No maintenance activities, such as garbage collection or
HFS checks, are performed by the Avamar server during the backup window.
During the blackout window backups cannot be performed. This window of time is reserved
for maintenance activities such as garbage collection and checkpoint creation. By default, the
blackout window runs in the morning from 8 a.m. to 11 a.m.
The maintenance window is reserved for other maintenance activities, primarily the HFS
check. Backups may be initiated, but both backup time and maintenance activities will be
impacted. By default, the maintenance window runs during the day from 11a.m. to 8 p.m.
Restores can be performed during any of these windows.
New bytes are added to the Avamar server through the backup process. Old bytes are
removed from the server through garbage collection of unused chunks from expired or
deleted backups. The goal of managing the capacity of the Avamar server, is to achieve a
steady-state server capacity utilization where the rate that new data chunks are added to
the server is equal to or less than the rate that expired data chunks are removed from the
server.
Factors affecting capacity utilization include the amount of primary storage being protected,
the initial and day-over-day backup commonality, and the length of time backups are
retained.
Capacity management is an important task for the Avamar administrator to ensure that the
Avamar system continues to have the capacity to store the required backup information.
Avamar provides many tools and reports to assist the administrator with this task.
For daily monitoring, Avamar Administrator Server Management, shown on the slide,
provides detailed server management information, including server and node utilization
percentages. Avamar automatically issues warnings when server utilization exceeds 80% of
user capacity and, at 100%, will go into read-only mode. EMC Technical Support is available
to work with the administrator on all capacity management issues.
Avamar maintains logs of client and server activities. Logs are especially useful for
investigating issues and troubleshooting error conditions. The slide shows an excerpt from a
client log detailing an on-demand backup operation.
Many standard reports are available with the Avamar Administrator Activity Report and
Manage All Reports features. Shown here is an example of one of the activity reports. You
can also create reports using the read-only views of the Avamar Administrator server
database.
Backend Capacity Reports can be generated to show how much capacity is used by a client or
a group of clients after deduplication.
These are the key points covered in this module. Please take a moment to review them.
These are the key points covered in this training. Please take a moment to review them.
This concludes the training.