Wise Linux gurus—and even young, less experienced ones—know a lot of slick
tricks for setting up efficient, reliable automated backups. Linux, like all
of its Unix cousins, comes with a large number of excellent archiving and copying
utilities. It’s very network-friendly, and its file structure and data formats
are friendly to being copied and archived, and restored at need. But look before
you leap into setting up backups on your SipX server in your usual fashion,
for SipX comes with its own excellent backup and restore scripts.
Log into your SipX Web administration console and go to System -> Backup. With a single button-click you can back up all of your SipX configuration files, all the data in the PostgreSQL database, and mailboxes and voicemail stores. Each file is stored in a directory named for the date and time, the type of file, and is then rolled into a compressed archive. Like these examples from my SipX server:
/var/sipxdata/backup/200705041742/backup-configs/fs.tar.gz /var/sipxdata/backup/200705041742/backup-configs/pds.tar.gz /var/sipxdata/backup/200705041742/backup-mailstore/mailstore.tar.gz
There are a couple of ways you can use these files. One is to store them safely away on a separate machine or storage device, because obviously keeping backups on the same drive is rather a silly thing to do. Which we shall get to presently, but for now let’s play with them a little. Sit yourself down at a neighboring PC, log into your SipX server, and copy the files over to your PC:
[email protected]:~$ ssh [email protected] [[email protected] ~]# cd /var/sipxdata/backup/200705041742/backup-configs/ [[email protected] ~]# scp fs.tar.gz pds.tar.gz [email protected]:~/test [[email protected] ~]# scp ../backup-mailstore/mailstore.tar.gz [email protected]:~/test
Now open another terminal and change to the directory you copied the files to, and unpack them:
[email protected]:~$ cd test [email protected]:~/test$ tar -zxvf fs.tar.gz
Use the same tar incantation to unpack all three files. Now you can poke around and see inside them. fs.tar.gz holds the contents of /etc/sipxpbx/, and unpacks into /etc in your download directory. pds.tar.gz has database data without the database, and sprays files all over your download directory. mailstore.tar.gz unpacks into a /var directory under your download directory. mailstore.tar.gz includes configurations and preferences as well as voicemail messages.
Restoring from backup
Oh no, bad things happened and your SipX server got messed up! But fear not, for you, the ace SipX admin, will have it back up in a jiffy. Follow these steps to restore from backup:
Create two directories named /root/backup-configs and /root/backup-mailstore on the SipX server:
[[email protected] ~]# mkdir backup-configs [[email protected] ~]# mkdir backup-mailstore
Notice how you are already in root’s home directory in this example. Next, copy your chosen fs.tar.gz and pds.tar.gz files into /root/backup-configs, and mailstore.tar.gz into /root/backup-mailstore.
Stop the server, then run the backup scripts:
[[email protected] ~]# service sipxpbx stop [[email protected] ~]# restore-configs.sh Will restore backed up configuration files and database from: /root/backup-configs Restoring configuration files... done. Restoring database... done [[email protected] ~]# restore-mailstore.sh The following actions will be taken (use -h to get help on this): Will restore backed up voicemail stores from: /root/backup-mailstore Is this correct? [y/N] Y Excellent! Restoring voicemail stores... done
You’ll see a whole lot of output from the service sipxpbx stop command, because it has to shut down a metric boatload of services.
And that’s all there is to it. Having nice prefab scripts to do all of this is a wonderful time-saver, especially for backing up and restoring the database data, because this requires using special dump and restore commands. And as a free bonus, now you know how to extract and copy individual files if you don’t want to perform a wholesale restoration.
The SipX Web interface doesn’t provide any options for setting up alternate
backup locations, and it allows a maximum of one scheduled backup every 24 hours.
However, you can schedule more by setting up some cron jobs in /etc/crontab
on the SipX server. These examples run the same backup scripts as the Web interface
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ 10 * * * * root /usr/bin/backup-configs.sh 30 * * * * root /usr/bin/backup-mailstore.sh
In both scripts, be sure to change INTERACTIVE=”yes” to
INTERACTIVE=”no”. The first one runs ten minutes after the hour, the second one 30 minutes after the hour, all day every day. You can set this up any way you like, such as longer intervals at night and on weekends. See Linux commands: /etc/crontab, crontab for more information.
The Web administration interface lets you easily configuration a rotation schedule, so that old backups are automatically deleted. It doesn’t backup any Linux system files, so you’ll still want to set up your normal system-wide backup routine.
Even if you have the most rugged hardware, the finest purest electricity and backup power galore, RAID everything, and multiple redundant SipX servers, it is still the wise admin who stores backups offsite. There are a number of ways to do this: with NFS shares, Samba shares, or rsync. Come back next time for detailed examples of all three of these.