Your browser does not allow storing cookies. We recommend enabling them.

PreviousNextUp[Front page] [Index]

Remote Live Backup

In live backup, the dbbackup process has a continuous TCP connection to the database server running in an SSH Tectia Certifier installation. To enable this the dbeng7 in the bin/ssh-ca-runenv script must be replaced with dbsrv7, which accepts remote connections. Further connection parameters can be given to dbsrv7 with the -x option. For example, -x "tcpip(MyIP=;ServerPort=7075)" would specify the interface and port the database server uses for incoming connections. If a non-standard port is used (Sybase uses port 2638 by default), it must also be given in client connection parameters to dbbackup (CommLinks=tcpip(Host=;ServerPort=7075)).

WARNING: This will also mean that anyone able to connect to your database machine and who also knows the password for a database user can change the database contents. Also, by default the password is transmitted as plain text in network, so anyone with access to your network can also get access to your database. The best way is either to run the whole setup in a physically trusted network or use some method to secure the connections (IPSec, Secure Shell tunnel, TLS tunnel or such). In such cases dbbackup also needs DoBroadcast=NONE option which disables UDP-broadcast-based database auto-discovery.

To run the live backup, use the following command:

source ./bin/ssh-ca-runenv
dbbackup -c "connection_string" -l transaction.log backup-directory

As the dbbackup needs specific libraries the ./bin/ssh-ca-runenv must be executed first.

In addition to the normal database name, database engine name, user name, and password parts, the connection string must contain links=tcpip(Host=serveraddress) in which serveraddress is the address of the machine running the database. Additionally if database is running in non-standard port, ServerPort=portnumber option must be given.

Live backup will only backup the transaction log, the database file itself is not backed up. All committed transactions are automatically flushed to the remote transaction log by the live backup process. This however is not transactional; when a transaction is committed to the database it is not ensured that it is already in the live backup transaction log. In case of failure, a few transactions can be lost if the recovery is done from the live backup.

The dbbackup process exits when the database connection is lost. This means that it must be encapsulated into a script that automatically restarts the process in such case, probably integraded into a monitoring solution which also either tries to restart the current server machine or switches the SSH Tectia Certifier to a spare unit.

When implementing a normal backup process for SSH Tectia Certifier, it must be remembered that the live backup transaction log is truncated when normal transactions logs are (the -x option for dbbackup). Best way to ensure that no data is lost during backup is to make the full backups also remotely. Otherwise a failure right after a truncating local backup might destroy both the database, transcation log, and the most recent backup at the same time.


Here is a simple example script to use for live backups. It does not offer any restart functionality for dbbackup or SSH Tectia Certifier itself.

if [ "X`uname`" = XLinux ] ; then BASE=/usr/local/certifier ; fi
if [ "X`uname`" = XSunOS ] ; then BASE="`pkginfo -r certifier\* | 
  tail -1`/certifier" ; fi
if [ -z $$BASE ]; then
  echo Unsupported OS; exit 2

if [ $$# != "2" ]; then 
  echo "Usage: $$0 backup-dest-dir server-address"; exit 1; 

. $$BASE/sybase/bin/

if [ -f $$PREFIX/live-transaction.log ]; then
  rm -f $$PREFIX/live-transaction.log.old
  mv -f $$PREFIX/live-transaction.log $$PREFIX/live-transaction.log.old

nohup dbbackup -c $$SSH_CA_DBCONN -l $$PREFIX/live-transaction.log $$PREFIX > 
  $$PREFIX/live-backup.out 2>&1 < /dev/null &
echo $$! > $$PREFIX/

As a safety measure, the script will first move the possibly existing transaction log and delete the older backup in the process. If wanted, this could also be changed to preserve all log files.

Then the script will start the dbbackup process in the background using nohup. Stdout and stderr are redirected to the file live-backup.out for debug purposes. Finally the pid of the dbbackup process is stored in and can be used by other scripts to check its status or kill it.

PreviousNextUp[Front page] [Index]




What to read next:

  • Reduce Secure Shell risk. Get to know the NIST 7966.

    The NISTIR 7966 guideline from the Computer Security Division of NIST is a direct call to action for organizations regardless of industry and is a mandate for the US Federal government.
    Download now
  • ISACA Practitioner Guide for SSH

    With contributions from practitioners, specialists and SSH.COM experts, the ISACA “SSH: Practitioner Considerations” guide is vital best practice from the compliance and audit community.
    Download now