AAP 2.6 Backup, Restore, and Disaster Recovery Guide
By Luca Berton · Published 2024-01-01 · Category: installation
Complete guide to backup, restore, and disaster recovery for AAP 2.6. Protect Automation Controller, Hub, EDA, and Platform Gateway data. Backup strategies for containerized, RPM, and Operator deployments.
Why Backup Matters for AAP
Ansible Automation Platform stores critical data that cannot be easily recreated: • Job history and output — audit trail of all automation runs • Credentials (encrypted) — SSH keys, API tokens, cloud secrets • Inventories — static host definitions and group variables • Job templates and workflows — your automation configurations • RBAC settings — users, teams, organizations, permissions • Projects — SCM configurations and sync settings • Schedules and notifications — recurring automation and alerting • EDA rulebook activations — event-driven automation configurations • Hub content — approved collections, namespaces, EE image metadata
Losing this data means rebuilding your entire automation platform from scratch.
What to Back Up
Database (Critical)
The PostgreSQL database holds all AAP state. This is the single most important backup target.
| Component | Database Contents | |-----------|-------------------| | Platform Gateway | Session data, service routing, SSO config | | Automation Controller | Jobs, inventories, credentials, templates, RBAC | | Automation Hub | Collection metadata, namespaces, approvals | | EDA Controller | Rulebook activations, event logs, credentials |
Files (Important)
| Path | Contents | |------|----------| | /etc/ansible-automation-platform/ | Configuration files | | Secret key file | Encryption key for credential storage | | TLS certificates | SSL certs for all components | | Custom EE images | If stored locally (also in Hub registry) | | Hub collection artifacts | Uploaded collection tarballs |
External Systems (Plan Separately) • Git repositories (Projects) — backed up via your SCM • LDAP/SAML identity providers — backed up separately • External secret backends (HashiCorp Vault, CyberArk) — separate backup • Load balancers and DNS — infrastructure backup
Backup Methods by Deployment Type
Containerized Deployment
The containerized installer includes backup and restore commands:
The backup includes: • PostgreSQL database dump • Configuration files • Secret keys • TLS certificates
RPM Deployment
Use the RPM installer's backup playbook:
Backup files are stored in the backup directory specified in your inventory:
Operator Deployment (OpenShift)
For Operator-managed AAP on OpenShift, use the AnsibleAutomationPlatformBackup CR:
Database-Only Backup
For more granular control, back up PostgreSQL directly:
Restore Procedures
Containerized Restore
RPM Restore
Operator Restore
Database-Only Restore
Backup Automation
Scheduled Backup Playbook
Schedule in AAP Controller
Create this playbook as a job template and schedule it:
Disaster Recovery Strategies
Strategy 1: Cold Standby
Maintain a standby environment that can be activated from the latest backup.
| Component | Primary | Standby | |-----------|---------|---------| | AAP VMs | Active | Powered off | | Database | Primary + backup | Restored from backup | | Recovery time | — | 2-4 hours | | Data loss | — | Since last backup |
Steps: Power on standby VMs Restore latest database backup Update DNS to point to standby Verify all services are operational
Strategy 2: Warm Standby with Database Replication
PostgreSQL streaming replication keeps a hot standby database synchronized.
| Component | Primary | Standby | |-----------|---------|---------| | AAP VMs | Active | Powered on, idle | | Database | Primary | Streaming replica | | Recovery time | — | 15-30 minutes | | Data loss | — | Seconds (near-zero) |
Strategy 3: Active-Active (Enterprise Topology)
The enterprise topology already provides HA for all components: • 2 Platform Gateway nodes behind HAProxy • 2 Automation Controller nodes • 2 Automation Hub nodes • 2 EDA Controller nodes • External PostgreSQL with HA (Patroni or RDS Multi-AZ)
This is not backup — it's availability. You still need backups for data protection (corruption, accidental deletion).
Testing Your Backups
Backups are worthless if you never test restores. Schedule quarterly restore tests:
Important Considerations
Secret Key Protection
The secret key (SECRET_KEY in Controller settings) is used to encrypt all credentials in the database. Without it, encrypted credentials cannot be decrypted after restore.
Always backup: • /etc/tower/SECRET_KEY (RPM) • The secret key from your containerized deployment configuration • Store securely in a separate location from database backups
PostgreSQL Version Compatibility
Per Red Hat documentation: backup and restore functionality depends on utilities provided with PostgreSQL 15. If using external PostgreSQL 16 or 17, you must use external backup and restore processes — the AAP installer's built-in backup does not support PG 16/17.
Backup Window and Performance
Database backups use pg_dump which can impact performance on large databases. Schedule backups during low-usage periods and monitor: • Backup duration • Database I/O during backup • Backup file size (monitor for unexpected growth)
FAQ
How often should I back up AAP?
Daily database backups are the minimum for production. For environments with frequent changes, consider twice daily. Always back up before upgrades or major configuration changes.
Can I restore to a different version of AAP?
No. Restore must target the same AAP version as the backup. To migrate across versions, restore first, then upgrade using the standard upgrade procedure.
What about backing up Execution Environment images?
EE images in Private Automation Hub are stored in the Hub's container registry. The database backup includes metadata but not the actual container images. Back up EE images separately using podman save or ensure they're stored in an external container registry with its own backup.
Can I do point-in-time recovery?
With PostgreSQL WAL archiving and streaming replication, yes. Configure archive_mode = on and archive_command to enable point-in-time recovery (PITR). This gives recovery to any point in time, not just the last backup.
What is the backup size for a typical enterprise deployment?
Database size varies by job history retention. A deployment running 1,000 jobs/day with 90-day retention typically has a 10-50 GB database. Compressed backups are usually 30-50% of the database size.
Conclusion
A robust backup strategy is not optional for production AAP deployments. The combination of automated daily backups, tested restore procedures, and a documented disaster recovery plan ensures your automation platform can recover from any failure scenario. Test your restores regularly — an untested backup is not a backup.
Related Articles • AAP 2.6 Architecture and Components: Complete Guide • AAP 2.6 Security Best Practices • AAP 2.6 Upgrade Guide from 2.5 • Backup Ansible Automation Platform • Restore Ansible Automation Platform
Category: installation