EMC AVAMAR - Dell EMC Isilon · Typeface Conventions The following table provides examples of standard typeface styles used in this publication to convey various kinds of information

OPERATIONAL BEST PRACTICESP/N 300-007-035

REV A01

EMC CORPORATION

COPORATE HEADQUARTERS:HOPKINTON, MA 01748-9103

1-508-435-1000WWW.EMC.COM

EMC AVAMAR4.1

Copyright and Trademark Notices

This document contains information proprietary to EMC. Due to continuing product development, product specifications and capabilities are subject to change without notice. You may not disclose or use any proprietary information or reproduce or transmit any part of this document in any form or by any means, electronic or mechanical, for any purpose, without written permission from EMC.

EMC has made every effort to keep the information in this document current and accurate as of the date of publication or revision. However, EMC does not guarantee or imply that this document is error free or accurate with regard to any particular specification. In no event will EMC be liable for direct, indirect, incidental or consequential damages resulting from any defect in the documentation, even if advised of the possibility of such damages. No EMC agent or employee is authorized to make any modification, extension or addition to the above statements.

EMC may have patents, patent applications, trademarks, copyrights or other intellectual property rights covering subject matter in this document. The furnishing of this document does not provide any license to these patents, trademarks, copyrights or other intellectual property.

The Avamar Agent for Microsoft Windows incorporates Open Transaction Manager (OTM), a product of Columbia Data Products, Inc. (CDP). CDP assumes no liability for any claim that may arise regarding this incorporation. In addition, EMC disclaims all warranties, both express and implied, arising from the use of Open Transaction Manager. Copyright 1999-2002 Columbia Data Products, Inc. Altamonte Springs. All rights reserved.

Avamar, RAIN and AvaSphere are trademarks or registered trademarks of EMC in the US and/or other countries.

All other product names and/or slogans mentioned herein may be trademarks or registered trademarks of their respective companies. All information presented here is subject to change and intended for general information.

Copyright 2002-2008 EMC. All rights reserved.

Protected by US Patents No. 6,704,730, 6,810,398 and patents pending.

Printed in the USA.

TABLE OF CONTENTS
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Scope and Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Product Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Typeface Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Notes, Tips and Warnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Guide Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Lifecycle Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Best Practices Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Avamar Server Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Assumptions and References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Top 10 Operational Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Architecting Avamar to Maximize System Availability . . . . . . . . . . . . . .11Avamar Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Stripes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Avamar Data Server Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

RAID, RAIN, Replication and Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Backing Up Clients in Remote Offices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Managing Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19Impact of Storage Capacity on System Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Definitions of Avamar Server Capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Avamar Capacity Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Impact of Capacity on Various Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Proactive Step to Manage the Health of the Avamar Server . . . . . . . . . . . . . . . . . . 21Other Proactive Steps to Manage Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Reactive Steps to Recovering from Capacity Issues . . . . . . . . . . . . . . . . . . . . . . . . 22Steady State System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Using capacity.sh to Assess System Steady State Behavior . . . . . . . . . . . . . . . . . . 23

Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25Avamar Client Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Restrictions and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Scheduling Activities During the Course of a Day. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Using sched.sh to Quickly Assess Daily Schedules . . . . . . . . . . . . . . . . . . . . . . . . . 29

AVAMAR 4.0 • OPERATIONAL BEST PRACTICES 3

TABLE OF CONTENTS

Defining Domains, Groups and Policies . . . . . . . . . . . . . . . . . . . . . . . . . 31Defining Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Defining Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Defining Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Defining Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Defining Retention Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Daily Monitoring of Backup Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . 34Monitoring the Avamar System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Daily Monitoring of Backup Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 36Monitoring the Avamar System Backup Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Closely Monitor Daily Backup Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Closely Monitor Nightly Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Tuning Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Tuning Client Caches to Optimize Backup Performance . . . . . . . . . . . . . . . . . . . . . . . . . 40

Client Caches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Overview of Cache Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41File Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Hash Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Impact of Caches on Memory Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Cache Information in the avtar Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Changing the Maximum Cache Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Tuning the Maximum Cache Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Rules for Tuning the Maximum Cache Sizes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Beware If More Than 4 GB of RAM Is Necessary . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Tuning the File Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Tuning the Hash Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Using cacheprefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Customizing Maximum Hash Cache Settings for Exchange and SQL Server. . . . . . 49Tuning Replicator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Understanding dpnsummary Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Performing a Healthcheck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Other Avamar Administration Best Practices . . . . . . . . . . . . . . . . . . . . . 58Protecting Your Avamar Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Changing Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Enabling the Email Home Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Assigning Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60


FOREWORD

Scope and Intended AudienceScope. This publication describes operational best practices for both single-node and multi-node servers in small and large heterogeneous client environments.

Intended Audience. The intended audience of this document are people with Unix, Linux and Windows system administration experience who will deploy and operate Avamar servers.

Product InformationFor current documentation, release notes, software updates, as well as information about EMC products, licensing and service, go to the EMC Powerlink web site at powerlink.emc.com.

Typeface ConventionsThe following table provides examples of standard typeface styles used in this publication to convey various kinds of information.

EXAMPLE DESCRIPTION

Click OK. - or -Choose File > Close.

Bold text denotes actual Graphical User Interface (GUI) buttons, commands, menus and options (any GUI element that initiates action).Also note in the second example that sequential commands are separated by a greater-than (>) character. In this example, you are being instructed to choose the Close command from the File menu.


FOREWORD

Notes, Tips and WarningsThe following kinds of notes, tips and warnings appear in this publication:

IMPORTANT: This is a warning. Warnings always containinformation that if not heeded could result in unpredictablesystem behavior or loss of data.

TIP: This is a tip. Tips present optional information intendedto improve your productivity or otherwise enhance yourexperience with our product. Tips never contain informationthat will cause a failure if ignored.

NOTE: This is a general note. Notes contain ancillary infor-mation intended to clarify a topic or procedure. Notes nevercontain information that will cause a failure if ignored.

Enter: cd /temp

Bold fixed-width text denotes shell commands that must be entered exactly as they appear in this publication.

--logfile=FILE All caps text often denotes a placeholder (token) for an actual value that must be supplied by the user. In this example, FILE would be an actual filename.

Installation Complete. Regular (not bold) fixed-width text denotes command shell messages. It is also used to list code and file contents.

EXAMPLE DESCRIPTION


OVERVIEWThis chapter provides an overview of the various operational best practices that apply to all Avamar® servers (single-node and multi-node).

Guide OrganizationThis best practices guide is organized as follows:

SUBJECT MATTER CHAPTERS

Core Avamar system functions

Architecting Avamar to Maximize System Availability (page 11)Managing Capacity (page 19)Scheduling (page 25)Defining Domains, Groups and Policies (page 31)Daily Monitoring of Backup Infrastructure (page 34)Daily Monitoring of Backup Operations (page 36)

Tuning the Avamar system

Tuning Performance (page 39)Understanding dpnsummary Reports (page 50)Performing a Healthcheck (page 57)

Other Avamar Administration functions

Other Avamar Administration Best Practices (page 58)


Avamar Server DeploymentOVERVIEW

Lifecycle IndicatorsThe introduction to each chapter indicates which of the following Avamar server lifecycle phases it covers.

Planning and design. Topology and architecture options, risks and limitations and any other planning and design issues that you must consider prior to implementing the design.

Implementation. Installation options and directions for testing Avamar components after installation is complete.

Daily operations. Regular management of Avamar server capacity, performance optimization of backups and replication, and daily monitoring of the Avamar infrastructure and operations.

Quarterly operations. Performing a healthcheck, and using and understanding a dpnsummary report.

Best Practices IndicatorsThroughout the guide, the following icons identify recommended and not recommended practices:

Practice recommended

Practice not recommended

Avamar Server Deployment When applying these best practices, remember that some practices apply to all Avamar servers, and some to only one.

Avamar servers can be deployed in the following configurations:

Physical. Single-node and multi-node servers on the following platforms:

• Customer-acquired computers • Avamar Data Store computers


Assumptions and ReferencesOVERVIEW

Assumptions and ReferencesThis guide does not attempt to provide introductory materials for basic Avamar technology or delivery methods. Refer to the following Avamar product documentation for additional information:

• Avamar Release Notes• Avamar Release Notes Addendum• Avamar System Administration Manual• Avamar Event Codes Listing• Avamar Administrator Command Line Interface Programmer’s Guide and

Reference Manual• Avamar Backup Clients Installation Guide and Reference Manual• Avamar DB2 Client Installation Guide and Reference Manual• Avamar Exchange Client Installation Guide and Reference Manual• Avamar NDMP Accelerator Installation Guide and Reference Manual• Avamar Oracle Client Installation Guide and Reference Manual• Avamar SQL Server Client Installation and Upgrade Manual• Avamar Product Security Manual• Server Software Installation Manual• Avamar Data Store Customer Service Manual• Avamar Data Store System Installation Manual• White Paper: Efficient Data Protection with EMC Avamar Global Deduplication

Software - Technology Concepts and Business Considerations• White Paper: Optimized Backup and Recovery for VMware Infrastructure with

EMC Avamar

Download the preceding manuals at http://Powerlink.EMC.com (the EMC Powerlink® website) in the following location:Support > Technical Documentation and Advisories > Software ~ A-B ~ Documentation > Avamar


Top 10 Operational Best PracticesOVERVIEW

Top 10 Operational Best PracticesThe following is a list of the most important best practices that you should understand and follow. These and others are included in the chapters that follow.

Deploy the Avamar server with reliable, high-performance RAID arrays for back-end storage.

Protect the data on the Avamar server by replicating the data to another Avamar server.

Understand how to monitor and manage the storage capacity of the Avamar server on a daily basis.

Minimize the number of groups used to back up clients, and use a single backup window that does not overlap with the daily maintenance jobs and does not exceed 8 to 10 hours per day.

Monitor the Avamar server on a daily basis and understand how to interpret all system warnings and errors.

Ensure that backups are monitored every day, and all failed backups, missing clients and backups that completed with exceptions are investigated.

Protect the Avamar server from the Internet by providing full firewall protection.

Change all factory default passwords.

Enable the email home capability.

Ensure every administrator logs in to the Avamar server with a unique user name.


ARCHITECTING AVAMAR TO MAXIMIZE SYSTEM AVAILABILITYThis planning and design chapter includes a description of Avamar architecture, planning and design details, considerations for design, recommended approaches and practices, and notes on data collection and documentation.

This chapter also includes descriptions of the following main redundancy methods for maintaining data integrity:

• RAID• RAIN• Checkpoints• Replication (including active/passive replication)

Avamar ArchitectureTo ensure the long-term reliability, availability and supportability of the Avamar server, you must design and architect it carefully.

Several processes run on the Avamar server nodes. Some of the key processes include the Avamar Administrator server and the Avamar Enterprise Manager server on the utility node and the Avamar data server (also known as the GSAN) on all active data nodes.

The Avamar data server stores, processes and manages the variable-sized chunks that the client sends during a backup operation. An average size chunk is about 10 KB depending on customer data. Through the patented deduplication technology, only unique data chunks are sent to the Avamar data server.

StripesThe term "stripe" is used throughout this document to indicate the container an Avamar data server uses to manage the data in the system. Stripes are files of various sizes based on the kind of stripe.


Avamar ArchitectureARCHITECTING AVAMAR TO MAXIMIZE SYSTEM AVAILABILITY

Each stripe has a unique name, and the Avamar server can identify and access a stripe by name only. There are four kinds of stripes:

Avamar Data Server FunctionsThe best way to characterize the Avamar data server is that it is a high-transaction-rate database-like application that is optimized to store and manage millions of variable-sized objects in parallel across all active data nodes.

The Avamar server performs several functions throughout each day. The major operational functions are the following:

Backup. The Avamar server supports the backup operation by receiving, processing and storing the backup data that Avamar clients send to it. During this process, the Avamar server interacts with the client to ensure that only unique data chunks are sent from the client to the server.

Restore. The Avamar server coordinates with the Avamar client to restore the data stored on the Avamar server to the Avamar client.

Checkpoint. The Avamar server creates two consistent point-in-time images (checkpoints) per day that it can use as rollback points to recover from various issues, such as sudden power loss.

hfscheck. The Avamar server validates one of these checkpoints every day through a process called hfscheck. Depending on how hfscheck is configured, this can be a full integrity check of the data stored on the Avamar server.

Garbage Collection. On a daily basis, the Avamar server performs a garbage collect operation, which deletes the orphaned chunks of data that are no longer referenced within any backups stored on the system. This process uses a mark and sweep operation to mark those hashes that are referenced and sweep away the unreferenced hashes (and associated data).

Replication. The Avamar server also supports daily replication of the backups.

Precrunching. Throughout the day, the Avamar server prepares stripes to be reused during backup. During this process, the server selects the emptiest stripes

STRIPE DESCRIPTION

Atomic data Contains data that originates on the customer system and is read during a backup.

Composite Contains references to other composite or atomic stripes, and provides the means to build trees that can represent arbitrarily large amounts of data. References are SHA-1 hashes.

Index Maps a hash to the stripe that contains the data corresponding to the hash. This is the essence of a “content addressed” store.

Parity Provides simple XOR parity that can be used to reconstruct data when a failure occurs. If RAIN is used, every stripe belongs to a parity group that protects it. A protected stripe is called a “safe” stripe.


RAID, RAIN, Replication and CheckpointsARCHITECTING AVAMAR TO MAXIMIZE SYSTEM AVAILABILITY

(limited to those that, percentage-wise, contain more empty space than the data partitions), and defragments them. This precrunching process leaves contiguous space for new data.

The Avamar server requires adequate CPU, memory and I/O resources to perform all these actions throughout the day. Avamar performs extensive qualification testing of all approved platforms to ensure that the resources available are adequate to meet long-term reliability, availability and supportability requirements.

RAID, RAIN, Replication and CheckpointsThe Avamar system provides up to four levels of systematic fault tolerance: RAID, RAIN, replication and checkpoints.

Redundant Array of Independent Disks (RAID). All standard Avamar server node configurations use RAID to protect the system from disk failures. RAID provides the capability to hot-swap the hard disk drives, which, across the entire population, have been the highest failure rate hardware items in Avamar servers. The Avamar server nodes are typically configured with SCSI hard drives in a RAID 5 configuration or SATA hard drives in a RAID 1 configuration.

Failed drives impact I/O performance and affect the Avamar server performance and reliability. Further, RAID rebuilds can significantly reduce the I/O performance, and so will adversely impact the performance and reliability of the Avamar server.

Operational best practices are:

Without exception, protect the data on the Avamar server by using RAID to protect against individual hard drive failures.

Set the RAID rebuild to a relatively low priority.

Set up log scanning to monitor and report hardware issues; also set up email home.

If the hardware is purchased separately by the customer, the customer must regularly monitor and address hardware issues promptly.

Redundant Array of Independent Nodes (RAIN). Except for two-node systems, RAIN protection is enabled in multi-node Avamar servers. Single-node servers do not use RAIN. RAIN provides the means for the Avamar server to continue to operate even when a node fails. If a node fails, you can use RAIN to replace the failed node and reconstruct the data on the replacement node. In addition to providing failsafe redundancy, you can use RAIN when rebalancing the capacity across the nodes after you have expanded the Avamar server (added nodes). This is a critical element to being able to manage the capacity of the system as the amount of data added to the system continues to grow.




Always enable RAIN for any configuration other than single-node servers and 1x2’s (two active data nodes). Minimum RAIN configuration is a 1x3 (three active data nodes plus a utility node and spare node). Double-disk failures on a node or a complete RAID controller failure can occur, which can corrupt the data on a node. Without RAIN, the only recourse is to reinitialize the entire system and replicate the data back from the replication target.

When deploying non-RAIN servers, you must replicate the data on these servers to ensure the data is protected. Non-RAIN servers have no data redundancy and so, any loss of data can have significant and widespread impacts to the backups stored on that Avamar server.

When deploying a RAIN configuration, always include an active spare node in the module. The best way to minimize system downtime is to have a spare node readily available.

For performance reasons, Avamar recommends limiting the number of nodes to 16 active data nodes (1x16 configuration). Limit starting configurations to 12 to 14 active data nodes so that nodes can be added later if needed to recover from high capacity utilization situations.

Replication. The Avamar system can efficiently replicate data from one Avamar server to another on a scheduled basis. This ensures complete data recovery if the primary backup Avamar server is lost. If the primary server and the replication target are configured in an active-passive configuration, then with one change to the DNS entry and with a few commands, all clients can continue daily backups to the replication target. (See the following images.)

Replication is useful for more than recovering from the traditional disaster associated with a site failure. Replication is, by far, the most reliable form of redundancy that the system can offer because it creates a logical copy of the data from the replication source to the destination. It does not create a physical copy of the blocks of data, and therefore, any corruptions, whether due to hardware or software, are far less likely to be propagated from one Avamar server to another. Further, during replication, multiple checks of the data occur to ensure that only uncorrupted data is replicated to the replication target.

Therefore, if maximizing the availability of the backup server for backups and restores is important to you, then you should set up a replication system as quickly as possible.



Normal Backup and Replication Operation

Failover Operation

During this example failover, clients still back up to hostname BACKUP_SRVR, but in the DNS server, BACKUP_SRVR is associated with IP address 192.168.200.1, the utility node of REPL_DST.




Protect the data on the Avamar server by replicating the data to another Avamar server.

To take advantage of the failover capability, set up active-passive replication pairs. If a replication pair is set up as active-active (that is, some clients back up to one Avamar server while other clients back up to the other server), then the failover capability cannot be implemented.

Set up the replication pair so that one Avamar server is the active server used to back up the clients, and the other Avamar server is the passive server used exclusively as a dedicated replication target for the backup Avamar server. If the active server fails, the customer can change the DNS entry and then all clients begin backing up to the passive server.

Ensure that available bandwidth is adequate to replicate all of the daily changed data within a 4-hour window so that the system can accommodate peaks of up to 8 hours per day. The replicator can use 60 to 80 percent of the total available bandwidth when WAN bandwidth is the performance bottleneck.

When defining daily replication, avoid using the --include option. This option should only be used to perform selective replication under certain conditions. Specifying clients that must be replicated by listing them with the --include option is prone to error. In other words, every time you add a new client to the active Avamar server, the client data is not replicated unless you edit the repl_cron.cfg file to add a new --include option for that client. Also, a system that specifies the --include option might not include the MC_BACKUPS data. That means none of the policies are then replicated.

Use the --exclude flag only if you decide that a high change-rate or low-priority client can selectively be excluded from the nightly replication.

Checkpoints. Checkpoints provide redundancy across time. Checkpoints allow you to recover from operational issues (such as attempting to back up a client that is too large to fit in the available remaining capacity or accidentally deleting a client and all of the associated backups). In addition, checkpoints allow you to recover from certain kinds of corruption by rolling back to the last validated checkpoint.

Although checkpoints are an effective way to revert the system back to an earlier point in time, checkpoints are like all other forms of redundancy and therefore, require disk space. The more checkpoints you retain, the larger the checkpoint overhead.


Backing Up Clients in Remote OfficesARCHITECTING AVAMAR TO MAXIMIZE SYSTEM AVAILABILITY

Operational best practice is:

Leave the checkpoint retention policy at the default values. The default is set to retain the last two checkpoints, whenever created, and to retain the last validated checkpoint.

NOTE: During certain support actions, your Customer Sup-port Representative might temporarily change the check-point retention policy to ensure that certain criticalcheckpoints are retained during the support action. Ensurethe checkpoint retention policy is restored to the default set-ting when the support action is completed.

Backing Up Clients in Remote OfficesWhen you want to back up clients in a remote office, the following common architectural options should be considered:

Option 1: Is it better to back up remote office clients to a small Avamar server located in the remote office (remote Avamar backup server) and replicate data to a large centralized Avamar server (centralized replication destination)?

