Ask the Expert: Avamar Server management best practices

Fantastic - thank you.  I actually use a Linked Server in our SQL Server 2008 instance; it works fairly well.

One more question - we have about 10 servers of 300 that essentially account for 60-70% of our GRID.  All of these are Oracle database servers.  We've tried both Avamar RMAN backups as well filesystem plugin backups of Oracle backups created by the DBAs.  In either case, it nets about 10-20% new data a day and subsequently, 40-50GB per host a day in some cases.  As such, we've been growing since July of last year.  Is there anything we can do about this?  Is that normal behavior?  We do not have these problems with our SQL Servers.

My pleasure! One thing to be aware of is that the Administrator Server database is pruned periodically so you may want to make a replica if you need to preserve activities data more than a year old.

It sounds like the daily change rate on these particular database clients may be quite high. If that's the case, this is expected behaviour. If the Avamar client detects changes to the data, it really has no choice but to back those changes up.

Adding more storage nodes to a system will always help if there are high change rate clients. As the capacity utilization on the Avamar Server increases, the change rate starts to have more of an impact on the system because we have to change more data container files (called "stripes" in Avamar) to back up the same amount of data.

You may want to look into moving these high change rate clients over to Data Domain on the back-end if you can. Both back-ends (Avamar Server and Data Domain) have their strengths and weaknesses and one of Data Domain's strengths is dealing with high change rate database clients.

If you decide to go the Data Domain route, Avamar / Data Domain integration supports Oracle RMAN backups (though I've been warned by one of our Oracle Subject Matter Experts that it works on HPUX on Itanium but not on HPUX on RISC, so watch for that). There is also a known issue with Avamar / Data Domain integration in versions prior to 6.0.1-66 that can cause data loss, so if you will be using the integration be sure to have your system upgraded and fully patched before moving any clients over.

Alternatively, if you have other backup software in your environment (e.g. NetWorker), the clients could be migrated to Data Domain that way.

Hi Anderson

Can you give us the best and good timings for replication to start on Avamar server side we do have domains and backing up on Avamar by 10PM and can we divide our replication with in our domains like

Avamar server -Windows-Windows2k,W2k3, 2k8

Windows- W2k domain at 10PM and  Windows-w2k3,2k8 12PM can we do that ?

I Know we can replicate the clients data to different servers but can we replicate this servers to same target.

Please let me Know

thank you.

Generally speaking, you should configure replication to start no earlier than two hours after most of your backups have started. On typical systems, more than 75% of the backups complete within the first two hours meaning the latest backup for those clients will be replicated. You could delay further to catch more backups in the replication.

Current recommended practice is to use a single replication configuration for ease of management. It is possible to set up multiple replication jobs but this quickly becomes difficult to manage. There are improvements to this area of the product coming in a future release.

Hello,

I have a question regarding AVE and DD as backup device.

We have a large VMware environment (about 1400 VMS (each about 90GB in size) on 2 clusters) and want to backup them with Avamar.

We decided to try this with one 2TB AVE per cluster which is using two existing DD860 systems as backup device in the first step. So my question is about the AVE limitations ( > 20GB per day change rate should go to an physical device). Do this limitatons apply here too?

I mean only the metadata is written to the AVE, the datastream is directly from the proxys to the DD over boost. So in my opinion this should work, but I am not sure? The performance of the ESX Hosts shoudl not be the problem, we have about 20 hosts per cluster and the DD is attached over 10Gbit.

Any hints for that?

Hi ianderson,

thanks for your answer.

The limitation still applies but in the case of DD integration, it would only be the backup metadata that is subject to this restriction. It is unlikely that you would have problems with the Avamar change rate in a DD integration scenario since the overall amount of metadata is normally quite small.

This type of setup with a small AVE for metadata and a large DD device for backup data is becoming a reasonably common configuration.

My pleasure!

Hi,

In this summary https://community.emc.com/docs/DOC-16121  

we can read "For initial backups...allow the client to time out daily and rely on partial backups"

This link refers to this discussion, but I cannot find any reference to this option to time out daily a backup and then rely on partial backup.

It could be a perfect solution for our client, which are backuped through low speed connection.

For example, we backup the vmdk file from a windows SBS with vmware image plugin. It take a more than a day.

and to avoid to disturb our customer, it will be a great solution to pause the backup in the morning, then resume it in the evening. As vmware image backup  use a snapshot, it should be possible.

Is this possible?

This isn't an option, exactly. If a file system backup times out when the backup window ends, it will "wrap up" the progress so far and create a "partial" backup that will be retained for 7 days.

Unfortunately you can't do this with most plug-in backups (including VMware image backups) since they generally don't create partial backups in this way.

Thanks Ianderson.

So may be a solution for me, is :

- in first step, doing a full file system backup of C: from this SBS server through the client installed on it.

In this case, it will create a partial backup then rely on until it succeed to make a full backup.

- and then right after to run a vmware image backup of the vmdk corresponding to the C: of this virtual SBS server.

What do you think about this idea?

And is there a way to schedule and run the vmware image backup only if the file system backup is completed?

I don't think this will do what you want it to do.

The commonality between a VMware image backup and a regular file system backup is typically low because an image backup is backing up a representation of the physical filesystem, where a client backup is looking at a logical view of the filesystem. Completing a file level backup is unlikely to improve performance of an image level backup and vice-versa.

Also, please note that SBS is not a supported platform for guest level backups. As I always say, "not supported" doesn't necessarily mean "doesn't work" but you won't be able to get help from the support team for guest level backup issues on SBS.

If you need help improving the performance of the image level backup, it may be helpful to open a service request.

Why is it when you register a physical server it comes in FQDN but when importing a VM it comes in short?

Ian,

Just started a new role,

- Avamar is my new resp, what should I check/do first to get everyth under control in the Avamar env?

I determined that data that is being backed up is about 7TB, and it is being replicated from VNX5500 to itself.

- After reading everything on this forum, I concluded that DPN report is to place to start to check if everything is going as it should?

- What are the first steps you would take to assess the backup environment overall, to make sure to get things under control?

I am currently catching up by reading everything related Avamar. I know how to add/remove clients, modify backup jobs and create/delete backup schedules, thats about all.

- What else would you recommend to read/watch to catch up on everything related to Avamar administration?

Thank you for doing an awesome job btw, I already learn so much by reading these 4 pages of this thread. Keep it up Ian.