Best Practices for Disaster Backup and Recovery with PGP Server (Symantec Encryption Management Server (SEMS)
Article ID: 269071
Updated On:
Products
Issue/Introduction
This Knowledge Base article provides information on the best practices for planning and executing a successful Disaster Recovery program for the PGP Server (Symantec Encryption Management Server) product.
For Best Practices and Disaster recovery for the Symantec Endpoint Encryption Management Server (SEE Management Server) product line, see the following article:
Resolution
Use the information in this article to help prepare the PGP Server environment and data in an event of a disaster or an unplanned interruption, such as a natural disaster or power outage.
Table of Contents
- Item 1 of 7: Backup/Restore Strategy
- Item 2 of 7: Credentials to login to the PGP Server
- Item 3 of 7: Determine which services are currently in use with the PGP Server
- Item 4 of 7: Network Details
- Item 5 of 7: TLS Certificate
- Item 6 of 7: PGP Desktop client Communications
- Item 7 of 7: Test the redundancy from time to time.
Item 1 of 7: Backup/Restore Strategy
The first thing to do in preparation for a disaster is to ensure your backup strategy is sound. The following article will help you configure a proper strategy that will work for you and is the most critical part of this strategy to review:
153588 - Restore Backup files to Symantec Encryption Management Server (PGP Server)
It is *critical* to have a copy of the Organization Keypair as each backup is encrypted to this key and you need to have both the keypair and the passphrase to restore a backup.
Item 2 of 7: Credentials to login to the PGP Server
To avoid being unable to login to your PGP server due to an unknown password, be sure to note at least one account and its password for safekeeping.
The PGP server is currently undergoing some improvements for password recovery, but until these are rolled out to our next major release (at the time of this writing, the PGP 10.5.1 is the current version branch), you may be forced to use the SSH portal to login.
If you are unsure what your password is, and you cannot login, please reach out to Symantec Encryption Support for further Guidance.
Item 3 of 7: Determine which services are currently in use with the PGP Server
The PGP Server has a vast array of features you can take advantage of. Depending on which SKU you have purchased, some additional steps may need to be taken.
For example, if you have the Web Email Protection functionality, you will want to make sure the WEP service is enabled on all your cluster nodes, as well as the "All" option for cluster replication. This will ensure that all mailboxes will be on each cluster member, so if one server was to go down, you will have all the messages on the other server.
It's always a good idea to check which services are available on each server, and bring the functionality inline with each node.
DMZ Mode is a special cluster mode and may not be 100% reliable to failover to if another non-DMZ node goes down.
It is a good idea to consult the PGP Server documentation for full information on this, and if in doubt, reach out to Symantec Encryption Support for further guidance.
Item 4 of 7: Network Details
The PGP Server backup includes network details (hostname, IP address, MAC address, etc.) of the original server. It is very useful to know these details and document in your network diagram or other internal documentation if needed.
To find this information, login to the PGP Server, click on System, then Network to see the details.
Item 5 of 7: TLS Certificate
Although the PGP Server has a backup of the TLS certificate keypair, it may be a good idea to export the keypair and keep in a safe location.
To do this, login to the server, go to System, Network, Certificates, locate the certificate and export the keypair. Be sure you put a passphrase on the TLS Certificate Keypair and keep a record of it.
Item 6 of 7: PGP Desktop client Communications
When you create your PGP Desktop client, it will include a hostname for the PGP Server. This hostname will be the host the client will reach out to.
If you have 2 PGP servers as an example, and one of the servers is called "keys1.domain.dom" and the other is called "keys2.domain.dom", you can build the PGP Desktop client with only one node.
Consider using a Load Balancer to manage this. In this case, you could have a Load Balancer host of "keys.domain.dom" and that will resolve to keys1 or keys2 depending on the availability.
If one of the servers goes down, the PGP server will be redirected via the load balancer.
The current version does not have automatic failover, but is a feature we are working on. To be added to this feature request, reach out to Symantec Encryption Support and provide ID ISFR-2443.
For more information on Load Balancers and PGP, see the following article:
Review Section 3 of this article.
Item 7 of 7: Test the redundancy from time to time.
In most cases you will not have outages, but you do want to know that the redundancy strategies you have put in place work.
It may even be required to test this and do an official "failover" to another node. This is a good idea to test from time to time, but if you are in a clustered environment, we do not recommend leaving the servers down for too long.
Depending on the size of the database, and how active the server is, data deltas that occur while the other node are queued on one server.
Symantec Encryption Support advises these tests be limited to only a few hours at most and we do not recommend this be done for days.
If you do run into an actual production-down issue, and need immediate assistance, reach out to Symantec Encryption Support by calling the phone number listed in the KB below:
Feedback
