Learn Authentik - Backup & Disaster Recovery

#Introduction

Episode 25 gave you eyes to see problems: metrics and alerts that tell you when Authentik starts drifting from a healthy state. But seeing a problem and being able to recover from a problem are two different things. A server can burn, a disk can fail, a database can be wiped by human error, or an entire cluster can be lost due to a configuration mistake. The question isn't "will this happen?", it's "when this happens, can your data come back?".

That's this episode's topic: backup and disaster recovery. Think of a backup like an emergency savings fund — never pleasant to prepare, but when a crisis comes, it's the difference between a minor disruption and a devastating disaster. For an identity provider, data loss means more than just losing configuration: all users, access policies, and authentication flows vanish with it. Let's break down what you actually need to secure.

#What Must Be Backed Up

Authentik's source of truth lives almost entirely in PostgreSQL. Inside it are stored users, groups, applications, providers, flows, stages, policies, events, and all configuration. The official documentation states firmly: without the database, Authentik cannot be restored to a usable state. This is the absolute priority.

Besides the database, there are several supplementary layers:

Blueprints and templates — the /blueprints directory stores the blueprints you write, and /custom-templates holds UI modifications (episode 20). Both are recommended for backup, because they can contain logic not stored in the database.
Secrets and keys — AUTHENTIK_SECRET_KEY, database credentials, API tokens, and the signing certificates for JWT and SAML. Losing these doesn't erase data, but it makes tokens and sessions unverifiable, and providers depending on the old certificates will reject them.
Declarative configuration — values.yaml in Kubernetes, or docker-compose.yml and .env in Compose. These values explain how Authentik should run.

Redis doesn't need a backup: it's a cache and message queue. If Redis is lost, the system refills the cache and continues the queue — a far lighter loss than the database.

#Database Backup: pg_dump and the Right Strategy

PostgreSQL provides native backup tooling: pg_dump for a single database, and pg_dumpall for cluster level (roles, global access rights). The custom format (-Fc) is recommended because it's compressed, can be restored in parallel, and allows selective restore. Remember to exclude the system databases template0 and template1.

Dump the database to custom format

pg_dump -h localhost -U authentik -Fc \
  -f authentik_20260803.dump authentik

In a Docker Compose setup, run the dump from inside the database container:

pg_dump from the Postgres container

docker compose exec postgresql pg_dump -U authentik -Fc \
  -f /tmp/authentik.dump authentik
docker compose cp postgresql:/tmp/authentik.dump ./backups/

The next key: don't store backups on the same machine as the data. A failed disk usually takes the backups on it with it. Keep a copy off the host — object storage like S3/R2, another NAS, or a separate storage bucket — ideally in a different geographic location than production.

#Configuration Backup: Exporting Blueprints

Authentik configuration can be exported as a blueprint — a sort of "source code" for every object in the database. The ak export_blueprint command is run inside the worker container:

Export a blueprint of the whole configuration

docker compose exec worker ak export_blueprint > config.yaml

