This post is more than 5 years old
38 Posts
0
1034
July 14th, 2015 08:00
Selective root to root?
For various reasons we have the need to migrate from our present Avamar grid to a new one that is slightly smaller. So we cannot perform a full traditional root to root migration. What we'd like to do is migrate the configuration and only the historical backups for each domain. Certain domains have very small retention windows and therefore will be allowed to "die on the vine" and all new backups will be redirected to the new system.
Looking for some advice on best way forward given our situation.
No Events found!
ionthegeek
2 Intern
•
2K Posts
1
July 14th, 2015 09:00
There are some potential pitfalls here that I hope your account team has considered.
The main one is that you can't mix and match node sizes so, for example, a 7.8TB node grid can only be expanded using 7.8TB nodes. It's not possible to add 3.3TB or 3.9TB nodes to 7.8TB node grids.
A more subtle potential issue is that mixed Gen4 / Gen4S grids cannot be expanded using Gen4 nodes. Only Gen4S nodes may be added to a mixed Gen4 and Gen4S grid.
Those two caveats out of the way, this type of migration is possible. I would recommend working with professional services on this because the implementation can be tricky and it's easy to make a mistake.
Important: The information I've given below is a general outline only. It assumes a certain level of familiarity with Avamar migrations. If things go really wrong during a migration like this, it could take days or weeks to correct the problem. People who are not 100% comfortable with all the steps in a typical Avamar migration should NOT attempt this on their own.
The basic process is:
The replication(s) in step 4 can get more dicey if you have to selectively replicate clients within a domain since the exclude rules are somewhat unintuitive. It sounds like you'll be operating on whole domains so this may not be an issue for you.
Do not use full client paths (e.g. /clients/domain1/myclient.example.com) in the srcpath or dstpath. Specifying clients in the srcpath or dstpath will trigger account-to-account replication and this replication mode does not guarantee that client IDs will be preserved. Client ID mismatches can be a nightmare to clean up after, especially if there are a lot of clients affected.
I hope this helps.
nixonm
38 Posts
0
July 14th, 2015 08:00
I forgot to mention that our end state avamar after migration cutover will use kickstarted nodes from the old grid to be grown larger than the original source.
nixonm
38 Posts
0
July 14th, 2015 08:00
Avamar source version is 6.1.2-46
ionthegeek
2 Intern
•
2K Posts
0
July 14th, 2015 09:00
My pleasure!
That's reasonable. Once the MCS restore has been completed, the timing of when you cut the clients over is really up to you.
For something like a DTLT client, the impact of running a new initial might be relatively low. For very large clients that will take a long time to replicate, it might make sense to replicate the most recent day's backups using --before, --after, --count, etc., then cut the client over. For other clients, it might make sense to replicate all their backups in one shot. The right approach is the one that works best for you.
nixonm
38 Posts
0
July 14th, 2015 09:00
thank you very much for the reply Ian
We know we can't mix node sizes. All nodes are the same size. We are also aware of the pitfalls of mixed GEN grids. Our intention is to use only the GEN4s nodes we own in the source grid in the new one.
A question about the steps you listed however.
I would think we'd want to complete most of step 4 prior to cutting clients over, especially since this is a hosting grid with clients spread all over the geography and the last thing we'd want to do is accidentally force a new initial full.
nixonm
38 Posts
0
July 14th, 2015 09:00
Agreed we'll have to find the best approach. The idea is to cutover using the old name so everything is going to happen at once. We've done this a few times before with minimal issues, this is the first time we'll be doing it with a temporarily smaller grid so we are going to have to use a few filters to replicate only the necessary backups to ensure as little disruption and let most of them die on the vine since the retentions on most are so short. 2 weeks or less.