Avamar Configuration Design Best Practices

When configuring Avamar clients, the first place to begin is to check all documentation to ensure that all OS and applications are supported.  Secondly, make sure the RTO is achievable and realistic.  If it is neither, consider locating an Avamar server local to the client.

Keep your Avamar system as simple as possible.  Limit domains to situations where administrative duties must be divided, as well as groups and policies.  Policies should be planned well in advance with a simple solution fitting today's need being the best route to take.  Also remember to leave the default group disabled.

It's best practice to use a single data set for Windows, Solaris, Linux, etc.  The data will be skipped if it doesn't match, and it will keep policies to a minimum.  Retention policies should always be at least 14 days, and implement advance retention policies with daily scheduled backup.  Make sure your backup jobs all complete within the backup window and not during blackout or maintenance windows, and after the initial backup be sure to set the expectations with customers and monitor backup for anomalies.  Backup may need to be adjusted if daily change rates are not what were expected, or other factors may be causing differences. 

There are recommended limitations on Avamar clients, and if outside these it may be best to find alternate solutions:

• 5-10 million files per Avamar client
• 0.5-2 TB of database data per Avamar client
• 2-5 TB of file data per Avamar client

When backing up remote clients, RTO is the primary consideration.  Be sure to understand what kind of WAN connectivity exists and how it's being used already before introducing backup traffic.  It's best practice to keep Exchange on the local segment where the Avamar is located, and always be aware of what is being backed up to where.  It may be best to use a centralized Avamar server where administrative resources don't exist at a remote location, or if large multi-node Avamar servers are required at a remote location the cost may be prohibitive.  Best practice states that we use a centralized server unless RTO can not be met.

Keep clients within the same time zone on the same Avamar server, and be cautious of crossing regions so as not to interfere with blackout and maintenance windows.  This principle goes for replication as well.  EMC technical support can modify those windows in cases where there is a requirement.

When backing up desktops and laptops, exclude common data such as OS and application files.  Using the flag #USERDOCS# for Windows systems will backup up the user folder form multiple Windows versions.  Schedule DLO for a time when you know all systems will be online but under-utilized, such as lunch time, and minimize the include/exclude lists for efficiency.

Training users about the backup is also important, and they should know how and why to perform an on-demand backup, and set the Avamar to reject backup requests during the maintenance window to keep things running smoothly.  Multiple backup schedules can also be configured as selectable by the end users to determine which is best for their need, and reminders can be sent along with the ability to suspend or pause them if needed.

For initial backup of Avamar clients, it's best to start with a small number of clients to produce a dataset from which commonality will be generated.  This will increase the backup speed of following clients.  On a new Avamar system, consider enabling overtime because all the data is new and there won't be much maintenance to take place.  Never enable overtime on an existing Avamar, rather configure the use of partial backups to be saved.  Partial backups are saved for 7 days and are not deleted by the garbage collection process.  When an unfinished job ends before completing and partial backups are enabled, the backup job will continue from the last known state and will complete faster.

For a large number of clients, start in small groups.  It's recommended to start at ten times the number of Avamar Storage Nodes, and then double it each day as long as the backup is completing within the backup window.  Reduce the number of clients if the backup window is not being met.  Also consider using the Avamar Client Manager to roll out clients.

When initializing remote clients, the main issue to be concerned about is network outage.  It may be best to seed backup over the LAN or to a USB drive.  To seed to USB, the data is copied to removable media and then attached to an Avamar client local to the Avamar server.  A backup is performed on that local client, and once the data is introduced into the system it will not be duplicated over the WAN.

When initializing clients, large backup may time out at the end of the schedule or at the end of the backup window.  To avoid this, configure partial backup to be kept, and run backup daily - at least to begin.  This way the backup will rapidly complete after which a desired schedule will have commonality and complete faster.  Also run multiple, shorter backup and disable overtime to get partial backup.  If the initial backup is taking too long, check to make sure the cache files are sized appropriately or seed the backup.

The avtar process requires 20-30 MB of memory depending on OS, and client cache files are loaded into memory and grow to a configured max.  The file cache (f_cache) will grow to 1/8 of physical RAM, and the hash cache (p_cache) will grow to 1/16 physical RAM.  The size of the cache files is recorded at start and end of the avtar log for monitoring and tuning assistance.