The ability to backup and restore your system(s) has been integrated into the Tower setup playbook, making it easy for you to backup and replicate your Tower instance as needed.
Note
When restoring, be sure to restore to the same version from which it was backed up. However, you should always use the most recent minor version of a release to backup and/or restore your Tower installation version. For example, if the current version of Tower that you are on is 3.0.0, 3.0.1, or 3.0.2, use only the 3.0.2 installer.
The Tower setup playbook is invoked as setup.sh from the path where you unpacked the Tower installer tarball. It uses the tower_setup_conf.yml and inventory files written by the Tower Installation Wizard. The setup script takes the following arguments for backing up and restoring:
-b Perform a database backup rather than an installation.-r Perform a database restore rather than an installation.As the root user, call setup.sh with the appropriate parameters and Tower backup or restored as configured.
root@localhost:~$ ./setup.sh -b
root@localhost:~$ ./setup.sh -r
A default restore path is used unless EXTRA_VARS are provided with a non-default path, as shown in the code example below:
root@localhost:~$ ./setup.sh -e 'restore_backup_file=/path/to/nondefault/location' -r
In addition to the install.yml file included with your setup.sh setup playbook, there are also backup.yml and restore.yml files for your backup and restoration needs.
These playbooks serve two functions:
The backup.yml file looks like the following:
---
- hosts: primary
gather_facts: yes
roles:
- backup
And is called within setup.sh as:
b)
PLAYBOOK="backup.yml"
TEMP_LOG_FILE="backup.log"
OPTIONS="$OPTIONS --force-handlers"
;;
The restore.yml file looks like the following:
---
- hosts: primary
gather_facts: yes
roles:
- restore
And is called within setup.sh as:
r)
PLAYBOOK="restore.yml"
TEMP_LOG_FILE="restore.log"
OPTIONS="$OPTIONS --force-handlers"
;;
When restoring your system, Tower checks to see that the backup file exists before beginning the restoration. If the backup file is not available, your restoration will fail.
Note
Ensure your Tower host(s) are properly set up with SSH keys or user/pass variables in the hosts file, and that the user has sudo access.
sudo access, depending on how credentials were setup. On remote systems, you may need different credentials to grant you access to the remote system you are trying to backup or restore.setup.sh to do a restore, -r is still required in order to do the restore, but it no longer accepts an argument. If a non-default restore file path is needed, the user must provide this as an extra var (-e 'restore_backup_file=/path/to/nondefault)