<p>All you need is a backup of the postgres database and the projects (to be safe but they should be rebuildable by pulling them again from your VCS in most cases).</p>

<ul>
<li>Exporting an ovf of you full vm is really an overkill IMHO.</li>
<li>Copying the volumes (pgdata and projects) is by far the simplest solution (the one I actually use). You simply have to put the folders back in place, and <code>docker-compose up -d</code> the correct version and you are set. <strong>But</strong> to make sure your backup is consistent, <strong>you need to stop AWX before copying the dirs</strong>, especially for postgres. </li>
<li>Dumping the postgres database and copying the projects will let you do a backup while AWX is running. For your recovery, you will have to first pop-up a posgres container and reinject the dump before starting all the other containers.</li>
</ul>

<p>Keep in mind that AWX is the dev version of Tower. As such, there is no real "recommendation" for backups. So the above explanation simply reflect my own experience with AWX. The commercial Tower version embarks the backup in it's deployment playbook. I have never played with it.</p>

<p>If you did not experienced with an AWX upgrade yet, you should be aware that they are sometimes working but can be a real pain (export from old version / import to new version / re-set all the user passwords and jobs credentials). So a backup to quickly rollback when testing the upgrade is <em>vital</em> in this case.</p>

<p>Hope this will help you make a wise choice ;)</p>

CC BY-SA 4.0
2019-03-28T21:09:29.093Z
2019-03-28T21:09:29.093Z
Zeitounator
<p>Currently we have an <code>awx</code> running on a <code>VM</code> using containers:</p>

<pre><code>CONTAINER ID     IMAGE                        COMMAND                  CREATED             STATUS              PORTS                                                 NAMES
dfb9fa57a8eb    ansible/awx_task:latest      "/tini -- /bin/sh -c…"   2 months ago        Up 6 days           8052/tcp                                              awx_task_1
60dcb5340ca5    ansible/awx_web:latest       "/tini -- /bin/sh -c…"   2 months ago        Up 6 days           0.0.0.0:80-&gt;8052/tcp                                  awx_web_1
e80aaddee738    postgres:9.6                 "docker-entrypoint.s…"   2 months ago        Up 6 days           5432/tcp                                              awx_postgres_1
54f20decccfe    ansible/awx_rabbitmq:3.7.4   "docker-entrypoint.s…"   2 months ago        Up 6 days           4369/tcp, 5671-5672/tcp, 15671-15672/tcp, 25672/tcp   awx_rabbitmq_1
0e7ed8c75796    memcached:alpine             "docker-entrypoint.s…"   2 months ago        Up 6 days           11211/tcp                                             awx_memcached_1
</code></pre>

<p>What is the recommended way for backing up our <code>awx</code> instance:</p>

<p>a) Take an export of the VM using <code>ovf</code>?</p>

<p>b) Just copying the volume where the pgdata is held enough?</p>

<p>c) Running </p>

<pre><code>docker exec -t &lt;postrges_container_id&gt; pg_dumpall -c -U postgres &gt; dump_`date +%d-%m-%Y"_"%H_%M_%S`.sql
</code></pre>

<ansible><backup><awx>
How to take a backup of Ansible tower?
pkaramol
# How to take a backup of Ansible tower?

(Asked by: username_0 on 2018-08-20)

Currently we have an awx running on a VM using containers:
CONTAINER ID     IMAGE                        COMMAND                  CREATED             STATUS              PORTS                                                 NAMES
dfb9fa57a8eb    ansible/awx_task:latest      "/tini -- /bin/sh -c…"   2 months ago        Up 6 days           8052/tcp                                              awx_task_1
60dcb5340ca5    ansible/awx_web:latest       "/tini -- /bin/sh -c…"   2 months ago        Up 6 days           0.0.0.0:80->8052/tcp                                  awx_web_1
e80aaddee738    postgres:9.6                 "docker-entrypoint.s…"   2 months ago        Up 6 days           5432/tcp                                              awx_postgres_1
54f20decccfe    ansible/awx_rabbitmq:3.7.4   "docker-entrypoint.s…"   2 months ago        Up 6 days           4369/tcp, 5671-5672/tcp, 15671-15672/tcp, 25672/tcp   awx_rabbitmq_1
0e7ed8c75796    memcached:alpine             "docker-entrypoint.s…"   2 months ago        Up 6 days           11211/tcp                                             awx_memcached_1

What is the recommended way for backing up our awx instance:
a) Take an export of the VM using ovf?
b) Just copying the volume where the pgdata is held enough?
c) Running 
docker exec -t  pg_dumpall -c -U postgres > dump_`date +%d-%m-%Y"_"%H_%M_%S`.sql

**Tags:** ansible, backup, awx


---

## 1 answers

### Answer by username_1 on 2019-03-28. Score: 2

All you need is a backup of the postgres database and the projects (to be safe but they should be rebuildable by pulling them again from your VCS in most cases).

* Exporting an ovf of you full vm is really an overkill IMHO.
* Copying the volumes (pgdata and projects) is by far the simplest solution (the one I actually use). You simply have to put the folders back in place, and `docker-compose up -d` the correct version and you are set. **But** to make sure your backup is consistent, **you need to stop AWX before copying the dirs**, especially for postgres.
* Dumping the postgres database and copying the projects will let you do a backup while AWX is running. For your recovery, you will have to first pop-up a posgres container and reinject the dump before starting all the other containers.

Keep in mind that AWX is the dev version of Tower. As such, there is no real "recommendation" for backups. So the above explanation simply reflect my own experience with AWX. The commercial Tower version embarks the backup in it's deployment playbook. I have never played with it.

If you did not experienced with an AWX upgrade yet, you should be aware that they are sometimes working but can be a real pain (export from old version / import to new version / re-set all the user passwords and jobs credentials). So a backup to quickly rollback when testing the upgrade is *vital* in this case.

Hope this will help you make a wise choice ;)


---

