The Softswitch includes a system that makes possible a periodic, automatic backup of the database. Parameters of the database back up, such as schedule, start time, compression, and number of generations to keep, can be configured via the Backup section of the System Parameters interface. Care should be taken when selecting a start time for the backup because even though the backup procedure is on-line, (which means that it doesn’t take service offline for its duration) it creates a significant load on the system which can interfere with call processing. An off-peak time for database backup should be selected.

It should be noted that in "weekly" mode the backup will run on the same day of the week as it ran the first time after being enabled. So, if you have enabled it on Friday afternoon to run weekly at 04:30am then it will run every Saturday at 04:30am. The same rule applies for "monthly" mode – the backup will run on the same day every month as it 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 itself. It is advised to configure the server to mount a 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.

A format for the Database backup can be selected from several different formats, each with 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 the fastest recovery speed, but it is not compatible across major and minor database server software versions. The format is 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 that allows uploading of backup files to an 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 in the /var/db/pgsql directory: ecopy and eremove, each of them taking "backup filename" as a single argument. The first one is invoked when the 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.  A sample ecopy script that uploads the 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.

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

How to restore system from backup when your production server is totally crashed and there is no Standby server:

  1. Activate the database backup on the web interface of your Sippy Softswitch (when you first use Sippy softswitch);

  1. Set a " Schedule"(how frequent the system should backup the database), "Dump Format = SQL dump(text)", "Compression = gzip"(or w/o compression), "Start Time" (suitable time of DB backup), "Generations" (the amount of backups you plan to store)
  2. Prepare the ftp server and provide the Sippy support team all information needed (ftp's IP, credentials and folder).  The Sippy support team will configure database backup to your ftp server. Configuration of "Database Upload" to the FTP server should be done only once, after that the system will always upload new backups to your ftp server automatically
  3. If the server crashes and can't be recovered, you can install the system from scratch by using a Sippy ISO image
    How to install system from ISO:
  4. When the installation is done, contact support for further activation of the server and provide a link to the backup file (file that was uploaded to FTP beforehand).  Support needs the backup file for data recovery.
    NOTE:  due to the complexity of the procedure, only Sippy's support team can restore the backup. Sippy Software's support team knows Sippy's architecture and the appropriate services involved.