Documentation

19. Backing Up and Restoring Tower

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.

[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

19.1. Backup/Restore Playbooks

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:

  • To backup the configuration files, keys, and other relevant files, plus the database of the Tower installation.
  • To restore the backed up files and data to a freshly installed and working second instance of Tower.

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.

19.2. Backup and Restoration Considerations

  • Disk Space: Review your disk space requirements to ensure you have enough room to backup configuration files, keys, and other relevant files, plus the database of the Tower installation.
  • System Credentials: Confirm you have the system credentials you need when working with a local database or a remote database. On local systems, you may need root or 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.
  • 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.
  • When using 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)