Overview
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.
To enhance monitoring of backup procedures, Sippy 2022 gets the 'Notify on Success' option has been integrated into the Backup configuration. When enabled, this feature will automatically send a email notification to switch owner upon the successful completion of each backup. To utilize this feature, simply check the 'Notify on Success' box in the Backup section.
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 Dump (Text) – Default backup format. 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.
- SQL Dump (Binary) – this format provides good recovery speed but it is compatible only across minor database server software versions. Very space efficient.
- SQL Dump (Tar) – 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.
- Filesystem DB Snapshot – this format provides the fastest recovery speed, but it is not compatible across major and minor database server software versions. One archive would contain the backup of all databases of all environments, useful for backup of multi-tenant system with lots of Environments. The format is space inefficient.
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: pre-ecopy and ecopy, each of them taking "backup filename" as a single argument. Both of them are invoked after the backup file has been created, it allows to execute some distinct scripting within different files, e.g. check the presence of old backups on remote server and rotate them in pre-ecopy while upload the current backup file to the remote server.
Both scripts should return the exit status – exit code 0 means that the upload has completed successfully, while any other codes indicate 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 pre-ecopy 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 to /var/log/backup.log file
Restoration from backup
In order to be able to restore the system from backup, the backup should preliminarily be configured and available for restoration, e.g. uploaded to some external server.
1. Setup the regular backup
When you first use Sippy softswitch, activate the database backup on the web interface in System Parameters - Backup section:
- Schedule - how frequently the system should backup the database
- Dump Format - SQL Dump (Text), SQL Dump (Binary), SQL Dump (Tar), DB Snapshot
- Compression - gzip/bzip2/no compression. bzip2 provides slightly better compression rate at cost of longer time to compress archive.
- Start Time - suitable time to start DB backup based on timezone of the web user.
- Generations - the number of backup generation that should be stored, backup rotation setting.
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
Install the system from scratch by using a Sippy ISO image
https://support.sippysoft.com/solution/folders/133030
4. Contact Sippy support
Either by creating new ticket or via email to support@sippysoft.com, provide credentials to access newly installed server if old can not be accessed anymore and access to the backup files (file that was uploaded to FTP beforehand).
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.
Encrypted Cloud Backups
In order to automate backup upload to remote system and provide the easier restoration path, a new feature was added: