Backups & snapshots

Encrypted config snapshots, retention, Full-DR capture and restore.

What gets backed up

Config backups capture your IdP's configuration objects via its API: applications/clients, providers, flows, stages, policies, groups, mappings, zones, hooks, and more (the exact set depends on the provider). Each backup is a complete point-in-time snapshot, encrypted with a per-tenant data key before it touches disk.

Scheduling & retention

Each tenant has its own schedule (Daily/Weekly/Monthly with a time, or custom cron for anything else) and a retention count - how many snapshots to keep. Schedules run in the org timezone set in Administration > System settings. Backups queue and run one at a time, so same-time schedules never overload the host. Old snapshots past the retention count are pruned automatically after each successful backup. Manual backups any time with Backup config now.

Background jobs & the Activity area

Backups and Users & Access restores run as background jobs. Starting one returns immediately; you don't need to keep the page (or even the browser) open for it to finish. Everything queued or running, including scheduled backups, appears in the Activity area at the bottom of the sidebar with live progress, and clicking an entry opens that tenant. Jobs run one at a time in the order they were started. If the app restarts mid-run, the interrupted job is marked failed and can simply be re-run.

Snapshots

• Type & Status - every row shows whether the backup was scheduled or manual and whether it succeeded. Failed backup attempts appear in the list with their error instead of disappearing.
• Browse - open any snapshot and inspect every object in it (searchable).
• Compare - select any two snapshots and see exactly what was added, removed, or changed between them. The snapshot list also shows a per-snapshot change summary vs the previous backup.
• Restore… - see the Config restore doc.
• Delete - admins can select any number of backups (config or Users & Access, or select all) and permanently delete them. Deleting requires re-entering your password, and every deletion (and denied attempt) is recorded in the audit log.

Restore history

Every restore preview and apply is permanently recorded: who ran it, when, from which snapshot, and a summary. Each page shows its own history - config restores and previews on the Backups page, Users & Access restores on the Users & Access page. View reopens the full per-object report exactly as it looked at run time - the audit trail for restores. The list shows actual restores by default; tick include previews to see recorded dry-runs too. Applying a restore prompts for a justification (recorded in the history, shown in the report, and included in the Restores alert; a System setting can make it required) and re-verifies your password, the same protection as deleting backups - wrong attempts are audit-logged.

Find in backups

Search the change history for any object by name (an app, group, policy, or - on the Users & Access page - a user, membership, or assignment). Results show the object's full change timeline, and for deleted objects, the last snapshot where it was present with a Restore shortcut straight to it. The same search box exists on each tenant's Activity page for the raw event list. Objects that never changed while IdPVault was watching have no history to search - use Browse on a snapshot for those.

What backups can't include

Identity providers deliberately redact secret material (client secrets, private keys, SAML signing certificates) from their export APIs; no backup product can capture them. A restored app therefore comes back with regenerated credentials; the restore report flags exactly which ones.

Full-DR for self-hosted Authentik

Optionally add a Postgres URL to an Authentik tenant and every config snapshot also stores an encrypted pg_dump of the Authentik database, the belt-and-suspenders option for self-hosters.

The URL format is postgresql://user:password@host:5432/dbname, and it must be reachable from the IdPVault container. If the password contains special characters (@ : / #) they must be URL-encoded (@ becomes %40) - the tenant form rejects a URL it cannot parse when you save. If a dump ever fails after that (database unreachable, credentials rotated), the snapshot's Full-DR column shows a red dump failed tag and a Full-DR dump FAILED alert fires through the Config Backups alert group - a configured Full-DR that stops working is never silent.

Note: dumps can be large even for small instances, because the database includes Authentik's event logs. Each retained snapshot keeps its dump, so factor Full-DR into your retention count. The Full-DR event and session data option on the tenant form can exclude ephemeral and history rows (login sessions, background task logs, event history) from the dump - typically a 90%+ size reduction. The tables stay in the dump so restores boot clean; users sign in again after a full-DR restore, and historical events are not included.

Full-DR restore (replace the database)

Any snapshot with a dump has a red Restore DB... button in its Full-DR column (global admins only). It applies the dump back onto the tenant's configured Full-DR database - full credential recovery, including password hashes and MFA devices, the one thing an API restore cannot bring back. The target is always the tenant's own Full-DR URL; to restore into a fresh instance, point that URL at the new database in tenant settings first.

The guardrails, in order: a preflight probes the target and refuses anything that is not an Authentik database or empty (so a mistyped URL cannot destroy some other application's data); a rescue dump of the current database is saved (encrypted, under the tenant's data folder) before anything is written - skippable only via an explicit acknowledgment for the case where the current database is too broken to dump; the apply requires a justification, your password, and typing the tenant's slug (shown in the dialog); and the restore itself runs in a single transaction with stop-on-error, so any failure rolls back and leaves the database exactly as it was. It runs as a background job with real percent progress and is recorded in restore history with a full report.

Afterward: restart the Authentik server and worker containers, everyone signs in again, and if the API token IdPVault uses was created after the snapshot, recreate it and update the tenant settings.