Unsolved
This post is more than 5 years old
2 Intern
•
336 Posts
0
1885
October 10th, 2017 08:00
Avamar backups after DR failover
Does anyone have any experience with backing up servers that have been failed over to DR hardware in a DR scenario?
For example, one of our production Oracle servers has a DR "twin" with a different system name. In a disaster scenario, the storage is failed over to the DR hardware and the twin is reconfigured to "become" the production server, with the original production IP and system name etc.
The problem I see with this is that in order to back up the twin after failover, I'm going to have to re-register the server, which in turn will create a new instance of the client in Avamar. So I'll end up with two versions of the production server name in Avamar.
I suppose the question to ask is "what does Avamar use to identify an individual client"? For example, I've modified IPs before and the client has been able to re-register without duplication. However if I change the system name Avamar can no longer "see" the client, and when it's re-registered it creates a new client instance.
Thanks.
connolly
2 Intern
•
132 Posts
0
October 10th, 2017 08:00
Just to clarify - are you asking about backups to a "primary" Avamar server from a customer "DR" server? As opposed to backups to a "secondary" DR Avamar from the customer "DR" server as part of a "complete" DR failover?
ionthegeek
2 Intern
•
2K Posts
0
October 10th, 2017 08:00
If the "twin" has the same storage (and therefore the same Avamar client directory), and the hostname and IP are updated to match the original system, the Avamar software should never even notice the difference.
Client registration information is stored in a file in the Avamar "var" directory called cid.bin. This file contains the hostname of the Avamar server, the server's create time (an immutable property that can be used to identify a particular Avamar installation) and the client's "CID" which is a unique identifier generated by the Avamar server.
Assuming everything is intact post-failover, you may not even need to re-register the client since the "twin" should still have valid information about the server the original client system was activated with. You might need to restart the agent. The next time you're doing a DR exercise, check avagent.log and see what the agent is doing.
connolly
2 Intern
•
132 Posts
0
October 10th, 2017 08:00
And would we also be working under the theory that "twin" means that the DR server has the same CID.bin file as the original server? (that is, the storage that is failed over includes the Avamar software directories)
ionthegeek
2 Intern
•
2K Posts
0
October 10th, 2017 08:00
This is a good point. I assumed in my reply that the twin is being activated to the original Avamar server.
brastedd
2 Intern
•
336 Posts
0
October 10th, 2017 09:00
Thanks for the replies.
The Avamar server is the same, it's actually situated in the DR hardware location. The DR server is not an exact replica of the production server, it's just the same hardware and OS and such. The Avamar agent does not come over with the storage failover - when we're not in a DR scenario it has its own Avamar install, albeit not registered.
Ian, can I just copy the cid.bin file to the DR server? Then when the server becomes production, Avamar will see it as the original production server?
Alternatively, is it possible to tell Avamar to use a different name for a server even when the system name is the same as another client? i.e. have the DR server called "oracle-dr" in Avamar even though the system name is changed to "oracle-production"? That way we won't confuse the backups done by the production server and those done by the DR server "as production".
ionthegeek
2 Intern
•
2K Posts
0
October 10th, 2017 10:00
Is it possible to make it so the agent's storage location also fails over? If the agent on the DR system isn't used except during a DR, that would probably be simplest.
Copying cid.bin over and restarting the agent should be enough but I have not tested this and it's probably not officially supported.
If you override the hostname list in avagent.cmd, you might be able to convince the client to check in with a different name but I an think of a few potential issues here: