|[Front page] [Index]|
A properly set up backup plan is needed to ensure data recovery in case of hardware malfunction. One method is to use hardware mirroring which will work on physical device level. This requires no changes to SSH Tectia Certifier installation.
The other method is to use software mirroring in Sybase. To make the mirroring useful, two physically independent disks are needed. This way random hardware failures are very unlikely to affect both disks at the same time.
Establishing Backup Policy
For successful data recovery, the current backup of the database file (or the database file itself) and one of the two transaction log files must be available. To guarantee total recovery, establish a regular backup policy using
cron or something similar.
On Unix software mirroring and automated database backups are set up by running(preferably as root) the command:
This script will prompt you for:
- Directory (on your file system) where the Certifier Database transaction logs will be mirrored. This directory must be located on a different physical disk from the Certifier Database
- Directory (on your file system) where the Certifier Database backups will be copied to.
This directory should also be located on a different physical disk from the Certifier Database. If this is not he case, even if you arrange automated copying of the backups to a removable media or to a remote host you are exposed to a catastrophic disk failure during the time window between the end of the backup and the end of the copy operation.
- The backup schedule (daily/weekly/monthly).
Please note that this schedule affects the amount of lost information only in the case of a catastrophe destroying both your disks at the same time. If either one of the disks survives, you will be able recover the database completely.
The script will:
- Enable/disable software mirroring for the Database
- Enable/disable up a daily/weekly/monthly cron job for automated full database backups.
- The cron job will be run as the
certifier user. The backup is done with the script
- The backups will include the database, configuration files, internal PKI data in the
- Each new backup will be saved in a separate subdirectory and the older backups will not be erased.
- Also the nCipher HSM security world files are automatically backed up if they are located in the default directory.
- The cron job will be run as the
- Modify the cron.allow file if that is/was required for enabling the cron job.
bin/ssh-ca-runenvto reflect the new backup policy.
To set up software mirroring on Windows:
- Shut down SSH Tectia Certifier using the
ssh-ca-stopscript (see Section Starting and Stopping Certifier Manually). This will also shut down the Database.
- Choose two physically independent disks for storing the transaction logs. In the following example, the file systems mounted on
D:\are located on two physically separate hard disks.
- Use the
utility to change the transaction log files the database is using. Give the following command on the Command Prompt:
dblog -t C:\sshcertifierdb\certifier.log -m D:\dbbackup\certifier.log C:\sshcertifierdb\certifier.db
- Restart SSH Tectia Certifier by using the
ssh-ca-startscript (see Section Starting and Stopping SSH Tectia Certifier Manually).
On Windows (assuming default installation locations and the location
D:\dbbackup for the backup), the backup can be done with the following command:
dbbackup -d -c "FileDSN=C:\Program Files\SSH Communications Security\SSH Certifier\ssh_certifier_file_dsn.DSN" -t C:\dbbackup -x
Back up also the
ssh_certifier_file_dsn.DSN file itself.
Data Integrity Check
Backup as such is worthless if the data itself is corrupted. Checking the database thoroughly is a somewhat long process it is not normally done at startup. However after (or before) each backup it is recommended to run a special validation utility:
dbvalid -c "connection_string" -f
To check the backup (as opposed to the running system), the backup database must be run under an additional database engine in read-only mode (
-r option in
) to prevent modifications to the backup. Checking the backup database can be useful for performance reasons as the validity check can be performed on a separate, spare machine.
On Unix, the
ssh-ca-backup script by default performs
dbvalid before proceeding with the backup.
[Front page] [Index]