Page tree

Welcome to FreeSoftwareServers Confluence Wiki

Skip to end of metadata
Go to start of metadata

Shortend down from the Original Guide found here @

If running on PBX in a FLASH aka PIAF then 1st run update-scripts and update-fixes.

mkdir /incredible-backup
chmod 777 /incredible-backup
cd /incredible-backup
tar zxvf incredible.tar.gz
chmod a+x incredible*
nano -w /incredible-backup/incrediblebackup && nano -w /incredible-backup/incrediblerestore
#backuploc="/mnt/pogoplug/WD My Book 1110/PIAF-Backup"

There are some customizations needed before running :
# Create Backup Directory
# Insert location into Script (Backup & Restore)
# Use same location on both servers and save scripts for later :)
# Wish there was just a default...

What it backs up :

/var/www/html /var/lib/asterisk /var/lib/mysql /root /etc/asterisk /tftpboot
/etc/pbx /etc/wanpipe /etc/sudoers /etc/odbc.ini /etc/odbcinst.ini
/var/lib/asterisk/sounds/tts /var/lib/asterisk/sounds/custom
/var/spool/asterisk /etc/amportal.conf /etc/wanpipe
/etc/hosts /etc/resolv.conf /etc/sysconfig/network-scripts/ifcfg* /etc/sysconfig/iptables /etc/sysconfig/network /etc/mail
/usr/local/bin /usr/local/sbin /usr/src and portions of /usr/sbin

Note :
If you wish to run incrediblebackup as a cron job, remember to comment out the following line in the script with a leading #:

read -p "To proceed at your own risk and agree to license, press Enter. Otherwise Ctrl-C."

Restore :

Note: The restore is where problems happen, make sure to use a testing environment!
Questions to ask yourself :
Whether to restore FreePBX application from the backup
Unless you are absolutely certain that the version of FreePBX in your backup matches the version on your new server, choosing Y for this option is highly recommended. Otherwise, the structure of the FreePBX MySQL tables may differ and cause all sorts of difficult to diagnose problems.

# Whether to restore Incredible PBX apps to new server
If your backup was made on an Incredible PBX server, then the Incredible PBX apps should be restored to your new server. We've made this optional only to accommodate those who may wish to tailor the scripts to support other Asterisk distributions.

# Whether to restore Network Settings from the backup
If you're recovering from a catastrophic failure and want to make certain that a static IP address is preserved when you restore your backup, then you obviously would want to restore your network configuration. If you're building a duplicate system to be kept off line or if you're moving your server to a virtual machine platform, then you probably do NOT want to restore the network configuration from your primary machine. A good rule of thumb probably goes like this. If network connectivity already is working on your new server, don't restore the network setup from your backup.

# Whether to restore SendMail Setup from the backup
The only situation in which you would want to restore the SendMail setup from your primary server is if you have specially tailored SendMail on the primary server in order to send email. This typically would happen where an Internet service provider blocks outbound SMTP traffic, e.g. Comcast residential Internet service.

# Whether to restore Asterisk binaries and source code
This functionality is EXPERIMENTAL AND BARELY TESTED!! It only works (at all) with Asterisk implementations still using Zaptel, not DAHDI. Unless your primary server was running a version of Asterisk that differs from the default PBX in a Flash build, the correct answer to this prompt is N. Never use this option if you are restoring from a catastrophic failure. Instead, run update-source and update-fixes on the newly restored server. It's safer! We'll keep you posted on future developments.

# Whether to disable outbound SIP/IAX connectivity
This option allows you to disable outbound SIP and IAX traffic on the new server. Typically, you would use this if the server on which the backup was made is still on line. The reason is to avoid having two identical servers compete for connections to SIP and IAX providers. If this option is chosen and you subsequently take your primary server off line, then you will need to enable SIP and IAX connectivity on the newly restored server before it can take over primary duties.

Disable :

cd /etc/sysconfig
cp iptables.sip iptables
service iptables restart

Enable :

cd /etc/sysconfig
cp iptables.nosip iptables
service iptables restart


Note: The last paragraph can be discerning, about it being in Dev stage, but look @ the date.
Posted in Technology by ward, Monday, May 10, 2010 12:00 pm

  • No labels