Option 2: Or is it better to back up those clients directly to a large centralized Avamar server (centralized Avamar backup server) and replicate data to another large centralized Avamar server (centralized replication destination)?

The following key factors must be considered when making this decision:

FACTOR DESCRIPTION

Recovery time objective (RTO)

When the Avamar system performs a restore, all data that needs to be restored is sent in compressed form from the Avamar server to the Avamar client, where it is uncompressed. However, no deduplication is performed on the restored data. The primary advantage of backing up to a remote Avamar backup server (Option 1) is that the restore can be done directly from that server across the local area network to the client. This is important if a recovery time objective (RTO) requirement must be satisfied.

Server administration

The amount of administration and support required is roughly proportional to the number of Avamar servers deployed in an environment.For example, 10 single-node servers deployed as remote Avamar backup servers require considerably more administration and support than a single 1x8 multi-node configuration of 10 nodes (eight active data nodes, one utility node and one spare) serving as a centralized Avamar backup server.


Backing Up Clients in Remote OfficesARCHITECTING AVAMAR TO MAXIMIZE SYSTEM AVAILABILITY

If the deployment environment’s WAN throughput is a bottleneck, the time required to perform nightly replication in Option 1 is roughly the same as the time required to perform backups in Option 2. The tradeoff then becomes RTO versus the additional cost of deploying, managing and supporting multiple Avamar server instances.

Three additional factors should be taken into consideration when making this decision:


Unless you cannot meet your restore time objectives, architect the system so that clients back up directly to a large active centralized Avamar server and then replicate data to another large passive centralized Avamar server.

FACTOR DESCRIPTION

IT resources Even if a remote Avamar backup server is deployed at a remote office, adequate IT resources for performing disaster recovery restores might not be available at the remote office. In this case, Option 2 might be appropriate, in which case, centralized IT staff can perform disaster recovery restores to replacement hardware at the central site and then ship the fully-configured replacement client to the remote site.

Exchange Server If an Exchange Server is located in the remote office, depending on the bandwidth, the only practical way to restore the large amount of data typically associated with this kind of server’s storage group or database might be Option 1.

Large multi-node servers

If large multi-node servers are required to back up all data in a remote office, there might not be a significant reduction in the number of Avamar servers that are deployed, even if Option 1 is selected. In this case, the cost of deploying, managing and supporting the Avamar servers is roughly the same, regardless of whether these Avamar servers are deployed as remote Avamar backup servers or as centralized Avamar backup servers.


MANAGING CAPACITYThis daily operations chapter focuses on the kinds of activities and behaviors one can reasonably expect during the first several weeks in your Avamar server lifecycle.

When your new Avamar system is initially deployed at your site, the server typically fills rapidly for the first few weeks. This is because, at least initially, nearly every client that is backed up contains relatively high amounts of unique data. Avamar's commonality feature is best leveraged when other similar clients have been backed up or the same clients have been backed up at least one time.

After the initial backup, the Avamar system backs up significantly less unique data during subsequent backups. When initial backups are complete and the maximum retention periods are exceeded, it is possible to consider and measure the ability of the system to store about as much new data each day as it frees during the maintenance windows. This is referred to as achieving a steady state of capacity utilization.

Successfully achieving steady state capacity utilization is especially important for the single-node and non-RAIN server because these are fixed-capacity systems.

Impact of Storage Capacity on System PerformanceWhen managing an Avamar server, keep in mind that you can significantly improve the long-term reliability, availability and manageability of the Avamar server if you do either of the following:

• Minimize the average daily data change rate of the clients being protected.• Reduce the per-node capacity utilized within the Avamar server by doing one

or more of the following:• Reducing backup retentions• Ensuring daily maintenance jobs run regularly• Adding more nodes to the Avamar server

Many of the operational best practices described throughout this document are targeted at understanding the average daily change rate or managing the per-node capacity.


Impact of Storage Capacity on System PerformanceMANAGING CAPACITY

Definitions of Avamar Server Capacities

Storage Subsystem (GSAN) Capacity. This is the total amount of commonality factored data and RAIN parity data (net after garbage collect) on each data partition of the server node. This is measured and reported by the GSAN process. The administrator of the Avamar server can control this reported capacity by changing the dataset definitions, retention policies or even the clients that are backed up to this server, and then by ensuring that a garbage collect operation runs regularly to remove expired data.

Operating System Capacity. This is the total amount of data in each data partition, as measured by the operating system. This not only includes the size of all the stripes in the current working directory (cur), but also the checkpoint overhead, plus the amount of data stored on the data partition by other activities. For example, the /data0? directories not only include /data0?/cur and the /data0?/cp.* checkpoint directories, but also temporarily the /data0? hfscheck directory.

Avamar Capacity ThresholdsThe GSAN changes behavior as the various capacities increase. You need to understand the following key thresholds:

THRESHOLDDEFAULT

VALUE

CAPACITY USED FOR

COMPARISON BEHAVIOR

Capacity Warning

80% of read-only threshold

GSAN Capacity

The Management Console Server issues a warning event when the GSAN capacity exceeds 80% of the read-only limit.

Health Check Limit

95% of read-only threshold

GSAN Capacity

When the GSAN capacity reaches this health check limit, existing backups are allowed to complete, but all new backup activity is suspended. Notifications are sent in the form of a pop-up alert each time you log into the Avamar Administrator, and a system event must be acknowledgment before future backup activity can resume.



Impact of Capacity on Various OperationsAnother key consideration when managing the Avamar server is that many of the maintenance operations take longer to complete as the capacity on each node increases. The most significant daily operational impacts are to backup performance and hfscheck.


Understand how to monitor and manage the storage capacity of the Avamar server on a daily basis.

Limit storage capacity usage to 80 percent of the available "server utilization" capacity.

Proactive Step to Manage the Health of the Avamar ServerYou will get a warning when the GSAN capacity exceeds 80 percent of the capacity threshold. It is important that you perform a system healthcheck at this point. Refer to Performing a Healthcheck (page 57) for additional information.

Other Proactive Steps to Manage CapacityYou will get a warning when the GSAN capacity exceeds 80 percent of the Read Only threshold. If this occurs, you must perform the following additional operational best practices.

Server Read-Only Limit

100% of read-only threshold, which is set to a prespecified percentage of available hard drive capacity

GSAN Capacity

If the GSAN capacity on any data partition on any node exceeds the read-only threshold, the Avamar server transitions to read-only state. This prevents new data from being added to the server. This value is reported in Avamar Administrator > Server > Server Management Tab > Server utilization. The reported value represents the average utilization relative to the read-only threshold.

System Too Full to Perform Garbage Collect

85% of available hard drive capacity

Operating System Capacity

If the operating system capacity on any data partition on any node exceeds the disknogc configuration threshold, a garbage collect operation does not run. The gc_cron fails with the error message MSG_ERR_DISKFULL.

THRESHOLDDEFAULT

VALUE

CAPACITY USED FOR

COMPARISON BEHAVIOR




Stop adding new clients to the system.

Reassess retention policies to see if you can decrease the retention, and therefore, reduce the capacity use.

Investigate the possibility that backups are preventing a garbage collect operaton from starting. If this is the case, the following error message is logged in the /usr/local/avamar/var/cron/gc.log file:

MSG_ERR_BACKUPSINPROGRESS or garbage collection skipped because backups in progress.

IMPORTANT: You can decrease the GSAN capacity bydeleting or expiring backups and running garbage collection,but you cannot decrease the amount of data in the cur direc-tories. The amount of data in each of the cur directories setsthe lower threshold for the operating system view of capac-ity use.

IMPORTANT: Deleting backups or clients (and therefore,all the backups associated with those clients) does not freespace until garbage collect has run several times. Garbagecollect finds and deletes the unique data associated withthese backups.

Reactive Steps to Recovering from Capacity IssuesOnce the Avamar server capacity significantly exceeds the warning threshold and approaches the diskreadonly limit, you must do one or more of the following:

1. Follow the steps described previously for an Avamar server that starts to issue warnings.

2. Because the maintenance tasks become less efficient, consider consolidating backup and replication activities into tighter windows.

3. If the Avamar server reaches the health check limit, all new backup activity is suspended until you acknowledge this event.

4. If the Avamar server transitions to a read-only state, you must contact EMC Technical Support. You will be expected to delete backups, change retention policies and suspend backups for at least 2 days while the system performs an aggressive garbage collect operation.

5. In an extreme case, you might consider replicating the data to another server temporarily, and then replicating the data back after reinitializing the server. Because replication creates a logical copy of the data, this compacts all the data onto fewer stripes.



6. If the Avamar server is a multi-node server that utilizes RAIN, consider adding nodes and rebalancing the capacity. If the server has eight or more active data nodes, EMC recommends adding two nodes at a time, rather than adding just one node, to noticeably reduce the capacity per node.

Steady State SystemTypically, an Avamar system achieves steady state shortly after the longest retention period for the backups. For example, if you retain all daily backups for 30 days and all monthly backups for 3 months, the system begins to operate in steady state about 3-1/2 to 4 months after the last client has been added to the system. A slight delay occurs before achieving steady state because the garbage collect process requires several passes before it reaches the bottom of the filesystem tree. Garbage collect finds orphaned chunks in the upper levels first before removing orphaned data in the lower levels of the filesystem.

After the system has achieved steady state, then do the following:

1. Ensure that activities are scheduled so that all backups and maintenance successfully run.

2. Verify that the server use reported by the Avamar Administrator is at or below 80% (see the following image):

3. Compare the average daily new bytes that are added to the Avamar server with the average daily bytes freed during garbage collection to ensure that the system is in steady state.

Using capacity.sh to Assess System Steady State BehaviorUse the capacity.sh program to assess whether the system is in "Steady State." This program is useful in quickly providing a high-level summary of the amount of new data added to the system and the amount of data deleted in the garbage collect process. By comparing these two figures, you can quickly assess whether the system is successfully achieving steady state operation.



The capacity.sh program also provides a list of the highest change rate clients that contribute most to the daily change rate. This information is useful for assessing the impact of a few clients on the overall capacity utilization of the system.

