Chilling_Silence's blogOffsite differential nightly backups for Elastix
It’s happened to everybody at some time or another, you wish you could go back to yesterdays system. You make a change and delete some IVR menu you shouldn’t have but can’t remember how it was setup so you can’t recreate it.
The built-in Elastix Backups is great, but only if you remember to do it. I have the memory of a sieve so unfortunately I rarely remember.
The good thing is it’s now no longer difficult for you to backup a system automatically!
Because I don’t do any faxing or the likes on my systems, it doesn’t get backed up. This also won’t backup FOP2, your amportal.conf and other such things.
Here’s what it will do:
- All core Asterisk files in /etc/asterisk
- Custom sound files used in voicemails / recordings
- Voicemail boxes
- CDR records
- FreePBX custom system files
- Differential backups from the previous day, so you’re not wasting storage space and transferring large volumes of data regularly.
It’s enough for you to basically take a stock Elastix system and be back up and running in seconds.
Scenario: Your HDD died. You didn’t have any monitoring in place and so the SMART warnings went undetected. Your system is now down. Thankfully you have the ISO of Elastix, so you quickly throw it into the machine and reinstall (Or if you’re like me, you have a “vanilla” system ready on another HDD). Â It boots the brand new Elastix installation and you’re now in a position to restore from your backups.
You now restore from your backups by simply copying everything in your last daily backup to your / folder, and it overwrites everything it needs to. You quickly reimport the .sql file into MySQL and you’re back, with minimal disruption.
- The script
- The prep work
- Adding it to your crontab (So it works automatically of course)
- Testing
- Password-less logins
- More testing = Success!
- Restoring
Here’s how you do it:
1) The script
#!/bin/sh # Version 0.1 # Written by Josiah Spackman - www.c2s.co.nz # Run on the client machine that you want to be backed up to another server # Set the local SQL server details. Pretty generic across all Elastix, so hopefully your MySQL port isn't public MSQLU="root" MSQLP="eLaStIx.2oo7" # Set the destination username and servername DSTUSER="backupuser" DSTHOST="destination.backupserver.com" DSTFULLDIR="/home/backupuser" # We want the Hostname of the current box so we can backup multiple boxes and easily distinguish them with as little modification to this script as possible # NOTE: You need to create this Dir on the remote host prior to the first backup run HOST="elastixtest" # Set the local tempdir to store the files in. Default is usually sufficient TMPBACKUPDIR="/tmp/asteriskbackup" # Setting the day DAY=`date +%a | tr '[A-Z]' '[a-z]'` case $DAY in sun ) PDAY=sat ;; mon ) PDAY=sun ;; tue ) PDAY=mon ;; wed ) PDAY=tue ;; thu ) PDAY=wed ;; fri ) PDAY=thu ;; sat ) PDAY=fri ;; esac # Setting options for rsync to run with OPTS="-aHL --link-dest=$DSTFULLDIR/$HOST/$PDAY/ --delete --stats" # Copying everything locally and doing it all in one go mkdir -p $TMPBACKUPDIR/etc/ $TMPBACKUPDIR/var/spool $TMPBACKUPDIR/var/lib/asterisk/sounds $TMPBACKUPDIR/var/www/html/admin/modules/core cp -Rs /etc/asterisk $TMPBACKUPDIR/etc/ cp -Rs /var/spool/asterisk $TMPBACKUPDIR/var/spool/ cp -Rs /var/lib/asterisk/sounds/custom $TMPBACKUPDIR/var/lib/asterisk/sounds/ cp -Rs /var/www/html/admin/modules/core/etc $TMPBACKUPDIR/var/www/html/admin/modules/core/ # MySQL Dump so we have all parts of the server mysqldump --add-drop-table -h localhost -u$MSQLU -p$MSQLP -A > $TMPBACKUPDIR/database.sql # Running rsync now rsync $OPTS $TMPBACKUPDIR $DSTUSER@$DSTHOST:$HOST/$DAY/ # Cleaning up afterwards, no point in keeping the database or other links... rm -rf $TMPBACKUPDIR
Now here’s how you use it:
Copy all of that text and save it as /root/backups.sh using your favorite editor
2) The prep work
Change a few values, namely the DSTHOST, DSTUSER and DSTFULLDIR.
You need to specify the full directory where the files are stored remotely, usually this is just the home directory.
Now we’re going to give it execute permissions:
chmod +x /root/backups.sh
3) Adding it to your crontab (So it works automatically of course)
As root, run:
crontab -e
Add in the following line by pressing “i” to “insert” text:
0 1 * * * /root/backups.sh
This will run the backup every night at 1AM
To save and quit, write:
:wq
Then press enter
4) Testing
Run a test backup, by using:
sh /root/backups.sh
See if it runs OK.
Chances are it’s going to fail. This is because you need to remotely create the “host” directory. Example:
You’re backing up a machine called AcmeInc, you want to create a directory on the destination backup server called “AcmeInc” first, and then it will do the rest. This should be the same value as $HOST, remember it’s case sensitive.
Now that you’ve got your directory on the server, run it again:
sh /root/backups.sh
It should do a successful initial run.
But it doesn’t stop there.
5) Password-less logins
Up until now it’s been prompting for your password. This isn’t going to work if you’re trying to run the job automatically via a scheduled cron job, because naturally you’re not going to be around at 1AM (Or at least you shouldn’t be).
We’re going to create password-less logins with:
ssh-keygen -N '' -t rsa -f ~/.ssh/id_rsa
Now you should have /root/.ssh/id_rsa.pub so run this to see the contents
cat ~/.ssh/id_rsa.pub
Now you want to copy that and on the server you’re backing up to, you want to edit ~/.ssh/authorized_keys
Put in the contents of the id_rsa.pub file.
Now, we’re going to secure it down just a little more:
chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
Great stuff, you’re almost there!
6) More testing = Success!
Now if you run:
sh /root/backups.sh
It should complete successfully, and not ask you for a password!
What we’re now going to do is time-warp forwards a day and make sure it’s doing the differential transfers correctly. Login to your backup server and rename the folder so that the day is the previous days. For example if today is tuesday, then rename “tues” to “mon”. The day is always the first 3 chars of the day name. Easy enough yes?
Now, login to your server and make a change of some description, perhaps even create a dummy Extension, just so that some of the files will change.
Re-run the script and it should tell you it’s completed happily and it should only take a *very* short time to run, under 7 seconds for me on a barely used system.
If you see an error such as:
--link-dest arg does not exist: mon
This means your absolute path is not correct. Double-check your home dir and the DSTFULLDIR variable in the script.
7) Restoring
It’s all well and good to have a flashy system like this, but if you don’t know how to restore, it’s relatively useless. Thankfully it’s incredibly easy to restore!
Grab the contents of the last “day” that you backed up, for example yesterdays backups and save them in /root. We’ll use Tuesday as a reference. Run this on the PBX server you’re wanting to restore:
scp -r user@backup.server.com:~/hostname/tue/ /root/ cp -Rvf /root/tue/asteriskbackup/* / mysql -u root -peLaStIx.2oo7 < /root/tue/asteriskbackup/database.sql /etc/init.d/mysqld restart amportal restart
However, it’s going to prompt you for each file, so you might want to edit /root/.bashrc and remove the line:
alias cp='cp -i'
It is basically forcing you each time to answer “y/n” to the cp command, even if you don’t want it to. You then need to either log out and back in again, or you could just run:
su -
Re-run the cp command and anything after it and you should now be back up and running!
As always, I’m open to feedback, comments and suggestions. If this has helped you in any way, please just leave a brief message and say Hi!
This has also been posted here: http://blogs.elastix.org/en/2010/06/offsite-differential-nightly-backups-for-elastix/
Leave a Reply