备份与保留

备份命令，以及备份、作业和审计记录的保留时长

示例
变量

修改这些变量，以控制数据库保留多少历史记录，以及磁盘上保留多少个备份。

示例

已完成的作业保留 90 天，审计记录保留两年。在 compose 项目的 .env 中：

JOB_RETENTION_DAYS=90
AUDIT_RETENTION_DAYS=730

每日任务会在凌晨 2:30 删除早于此期限的已完成作业，在凌晨 3:30 删除审计条目。正在运行的作业或等待批准的作业永远不会被删除。在设置页面上修改这两个变量后，无需重启即可生效。

变量

本组的所有变量，包括其类型、默认值和描述：

变量	可选值/默认值	说明
OLD_BACKUP_DAYS number added in version 4.0.3	默认值： 60	Backup retention (days) a whole number where 0 disables the cleanup 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	默认值： 30	Nightly backups kept a whole number where 0 disables the cleanup Number of automated nightly backups to retain. AnsibleForms 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	默认值： 365	Audit log retention (days) a whole number where 0 keeps every entry 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	默认值： 90	Job history retention (days) a whole number where 0 keeps jobs for ever 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 90 days since 7.6.0; before, the default 0 kept everything. Set 0 to keep every job for ever.
UPGRADE_BACKUP number added in version 7.0.0	默认值： 1	Back up the database before an upgrade 0, 1 Before upgrading from an older release, the worker takes a regular backup (it shows on the Backups page, named after the release), then upgrades. If the backup fails (no `mysqldump`, BACKUP_PATH not writable) the upgrade stops and says why, and the app does not start on a half-upgraded database. A fresh install needs no backup, and one is taken once per release. 0 upgrades without a backup. The patches applied, and by which release, are recorded in the `schema_migrations` table.
MYSQLDUMP_COMMAND string added in version 6.0.0	默认值： mariadb-dump --ssl-verify-server-cert=OFF	Database dump command a valid mysqldump 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	默认值： mariadb --ssl-verify-server-cert=OFF	Database restore command a valid mysql 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	默认值： 3600	Backup and restore timeout (seconds) 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.