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.

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

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. Please activate the backup of the database on the web interface of your SippySoftswitch (at the begining of Sippy softswitch usage);

  1. Set some " Schedule"(how frequent 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 to Sippy support team all needed information about it (ftp's IP, credentials and folder) and they will configure backup of database to your ftp server. Configuration of "Database Upload" to the FTP server should be done only once and then system will always upload new backups to your ftp server automatically;
  3. If server crashed and can't be recovered, you can install system from scratch with usage of Sippy ISO image (link to the latest image you can request from Sippy support);
    How to install system from ISO see here:
  4. When installation is done, please contact to support for further activation of server and provide them a link to the backup file (that was uploaded to FTP beforehand) that support have to use for data recovery.
    Please note that backup can be restored only by Sippy support, because of the complexity of the procedure and with a deep knowledges of Sippy's architecture and appropriate services.