Symantec Encryption Management Server (SEMS or PGP Encryption Server) has a feature to backup all data so in the event of hardware\system failure, the backup can be restored and will restore the server to the same state before the failed event.
This article will cover the basics of backing up the server.
This article provides instructions on how to configure the backup location for Encryption Management Server (AKA PGP Universal Server or just PGP Encryption Server)
TIP: When backup is taken, you need roughly 5 times the amount of free space as your database. For new environments, the database will be very small, but can build up over time. If your database is 1GB, then to make a backup, make sure you have at least 5GBs free space on the system. This is a very simple example and servers should have well beyond 5GBs free space. This is to illustrate only how much free space should be available. If in doubt, contact Symantec Encryption Support for further assistance.
The SEMS backups can be configured by navigating to System\Backups within the SEMS UI. To configure the Backup Schedule, click the "Backup Schedule..." button and the following windows will appear:
This is a fairly straightforward window where you can configure the days and time of day to perform backups. Staggering your backup schedule may be beneficial for clustered environments so all of the cluster members are not backing up at the same time. For example, one server could backup every day at 7PM, another at 8PM and another at 9PM. This is all dependent on what time will work best. Configure the appropriate settings and click Save.
Caution: If you have any custom scheduled tasks configured in crontab, changing any of these values can reset your crontab to the default values. See the following article for more information on this:
214963 - Symantec Encryption Management Server modifications can cause crontab entries to be reset to default values
By default, backups are saved to the local disk on Encryption Management Server (not recommended for long-term operation).
Symantec Enterprise Division highly recommends specifying another location off the server to save backup files to using either FTP or SCP.
When the backup job is preformed, backup files are then automatically sent to that location via FTP or SCP. If you change your backup location, you cannot restore from backups stored on the old location, even though the backup files still appear listed on the System Backups page.
Note: If your remote host is temporarily unavailable, the backup file is stored on the Symantec Encryption Management Server until the host becomes available. Make sure that you get the backup file from the host in binary format, not ASCII.
As mentioned above, even if you are saving backups to FTP or SCP, you need at least 5 times the free space as the size of the database because all backups are created locally, archived, then encrypted, and then delivered to the remote location for final storage.
The following is a screenshot of the Backup Location page for SEMS 10.5 and above:
You will notice all the expected values, but notice the compression options. In SEMS 10.5, you can configure whether you want backups to be larger, or smaller. The larger the backups, the faster the backups will complete, but the more storage these will take (requiring about 5 times the size of your database at minimum).
The slower the backups, the more compressed they can be. It's a good idea to test which is preferred and best for your environment.
To configure the backup location
You can download your SSH keypair and place the public part of the key onto another server to use to validate logins on that server.
Scenario 1 of 7: Credentials are incorrect
If SEMS is not delivering the backup to the expected location, attempt to use WinSCP and configure all the same credentials to see if you can browse to the expected location.
Scenario 2 of 7: Linux may work better than Windows SCP Servers
*Linux is recommended for remote SCP backup as some 3rd party SCP solutions for windows may not work as expected .
Scenario 3 of 7: Larger backup sizes may not work with certain SCP Solutions
*Some 3rd party SCP solutions for Windows may fail if the backup size exceeds 2GBs.
Scenario 4 of 7: Some FTP/SCP solutions may not delete - Ensure proper permissions to "delete"
*Some 3rd party Windows solutions may not remove old backups even if the option "Keep at most 5 scheduled backups” is set as expected. Always ensure delete permissions is available for the user making the backups.
Scenario 5 of 7: FTP/SCP Timeouts
*Ensure that your FTP/SCP solutions do not have a timeout. If your backups are very large, it may take longer to copy the backup. Ensure the copy interval will not fail due to SCP/FTP Timeout.
Scenario 6 of 7: Backup Protocol may not be allowed
If you are finding a backup is not working, you can try to telnet via SSH from the PGP server to make sure the ports are not blocked.
If the IP of the SCP server where backups are to be delivered to is 192.168.1.199, run the following command:
telnet 192.168.1.199 22
Change the port to match the protocol, such as port 21 for FTP.
In the drop-down menu for the backup, make sure "SCP" is selected if you are backing up to an SCP server or "FTP" if you are backing up to an FTP server.
The telnet connection should succeed immediately. If there is any lag, this likely means you can't connect on the port.
Check to make sure DNS is configured properly, and that the port is open.
If the session does connect, to get out of the session, type the following key combination:
ctrl + ]
Then type "quit"
Scenario 7 of 7: Backup Failure Scenario - FTP Server has insufficient Storage Space
Attempting to backup the server to a remote FTP location (ensuring the backups are encrypted), and the following error appears:
"Failed to FTP backup archive: server did not report OK, got 452. Attempted to delete failed backup."
Solution: In reviewing the FTP codes, 452 means insufficient space:
"452 Requested action not taken; insufficient storage space."
To resolve this issue, either provide more storage or clear off some of the previous data and attempt the backup again.