After running the capacity.sh command, the following appears in your command shell:

Date New Data Removed-GC Net Change2007-11-19 38 mb 0 mb 38 mb2007-11-20 30 mb -936 mb -906 mb2007-11-21 64 mb -28 mb 35 mb2007-11-22 0 mb -66 mb -66 mb2007-11-23 0 mb -1911 mb -1911 mb2007-11-24 0 mb -56 mb -56 mb2007-11-25 467 mb -557 mb -89 mb2007-11-26 2292 mb -66 mb 2226 mb2007-11-27 3909 mb -165 mb 3743 mb2007-11-28 85 mb 0 mb 85 mb2007-11-29 103 mb -5777 mb -5674 mb2007-11-30 71 mb 0 mb 71 mb2007-12-01 43 mb -51 mb -7 mb2007-12-02 25 mb -64 mb -39 mb2007-12-03 52 mb -41 mb 11 mb---------- ---------- ---------- ----------Average 449 mb -607 mb -158 mb

Top 3 High Change Clients:--------------------------Total for all clients 7185 mb 100.0% a1244.avamar.com 5715 mb 79.5% usitmckinkl1c.corp.emc.com 475 mb 6.6% a1195.corp.emc.com 463 mb 6.5%

Analyze the data over 2 weeks, as shown in the Date column. The average daily amount of data added to the server is shown on the Average row of the New Data column. The average daily amount of data deleted from the server through the garbage collect process is shown on the Average row of the Removed-GC column. To successfully be in steady-state operation, the average Net Change should be negative or, if positive, a very small percentage of the average New Data added to the system.

The highest change rate clients are listed under Top 3 High Change Clients.

If you would like to install and receive training in the use of the capacity.sh program, contact EMC Technical Support.


SCHEDULINGThis planning and design chapter focuses on scheduling activities, important steps in designing and setting up a new Avamar system. This chapter discusses several of these activities including:

• Avamar server maintenance cron jobs• Backups

Avamar Client DetailsAvamar's client agents are applications that run natively on the client systems. The Avamar client software comprises at least two executable programs — avagent and avtar. The avagent runs as a service on the client and establishes and maintains communication with the Avamar Administrator Server.

When the Avamar Administrator Server queues up a work order (for example, a backup), the Avamar Administrator Server pages the client avagent. If the client is nonpageable (that is, the Avamar Administrator Server cannot establish a connection with the client), then the client avagent polls the Avamar Administrator Server at a regular interval to check for a work order.

If the Avamar Administrator Server queues up a work order for the client, then the client avagent retrieves the work order.

The avagent then launches the avtar executable with the parameters specified in the work order. The avtar program executes the backup based on the set of parameters related to the backup task. The avtar performs a backup by making a connection with the Avamar server over the LAN or a remote connection over the WAN. TCP/IP is the base protocol used to make the connection.

Restores are executed in a similar manner to backups. A restore work order is created containing the parameters necessary to complete a restore of all or a subset of the files of a specific backup.


Avamar Client DetailsSCHEDULING

Restrictions and LimitationsThis section lists known restrictions and limitations you should consider during planning and design. Refer to the most recent release notes and documents listed in Assumptions and References (page 9) for updates to this information.

RESTRICTIONS AND LIMITATIONS IMPACT

Carefully review the client support matrix with the presales technical engineer.

Ensure that clients and applications you want to protect with Avamar software are fully supported. In particular, verify the specific details of the deployment, such as revisions, clusters, third-party plugins and add-ons, are supported.

Recovery Time Objective (RTO)

RTO involves many things including processes, communication service levels, regular testing and people. The time to restore data is only one of several critical components needed to achieve a given RTO.

Also, the RTO for any individual client is typically limited by the performance capabilities of the client or network and not the capability of the Avamar server to restore the data.

5 million files per Avamar client

Backup scheduling is impacted when an Avamar client has more than five million files. This is because client backups average one million files per hour and the average backup time must be limited to 5 hours to be able to handle peaks of up to 10 hours (2:1 variation between peak and average).This is a typical file scan rate. Sometimes clients might perform two-to-three times faster than that.

500 GB of database data per Avamar client

Backup scheduling is impacted when an Avamar client has more than 500 GB of database data. This is because all the data in the database must be rescanned every day and the scan rate typically averages 100 GB per hour. Average backup time must be limited to 5 hours to be able to handle peaks of up to 10 hours (2:1 variation between peak and average).This is a typical data scan rate. Sometimes clients might perform more than three times faster than that.

2 TB of file server data per Avamar client

Backup scheduling is impacted when an Avamar client has more than 2TB of file server data. EMC observations of large file server backups conclude that typically about 250 GB to 500 GB every hour can be backed up. Since average backup time must be limited to 5 hours to be able to handle peaks of up to 10 hours, this means that only about 2TB per client per night can be backed up.


Scheduling Activities During the Course of a DaySCHEDULING

Scheduling Activities During the Course of a DayDuring the planning and design stage, properly scheduling activities throughout the day is one of the most important factors that influences the system reliability, availability and supportability.

Here are the rules that determine how to schedule the backup and various server maintenance activities throughout the day:

IF THE FOLLOWING OPERATION IS RUNNING... THE IMPACT IS…

Checkpoint No other maintenance jobs can start.

All backup work orders will be queued until the checkpoint operation is complete.

Garbage Collect No other maintenance jobs can start.

All backup work orders will be queued until the garbage collect operation is complete.

Hfscheck The garbage collect operation cannot start. All other maintenance jobs, such as checkpoint, replication and so forth, can start.All backup work orders will be queued until after the hfscheck process has started. After the hfscheck process has started, then only 2 backup jobs per node (instead of the usual 18 per node) will be queued, less 1 for the overall system that is reserved for a restore job.

Replication Source (that is, when replicating data from the local server to a replication target)

All other maintenance jobs can start.

All backup work orders will be queued immediately.

Replication Destination (that is, when receiving replicated data from the replication source)

The garbage collect operation cannot start. All other maintenance jobs, such as checkpoint and hfscheck, can start.

All backup work orders will be queued immediately.

Backups The garbage collect operation cannot start.

Also, on a single-node server, hfscheck might not be able to start if there are more than two backup sessions in progress.

All other maintenance jobs can start.



The following implications arise from the previous table:

Typically, the longest running activities throughout the day are hfscheck, backups and replication. If either hfscheck or backups are running, then the garbage collect operation will not run. If garbage collection does not run on a daily basis, then the system will get more full, which causes hfscheck and possibly even backups to run even longer. Then garbage collection is less likely to run, a vicious cycle that must be avoided.

What is less obvious from the previous table is that although hfscheck and backups can, to a limited extent, be overlapped, the problem is that overlapping these two activities causes both activities to take longer to complete and possibly even to fail. This is because of I/O resource contention.

If replication is bottlenecked by the WAN throughput, then overlapping replication with backup activities is unlikely to affect the amount of time required to perform replication and will have only a slight impact on backup performance.

Two reasons some clients take a long time to back up are:

The backup throughput for these clients is limited by the WAN bandwidth. In this case, since the activity level on the Avamar server is relatively low, it is acceptable to overlap replication with the end of the backup window.

The backup window for these clients is long because the clients are large clients. As described later, the time required to perform the backup is directly proportional to the type and amount of data on the clients being backed up.


Minimize the number of groups used to back up clients, and, if possible, use a single backup window that does not overlap with the daily maintenance jobs and does not exceed 8 to 10 hours per day.

Keep the overall daily schedule simple as shown in the image on the following page. Use the following schedule and do not deviate from this schedule unless absolutely necessary:

• 6 A.M. through 8 P.M.: Window for maintenance jobs. No backups allowed.

• 8 P.M. through 6 A.M.: 10-hour backup window• 10 P.M. through 6 A.M.: 8-hour replication window overlapped with

backup window.• 12 noon through 3 P.M.: If the customer must back up clients

during the middle of the day, then provide a 3-hour window during the middle of hfscheck so that a limited number of clients can be backed up during this window.

If there are a large number of clients that need to be backed up outside of the 8 P.M. to 6 A.M. backup window, set up a separate Avamar server that backs up those clients. For example, if a customer wants to back up clients from around the globe, it might be best to set up one Avamar server to back up the clients in the Americas, another server to back up the clients in EMEA and a third Avamar server to back up the clients in APJ.



Limit the amount of time required to perform checkpoint, hfscheck and so forth, by carefully managing the capacity on the node. The most effective way to do this is to limit the clients being backed up, reducing the retention policies, backing up clients with lower daily change rates and ensuring that the garbage collect operation runs every day.

Limit the amount of time required to perform backups by carefully observing the limitations on the maximum number of files per client (5 million files), the maximum amount of database data per client (500 GB) and the maximum amount of data per file server (2 TB). Typically, 80 to 90 percent of the clients will, on a daily basis, complete backups within the first hour or two of the backup window. This is the reason we schedule replication to start 2 hours after the start of the backup window — because the Avamar server is typically the bottleneck for backup operations only during the first 1 to 2 hours of the backup window. The remaining 10 to 20 percent of the clients might take several hours to complete backups, depending on the number of files or amount of data that needs to be backed up on these clients.

The following image outlines an ideal Avamar system daily schedule.

Using sched.sh to Quickly Assess Daily SchedulesThe sched.sh program is useful to quickly visualize how all the daily activities fit together during the day. You can also quickly ensure that all of the daily maintenance jobs are running on a daily basis, and the degree of overlap between the various activities.

The following is a sample output from a sched.sh --days=14 command:

