GetBack Configuration Steps

Setting up the FreeNAS User

  1. From your command machine, open a browser to the FreeNAS front-end and open a terminal emulator window.
  2. On the Web front-end, add a user for your server
    We have discovered that dashes in servernames occasionally break the script, so for Webserver-02, we will choose a the name “webserver_02”
    We are setting up a regular possix user on the FreeNAS machine here, so the automatic uid, e.g. “1014,” is fine.
  3. Our volume names follow the pattern of Bin[volume number], so we might add this user to “/mnt/Bin2230/webserver_02” for their home directory
  4. We prefer the bash shell so we choose bash under “default shell.” you may prefer another shell so choose your favourite.
  5. We use the server’s hostname as the “Full Name” field.
  6. Choose a strong password. If you follow these instructions, it is possible you will never need to use it to set up the GetBack system.
  7. Save the user and go to your terminal emulator

Setting Up the SSH Tunnel

  1. In your terminal window shell into the root account on the FreeNAS box.
  2. Check the free capacity of the volume you are going to use.
    df -h
    If you are using more space than you expect, you can use the du command to find out which user is taking too much space. cd into Bin2230 (or whatever you named your volume.
    cd /mnt/Bin2230
    The following command gives you a summary of the sizes of the user folders in that directory:
    du -hs ./*
    If there is not enough space, choose a different volume or add drives to this volume.
  3. Since there was enough space, or you made enough space, switch to being the new webserver_02 user.
    su – webserver_02
  4. The previous instruction put you into webserver_02′s home directory and gives you all rights and path options that webserver_02 has. Now to make things easier later, we generate a ssh key for webserver_02. Depending upon how you choose to do your restores, you might want to make the ssh tunnel a 2-way street. For now, we are going to have a one-way tunnel from webserver_02 to this user’s space on FreeNAS.
    Leave the passphrase empty
    Note the default location of the keys generated .ssh/id_rsa and .ssh/ we will be using them later.
  5. shell into webserver-02:
    ssh root@
    Note: In our LAN the entry is always into a private IP address. You may use FQDNs as well when needed.
  6. Now we are root on webserver-02. To complete our one-way ssh tunnel:
    Leave the passphrase blank
  7. We need to copy root@′s public key. You can do it this way:
    cat .ssh/ | ssh webserver_02@ ‘cat >>.ssh/authorized_keys’
    This command will prompt you for the password of the webserver_02 user and append the key to that user’s authorized_keys file.
    Since my workstation is a Linux machine with a GUI frontend, I do it like this:
    less .ssh/
    Copy line 1 (The only line in the file with content)
    exit #ends ssh session and puts me back on FreeNAS as user webserver_02
    vi .ssh/authorized_keys
    i (or hit [Insert] key)
    [Ctrl][Shift][v] #pastes the key in the first line (.ssh/authorized_keys did not exist for this user before you added it.)
    [Esc] :wq
  8. Shell back into webserver-02
    ssh root@
  9. Test your one-way tunnel by shelling back into the FreeNAS server
    ssh webserver_02@
    You will need to say ‘yes’ to add this new machine to root@webserver-02′s .ssh/known_hosts file.
    If it didn’t prompt for a password, your one-way tunnel is complete.

Uncompress the GetBack Applications

  1. Type
    to close the ssh session on the FreeNAS server.
  2. Type
  3. cd GetBack/
  4. Inside that folder, you will find 2 files and

Making the Backup Run

You want the backup file to run without having to stipulate a path, so it is easiest to make a shortcut or alias to the file from a place that is in every users’ path. You will always run the script as root, of course.

  1. cd /usr/local/sbin
  2. ln -s /root/GetBack/ # Soft link to the file in /root
  3. cd – # The hyphen takes you back to your previous location
  4. Make sure the script is executable:
    ls -l # Should have three “X”s in the first column if not then
    chmod +x

Making GetBack Run Automatically

Make a Cron job:

  1. crontab -e # this opens a file editor
  2. On the last line of the file, type:
    @daily /usr/local/sbin/ # This makes the application run every day
    # at Midnight. There are lots of other
    # crontab directives that let you set your
    # timing very granularly. Here we are
    # concerned with simple and quick.
  3. Add a line return at the end of the crontab sheet and save then exit.


MySql and Postgresql have bundled data-dump scripts and we can use those inside the GetBack system. The databases have to be properly data-dumped as well as having their files saved. This makes it more likely that all the databases, schemas and users are properly reproduced when an error occurs requiring a restoration of the data.

Data-Dumping MySQL

The MySql Data-Dump command is included in the main backup script

To use this functionality, you need to put the MySQL root password into line 63 of replacing the placeholder, “YOURSECRETPASSWORD”

Testing the MySQL Data Dump

To test the MySQL data dump directive, type:

h=`hostname` # Those are back-ticks around the word hostname, not
# regular single-quotes

The next command all goes on one line:

mysqldump -u root -pYOURSECRETPASSWORD –all-databases > ~/”$h”_mysql_dumpall.sql

You should see a new file in /root/ called


Data-Dumping PostgreSQL

Since the possix user postgres user has to run the postgresql dump, there is a short sequence that must be done to make sure it is in the right place.

  1. Copy the script tp the postgres user’s home folder:
    cp /var/lib/postgresql
  2. Change ownership of the file to the postgres user:
    chown -R postgres:postgres /var/lib/postgresql

The postgresql dump script is designed to run at the time of your choosing and to purge old data dumps after seven days. There should never be a data-dump tarball in the postgres user’s home folder older than seven days after you run the script. We run this script every day, even if we run the GetBack incremental backup once a week.

  1. su – postgres
  2. crontab -e # New scheduled task for the postgres user.
  3. On the last line of the file, type:
    @daily /var/lib/postgresql/
  4. Add a line return, so there is a blank line at the bottom of the file, and save then close the file.

Test the PostgreSQL Data Dump

As the postgres user, type:


It may take a few minutes to run the dump, especially if you have a large database.

ls -l

You should see 2 new files in the postgres user’s home folder:

webserver-01_pg_dumpall.sql # This is the full dump and is always the only and
# up to date, as the old ones are overwritten by
# each new dump.



The tarballs are dated (down to the minute). All of the tarballs here are copied into the staging directory every time the main backup runs. This means there are going to be up to 8 incremented full backups of this data dump in every GetBack run. You will not be able to lose your data unless you really work at it.



to go back to being the root user

Pointing the Train Down the Tunnel

On line 114 of the file is the directive that sends your backups to the FreeNAS server.

rsync -av “${directory1}”*tar.gz utility01@

replace the word utility01 with your server name. In the case of our example, that would be

rsync -av “${directory1}”*tar.gz webserver_02@

This will move all available complete tarballs from your /backup/ directory to the remote server.

Testing the Whole Thing

as root, type:

You will see output from the several tar commands letting you know that it is removing trailing slashes. When your command line is returned to you, type exit to end your ssh session and return to the FreeNAS server session as webserver_02.


ls -Rlh

You will see a new folder called “back” in which your tarball resides.

Now the hard part. Multiply your file’s size by 30 to see how big the webserver_02 folder will be in 30 days.