Backups and retention
The backup commands, and how long backups, jobs and audit records are kept
Change these to control how much history the database keeps, and how many backups stay on disk.
Example
Keep finished jobs for 90 days and the audit trail for two years. In the compose project’s .env:
JOB_RETENTION_DAYS=90
AUDIT_RETENTION_DAYS=730
A daily task removes finished jobs older than this at 2:30 AM and audit entries at 3:30 AM. A running job, or one that waits for approval, is never removed. Both variables apply without a restart when they are changed on the settings page.
Variables
Every variable of this group, with its type, default and description:
| Variable | Choices/Defaults | Comments |
|---|---|---|
| OLD_BACKUP_DAYS number added in version 4.0.3 | Default: 60 | Backup retention days
When backups are made, they are kept for this many days before being removed. This applies to form backups made through the designer (not database backups). 0 keeps every restore point, matching AUDIT_RETENTION_DAYS, JOB_RETENTION_DAYS and NIGHTLY_BACKUP_RETENTION. It used to mean the opposite here - everything older than a day was removed - while the status page reported it as “never”. |
| NIGHTLY_BACKUP_RETENTION number added in version 6.1.0 | Default: 7 | Nightly backup retention count
Number of automated nightly backups to retain. Ansible Forms automatically creates a full backup (database + config + forms) every night at midnight. Older nightly backups beyond this count are automatically deleted. Set to 0 to disable automatic cleanup (not recommended). Only backups that actually contain a usable database dump count towards this number, so a run of failed backups can never push a good one out. |
| AUDIT_RETENTION_DAYS number added in version 6.3.0 | Default: 365 | Audit trail retention in days
How long entries in the audit trail are kept. The trail is append-only, so without a sweep it grows for ever; a daily task at 3:30 AM removes entries older than this. Set to 0 to keep everything. |
| JOB_RETENTION_DAYS number added in version 6.3.0 | Default: 0 | Job history retention in days
How long finished jobs and their output are kept. Job output can be large, so this is usually the fastest growing table in the database; the Status page reports its size. A daily task at 2:30 AM removes finished jobs older than this, together with their output. Only finished jobs are ever removed - a running job, or one awaiting approval, is kept however old it is. Defaults to 0, which means keep everything: upgrading must never silently delete job history, so switching this on is a deliberate choice. |
| MYSQLDUMP_COMMAND string added in version 6.0.0 | Default: mariadb-dump --ssl-verify-server-cert=OFF | Database dump command
MySQL dump commands and MySQL/MariaDB flavours differ, hence the need for a configurable command. |
| MYSQL_COMMAND string added in version 6.0.0 | Default: mariadb --ssl-verify-server-cert=OFF | Database restore command
MySQL restore commands and MySQL/MariaDB flavours differ, hence the need for a configurable command. |
| BACKUP_COMMAND_TIMEOUT_SECONDS number added in version 6.3.0 | Default: 3600 | Backup/restore command timeout
How long the database dump and the database restore may run before they are killed. Both used to inherit the generic 60 second command timeout, which no real database can honour. Raise it if a large database is cut short; a restore that is killed part way leaves the database partially replayed, because the dump drops and recreates each table in turn. |