12am 1 1 1 1 1 1 1 1 1 1 2 2 2 2 PST 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3<< Snip >>2007/11/24 sssssssss...c.................c...............ss2007/11/24 ............ggggg.hhhhhhhhhhhhh.................2007/11/25 ssssssssss..c.................c.uuuuuuuuuuuuuuuu2007/11/25 ............ggggg.hhhhhhhhhhhhh...............ss2007/11/26 uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu...........c.ss2007/11/26 ssssssssss..c.....hhhhhhhhhhhhhhhhhhhhhhhhhh....2007/11/26 ............ggggg...............................2007/11/27 ssssssssss..c.................cc..............ss2007/11/27 ............ggggg.hhhhhhhhhhhhh.................2007/11/28 ssssssssss..c.................c...............ss2007/11/28 ............ggggg.hhhhhhhhhhhhh.................2007/11/29 ssssssssss..c.................c...............ss2007/11/29 ............ggggg.hhhhhhhhhhhhh.................2007/11/30 ssssssssss..c.................c...............ss2007/11/30 ............ggggg.hhhhhhhhhhhhh.................2007/12/01 ssssssssss..c.................c...............ss2007/12/01 ............ggggg.hhhhhhhhhhhhh.................2007/12/02 ssssssssss..c.................c.uuuuuuuuuuuuuuuu2007/12/02 ............ggggg.hhhhhhhhhhhhh...............ss



2007/12/03 uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu..............2007/12/03 sssssssssss.c...................................2007/12/03 ............gggggg..............................s=snapup, h=hfs, c=CP, g=GC, r=Repl, d=ReplDest, e=restoreUppercase/Reverse means failed. v1.5

Each character in this format represents 1/2 hour. It is also possible to print it in a wide format in which each character represents 1/4 hour.

Analyzing the Data. Use the data output by the sched.sh program to analyze system activities and ensure that maintenance jobs are running properly. Any anomalies should be investigated.

Consider the following factors, using the ideal Avamar system daily schedule (see previous image) as a guide. Ensure that:

Backups start in a timely manner to avoid overrunning your backup window and interferring with morning maintenance jobs.

Garbage collect runs at the proper time every day.

Checkpointing is performed at correct intervals.

Your system is properly replicating data.

Scaling up node capacity does not cause hfscheck to run longer than desired.

The time between the end of backups and the start of morning crons is enough to accommodate day-to-day variations.

For training in the use of the sched.sh program, contact EMC Technical Support.


DEFINING DOMAINS, GROUPS AND POLICIESThis planning and design chapter describes initial backup management policy decisions that must be made after the overall daily schedule has been defined, such as:

What domains should I set up with designated domain administrators to take advantage of the hierarchical administration capability?

What groups (which include dataset, backup schedule and retention policies) should I create in order to back up clients effectively and manage the backups?

How do I set up the retention policies to retain the backup data for the required period?

When should I schedule these backups and how long should I allow client backups to run?

Defining DomainsDomains are distinct zones within the Avamar server accounting system that are used to organize and segregate clients. The real power of domains is that they provide the ability for a domain-level administrator to manage the clients and policies within that domain. This is known as hierarchical management.

Another possible reason for segregating clients by domain is for billing other internal organizations for backup services. Segregating clients by department or work group might be a convenient way to bill them.

If you are not going to use hierarchical management, then you should register all clients in the /clients domain.


Minimize the number of domains that you create. Ideally, you will register all clients in the /clients domain.


Defining SchedulesDEFINING DOMAINS, GROUPS AND POLICIES

Defining GroupsA group defines the backup policy for the clients assigned to it, and includes the following three policy elements: dataset policy (including the source data, exclusions and inclusions), backup schedule (or backup window) and retention policy.


Minimize the number of groups that you define. Remember that each dataset policy can include separate dataset definitions for various client plugins. In other words, a single dataset policy can define independent datasets for Windows, Linux, Solaris and other clients. Therefore, you do not need to define separate groups to back up various kinds of operating system clients.

Leave the default group disabled. By default, all new clients that have been activated with the Avamar server are automatically added to the default group. If you enable the default group, then any clients that are activated with the Avamar server will automatically be backed up according to the default group policy. To help manage the capacity on the Avamar server and to avoid being surprised by unexpected clients, leave the default group disabled. If you want to back up any clients in the default group to the Avamar server, you can add the client to an enabled group and remove the client from the default group.

Defining DatasetsOperational best practices for defining datasets are:

Minimize the number of datasets required.

In general, do not attempt to back up a large client by defining multiple subsets of data that run every night. This is a good practice in only three instances:

• When you want to define different retentions for different subsets of data on the client.

• When you are breaking up the dataset so that different subsets of the data are backed up on different days of the week.

• When you do not have enough memory to accommodate an appropriate sized file cache or hash cache for the entire dataset. Refer to Tuning Client Caches to Optimize Backup Performance (page 40) for additional information.

Defining SchedulesThe default schedule runs nightly and specifies a maximum backup window of eight hours. Depending on the amount of data in your largest clients, this might not be enough time, and you might need to extend the window to 10 hours (from 8 P.M. to 6 A.M.).


Defining Retention PoliciesDEFINING DOMAINS, GROUPS AND POLICIES

Furthermore, at least initially, clients require extra time for the first few backups. Therefore, you should consider setting the Client Properties Allow overtime option, at least initially, to ensure that client backups complete each night.


Set appropriate expectations for how long the longest client backups should run every night, and validate that the long-running client backups meet the expectations.

Minimize the number of clients that need to be backed up outside of the 8 P.M. to 6 A.M. backup window. When setting up the backup schedules, remember that mobile laptop clients might need to be scheduled to back up during the day when they are connected to the network. The system can handle a small number of exceptions. In this case, you will want to overlap the backup of this handful of exception clients with the hfscheck process.

Do not allow overtime after the system has achieved steady-state operation. Remember that allowing overtime will allow the client backup to run beyond the end of the backup window. When this happens, the garbage collect operation might not be able to start. Garbage collection needs to run every day to keep the system at steady-state capacity.

Defining Retention PoliciesWhen setting up retention policies, operational best practices are:

Use the advanced retention policy whenever possible. This helps to reduce the total amount of back-end storage consumed on the Avamar server. Typically, the following applies:

• Weekly backups are equivalent, in the amount of unique data, to three daily backups.

• Monthly backups are equivalent, in the amount of unique data, to six daily backups. Therefore, if you retain 3 months of backups by retaining 30 days of daily backups and 3 months of monthly backups, the total amount of data stored on the Avamar server for the clients is equivalent to the initial unique data plus 42 equivalent days of backups. This requires less back-end capacity than storing 3 months of daily backups, which is equivalent to the initial unique data plus 91 equivalent days of backups.

Set the minimum retention period to at least 14 days. Remember that, when selecting the maximum retention period, the Avamar server does not retain the last unexpired backup. Therefore, if the retention period is relatively short (for instance, 7 days), the customer must monitor the backup operations closely enough to ensure that the last unexpired backup does not expire before the system completes another backup. If all backups for a client expire before the customer corrects the backup issue that prevented the client from completing a backup, then the next backup will be equivalent to an initial backup.


DAILY MONITORING OF BACKUP INFRASTRUCTUREThis daily operations chapter focuses on a number of Avamar features and functions that generate notifications when specific events occur. The system reports all Avamar system activity and operational status as events to the administrator server. Examples of Avamar events include offline server nodes, failed or missing server maintenance cron jobs and even hardware issues.

Monitoring the Avamar SystemYou should monitor the event notification system for warning and error events every day.


Monitor the Avamar server on a daily basis and understand how to interpret all system warnings and errors.

The following are possible ways to monitor your Avamar systems:

METHOD DESCRIPTION

syslog or SNMP event notification

If your network management infrastructure supports syslog or SNMP event notification, enable the syslog or SNMP event notification subsystem through Avamar Administrator. Refer to the Avamar System Administration Manual for instructions on enabling syslog or SNMP notification.

Email notification system

You can set up email notification in either of the following ways:

• To batch email notifications that are sent twice daily according to the default Notification Schedule.

• To send emails as the selected events occur.


Monitoring the Avamar SystemDAILY MONITORING OF BACKUP INFRASTRUCTURE

Avamar Enterprise Manager dashboard

To manually monitor the Avamar system, monitor the overall health of the Avamar backup infrastructure through the Avamar Enterprise Manager dashboard. Avamar server issues are immediately obvious because they are flagged by a red "X" under Server Status.

Unacknowledged events

On a regular basis (at least daily), you should review and clear any Unacknowledged Events queued on the Avamar Administrator > Administration > Event Management tab > Unacknowledged Events tab. On any Avamar Administrator view, you can click Have Unacknowledged Events to be redirected to the Unacknowledged Events page.

Avamar Administrator Event Monitor

At least once a day, you should review the event monitor on the Avamar Administrator > Administration > Event Management tab > Event Monitor tab.

METHOD DESCRIPTION


DAILY MONITORING OF BACKUP OPERATIONSThis daily operations chapter focuses on a number of Avamar features and functions that generate notifications when specific backup, restore or replication operation events occur. The system reports all Avamar system activity and operational status as events to the administrator server. You can then use client logs to investigate backup or restore issues.

Monitoring the Avamar System Backup OperationsYou should monitor the event notification system for warning and error events related to backup operations every day.


Monitor the Avamar Activity Monitor on a daily basis and understand how to interpret all activity warnings and errors.

Closely Monitor Daily Backup ActivitiesTo create consistent backups every day, you must closely monitor daily backup activities. The Avamar system offers several tools to do this.

The following factors may interfere with backups:

• Network issues

These can cause backup failures.

• Client I/O errors

These can prevent all files from being backed up (also known as Completed with Exceptions status).

• High client activity levels

These can prevent all files from being backed up or can prevent backups from completing within the backup window.

• Operator intervention

Such as rebooting the client during the backup or canceling the backup.


Monitoring the Avamar System Backup OperationsDAILY MONITORING OF BACKUP OPERATIONS

• Incomplete or incorrect dataset definitions• Inadequate or incorrect retention periods

When you examine the activities, resolve all exceptions and failures.

The most obvious issues are the ones where the clients did not create a restorable backup. The status messages typically associated with these failures are the following:

• Failed

The client failed to perform the activity. In other words the activity ended due to an error condition. Refer to the associated client log.

• Canceled

The activity was cancelled, either from the client or from the Avamar Administrator. Refer to the associated client log.

• Dropped Session

