Learn Authelia - Backup & Disaster Recovery

#Introduction

Episode 26 taught you how to observe Authelia: logs, metrics, and alerting tell you when there's a problem. But observability doesn't save data. If the Authelia database is damaged without a backup, every user must re-register all their MFA devices — TOTP, WebAuthn, everything — all at once. That's not just a tedious night; it's a loss of trust.

Episode 27 arranges a backup and disaster recovery strategy: what must be saved, how to schedule and secure it, how to restore during a disaster, up to secret rotation. Backup is insurance — boring when everything is fine, priceless when everything falls apart.

#What Must Be Backed Up

Authelia stores important data in several places. The complete list:

Note the impact hierarchy. Losing Redis sessions only forces a re-login. Losing the storage database is a medium disaster: users can still log in with a password, but all second factors are gone. Losing the secrets means the encrypted MFA data in the database becomes unreadable — even existing backups are useless if they don't include the keys.

#Backup Strategy

Apply the 3-2-1 rule: three copies of the data, on two different media, one at a separate location. For the Authelia components:

• PostgreSQL. A logical backup with pg_dump in custom format, run as a scheduled task (cron or a K8s CronJob), then send a copy to object storage:

pg_dump -U authelia -h postgres-primary -d authelia -Fc \
  -f /backup/authelia-$(date +%F).dump

• Redis. Something that can be rebuilt doesn't need to be backed up as aggressively as a database. Take periodic RDB snapshots to recover active sessions after a mass restart:

redis-cli -a '<redis-password>' SAVE
cp /var/lib/redis/dump.rdb /backup/redis-dump.rdb

• Files. configuration.yml and users_database.yml just need to be copied, but because they contain secrets, encrypt them first. If the configuration already lives in Git with secrets separated into Vault, these files just get re-rendered from the source of truth.

#Restore Procedure

A good restore goes bottom-up in sequence. The order for a full disaster:

1. Restore the storage database first — everything else depends on it.

pg_restore -U authelia -h postgres-primary -d authelia \
  --clean --if-exists /backup/authelia-2026-08-03.dump

2. Restore the configuration file and user database to their original locations.
3. Restore the secrets exactly as they were when the backup was taken.
4. Restore Redis if you want sessions to return too; if not, old sessions are considered expired and users log in again.
5. Validate before opening the door: run authelia validate-config --config /config/configuration.yml and authelia storage schema-info to make sure the config is valid and the database schema matches, then test one login.

An untested restore is just wishful thinking. You don't want to test this procedure for the first time in the middle of a real incident.

#Secret Rotation

Rotating Authelia secrets requires understanding their side effects. The session secret is used to encrypt session data — changing it invalidates all active sessions. That's not a bug, it's a feature: when a leak is suspected, replacing the session secret is the instant way to cut all sessions.

The storage encryption key protects MFA data in the database. Authelia provides a special command to change it without losing data:

authelia storage encryption change-key --new-key '<new-key>'

Secret rotation should be a scheduled agenda, not a reaction — for example every 90 days for the session secret and JWT secret, and test the storage key rotation in a staging environment before production.

#Disaster Scenarios and RTO/RPO

Plan for disasters before they happen by setting two numbers:

• RPO (Recovery Point Objective): how far back in data you can accept. Daily backups mean an RPO of 24 hours — MFA registrations that happened since the last backup will be lost.
• RTO (Recovery Time Objective): how fast the service must return. This determines how automated your restore procedure is.

Three common scenarios and how to handle them:

Important note: in the HA architecture from episodes 24 and 25, the Authelia instance isn't "restored" — it's replaced. What's truly restored is the data: database, files, and secrets.

#Testing Backups

A backup that's never tested is a guess. Schedule regular restore drills: at least once a month, restore the dump to a separate environment, run Authelia there, and test a real login + MFA. Many teams find corrupted dumps, missing keys, or wrong procedures exactly at the first drill.

Automate as much as possible. In Kubernetes, a CronJob that runs pg_dump, encrypts the result, and uploads it to object storage removes human error from the equation. Document everything — scripts, order, and contacts — because during an incident, memory is the first thing to go.

#Closing

Episode 27 gives you Authelia's digital insurance: understanding what must be backed up along with the impact of losing it, applying the 3-2-1 strategy with pg_dump, Redis snapshots, and secret encryption, running a sequential restore with validation at the end, rotating secrets including authelia storage encryption change-key, and setting RTO/RPO and testing backups with regular restore drills.

Key points:

• The storage database is the most important asset; a lost Redis session is just a re-login.
• Secrets must be included in the backup — a backup without the key is pointless encryption.
• Rotating the session secret cuts all sessions; rotating the storage key needs a special command.
• Set RTO/RPO before a disaster, not during one.
• Test restore regularly; a backup that's never restored can't be trusted.

The infrastructure is secure and recoverable. Now how do you make it fast? In episode 28 we dissect Performance Tuning: benchmarks, Redis and database tuning, reverse proxy optimization, up to capacity planning. See you in episode 28!