Use of Proprietary Information and Copyright Notice. This document contains proprietary information that is to be used only by the Sippy Software, Inc. customers. Any unauthorized disclosure, copying, distribution, or use of this information is prohibited. (c) 2006-2008 Sippy Software, Inc. All rights reserved.


The Softswitch includes the system which allows performing automatic backup of the database periodically. Parameters of this backup, such as schedule, start time, compression and number of generations to keep, can be configured via the Backup section of the System Parameters interface. The care should be taken when selecting start time for the backup, since even though the backup procedure is on-line one, which means that it doesn’t take service offline for its duration, but due to its very nature its creates significant load on the system, which can interfere with call processing. Therefore, off-peak time has to be selected.

It should be noted that in a weekly mode the backup will run on the same day of the week as it has ran for the first time after being enabled. So that for example if you have enabled it on Friday afternoon to run weekly at 4:30am then it will run every Saturday at 4:30am. The similar rule applies for the monthly mode – the backup will run on the same day every month as it has ran for the first time after being enabled.

By default backup copies of the database are stored in the /var/backups directory of the Softswitch system itself. It is advised to configure the server to mount separate physical hard drive (or a network drive) into that directory, so that if the main drive fails, the system can be restored from the backup one.

Starting with version 1.6 the database backup format can be selected from several different database backup formats, having different characteristics:

  • SQL Text Dump (default) – this format provides best combination of recovery speed and compatibility across database server software versions. Can be restored on any version of database server software. Moderately space efficient.
  • Filesystem DB Snapshot – this format provides fastest recovery speed, but it is not compatible across major and minor database server software versions. The format is very space inefficient.
  • SQL Binary Dump – this format provides good recovery speed but it is compatible only across minor database server software versions. Very space efficient.
  • SQL TAR Dump – this format provides good recovery speed but it is compatible only across minor database server software versions. Using this archive format allows reordering and/or exclusion of database objects at the time the database is restored. Unlike with other formats it is also possible to limit which data is reloaded at restore time. Moderately space efficient.

For even better protection, there is an optional mechanism allowing uploading backup files to external remote server over the network automatically as part of the backup procedure. In order to use this mechanism, one or two scripts have to be placed into the /var/db/pgsql directory: ecopy and eremove, each of them taking backup filename as a single argument. The first one is invoked when backup file has been created and needs to be uploaded to the remote server, while the second one – when the backup file has to be removed as part of the rotation procedure. The ecopy script should return its error status – exit code 0 means that the upload has completed successfully, while any other code indicates error. Sample ecopy script that uploads file to the remote TFTP server is available in the /home/ssp/scripts/ecopy_tftp.sh file. The eremove script can be absent, in which case some external mechanism for remote backup aging and rotation has to be implemented instead.


All backup activity is logged in the /var/log/backup.log file.