The activity was successfully initiated but, because the Administrator server could not detect any progress, the activity was cancelled. The two most common causes are:

• Somebody rebooted the client in the middle of the backup.• A network communication outage longer than 1 hour occurred.

The Administrator server will automatically queue a rework work order if the client backup fails due to a dropped session.

• Timed Out - Start

The client did not start the activity in the scheduled window. This is most likely because the client is not on the network.

• Timed Out - End

The client did not complete the activity in the scheduled window. This requires special attention because there is a lot of system activity with no restorable backup. Typically, if this is the case, subsequent backups will continue to fail with the same status, unless some change is made, such as tuning the client caches.

The less obvious failure, but one that still requires attention, is a backup that reports the Completed with Exceptions status. In this case, the backup completed but with errors. Typically, the errors are due to open files that could not be backed up. Do not ignore this status. Some missing files, such as .PST files, can be significant.

You should examine all backups that completed successfully to ensure that the dataset definitions and retentions are appropriate.

The primary tool for monitoring daily backups is the Activity monitor in Avamar Administrator. This tool is described in the Avamar System Administration Manual.

Avamar Administrator can email reports that you can use to monitor clients that failed backup or completed backup with exceptions. The following client reports are helpful:

• Activities - Exceptions

This report lists all activities in the specified period that completed with exceptions.


Monitoring the Avamar System Backup OperationsDAILY MONITORING OF BACKUP OPERATIONS

• Activities - Failed

This report lists all activities in the specified period that failed due to errors.

• Clients - No Activities

This report lists all clients that did not have any activities in the specified period.

Refer to the Avamar System Administration Manual for descriptions of these and other reports that are available.

Operational best practice are:

Monitor backups every day and investigate all failed backups, missing clients and backups that completed with exceptions.

Enable the advanced statistics report during all backups. This information is useful for addressing performance issues.

Enable debugging messages when investigating backup or restore failures.

Enable various activity report email messages, such as:

• Activities-Exceptions• Activities-Failed• Clients-No Activities

Closely Monitor Nightly ReplicationEnsure that nightly replication successfully completes. The Avamar Administrator Activity Monitor displays a list of all clients that completed replication activities.


TUNING PERFORMANCEThis implementation and daily operations chapter focuses on important Avamar system tuning activities, such as:

• Optimizing backup performance• Setting up and using replication• Tuning caches

Refer to Managing Capacity (page 19) for additional information.

IMPORTANT: The information in this chapter is very impor-tant. The difference in backup performance with properly-sized caches is dramatic. Experience has shown that, aftersizing the client caches properly, backups that regularlyrequired over 20 hours to complete suddenly complete in 4hours every night.

Typical backup should take about 1 hour for every millionfiles in a file server or about 1 hour for every 100GB of datain a database server. If backups take more than 30 percentlonger than these metrics, you should investigate whetherclient caches are properly tuned.

As with many Operational Best Practices, tradeoffs need tobe carefully considered. Arbitrarily increasing the size of cli-ent caches consumes more memory. That could cause swap-ping and slow overall client performance. So ensure that youdo the math required to size client caches appropriately.


Tuning Client Caches to Optimize Backup PerformanceTUNING PERFORMANCE

Tuning Client Caches to Optimize Backup PerformanceThis section describes how the client caches work, and how you can tune the client caches appropriately to optimize backup performance. This section also describes best practices that should be considered when setting up and installing clients.

The Avamar client process (the avtar process) loads two cache files into memory when performing a backup. These client caches are used to:

• Reduce the amount of time required to perform a backup• Reduce the load on the Avamar client• Reduce the load on the Avamar server

Client CachesAt the beginning of the backup, the avtar process loads into memory two cache files from the var directory (this directory is found in the Avamar installation path).

The first of the cache files is the file cache (f_cache.dat). The file cache stores a 20-byte SHA-1 hash of the file attributes, and is used to quickly identify which files have previously been backed up to the Avamar server. The file cache is one of the main reasons subsequent Avamar backups (that is, those that occur after the initial backup) are generally very fast. Typically, when backing up file servers, the file cache screens out approximately 98 percent of the files. When backing up databases, however, the file cache is not effective since all the files in a database appear to be modified every day.

The second cache is the hash cache (p_cache.dat). The hash cache stores the hashes of the chunks and composites that have been sent to the Avamar server. The hash cache is used to quickly identify which chunks or composites have previously been backed up to the Avamar server. The hash cache is very important when backing up databases.



Overview of Cache OperationThe following image shows the process that avtar uses to filter out previously backed up files and chunks. This image shows the values that are incremented and reported in the avtar advanced statistics option (for instance, filebytes, filecache and so forth).

The following image illustrates the effectiveness of the file cache when backing up file servers in contrast to databases. In file servers, the file cache is typically around 98 percent effective in filtering previously backed up files.



File CacheIf the file cache is deleted, not used or is undersized, every file that is not a hit in the file cache must be read, chunked, compressed and hashed before the avtar process finds that the hashes were previously sent to the Avamar server. If a file hits in the file cache, then the file is never read, saving significant time and CPU.

By default, the file cache could consume up to 1/8th of the physical RAM on the Avamar client. For example, if the client has 4 GB of RAM, the file cache will be limited to 4 GB/8, or 512 MB maximum.

The file cache doubles in size each time it needs to grow. The current file cache sizes are: 5.5 MB, 11 MB, 22 MB, 44 MB, 88 MB, 176 MB, 352 MB, 704 MB and 1,408 MB. Since the avtar application is a 32-bit application, the maximum file cache size that can be used is limited to less than 2 GB. So, in this example where a client has 4 GB of RAM, the maximum size of the file cache will be 352 MB.

The file cache includes two 20-byte SHA-1 hash entries:

One of the entries is the hash of the file attributes. The file attributes include: filename, file path, modification time, file size, owner, group and permissions.

The other entry is for the hash of the actual file content, independent of the file attributes.

The file cache rule is: If the client comprises N million files, the file cache must be at least N million files x 40MB/million files. Example: If a client has four million files, the file cache must be at least 160MB (4 million files x 40MB/million files). In other words, the file cache must be allowed to grow to 176MB.



Hash CacheIf the avtar process finds that a hash of a chunk that is not contained in the hash cache, it queries the Avamar server for the presence of the hash.

By default, the hash cache could consume up to 1/16th of the physical RAM on the Avamar client. In the previous example of the client with 4 GB of RAM, the hash cache will be limited to 4 GB/16, or 256MB maximum.

The hash cache also doubles in size each time it needs to grow. The current hash cache sizes are 24MB, 48MB, 96MB, 192MB, 384MB, 768MB and so forth. So, in this example where a client has 4 GB of RAM, the maximum size of the hash cache will be 192MB.

The hash cache includes only one SHA-1 hash per chunk, which is the hash of the contents of the chunk.

The hash cache rule is: If the client comprises Y GB of database data, the hash cache must be at least Y GB / average chunk size x 20MB/million chunks. Use 16kB as the average chunk size for streaming Exchange database backups. Use 24kB as the average chunk size for all other backups, including backups of database dump files.

Example: If an Exchange database client has 250GB of database data, the hash cache must accommodate 16 million chunks (250GB / 16kB). At 20MB per million chunks, this means that the hash cache must be at least 320MB. In other words, the hash cache must be allowed to grow to the next incremental size (384MB).

Impact of Caches on Memory ConsumptionSome customers might be concerned about the amount of memory that the avtar process uses during a backup.

The avtar binary itself requires memory when performing a backup. The amount of memory consumed by the avtar process is generally in the range of 20 to 30 MB. This amount depends on which operating system the client is running, and also fluctuates during the backup depending on the structure of the files that are being backed up by avtar.

Since the file cache and hash cache can grow to maximium sizes of 1/8th and 1/16th of the total RAM in the system, respectively, you can see that, for a client that has, for example, more than 1/2 GB of RAM, the file and hash caches contribute more to the overall memory use than the rest of the avtar process. This is because both caches are read completely into memory at the start of the avtar backup. Also, by default, the overall memory that client caches use is limited to approximately 3/16th of the physical RAM on the Avamar client.



Cache Information in the avtar LogsThe sizes of the file and hash caches are printed near the beginning of the avtar logs. For example:

avtar Info <5573>: - Loaded cache file C:\Program Files\Avamar\var\f_cache.dat (5767712 bytes)avtar Info <5573>: - Loaded cache file C:\Program Files\Avamar\var\p_cache.dat (25166368 bytes)

In this case, the file cache is currently 5.5 MB, and the hash cache is currently 24 MB.

At the end of the avtar log, you will see the following set of messages:

avtar Info <5587>: Updating cache files in C:\Program Files\Avamar\var avtar Info <5069>: - Writing cache file C:\Program Files\Avamar\var\f_cache.dat avtar Info <5546>: - Cache update complete C:\Program Files\Avamar\var\f_cache.dat (5.5MB of 63MB max) avtar Stats <6151>: File cache: 131072 entries, added/updated 140, booted 0 avtar Info <5069>: - Writing cache file C:\Program Files\Avamar\var\p_cache.dat avtar Info <5546>: - Cache update complete C:\Program Files\Avamar\var\p_cache.dat (24.0MB of 31MB max) avtar Stats <6152>: Hash cache: 1048576 entries, added/updated 1091, booted 0

You can see that the file cache has room to grow, but the hash cache is at its maximum allowable size. If the file cache is undersized, you will see that the booted value will be nonzero, and the log will include a warning that the cache is undersized. This is very important because the size of the cache has a huge influence on the overall performance of the system.

Changing the Maximum Cache SizesYou can override the default limits on the size of the file and hash caches by using the following two options:

--filecachemax=VALUE

--hashcachemax=VALUE

Where VALUE is an amount in MB or a fraction (negative value = fraction of RAM).

As described previously, the default values are:

--filecachemax=-8

--hashcachemax=-16

As another example, the following option will limit the file cache to 100 MB. Because the file cache doubles in size every time it needs to grow, the file cache will actually grow up to 88 MB if the following option is used:

--filecachemax=100

