Highlighted
tmotto
1 Copper

Avamar Update/Migration

Jump to solution

Hello All, looking for some input from anyone that can help give me some answers to some questions..

We have an Avamar 7.3.0 on site, with vCenter 5.5, we are looking to update vCenter to at least 6.0 with latest update, we'd like to go higher but we know avamar is a problem for this.

What is the highest vCenter 6.0 release we can run with 7.3.0, I know there is a compatibility site, but it isn't loading for me and I get an error that the page can't be reached. So I'm hoping someone here are ran across that information.

We are also looking to update to Dell IDPA (which from what we have been told basically runs Avamar on the back-end). Has anyone heard or seen evidence or documentation that the backups in the older Avamar can be migrated to IDPA?

0 Kudos
1 Solution

Accepted Solutions
ionthegeek
4 Beryllium

Re: Avamar Update/Migration

Jump to solution

According to the online compatibility guide at CompGuideApp, 6.0U3 is the highest version of vSphere supported by Avamar 7.3.

Frankly, I'd recommend moving to 7.4.1 or 7.5.1 if you can. We've never been comfortable designating target code for the 7.3 release. Avamar 7.4.1 supports up to vSphere 6.5U2 and Avamar 7.5.1 supports vSphere 6.7.

I'm not sure what you're looking for in the way of evidence but IDPA comes in a variety of configurations that include physical or virtual Avamar integrated with Data Domain. If your existing Avamar is DD integrated, migrating to IDPA should be relatively painless. If you're not currently using DD integration, older backups would have to be migrated from Avamar (GSAN) storage to DD storage if you wanted to retain them. GSAN to DD migration tends to be more involved and take more time.

One caveat we've run into in the field is that older VM backups written in "capacity" chunking mode and new backups created in "performance" chunking mode do not deduplicate against each other very well. This can lead to an unexpected capacity utilization increase on Data Domain if older backups are migrated and newer backups are allowed to run in "performance" mode.

There are a few ways we've dealt with this in the past:

  1. Migrate the older backups but size the solution to accommodate both sets of backups until the older backups can age out. This solution is most reasonable if your retention isn't too long and you expect significant data growth.
  2. Only use the new system for new backups. Leave the older backups on the old system to age out. This is a good solution if you don't mind leaving the old system around and your retention isn't too long.
  3. Change the configuration of the new system to use "capacity" chunking mode before creating any new backups. This is a better solution if you have long retention and need to keep the older backups around.
0 Kudos
4 Replies
ionthegeek
4 Beryllium

Re: Avamar Update/Migration

Jump to solution

According to the online compatibility guide at CompGuideApp, 6.0U3 is the highest version of vSphere supported by Avamar 7.3.

Frankly, I'd recommend moving to 7.4.1 or 7.5.1 if you can. We've never been comfortable designating target code for the 7.3 release. Avamar 7.4.1 supports up to vSphere 6.5U2 and Avamar 7.5.1 supports vSphere 6.7.

I'm not sure what you're looking for in the way of evidence but IDPA comes in a variety of configurations that include physical or virtual Avamar integrated with Data Domain. If your existing Avamar is DD integrated, migrating to IDPA should be relatively painless. If you're not currently using DD integration, older backups would have to be migrated from Avamar (GSAN) storage to DD storage if you wanted to retain them. GSAN to DD migration tends to be more involved and take more time.

One caveat we've run into in the field is that older VM backups written in "capacity" chunking mode and new backups created in "performance" chunking mode do not deduplicate against each other very well. This can lead to an unexpected capacity utilization increase on Data Domain if older backups are migrated and newer backups are allowed to run in "performance" mode.

There are a few ways we've dealt with this in the past:

  1. Migrate the older backups but size the solution to accommodate both sets of backups until the older backups can age out. This solution is most reasonable if your retention isn't too long and you expect significant data growth.
  2. Only use the new system for new backups. Leave the older backups on the old system to age out. This is a good solution if you don't mind leaving the old system around and your retention isn't too long.
  3. Change the configuration of the new system to use "capacity" chunking mode before creating any new backups. This is a better solution if you have long retention and need to keep the older backups around.
0 Kudos
tmotto
1 Copper

Re: Avamar Update/Migration

Jump to solution

That is a perfect response, Thank you!!

Agreed, we were finally able to load up the compatibility guide yesterday and were able to verify the firmware to vCenter ability. From what I'm told we attempted a vCenter 6.0 U3 update in the past and Avamar wouldn't play nice with vCenter. Backup restores wouldn't even start, and new backups taken would be nothing but gibberish (nonsense data\corrupt). So vCenter was rolled back to what was working before and wasn't touched again. But we would like to take it to 7.5.1 to gain vCenter software support, do you know if it's possible to go straight from 7.3.0 to .7.5.1 with no jumps?

We are just looking for conformation of what we believe from what we have read, and been told in sorts from inquires asked to sales teams and what not. From what I have looked at we don't have DD (Data Domain), status reports comes back as "No Data Domain systems". We just want to confirm that the old backup data can migrate and still be restored from the new system is mainly it. In terms of retention, we do have a policy that requires 7 years worth of backups. Due to that, we'd have to keep the old data. The other part of the problem is that the older Avamar system is out of space, which is where the idea of moving to the iDPA came in. Not only that, but its also less rack space required, currently we have over half a rack dedicated to Avamar.

This does give us more information than we had, and we can discuses even more. Any more feedback you can think of would be more than welcomed!

0 Kudos
ionthegeek
4 Beryllium

Re: Avamar Update/Migration

Jump to solution

My pleasure!

Direct upgrades from 7.3.0 to 7.5.1 have been qualified and are supported.

For a migration from a legacy Avamar system using GSAN storage to an IDPA system, ADMe is probably your best bet at this time. For any migration, there will be limitations in terms of the amount of data that it's practical to migrate. Most customers running ADMe migrations only migrate their monthly and yearly backups, for example.

I'll also throw out a mention to Adam Kirkpatrick since he's Mr. ADMe and may have comments to add..

tmotto
1 Copper

Re: Avamar Update/Migration

Jump to solution

Awesome! Thank you again, if any more questions come up from our internal review I will respond to this thread.

0 Kudos