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.
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
inventory files written by the Tower Installation Wizard. The setup script takes the following arguments for backing up and restoring:
-bPerform a database backup rather than an installation.
-rPerform 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.
[email protected]:~$ ./setup.sh -b
[email protected]:~$ ./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:
[email protected]:~$ ./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
restore.yml files for your backup and restoration needs.
These playbooks serve two functions:
backup.yml file looks like the following:
--- - hosts: primary gather_facts: yes roles: - backup
And is called within
b) PLAYBOOK="backup.yml" TEMP_LOG_FILE="backup.log" OPTIONS="$OPTIONS --force-handlers" ;;
restore.yml file looks like the following:
--- - hosts: primary gather_facts: yes roles: - restore
And is called within
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.
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.
sudoaccess, 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.shto do a restore,
-ris 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 (