If you choose to limit either of the two cache sizes to a lower limit than the default limit, and if the cache size is already beyond your specified value, you will need to



delete the cache for the new limit(s) to become effective. The cache sizes increase monotonically; that is, there is no way to shrink the cache files without deleting them and building them back up to the new limit.

Another implementation consideration is that if you choose to limit the cache size on a set of clients, then you should add the appropriate parameters to each client's avtar.cmd file so that they are applied every time the client performs a backup, even an on-demand backup. If you do not include the flag in the avtar.cmd file, and somebody performs an on-demand backup and forgets to include the appropriate option, the file cache or hash cache could grow to the default values.

Tuning the Maximum Cache SizesTo optimize performance, sometimes you need to increase the cache sizes from the default values. These conditions could exist in the following two opposed cases: millions of small files and large databases.

Millions of Small Files. If the client has millions of small files, then you might need to increase the file cache from the default size. The general rule is that, for every one million files on the Avamar client, the client requires 512 MB of physical RAM. If a client has one million files, then, since there are two 20-byte entries per file, a minimum of 40MB is required just to store all the file hashes for a single backup. Since the file hashes must be stored for several backups, more than this is required.

The file cache doubles in size each time it needs to grow. The current file cache sizes are: 5.5 MB, 11MB, 22MB, 44MB, 88MB, 176MB, 352MB, 704MB and 1,408MB.

This means grow to about 44MB occurs. By default, since 1/8th of the physical RAM of 512MB is used, cache can grow to a limit of 64MB, which means that the default value of 1/8th of RAM for the file cache is adequate.

You must be particularly alert to this situation when configuring a Windows client to back up a large file server (for example, a NAS filer) through a network mount.

Large Databases. If the client has a few large files, then usually the default of 1/16th for the hash cache is insufficient. For example, for a 240GB database, a cache of up to 10 million hashes is required. Since each hash is 20 bytes, a hash cache that is at least 200MB is required, and that can only store the hashes for a single backup.

The hash cache also doubles in size each time it needs to grow. The current hash cache sizes are: 24MB, 48MB, 96MB, 192MB, 384MB, 768MB and 1,536MB.

The next increment available is 384MB. Therefore, if this client has 4 GB of RAM, the hash cache must grow up to 1/8th of the RAM. If the default of 1/16th of the RAM is used, then the hash cache will be limited to 192MB, and an undersized hash cache will result. In the case of databases, since very few files are backed up, the file cache will be considerably smaller, so the net memory use is still about 1/8th to 3/16th of the RAM.



Rules for Tuning the Maximum Cache SizesThe most important rule is to ensure that the caches do not grow so large that the client ends up swapping because it has insufficient physical RAM to handle all the processes.


Never allow the total combined cache sizes to exceed 1/4 of the total available physical RAM.

EMC strongly recommends that you set the maximum file and hash cache sizes to a fraction of the total available physical RAM. In other words, specify the file and hash cache sizes using negative integers. Since you should limit the total cache sizes to roughly 1/4 of the physical RAM, set one of the caches to be -5 (20 percent), and the other cache to be -32 (3 percent). For example, for a large database client:

--filecachemax=-32--hashcachemax=-5

If you are using something other than the default cache sizes, include the customized maximum cache settings in the avtar.cmd file on the client.

In some cases, you might have no choice other than to increase the amount of physical RAM on the client. You might also be able to back up the client using multiple smaller datasets.

If you need to limit the sizes of the caches below the optimum values, then remember the following:

For a typical file server, first allocate the required RAM to the file cache.

For a typical database client, first allocate the required RAM to the hash cache.

Beware If More Than 4 GB of RAM Is NecessaryAny client that requires more than 4 GB of RAM to accommodate an adequately sized file or hash cache may encounter one or more of the following bottlenecks that will prevent the client from backing up reliably every night:

As a general rule, 1 hour of backup window is required to back up a million files. EMC strongly recommends that clients be limited to approximately five million files so that the entire client can be backed up within about 5 hours, on average, or 10 hours, maximum. By default, a client with five million files will require approximately 2.5 GB of RAM.

As a general rule, database data can be scanned at approximately 100GB per hour per client. EMC strongly recommends that the largest database clients be limited to approximately 500GB. In the case of a 500GB database, approximately 30 million hashes must be cached. Since each hash is 20 bytes, there will be approximately 600MB worth of hashes in the hash cache. This means that the hash cache will need to grow to 768MB. If the hashmaxcache is tuned to -5, then approximately 4 GB of RAM is required.



Tuning the File CacheThe following table illustrates how many files can be effectively backed up given that a client has a certain amount of physical RAM and given the filecachemax value:

Tuning the Hash CacheThe following table illustrates how many GB of database data can be effectively backed up given that a client has a certain amount of physical RAM and given the hashcachemax value:

AMOUNT OF PHYSICAL

RAM

DEFAULT FILE CACHE SETTING (-8 OR 1/8 OF

PHYSICAL RAM)

CUSTOM FILE CACHE SETTING (-5 OR 1/5 OF

PHYSICAL RAM)

0.5 GB 1 million files 2 million files



2.0 GB 4 million files 8 million files (over max of 5 million files)

2.5 GB 4 million files 8 million files (over max of 5 million files)

3.0 GB 8 million files (over max of 5 million files)

8 million files (over max of 5 million files)



AMOUNT OF PHYSICAL

RAM

DEFAULT HASH CACHE SETTING (-16 OR 1/16 OF

PHYSICAL RAM)

CUSTOM HASH CACHE SETTING (-5 OR 1/5 OF

PHYSICAL RAM)

0.5 GB 16 GB 64 GB

1.0 GB 32 GB 128 GB

1.5 GB 64 GB 128 GB

2.0 GB 64 GB 256 GB

2.5 GB 64 GB 256 GB

3.0 GB 128 GB 256 GB

3.5 GB 128 GB 256 GB

4.0 GB 128 GB 512 GB (max)

6.0 GB 256 GB 512 GB (max)



Using cacheprefixIf the client does not have enough memory to accommodate the cache files of appropriate sizes, it is still possible to backup the client and get the full benefit of appropriately-sized cache files.

The way to accomplish this is:

• Break the client filesystem into multiple smaller datasets.• For each dataset, ensure that the maximum file and hash caches assign a

unique cacheprefix attribute.

Example: Assume a client has 5.5 million files but only 1.5 GB of RAM, one volume has 2.5 million files and three other volumes have 1 million files each. You can break this client filesystem into four different datasets. For the volume with 2.5 million files, a file cache of at least 100MB (2.5M files x 40 B/file) is required. The next increment that accommodates this is 176MB. The other datasets could be defined as follows:

• C:\ drive (2.5 M files)

filecachemax=200

hashcachemax=-16 (default)

cacheprefix=driveC

• E:\ drive (1.0 M files)

filecachemax=100


cacheprefix=driveE

• F:\ drive (1.0 M files)

filecachemax=100


cacheprefix=driveF

• G:\ drive (1.0 M files)

filecachemax=100


cacheprefix=driveG

Configure cacheprefix in the dataset by setting Attribute = cacheprefix and Attribute Value = driveC.

8.0 GB 256 GB

AMOUNT OF PHYSICAL

RAM

DEFAULT HASH CACHE SETTING (-16 OR 1/16 OF

PHYSICAL RAM)

CUSTOM HASH CACHE SETTING (-5 OR 1/5 OF

PHYSICAL RAM)



The following cache files are located in the Avamar /var directory on the client:

• driveC_f_cache.dat• driveC_p_cache.dat• driveE_f_cache.dat• driveE_p_cache.dat• driveF_f_cache.dat• driveF_p_cache.dat• driveG_f_cache.dat• driveG_p_cache.dat

Ensure adequate disk space is available to accommodate the additional file and hash caches.

When specifying various cacheprefix values, ensure that new cache files are excluded from the backups. The cache files are large and have extremely high change rates.

Customizing Maximum Hash Cache Settings for Exchange and SQL ServerFor an Exchange database backup, configure the maximum hash cache in the dataset definition by setting the following:

• Attribute = hashcachemax

• Attribute Value = 200

For a SQL Server database backup, configure the maximum hash cache in the dataset definition by setting the following:

• Attribute = [avtar]hashcachemax

• Attribute Value = 200

Tuning ReplicatorWork with your EMC Practice Consultant to configure and tune the replicator. The Practice Consultant will perform the following tasks:

1. Compute the bandwidth-delay-product (BDP) to determine whether the BDP is high enough to require customized tuning.

2. Verify that the expected bandwidth is available between the replicator source utility node and the replicator destination data nodes.

3. Test the WAN link with the Avamar system components to verify that the Avamar system can utilize about 60 to 80 percent of the available bandwidth.

4. Set up the appropriate replication parameters to optimize utilization of the available bandwidth.

5. Test the replicator to verify its performance.


UNDERSTANDING DPNSUMMARY REPORTSThis quarterly operations chapter describes usage of the dpnsummary report. As described in Managing Capacity (page 19), the capacity.sh program provides the easiest and fastest way to quickly assess the capacity management performance of the Avamar server. The capacity.sh program is a very effective tool for determining the impact the top change rate clients have on the overall system. For a broader assessment of change rates associated with all clients, use the dpnsummary report.

Use this report to determine how well an Avamar system performs once it has achieved steady state. The Avamar system can generate this report, which can be used to determine:

• Daily change rate for each individual client• Daily change rate across the overall system• High change rate clients contributing the most to overall system change rate• Amount of data being protected per client and across the system• Number of clients being protected• Abnormal client behavior such as:

• Days with unusually high change rates• Unusually long backups• Frequent backup failures

• Amount of data moved across the network with Avamar versus incremental tape backups

• Benefit associated with the combined effect of commonality factoring and compression in contrast to just commonality factoring or just compression

The purpose of this section is to help you understand the information in the dpnsummary report.


UNDERSTANDING DPNSUMMARY REPORTS

Example Dpnsummary EntryThroughout this discussion, the data shown in the following row of an actual dpnsummary report will be used:

