Your browser does not allow this site to store cookies and other data. Some functionality on this site may not work without them. See Privacy Policy for details on how we would use cookies.

PreviousNextUp[Front page] [Index]

Setting up Backup Procedure

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:

./bin/ssh-ca-backupconf

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 bin/ssh-ca-backup.
    • The backups will include the database, configuration files, internal PKI data in the var/pki directory.
    • 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.
  • Modify the cron.allow file if that is/was required for enabling the cron job.
  • Modify bin/ssh-ca-runenv to reflect the new backup policy.

To set up software mirroring on Windows:

  1. Shut down SSH Tectia Certifier using the ssh-ca-stop script (see Section Starting and Stopping Certifier Manually). This will also shut down the Database.
  2. Choose two physically independent disks for storing the transaction logs. In the following example, the file systems mounted on C:\ and D:\ are located on two physically separate hard disks.
  3. Use the dblog 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
    

  4. Restart SSH Tectia Certifier by using the ssh-ca-start script (see Section Starting and Stopping SSH Tectia Certifier Manually).

    Current transaction log paths can be checked with the dbinfo command.

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 dbeng7) 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.


PreviousNextUp[Front page] [Index]

===AUTO_SCHEMA_MARKUP===