14. 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

The new backup/restore mechanism only works on systems which have been upgraded or installed as Ansible Tower 2.2. If you have an instance on an earlier version of Tower that you want to backup, for example, you must perform this process manually. For additional information, refer to: https://support.ansible.com/hc/en-us/articles/203295497-Tower-Manual-Backup-Restore

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 BACKUP_FILE 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 BACKUP_FILE

14.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"
    BACKUP_FILE=`realpath $OPTARG`
    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.

14.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.