Definitions of each dpnsummary column follow. Refer to Background on Backups (page 53) for additional information.

Host. This is the client hostname as defined in DNS. During backups, this is the client that is backing up data to the Avamar server. During restores, this is the client that is receiving the restored data. This is not the client that sourced the data.

StartValue. This is the Unix start time of this activity. The Unix start time is in the local time of the Avamar server.

OS. This is the client operating system.

StartTime. This is the date and time this activity was initiated. The StartTime is in UTC (or GMT).

Root. This is the name of the dataset that was used during the activity, if applicable.

Seconds. This is the duration (in seconds) of the activity.

NumFiles. This is the total number of files scanned during this activity (less those files that were excluded through exclusion rules).

NumModFiles. This is the total number of modified files associated with this activity.

ModReduced. Refer to Background on Backups (page 53).

ModNotSent. Refer to Background on Backups (page 53)

ModSent. Refer to Background on Backups (page 53)



TotalBytes. Refer to Background on Backups (page 53)

PcntCommon. This is the commonality percentage during this activity.

Overhead. This is the number of bytes for COMPOSITEs and DIRELEMs used to store data. It is the amount of nonfile data sent by the client to the server, and includes such things as indexing information, requests from the client to the server for the presence of specific data chunks, ACLs, directory information and message headers. On any relatively active filesystem, this is generally a very small percentage of the file data that is sent to the server.

WorkOrderID. This is the unique identifier for the following activities:

• For scheduled backups, the work order ID is formatted as: <Schedule name>-<Group name>-<Unix time in ms>.

• For on-demand backups initiated from the Policy window Back Up Group Now command, the work order ID is formatted as: <Group name>-<Unix time in ms>.

• For on-demand backups or restores initiated from the Backup and Restore window, the work order ID is formatted as: MOD-<Unix time in ms>.

• For on-demand backups initiated from the Windows Avamar client systray icon, the work order ID is formatted as: COD-<Unix time in ms>.

• For command-line backups or restores, the work order ID is formatted as: NAH-<Unix time in ms>.

• For replication activities, the work order ID is formatted as: COD-NAH-<Unix time in ms>.

ClientVer. This is the Avamar client software version, where the Avamar client is as defined previously under Host.

Operation. Operation is one of the following kinds of activities:

• On-Demand Backup• Scheduled Backup• Restore• Validate• Replication Source• Replication Destination

Status. This is the FINAL status of the client activity (one of the following):

• Activity completed successfully• Activity completed with exceptions• Activity cancelled• Activity failed - timed out before starting• Activity failed - timed out before completion• Activity failed - client was given a workorder but did not acknowledge its

receipt• Activity failed - client error(s)• Activity failed - timed out before completion• Activity failed - client has no data specified by dataset• Dropped Session - No progress reported



SessionID. The SessionID is a unique identifier for the client activity.

Background on BackupsThis section provides background information about how the Avamar client performs backups, including key statistics.

Dataset Size. Begin with the dataset size (TotalBytes - column L) equal to 451,940,965,688 bytes (421 GB). This is the total bytes in the dataset. Any files that are excluded due to exclusion rules are not counted in this total. However, this total includes those open files that could not be backed up, perhaps because the filesystem was not frozen.

Modified Files. When scanning through a filesystem, obtain file metadata and compute the SHA-1 hash of the metadata. Then look up SHA-1 hash in the file cache on the client. If it is present, then opening and reading the files is not necessary. Therefore, a high percentage of hits in the file cache makes the overall backup proceed very quickly.

Any file whose metadata hash gets a miss in the file cache is considered a modified file (that is, a file that was modified since the last backup). Therefore, the Mod bytes in NumModFiles (column H), ModReduced (column I), ModNotSent (column J) and ModSent (column K) is really shorthand for bytes associated with modified files (that is, files you must open and read so that all the data in the file can be chunked, compressed and hashed).

The following image illustrates the roles of the file cache, the hash cache and the server is_present requests in determining which data to send to the server.



ModReduced. When the modified files are backed up, the data is chunked, compressed and then hashed. Since the compression takes place on the client, the amount that the data was compressed is reported as ModReduced. In the example row, the ModReduced = 55,023,086,382 (51 GB).

ModNotSent. If subfile level commonality exists, then the data is not sent. Therefore, ModNotSent is short-hand for bytes in modified files that do not have to be sent to the Avamar server because of subfile-level commonality factoring. In the example row, ModNotSent = 4,115,205,370 (3.8 GB), which means that 3.8 GB of compressed chunks were already on the Avamar server.

ModSent. If new bytes must be sent to the server, then that would be reported as ModSent. In this case, ModSent = 393,498,485 (0.37 GB).



Summary of Key dpnsummary TermsA few relationships between the following terms are:

TotalBytes = (Total bytes in the dataset, including open files that were not backed up) - (Subtotal bytes excluded by exclusion rules)

TotalBytes = (Subtotal bytes for files not modified) + (Subtotal bytes for files modified since previous backup)

(Subtotal bytes for files modified since previous backup) = ModReduced + ModNotSent + ModSent

The relationship between these values is shown in following image.

Definition of CommonalityAvamar change rate is equivalent to the ModSent / TotalBytes.

The Avamar commonality = 1 - (change rate).

Data Moved During Avamar Backup Versus Incremental Tape BackupDuring an incremental tape backup, the amount of data sent across the network (if the backup data was not already compressed on the client) is equal to the Subtotal bytes for files modified since previous backup. The efficiency associated with Avamar's commonality factoring compared to incremental tape backups is:

ModSent / (ModReduced + ModNotSent + ModSent)



On this particular date, the Subtotal bytes for files modified since previous backup = 51 GB + 3.8 GB + 0.37 GB = 55 GB. If this is divided by TotalBytes, the result is 55 / 421 = 13%.

Typically, in day-over-day backups of file servers, this value is expected to be in the 2 percent range.

When backing up databases, since every file is touched every day, expect this value to be 100 percent. Therefore, the total bytes associated with modified files is equal to the total bytes.

Definition of Terms During Restore ActivitiesDuring restore and validate activities, ModReduced is the amount that the data expanded during the restore or validate operation. ModSent is the actual amount of data sent from the Avamar server to the Avamar client during the restore or validate operation. During restore or validate, TotalBytes = ModSent + ModReduced.



PERFORMING A HEALTHCHECKThis quarterly operations chapter focuses on the warning you will receive when the GSAN capacity exceeds 80 percent of the capacity threshold. It is important that you perform the following operational best practice when you receive the Avamar capacity warning.


Contact EMC Technical Support, which will log in to the system and assess the overall health and performance of the system.

OTHER AVAMAR ADMINISTRATION BEST PRACTICESThis planning, design and implementation chapter contains information about the following various administrative operational best practices:

• Passwords• Internet and firewalls• Email home

Protecting Your Avamar ServerEMC recommends that an Avamar server be deployed in a protected network and not exposed to the Internet. Even when an Avamar server is deployed in an internal network, EMC recommends that it be protected by a firewall to prevent unauthorized access to the nodes that compose the server.


Protect the Avamar server from the Internet by providing full firewall protection.

Changing PasswordsIf your Avamar passwords have not changed from the factory default values, EMC strongly recommends that you change them by running the change-passwords utility. Refer to your Avamar System Administration Manual for additional information.

There are three operating system users, two SSH keys and two root-level software application users. You must change the passwords for all of these users. Simply changing the passwords for the operating system users is not sufficient to prevent someone from logging in to the Avamar server nodes. If you have not changed the two SSH keys, then it is possible for someone to use the factory-default SSH keys to log in to your Avamar server.


Enabling the Email Home FeatureOTHER AVAMAR ADMINISTRATION BEST PRACTICES


Change all factory-default passwords.

Enabling the Email Home FeatureWhen fully configured and enabled, the email home feature automatically emails the following information to EMC Technical Support twice daily:

• Status of the daily data integrity check• Selected Avamar server warnings and information messages• Any Avamar server errors• Selected hardware errors, if correctly configured

EMC strongly recommends that you enable this feature on your servers. Refer to your Avamar System Administration Manual for additional information.

The email home capability is offered as part of the server maintenance plan. However, it is offered with the following understanding:

1. There is no guaranteed service level agreement for monitoring the email home messages. The customer must assume primary responsibility for monitoring the Avamar systems.

2. EMC Technical Support monitors the email home messages twice a day: once at 6 A.M. Pacific Time and again at 3 P.M. Pacific Time. Email home messages are monitored only during standard business days (Mondays through Fridays). Messages concerning issues that arise over the weekend will not be monitored. Review of email home messages from Monday through Friday is done ONLY as a courtesy; therefore, no guarantee is implied that all issues will be noticed.

3. When EMC Technical Support reviews email home messages, only cases for issues that affect the backup infrastructure (Avamar server) will be opened (for instance, failed hfscheck). Cases are not opened for issues associated with backup operations (for instance, failed backups).

4. If email home messages are not being sent home, EMC Technical Support does not proactively alert customers of an issue that is causing the email home messages not to be sent. This could be because the server is down, because the scheduler has been disabled and so forth.


Enable the email home capability.


Assigning UsersOTHER AVAMAR ADMINISTRATION BEST PRACTICES

Assigning UsersThe Avamar software includes access audit logging capability. The broad intent of this feature is to maintain a log of every action taken on vital system components/objects.

The data in this log enable enterprises deploying Avamar to do the following:

• Enforce security policies• Follow up on security breaches or deviations from policies• Hold appropriate users accountable for those actions

To fully leverage the audit logging capability, follow these recommended best practices:

Assign each Avamar administrator, operator or user a unique login credential, and ensure that all users log in to the Avamar system using those unique login credentials rather than the default Avamar application root and MCUser users.

Work with your EMC Practice Consultant or EMC Technical Support Engineer to set up External Authentication so that all Avamar administrators, operators and users can log in to the Avamar server with Active Directory, LDAP or NIS login credentials.


Documents

EMC AVAMAR - Dell EMC Isilon · Typeface Conventions The following table provides examples of standard typeface styles used in this publication to convey various kinds of information