There are two recommended options to backup your system:
1. FreePBX Backup and Restore module
This module saves all settings that have been made with the FreePBX GUI. By default, a backup is already done on the first of each month to a local file in /var/spool/asterisk/backup/Default_backup/. Just in case your system is broken and you have not made any additional backup efforts, and assuming you still have access to these files, flash your card with a fresh image and restore your settings from there.
The Backup and Restore module of course offers a lot more possibilities to save your settings, such as uploading them to FTP servers. Read the full documentation here:
http://wiki.freepbx.org/display/F2/Backup+and+Restore
Needless to say it does not cover changes made to the system outside of FreePBX.
2. Backup the complete system to an image file
The command-line utility raspbx-backup is able to create an image file of your system, and continuously update this file with all changes. The image is similar to the .img file you’ve been initially flashing to your SD card, it can be copied to a card in the same way. The file contains a 1:1 copy of the whole installation including all changes. As it is a single file, it can easily be stored and in case of system failure just be flashed to a new card.
The backup procedure comprises of these steps:
2.1. Create the image
The image file creation can be skipped, if you did not resize your root partition and kept the original partition size. In this case, you can just use the originally downloaded and unzipped .img file (raspbx-date.img) sized 4 GB, and skip ahead to step 2. (On the BBB however image file creation cannot be skipped.)
The image file has to be located on an external storage, such as a USB thumb/hard drive or a mounted network share. Mount your storage to /mnt or /media/somedir, do not mount it to /media itself or anywhere else. The directories /mnt and /media will not be backed up, and it is clear the image file itself must not be contained in the backup. As an example, mount the first external storage to /mnt:
mount /dev/sda1 /mnt
Then run the backup utility without arguments:
raspbx-backup
You will be asked for a filename with full path. Specify a file on your external storage, such as /mnt/backup.img
Then enter the image file size in MB. In case you did not resize your root partition just keep the default. Otherwise make sure the specified size is not bigger than your card, as in this case it cannot be flashed back. In case of doubt, specify a size about 100 MB less. A much smaller size can be used as well, if you are sure the required storage space on your card will not exceed the specified image size. For example with a 32 GB card you can work with an image file sized 8 GB, if it is certain you are not using more than 6 GB or so.
The image file creation will take some time, depending on the speed of your storage device. On a typical thumb drive it easily takes 20 minutes or more for 4 GB.
2.2. Continuously update the image
In case step 1 was skipped and the original image file is being used, first install required programs (this step is only required once, and not needed if step 1 was done):
apt-get install rsync
Then make sure your storage is mounted and the image file present. Run
raspbx-backup /mnt/backup.img
or specify whatever image file you are using as argument. This step is pretty fast as only files changed with regard to the previous backup are updated. If everything is fine, there will be no text output! Only in case of an error messages will appear.
A missing image file just produces an error message and no backup will be done, for example if the storage was not mounted due to some other error.
Assuming your storage is constantly mounted, you can just put the line above into your crontab. Run
crontab -e
then add this line at the bottom
0 4 * * * raspbx-backup /mnt/backup.img
Press Ctrl-O, Ctrl-X to save the crontab. Your system will be backed up every night at 4 a.m. See the crontab manpage for more options on how to schedule backup times:
man 5 crontab
Let’s assume you need to run a specific command for example to mount a network share where the backup file is located. In this case it is best to write a small script:
nano /root/my_backup
Your script could look like this:
#!/bin/bash mount /dev/sda1 /mnt #or whatever your mount command is raspbx-backup /mnt/backup.img umount /mnt
Then:
chmod 755 /root/my_backup crontab -e
Add your script to the crontab instead:
0 4 * * * /root/my_backup
Mount a Windows share
Mounting a shared folder from a Windows machine on your local network is easy. First install required programs (only needed once):
apt-get install cifs-utils
Then mount the share with
mount -t cifs -o user=username,password=secret "//192.168.0.3/your share" /mnt/
Use quotes in case the share name contains spaces. This would replace the mount command in the script above.
Hi,
I also wanted to backup with the new script. I have a 8GB Card with resized root partition.
I enter 8192 MB for Image size. About 40 % of the filesystem are currently used. The backup script ends up with following error:
Schreibe Superblöcke und Dateisystem-Accountinginformationen: erledigt
Running backup now…
file has vanished: “/var/lib/asterisk/astdb.sqlite3-journal”
rsync warning: some files vanished before they could be transferred (code 24) at main.c(1070) [sender=3.0.9]
Error running backups.
The target file is created on a SMB share (NAS). How can I check if the backup is correct?
Thanks a lot.
regards Helmar
Hi I have used this method to backup. but I could get it how you calculate the image size. which is default for 1828 for BBB. I used a 4GB card but I could not find any way to make perfect back. Only way is to use dd to create a image of the memory card on another system then use that image to perform the further backups.
Could you please explain further what was going wrong when creating the image? Any error message or the like? Would be good if you could share more details.
No Error but image file is always bigger than the size I input for root partition. I have a 4 GB with a root partition of 3884 MB. Total capacity of SD card is 3965 MB. but Image created by raspbx-backup script is 4.2 GB. which is too big for SD card. When I use dd to make image file from my sd card and use it as destination it works perfectly and total image size is always 3.7 GB.
Ok I see! So a root partition size autodetect function should solve this issue. I will have a look at this soon.
Just wanted to mention on this page that if anyone is having a problem mounting a network share, but you can SSH to the target system and use SFTP to transfer files, then you could do this:
1. Install sshfs on the Raspberry Pi – the following will bring in sshfs and all necessary dependencies:
apt-get install sshfs
2. For this to work, you must be able to SSH from your Raspberry Pi to the target system without entering a password. Make sure you can do that first before proceeding. If you don’t know how to do that, there are several pages that will show you the procedure, such as this one:
SSH Passwordless Login Using SSH Keygen in 5 Easy Steps
http://www.tecmint.com/ssh-passwordless-login-using-ssh-keygen-in-5-easy-steps/
3. Once you have sshfs installed, and you know that you can ssh to the target machine without being prompted for a password, simply do this to mount your share:
sshfs username@ip_address:/home/username/RasPBX /mnt/RasPBX
Where username is the user name you use to log into the system, ip_address is the address of the system, which on a home network will often be something in the 192.168.x.x range, /home/username/RasPBX is the full path to the directory that will be used to store the image file on the target system, and /mnt/RasPBX is the mount point on the Raspberry Pi – you can use just /mnt if you prefer, as discussed in the article above.
When you are finished with the backup, you can simply umount to unmount the sshfs share, for example:
umount /mnt/RasPBX
4. You can put the sshfs, raspbx-backup, and umount commands into a script as discussed in the article, but if you plan to do that then you’ll want to make sure that the target system has a fixed IP address, not one that changes each time it is rebooted.