Welcome to the EMC Support Community Ask the Expert Conversation. On this occasion we will be covering EMC Avamar server, capacity and replication. Among the many areas will be discussing, our experts will answer your questions in regards to best practices, supported configurations and issues.
This discussion takes place from Sept. 5th - 16th. Get ready by bookmarking this page or signing up for e-mail notifications.
|FOLLOW THE ASK THE EXPERT COMMUNITY ON ECN|
Meet Your Expert:
Senior Solutions Recovery Engineer
Leo has been working with Avamar for 9 years. During this time he has focused on different aspects of Avamar, server, capacity, replication and clients. He also delivers training to new hires and level 2.
|INTERESTED ON A PARTICULAR TOPIC? SUBMIT IT TO US.|
Share this event on Twitter or LinkedIn:
>> Ask the Expert: Avamar Server, Capacity and Replication http://bit.ly/2bGvPtK <<
great to have this discussion open.
Regrading AV/DD installations. Is it best practice to use link aggregation (i.e. lacp) on the DD or DDBoost interface groups on single physical network ports?
Is there any best practice how to setup replication in a AV/DD environment?
I made the experience that the replication traffic is routed over the management network . Or in other words the network port(s) to which the Hostname of the DD is pinned and not the interface group network cards.
Although when I make static routes it don´t work at a customer.
Avamar replicates backups on DataDomain via MFR (Managed File Replication). If you are trying to setup interface groups for MFR, please reference the document below:
In Avamar architecture, metadata are an important part of the capacity. And sometimes we have to format the grid or ASN (to add DD for exemple) because there is too much metadata.
For customer this operation is disruptive and could lost old backups because he have not enough space.
Could you tell us if in the future we can clean metadata or expand its space?
In most cases, it is not the metadata container which occupies most space but the data container.
Within the GSAN, there are two primary types of containers for storing data: metadata containers and data containers.
◆ Metadata containers store the metadata for backups.
◆ Data containers store the actual backup data.
Both types of containers are created as required, based on the data that is being backed up.
Metadata can only be written to metadata containers. In addition, after the Avamar server creates containers, you cannot remove them. To illustrate how this process affects metadata capacity, consider the following scenario:
A customer uses an Avamar server as the target for backups. The customer is close to reaching full capacity on the Avamar server, and thus purchases a Data Domain system to provide additional capacity for backups. The customer then decides to transition existing backup workloads to the Data Domain system. Doing so results in a decrease in the amount of GSAN capacity used on the Avamar server. The customer then begins adding new backup workloads that require significant metadata capacity to the Data Domain system. The space freed in the data containers cannot store new metadata for the additional backup workloads. New metadata containers must be created for new workloads that require substantial metadata storage (for example, file system backups with lots of files).
The Avamar server must have sufficient disk space available to create new metadata containers. If the server has already allocated data containers, the disk space might be insufficient for creating new metadata containers.
For more information, please reference the following document:
What kind of impact can a WAN optimization device like RiverBed have on Replication between Avamar--Data Domain pair?.