Configuring Avamar with a daily root-to-root replication for DR purposes isn't actually a standard supported configuration which is why you won't find a customer accessible document which completely describes how to configure it. If you're interested in this kind of configuration it requires special qualification and approval by the engineering team (also known as an RPQ) which you can request through your local account team. This would require the local EMC team to work with you to implement the solution.
Bear in mind that using standard / to /REPLICATE replication the Avamar internal databases can be replicated to provide a full copy of data on the target which can also used for full DR purposes. This doesn't require any special 'engineering approval' and is much easier to set up and manage (all documented in the standard admin guide) and is fully supported.
The main advantage of root to root style DR config would be improved 'Time to Recovery' since the clients can be re-pointed at the target via DNS without needing to be re-activated against it.
thanks so much for your prompt response. As I could read around, this approach seems more appropriate for migration purposes. So, maybe there is something we're missing and you can help me get my head around this.
With root-to-replicate, restoring from site2 is easy and we just do redirected restore. Now, say we're in a DR situation where site1 is down for an extended period of time. My clients will need to keep backing up so I will have to register them with site2. Backing up to site2 is going to start full backups right? If I understand well, it's like a new client for site2. So all the clients will have to send full backups. Now, site1 comes back. I can replicate site2 to site1 but it will go into site1/replicate.
Meaning, when I point my clients again back to site1 and if I need to restore a file that was backed up during the DR period, then I need to use either site2 directly or site1/replicate. If all of this is correct, that's the reason why we thought we don't want to have to maintain 2 "databases" for the same clients. Plus, sending full backups during DR is not gonna work for us, we have a whole lot of data coming from VNX filers ... long NDMP backups ... not exactly what we want.
So, please tell me if we're missing something or we don't understand properly the root-to-replicate solution.
That definitely gives me some new ideas! Thanks so much. Indeed, we've been debating the active-active (which was our first intention) versus active-passive grid and that's why we wanted to give it a shot. I will try to do what you're suggesting with EM. Do I need to wipe everything out though from my policy-based replication?
Also, say I'd be able to export/import the group configurations ...etc., when in DR situation, the first client backup would still be a full right? And I would still have 2 separate databases (site1 for regular time, site2 during DR) right?
The reason you can't add the fullcopy now, is because the policy based replication is different to the one configured in the enterprise manager replication.
I have done root to root replications with a daily upgrade, and also performed the disaster recovery with it.
You just have to replicate root to root using the enterprise manager configuration and adding the --fullcopy to the parameters.... the problem with this type of replication, is that you will have a passive grid, that means you can only use it when you do a disaster recovery. and most of costumers will not like this idea.
Another way to do, is, you already have all the backups in the other site, so you just need to tranfer all the configuration to this secondary site.
its kind of tricky but just create the domains in the secondary site, and export and import the groups configurations. in that case you have 2 avamar grids with the same policys, so you can move the clients when needed with the client manager.
Backing up to site2 is going to start full backups right? If I understand well, it's like a new client for site2. So all the clients will have to send full backups.
This is not true. Assuming replication is up to date, backups will pick up right where they left off once the client is activated to the site2 server.
Every backup has a unique identifier called a root hash. This root hash is calculated from the contents of the backup, so when backups are replicated, the root hash is preserved on the replication target. When a new backup starts, the client asks the server if the root hashes for any of the 16 most recent backups are present. If they are, we know the cache data associated with these backups is valid so we don't have to re-send the data because we know it's already on the server.
Well that's one piece I was missing! In that case, that changes everything. Switching back and forth between the 2 sites, is then just a matter of re-activating the clients at DR. I can manually configure my domains, export/import groups to be ready and that should work. Thanks so much Ian and everyone, that looks much better than what we were intending to do.
Avamar Exorcist
462 Posts
1
November 7th, 2014 02:00
Hi Ergosphere,
Configuring Avamar with a daily root-to-root replication for DR purposes isn't actually a standard supported configuration which is why you won't find a customer accessible document which completely describes how to configure it. If you're interested in this kind of configuration it requires special qualification and approval by the engineering team (also known as an RPQ) which you can request through your local account team. This would require the local EMC team to work with you to implement the solution.
Bear in mind that using standard / to /REPLICATE replication the Avamar internal databases can be replicated to provide a full copy of data on the target which can also used for full DR purposes. This doesn't require any special 'engineering approval' and is much easier to set up and manage (all documented in the standard admin guide) and is fully supported.
The main advantage of root to root style DR config would be improved 'Time to Recovery' since the clients can be re-pointed at the target via DNS without needing to be re-activated against it.
Hope that helps,
Nick
Ergosphere
13 Posts
0
November 7th, 2014 06:00
Hi Nick,
thanks so much for your prompt response. As I could read around, this approach seems more appropriate for migration purposes. So, maybe there is something we're missing and you can help me get my head around this.
With root-to-replicate, restoring from site2 is easy and we just do redirected restore. Now, say we're in a DR situation where site1 is down for an extended period of time. My clients will need to keep backing up so I will have to register them with site2. Backing up to site2 is going to start full backups right? If I understand well, it's like a new client for site2. So all the clients will have to send full backups. Now, site1 comes back. I can replicate site2 to site1 but it will go into site1/replicate.
Meaning, when I point my clients again back to site1 and if I need to restore a file that was backed up during the DR period, then I need to use either site2 directly or site1/replicate. If all of this is correct, that's the reason why we thought we don't want to have to maintain 2 "databases" for the same clients. Plus, sending full backups during DR is not gonna work for us, we have a whole lot of data coming from VNX filers ... long NDMP backups ... not exactly what we want.
So, please tell me if we're missing something or we don't understand properly the root-to-replicate solution.
Thanks so much,
Olivier
Ergosphere
13 Posts
0
November 7th, 2014 06:00
That definitely gives me some new ideas! Thanks so much. Indeed, we've been debating the active-active (which was our first intention) versus active-passive grid and that's why we wanted to give it a shot. I will try to do what you're suggesting with EM. Do I need to wipe everything out though from my policy-based replication?
Also, say I'd be able to export/import the group configurations ...etc., when in DR situation, the first client backup would still be a full right? And I would still have 2 separate databases (site1 for regular time, site2 during DR) right?
Thanks so much Oscar for your inputs.
OscarG1
2 Intern
•
137 Posts
1
November 7th, 2014 06:00
The reason you can't add the fullcopy now, is because the policy based replication is different to the one configured in the enterprise manager replication.
I have done root to root replications with a daily upgrade, and also performed the disaster recovery with it.
You just have to replicate root to root using the enterprise manager configuration and adding the --fullcopy to the parameters.... the problem with this type of replication, is that you will have a passive grid, that means you can only use it when you do a disaster recovery. and most of costumers will not like this idea.
Another way to do, is, you already have all the backups in the other site, so you just need to tranfer all the configuration to this secondary site.
its kind of tricky but just create the domains in the secondary site, and export and import the groups configurations. in that case you have 2 avamar grids with the same policys, so you can move the clients when needed with the client manager.
I hope I gave you some ideas
ionthegeek
2 Intern
•
2K Posts
1
November 7th, 2014 06:00
This is not true. Assuming replication is up to date, backups will pick up right where they left off once the client is activated to the site2 server.
Every backup has a unique identifier called a root hash. This root hash is calculated from the contents of the backup, so when backups are replicated, the root hash is preserved on the replication target. When a new backup starts, the client asks the server if the root hashes for any of the 16 most recent backups are present. If they are, we know the cache data associated with these backups is valid so we don't have to re-send the data because we know it's already on the server.
Ergosphere
13 Posts
1
November 7th, 2014 06:00
Well that's one piece I was missing! In that case, that changes everything. Switching back and forth between the 2 sites, is then just a matter of re-activating the clients at DR. I can manually configure my domains, export/import groups to be ready and that should work. Thanks so much Ian and everyone, that looks much better than what we were intending to do.
I'll give it a try very soon.
ionthegeek
2 Intern
•
2K Posts
0
November 7th, 2014 06:00
Using "operational root-to-root" still requires an RPQ as Nick described above, no matter how it's implemented.