How to back up and restore Red Hat Ansible Automation Platform

The two main reasons a Red Hat Ansible Automation Platform (AAP) admin needs to back up their AAP environment are:

1. To save a copy of the data from your AAP environment, so you can restore it if needed.
2. To use the backup to restore the environment into a different set of servers if you're creating a new AAP cluster or preparing for an upgrade.

This article explains how to back up and restore AAP. It's applicable for either of these scenarios, but I'll provide specific guidance for scenario #2 (AAP migration or upgrade) in a follow-up article. In all cases, the recommended and safest process is to always use the same versions of PostgreSQL and AAP to back up and restore the environment.

[ Need more on Ansible? Take a no-cost technical overview course from Red Hat. Ansible essentials: Simplicity in automation technical overview. ]

Make a backup

You make a backup using the same setup.sh script that you use to install Ansible Automation Platform. It also makes sense to use the same inventory file that you used on the installation.

You just need to pass an additional flag -b when invoking the setup.sh command.

Here is one example running as the root user (the script requires root access):

# ./setup.sh -b

It's similar if you need to run it using sudo:

$ sudo ./setup.sh -b

Here is a more elaborate scenario:

$ ./setup.sh -b -- -b -u admin -e@vault.yml --ask-vault-password

In the latter command:

1. The initial part, ./setup.sh -b, runs the backup (as in the other examples).
2. The double dashes -- are a way to pass arguments to the internal playbook that setup.sh calls.
   • The second -b parameter tells Ansible to "become" an elevated user, which by default is root.
   • -u admin informs the playbook to connect as the user "admin" (which in my environment is allowed to sudo to root without a password).
   • -e@vault.yml reads variables from a file encrypted with the ansible-vault command because I don't want passwords defined in clear text inside my inventory file.
   • --ask-vault-password tells Ansible to prompt me for the password to decrypt vault.yml when I invoke the script.

These are different ways to do the same thing, depending on how strict your environment is. In the end, you expect to see something like this:

PLAY RECAP *********************************************************************
aapah.example.com          : ok=41   changed=12   unreachable=0    failed=0    skipped=87   rescued=0    ignored=0   
aapcontrol.example.com     : ok=82   changed=44   unreachable=0    failed=0    skipped=93   rescued=0    ignored=0   
localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

Image

Make sure that you have the mandatory -b (for backups) parameter in your execution, otherwise setup.sh just installs or reinstalls AAP.

[ Write your first Ansible playbook in this hands-on interactive lab. ]

Check the result

You should get something similar to this if your backup succeeds:

$ ll *backup*
-rw-------. 1 root root 4.3G Mar  4 17:41 automation-platform-backup-2023-03-04-17:34:16.tar.gz
lrwxrwxrwx. 1 root root  132 Mar  4 17:41 automation-platform-backup-latest.tar.gz -> /home/rnozaki/tools/ansible/ansible-automation-platform-setup-bundle-2.3-1.4/./automation-platform-backup-2023-03-04-17:34:16.tar.gz
-rw-r-----. 1 root root 439K Mar  4 17:42 backup-2023-03-04-17:34:13.log

Image

The long file name ending with tar.gz is the backup result, with a time stamp showing when it was taken.

The command also creates a link called automation-platform-backup-latest.tar.gz, which (as the name implies) always points to the latest backup.

Restore a backup

If you are restoring the backup to the same system where it was made, you just need to run the setup.sh script again, but this time pass the argument -r instead of -b.

If you want to restore from the latest backup, the command automatically uses the "latest" file and points to the link I mentioned before.

If you need to restore from an older backup, you have two options:

1. Point the link automation-platform-backup-latest.tar.gz to the file you really want, and then run setup.sh -r. This makes the selected file the official "latest" one:

   # unlink automation-platform-backup-latest.tar.gz
   # ln -s <your-other-backup-file> automation-platform-backup-latest.tar.gz
   # ./setup.sh -r

2. Pass an alternative backup file to restore, for one-time use:

   # ./setup.sh -e 'restore_backup_file=/path/to/nondefault/backup.tar.gz' -r

   These examples run the command as root. For brevity, I'm not showing all the other variations like I did for backup execution.

After the restoration is done, you may need to restart the AAP services on your controller(s) before you can log in again:

# automation-controller-service start         # Do this as root

[ Download now: A system administrator's guide to IT automation. ]

Final thoughts

Some additional ideas to consider:

1. To perform a simple restore test on the same cluster, you can create a dummy Organization or Job Template in AAP right after you make the backup, and verify when you restore that those test objects are gone. You could also delete something (unimportant) before restoring to verify that it was recovered.
2. You can restore your backup to another AAP cluster; this is one of the principles I will cover in an upcoming AAP upgrade and migration article. You could also do this to restore your backed-up AAP to a clone (a lab, for instance). The main requirements are:
   • The target AAP you are restoring to must be the same version as the one used for the backup. That includes the PostgreSQL version. This is because to be able to restore a database, the same database structure and the features handled by setup.sh and the playbook behind it must exist.
   • If you are restoring to a different cluster, you need a separate inventory. Pass it as an additional parameter to the script, if you are running from the same directory where the backup was taken:

     # ./setup.sh -r -i <inventory file>

   • Instead, if you just copy the backup file (the tar.gz) to another server or directory with the same Ansible installer and have the other inventory file defined there, you don't need to specify it separately.
3. AAP has different components and containers. To handle all the new elements, pay close attention to the available disk space required for the controller, automation hub, and database servers.

You can read more about backup and restore in the documentation.

I leave you with one final thought based on my experience: a backup doesn't have much value unless it can be restored.