Backup

Overview

Ascender uses the Ascender Operator's AWXBackup custom resource to back up your deployment. A backup captures the PostgreSQL database, encryption secrets, and the Ascender deployment configuration. The setup.sh script handles the full process: creating the backup in the cluster, waiting for it to complete, and copying the backup files to the local filesystem.

For restoring from a backup, see Restore.

This guide covers:

• Running a backup
• Verifying a backup
• Managing old backups

Prerequisites

• A working Ascender deployment installed via ascender-install
• Rocky Linux 8 or 9.
• kubectl access to the cluster with a valid kubeconfig at ~/.kube/config
• The ascender-install directory with your custom.config.yml from the original install

If you no longer have the ascender-install directory, clone it:

git clone https://github.com/ctrliq/ascender-install.git

If you already have it, pull the latest changes before running:

cd ascender-install
git pull

Copy your original custom.config.yml into the directory before running any commands.

Running a Backup

From the ascender-install directory, run:

./setup.sh -b

This creates an AWXBackup resource in the cluster, waits for the operator to finish, then copies the backup files to the local filesystem. The entire process typically takes a few minutes depending on database size.

What Gets Backed Up

Each backup contains three files:

• tower.db: a full PostgreSQL database dump containing all Ascender data (organizations, users, credentials, job templates, job history, inventories, schedules, and settings)
• secrets.yml: all encryption keys and application secrets (secret key, admin password, broadcast websocket secret, postgres configuration, TLS certificates, and receptor signing keys)
• awx_object: the Ascender deployment configuration

Where Backups are Saved

Backups are stored under the artifacts directory:

ascender_install_artifacts/backups/

Each run creates a timestamped backup directory, along with a current symlink pointing to the most recent backup.

The location of the artifacts directory depends on your configuration. By default, it is created within the Ascender install directory. If tmp_dir is set in custom.config.yml, the artifacts directory is created under that path instead.

To check:

grep tmp_dir custom.config.yml

• If tmp_dir is not set, backups are located under: ascender-install/ascender_install_artifacts/backups/
• If tmp_dir is set, backups are located under: <tmp_dir>/ascender_install_artifacts/backups/

Example:

ascender_install_artifacts/backups/
├── current -> backup-20260309T214902
└── backup-20260309T214902/
    ├── tower.db
    ├── secrets.yml
    └── awx_object

Verifying a Backup

List all backups in the cluster:

kubectl get awxbackup -n ascender

Backups are named ascender-backup-<date>-<epoch>. Check whether a specific backup completed successfully:

kubectl get awxbackup <backup-name> -n ascender -o jsonpath='{.status.conditions[?(@.type=="Successful")].status}{"\n"}'

A return value of True means the backup completed. If the backup is still running:

kubectl get awxbackup <backup-name> -n ascender -o jsonpath='{.status.conditions[?(@.type=="Running")].reason}{"\n"}'

If a backup fails, check the operator logs:

kubectl logs deployment/awx-operator-controller-manager -n ascender --tail=100

Managing Old Backups

Each ./setup.sh -b run creates a new AWXBackup resource and a corresponding directory on the backup PVC inside the cluster. These accumulate over time.

To delete a specific backup, first list the backups in the cluster:

kubectl get awxbackup -n ascender

Then delete by name:

kubectl delete awxbackup <backup-name> -n ascender

To delete all in-cluster backups:

kubectl delete awxbackup --all -n ascender

To keep only the most recent backup and delete the rest:

kubectl get awxbackup -n ascender --sort-by=.metadata.creationTimestamp -o name | head -n -1 | xargs -r kubectl delete -n ascender

Local backup archives in ascender_install_artifacts/backups/ can be managed with standard filesystem tools. Move or remove timestamped directories as needed for your retention policy.

Backup Configuration

The backup behavior is controlled by variables in your custom.config.yml (or default.config.yml):