The result is a single YAML file containing a list of all objects: flows, stages, policies, providers, and more. Two important notes: write-only fields (for example an OAuth provider's client secret) are not exported, and default values are skipped. That means this blueprint isn't a replacement for a database backup — it's a complement useful for migration and reproducing configuration in other environments, plus an additional source of truth that can be reviewed as code.

Because it's text, this blueprint is very convenient to store in version control — you can see the history of configuration changes with just a git diff config.yaml before committing a new version. This turns "who changed what and when" into a trackable record, exactly like the Infrastructure as Code practice from episode 21.

#Scheduling and Automating Backups

Manual backups only work if they're remembered — and in the middle of a busy day, "remember later" almost always means "never". Automation is the only way to make backups actually run every day. On Linux, cron is a sufficient tool:

Note the -T option on docker compose exec: it disables TTY allocation, which is required so the command can run from cron without an interactive terminal. Stamp the result with the date in the file name so the backup history can be governed by a retention policy (for example keep 7 daily, 4 weekly, 12 monthly).

Tip

Don't forget to notify the appropriate people when a backup fails. A cron script failing silently in the middle of the night only becomes known when it's needed — and by then it's too late. Send failure notifications via cron output, or hook the backup script into the alerting system from episode 25.

#Secrets and Signing Keys: Secure Yet Available When Needed

This is the part where people often get stuck. AUTHENTIK_SECRET_KEY is used to sign sessions and various cryptographic operations. If this key is rotated, all existing sessions are invalidated. For disaster recovery, the rule is simple: store the same key in a safe place — a password manager, a secret manager like Vault, or a locked filing cabinet — and make sure the authorized people know how to access it.

The same applies to the JWT and SAML signing certificates. JWT certificates can be regenerated, but changing them rejects already-issued tokens. SAML certificates must be re-registered at the service provider if they change. Backing up the certificates along with their private keys (in an importable format) saves you from the work of re-registering across many applications.

#Disaster Recovery Procedure

Disaster recovery isn't a single command, it's a documented procedure. Start by establishing two numbers:

RPO (Recovery Point Objective) — how much data loss is acceptable at most. Daily backups mean an RPO of about 24 hours; backups every 6 hours mean an RPO of 6 hours.
RTO (Recovery Time Objective) — how quickly the service must recover. This determines how automated and ready-to-use the procedure is.

The recovery procedure in general:

Prepare empty infrastructure (a Compose stack or new cluster) with the same version.
Restore the database before starting Authentik — this is the correct order per the official documentation.
Restore the /blueprints and /custom-templates volumes if present.
Set AUTHENTIK_SECRET_KEY and database credentials to the same values as production.
Start the services and verify.

Restoring the database from a custom-format dump uses pg_restore:

Restore the database from a dump

pg_restore -h localhost -U authentik -d authentik \
  --clean --if-exists authentik.dump

The --clean --if-exists options ensure old objects are dropped before being recreated, so a restore can run into an already-populated database without duplication errors.

#Testing the Restore: The Only Way to Be Sure

Here's the most violated golden rule of backups: a backup that has never been tested is just an illusion of security. A corrupt backup file, a script pointing at the wrong target, or changed dependencies can make recovery fail exactly when it's most needed.

Important

Schedule periodic restore tests — for example monthly — into a separate (staging) environment. Not just making sure the file can be read, but all the way to Authentik actually running and allowing login. Count users and applications before and after the restore as a verification signal; numbers that don't match are the first alarm.

Automation also helps: an automated backup script should produce success reports that can be monitored. A backup failing silently every night is a time bomb — the alerting from episode 25 can be leveraged to monitor the status of the backup job itself.

#Closing

In this episode 26, you learned that Authentik backup centers on PostgreSQL as the source of truth, complemented by blueprints and custom templates, plus secrets and signing keys that must be securely stored yet accessible when needed. You also understood the pg_dump and pg_restore patterns with the custom format, an RPO- and RTO-based disaster recovery procedure, and why periodic restore tests are the only way to ensure a backup actually works.

Key takeaways:

The database is everything; a backup that stores its data on the same machine doesn't deserve to be called a backup.
The custom pg_dump format is the right choice: compressed and restorable selectively.
A blueprint from ak export_blueprint complements, not replaces, a database backup.
AUTHENTIK_SECRET_KEY and signing certificates must be backed up and kept confidential.
A restore that has never been tested is the same as having no backup.

A system that can be restored is a system that's safe to operate. Now that your data is secure, it's time to narrow the security gaps. In episode 27, we cover Security Hardening: replacing default secrets, strengthening AUTHENTIK_SECRET_KEY, TLS termination, rate limiting, disabling registration, password policies, enforcing 2FA, least privilege for admins, security headers, and a disciplined update cadence. See you in episode 27!