Avamar Performance Consderations

The typical Avamar life cycle tells us that the initial deduplication rate for non-structured (file system) data is going to be about 70%, while structured data (databases) is going to be about 35%.  There is little garbage collection and the data is mostly unique.

Once we hit the retention period, the Avamar goes into a "steady state" where the amount of new, unique data coming in is the same or less than the amount of data being aged off.  For file data, daily change rate averages 0.3% and database daily change rate averages 3-5%.  Once steady-state is achieved, garbage collection will clean up about 10GB per node, per day.

Ingest performance can be negatively impacted if the nodes don't meet the minimum sequential read, write and random read seek performance requirements.  A less-utilized Avamar server will also perform up to 50% faster than a grid reaching capacity.  A short backup of 1-2 GB new data will backup slightly faster than large backups, and a larger chunk size will also be faster.  As with everything Avamar, doing anything during the maintenance window will decrease performance significantly.

Backup performance has several factors to consider as well, starting with inappropriately sized file and hash caches (tuning of caches will come in a later post).  A client requires sufficient CPU and disk I/O resources, and x86 processors will typically backup faster than SPARC or PPC due to the fact that x86 are typically faster CPUs with less cores than the others. 

Backing up multiple VMs on the same ESX host could cause a performance hit, and it's better to spread VM backup across several hosts if possible.  Network performance and configuration will also come into play, so make sure to match speed and duplex and measure WAN latency.  Similarly, a 100MB connection may be adequate for Avamar backup after initial backup, but may not perform well enough for the initial backup.  Seed systems when possible over more robust connections.

Restore actions will need to be read from the Avamar server, sent to the client and ordered in client memory, uncompressed and finally written to disk.  Therefore, read rate from the Avamar server, network performance and write rate on the client will all be factors.  Use the Avamar Validate function, which is a utility that performs a test restore without writing any data.

When restoring data, several small files will restore slower than a few large files, and again - if the maintenance functions are running the restore will be impacted by up to 70%.  Restoring from multiple nodes of the Avamar grid will be considerably faster than if restoring through a single node, and you can use the "all nodes" option in avtar to set this as the restore method.  The 2nd restore will also go faster than the first because there is data in cache from which we can obtain commonality.

Client restores will have similar limitations, in that file size, number of files, client resources, network and encryption will all be factors.

When replicating data, we're essentially doing an "all node" restore from the data nodes of the source to the utility node of the destination, then backing up the source utility node to the replication target.  WAN can be tuned to 60-80% of available bandwidth, and is almost always the issue with replication.  Start there.