I was looking to find out if there is a document out there now on setting up a secondary Endpoint Encryption Management server and what different options I may have and what others in this community are doing for such needs. Is it just a replication over to the new server of SBAdmin and SBDATA directories? but I'm sure there are various factors involving methods and best practices for updating clients wih the new info etc. Currently running 5.x environment. Appreciate any insight on this.
McAfee backup document outlines how to have live database copied to another system. If that is what you are looking for.
Thanks Peter. This is what I was looking for. Also, for existing clients to get the update of the new hotbackup server information is this handled via scm and sdmcfg files after the new server is added in the object directory and later pushed out as part of the client file updates?
As far as I know, no. You would not have to. If your primary dies, You change backup server settings to match primary, then bring it online.
Ok. Just so I have this understood correctly..The practice to get the clients talking to the Hot backup server is stop service on primary and then to change the hotbackup servers IP to the Primary servers IP, start the service etc? To understand further then why does the document suggest to create a secondary server entry in the database with separate IP which creates certain security keys etc in the ojbect directory. There has to be another way to let the existing clients know of the new server (hotbackup) so they can go to that instead of just looking at single IP.
That might come from some older design strategy, which is not being recommended anymore...
Since only one database instance should be servicing clients at any given time, I suggest to keep only one server name/key present. That is simple and easy to troubleshoot. All you need to control is the DNS and database service status.
Interesting. I prefer to have both servers configured on the clients at all times. They are set to always try the primary first, but if it fails, then they try the backup.
The backup has the service turned off at all times. There's a manual DR procedure to ensure that the primary is down, or at least the service is disabled, and then to bring up the servcie on the backup server. No touching the clients during a DR incident, no touching DNS, and minimal work for the operators.
If that works for you....We have decided to use load balanced multiple database servers in the front-end. Therefore we have multiple remote servers in client configuration. So it is just a different approach.