Avamar Backup Rates

Hi Karl

Initially, you have to consider that image level backup will backup the VM disk (the VMDK file) therefore for the size of the file to backup this will be the provisioned space that you need to take into account.

Now there are a lot of backup optimisation in Avamar for image level backups such as change block tracking and other tweaks.

But they only start to take effect from the second backup onward.

The initial backup remains a full backup that will scan and backup the whole VMDK, it is expected to take a significantly longer than any subsequent backup.

Thank you for the response, but I'm really looking for some numbers on what people are getting.  As my initial thread noted, this is not just for VM backups; rather it is across our environment.  Also, how can Avamar backup empty space?  If a VM has 4TB provisioned but only using 1TB, how can it "read" empty space and why would it take so long to read a bunch of 0's?

Just to clarify a few things:

• We do not read blocks of zeros beyond the allocated extents of a VMDK. We still need to include them in the backup but they are synthesized by the plug-in which is significantly faster than reading them from disk.
• Large contiguous sections of zeros will be processed into identical chunks / segments. Generally, only the first copy of the "all zero" chunk needs to be sent across the wire since we will get cache hits or successful hash / fingerprint lookups for subsequent copies. The main exception to this is in Data Domain environments where the software sometimes intentionally sends duplicate segments to improve the spatial locality of the data on disk but this is generally a very small percentage of data.

In VM backup we read the VMDK like a physical device so we do not backup the files in it, we are reading the blocks like you would read sectors in a hard drive. So even if they are at "0" they are still present (except if the VMDK is thin provisioned) and still backed up.

now if you look at the best practice guide: https://support.emc.com/docu69642_Avamar-7.3-Operational-Best-Practices.pdf?language=en_US ( here Avamar 7.3 but this is the same on all the Avamar) on page 53

A typical backup should take about one hour for every million files in a file server or about one hour for every 100 GB of data in a database server.

Consider a VM to be similar to a database are we are backing up data block and not files

To be noted those are typical conservative performances on backup after the initial backup is taken, as mentioned the initial backup will be slower.

I advise you to onboard clients by wave and observe subsequent backup performance ( the initial backup will be slow as you have to send all the data, even if the data are block of zeros) and for VM please make sure that the change block tracking is activated as it will have a dramatic effect on performance

https://support.emc.com/docu69641_Avamar-7.3-for-VMware-User-Guide.pdf?language=en_US

Jerome

We have tested with our all flash array (XIO) and our main production array (VMAX).  The datastores are enterprise class and certainly capable of far greater throughput.  Additionally, we have only backed up 1 VM at a time and getting this throughput.  We have TSM currently backing up our data and in some cases it has been 10x faster. 

Is there a community forum where I could get some real life numbers from Avamar users?  I really would like to see what people are getting in the present day. 

If you need an analysis of the bottleneck in your environment, I would strongly urge you to work with support. Without making a deep dive into your environment and configuration, we can only speak in generalities, we can't give you any specific, useful advice on this forum.

This is certainly the right place to ask if you're looking for input from other Avamar users.

Understand - we do have tickets open with every vendor looking into this (Cisco NXOS, Cisco UCS, and EMC) - I really just wanted to get some empirical data from the community on what they are seeing for throughput.  Thank you all for your responses.

- Karl