authentik sichern und wiederherstellen (Docker Compose)

authentik sichern: was genau ins Backup gehört

authentik sichern und wiederherstellen heißt in der Praxis, vier Dinge zu kopieren und einmal zu beweisen, dass daraus wieder eine funktionierende Anmeldung wird. Diese vier Dinge sind: der Dump der PostgreSQL-Datenbank, die Datei .env mit AUTHENTIK_SECRET_KEY und PG_PASS, das Verzeichnis ./data mit Icons, Hintergründen und hochgeladenen Dateien, und die Compose-Datei mit allem, was Sie selbst dazugemountet haben. Ohne die Datenbank ist die Installation verloren, denn dort liegen Benutzer, Gruppen, Flows, Provider und Applikationen.

Wer authentik betreibt, hat eine bewusste Entscheidung getroffen: ein einziger Dienst entscheidet, wer in alle anderen Dienste hineinkommt. Eine selbst gehostete SSO-Instanz mit authentik macht den Alltag einfacher und den Ausfall teurer. Wenn der Stack stirbt, ist nicht ein Dienst offline, sondern der Login für jeden Dienst dahinter, und Sie selbst kommen auch nicht mehr in die Admin-Oberfläche.

Was die offizielle Compose-Datei definiert

Die offizielle compose.yml von authentik (abgerufen am 26. September 2026, Standard-Tag 2026.8.3) definiert drei Services: postgresql, server und worker. Die Datenbank liegt im benannten Volume database unter /var/lib/postgresql/data. Dazu kommen Bind-Mounts aus dem Projektverzeichnis: ./data nach /data in server und worker, ./custom-templates nach /templates in beiden, und ./certs nach /certs nur im worker.

Einen Redis-Service suchen Sie dort vergeblich. Seit Release 2025.10 hat authentik Redis entfernt, Cache, Tasks, eingebetteter Outpost und WebSockets laufen seitdem über PostgreSQL. Wenn Ihre eigene Datei noch einen redis-Service samt Volume enthält, stammt sie aus einer älteren Version. Sichern müssen Sie dieses Volume nicht, denn es hielt nie Zustand, den Sie nicht wiederherstellen könnten.

Der Unterschied zwischen dem benannten Volume und den Bind-Mounts entscheidet darüber, was Ihr Backup erwischt. Ein tar über das Projektverzeichnis nimmt ./data, ./certs und ./custom-templates mit, weil diese Ordner dort real existieren. Das Datenbank-Volume nimmt es nicht mit, weil es unter /var/lib/docker/volumes/ liegt. Wenn das für Sie neu ist, lohnt vorher der Unterschied zwischen Bind Mounts und benannten Volumes.

Eigene Blueprints liegen nur dann als Dateien vor, wenn Sie ein Verzeichnis nach /blueprints gemountet haben. Die Standard-Compose-Datei tut das nicht. Prüfen Sie Ihre eigene Datei, bevor Sie annehmen, die Blueprints seien im Dump mit drin.

Warum ein Provider-Snapshot keine Datenbanksicherung ist

Ein Snapshot im Panel Ihres Anbieters friert die Blöcke der virtuellen Festplatte ein, während PostgreSQL weiterschreibt. Das Ergebnis entspricht einem Stromausfall. Beim Start aus dem Snapshot spielt PostgreSQL sein Write-Ahead-Log (WAL, das Protokoll aller Änderungen vor dem Schreiben in die Datendateien) nach und kommt so auf einen konsistenten Stand zurück. Das setzt voraus, dass der Snapshot wirklich in einem Zug über das gesamte Dateisystem gezogen wurde. Kopiert der Anbieter dateiweise oder verteilt sich das Datenverzeichnis über mehrere Volumes, fehlt diese Garantie. Sie merken das erst beim Restore, also genau dann, wenn es nicht mehr hilft.

Ein Dump ist eine andere Klasse von Sicherung. pg_dump liest die Datenbank in einer einzigen Transaktion und schreibt eine logische Beschreibung: SQL-Anweisungen, die dieselben Daten neu aufbauen. Diese Datei können Sie ansehen, prüfen, verschlüsselt auf einen Storage-VPS legen und auf einem zweiten Server einspielen, ohne den produktiven Server anzufassen. Einen Snapshot prüfen Sie nur, indem Sie eine ganze Maschine daraus starten.

Nehmen Sie ruhig beides. Der Snapshot ist der schnelle Rückweg nach einem missglückten Upgrade. Der Dump ist das Backup, auf das Sie sich verlassen.

Den Dump aus dem laufenden postgresql-Service ziehen

Die Datenbank läuft im Container, also läuft pg_dump auch dort. Die Umleitung dagegen läuft auf dem Host, deshalb landet die Datei im aktuellen Verzeichnis Ihres VPS und nicht im Container.

cd /opt/authentik
docker compose exec -T postgresql pg_dump -U authentik -d authentik -cC > authentik-postgres-backup.sql

-U und -d müssen zu PG_USER und PG_DB aus Ihrer .env passen. Beide haben in der offiziellen Compose-Datei den Standardwert authentik, wer sie geändert hat, setzt hier die eigenen Werte ein. -c schreibt die passenden DROP-Anweisungen in den Dump, -C zusätzlich ein CREATE DATABASE. Das -T schaltet die TTY-Zuweisung ab und ist Pflicht, sobald der Befehl aus einem Skript oder einem systemd-Timer ohne Terminal läuft.

Danach prüfen Sie, ob der Dump vollständig ist:

ls -lh authentik-postgres-backup.sql
tail -n 1 authentik-postgres-backup.sql

Ein vollständiger Dump im Textformat endet mit der Zeile -- PostgreSQL database dump complete. Fehlt sie, ist die Datei abgeschnitten, etwa weil die Platte voll lief oder der Container mittendrin gestoppt wurde. Diese Kontrolle ist wichtig, weil die Shell die Zieldatei schon anlegt, bevor pg_dump überhaupt startet. Eine Datei existiert also auch dann, wenn der Dump fehlgeschlagen ist, und eine Datei mit 0 Bytes sieht im Verzeichnislisting genauso ruhig aus wie eine gute.

Die Dateien neben der Datenbank

Der zweite Teil des Backups ist ein Archiv des Projektverzeichnisses. Es enthält die Zugangsdaten, das Aussehen und die Struktur Ihrer Installation.

cd /opt
sudo tar -czf /root/authentik-files-$(date +%F).tar.gz -C /opt/authentik .env compose.yml data custom-templates certs
sudo chmod 600 /root/authentik-files-$(date +%F).tar.gz

Die .env ist der heikelste Teil. Sie enthält PG_PASS und AUTHENTIK_SECRET_KEY im Klartext, also gehört das Archiv auf Modus 600 und niemals in ein Git-Repository. Wie Sie solche Dateien im Compose-Alltag sauber halten, steht in Umgebungsdateien und Secrets in Docker Compose.

Das Verzeichnis ./certs brauchen Sie nur, wenn Sie Zertifikate als Dateien einlegen. Zertifikate, die Sie in der Oberfläche importiert haben, liegen in der Datenbank und sind damit bereits im Dump.

Was AUTHENTIK_SECRET_KEY wirklich schützt

Hier kursieren viele Halbwahrheiten, deshalb der Blick in die eigene Dokumentation von authentik. Dort steht zu AUTHENTIK_SECRET_KEY genau ein Satz: "Secret key used for cookie signing. Changing this will invalidate active sessions." Der Schlüssel signiert also Cookies. Wird er geändert, sind alle aktiven Sitzungen ungültig. Dazu kommt ein historischer Hinweis: vor Version 2023.6.0 diente derselbe Schlüssel auch der Bildung eindeutiger Benutzer-IDs, weshalb er auf älteren Installationen nach der Erstinstallation nicht geändert werden darf.

Daraus folgt etwas Unbequemes. Der Secret Key ist kein Schlüssel, der Ihre Datenbank verschlüsselt. Behandeln Sie den Dump deshalb so, als stünde alles darin lesbar: Tokens, Client Secrets angebundener Anwendungen, Passwort-Hashes, E-Mail-Adressen. Die Verschlüsselung Ihres Backups müssen Sie selbst beisteuern, und genau das ist weiter unten die Aufgabe von restic.

Die Compose-Datei bindet die Variable als ${AUTHENTIK_SECRET_KEY:?secret key required} ein. Fehlt sie beim Start, bricht docker compose up mit dem Text secret key required ab, statt einen Stack mit leerem Schlüssel hochzufahren. Das ist die einzige laute Rückmeldung, die Sie rund um diesen Wert bekommen.

authentik wiederherstellen: der Restore-Test auf einem zweiten VPS

Ein Backup, das nie eingespielt wurde, ist eine Vermutung. Der Test kostet einen VPS für eine Stunde. Nehmen Sie einen zweiten Server mit Docker, legen Sie /opt/authentik an und kopieren Sie compose.yml, .env sowie die Verzeichnisse aus dem Archiv dorthin. Die .env kommt unverändert mit, inklusive desselben AUTHENTIK_SECRET_KEY.

Starten Sie zuerst nur die Datenbank:

cd /opt/authentik
docker compose up --force-recreate -d postgresql
docker compose ps

Warten Sie, bis postgresql als healthy gemeldet wird. Die offizielle Compose-Datei bringt dafür einen Healthcheck mit pg_isready mit, und server und worker starten über depends_on erst danach. Wer wissen will, warum dieser Umweg im Alltag Zeit spart, findet die Begründung in einem sauberen Healthcheck für den Postgres-Service.

Jetzt spielen Sie den Dump ein:

cat authentik-postgres-backup.sql | docker compose exec -T postgresql psql -U authentik -d postgres -v ON_ERROR_STOP=1

Zwei Details in dieser Zeile sind kein Zufall. -d postgres verbindet Sie mit der Wartungsdatenbank, weil der mit -cC erzeugte Dump die Datenbank authentik löschen und neu anlegen will. PostgreSQL lässt das nicht zu, solange Ihre eigene Sitzung in genau dieser Datenbank hängt. ON_ERROR_STOP=1 sorgt dafür, dass psql beim ersten Fehler abbricht. Ohne diesen Schalter läuft das Skript bis zum Ende durch, meldet am Schluss nichts Auffälliges und hinterlässt eine halb gefüllte Datenbank.

Danach den Rest starten:

docker compose up --force-recreate -d
docker compose logs -f server

Melden Sie sich mit einem Konto aus dem Backup an. Klappt das, ist die Datenbank angekommen. Der eigentliche Beweis ist aber die zweite Prüfung: eine angebundene Anwendung muss sich noch authentifizieren lassen. Achten Sie dabei auf den Hostnamen. Redirect-URIs von OIDC-Providern und die Domain Ihrer Forward-Auth-Konfiguration stehen in der Datenbank und zeigen weiterhin auf den produktiven Namen. Auf dem Testserver arbeiten Sie deshalb mit einem Eintrag in der lokalen hosts-Datei Ihres Arbeitsrechners, sonst lehnt der Provider die Anmeldung ab, weil die aufgerufene Adresse nicht zu den hinterlegten passt. Wie diese Kette im Detail läuft, steht in Forward Auth mit Traefik und authentik.

Was Sie sehen, wenn der Secret Key nicht passt

Wenig. Das ist das Problem. Der Stack startet, die Anmeldemaske erscheint, der Dump ist eingespielt, und trotzdem stimmt etwas nicht. Weil der Schlüssel Cookies signiert, sind alle bestehenden Sitzungen ungültig: Jede Browsersitzung, die noch ein Cookie der alten Installation mitbringt, landet wieder im Login-Flow. Nach einem Wechsel des Schlüssels in einer produktiven Umgebung sind also alle Benutzer gleichzeitig abgemeldet, ohne dass ein Fehler im Log steht.

Deshalb die einfache Regel: Der Restore bekommt dieselbe .env und damit denselben Schlüssel. Ein neuer Schlüssel ist kein Datenverlust, aber er ist eine Änderung, die niemand angekündigt hat, und auf Installationen älter als 2023.6.0 hängt zusätzlich die Bildung eindeutiger Benutzer-IDs daran. Wenn Sie den Schlüssel wirklich rotieren wollen, tun Sie es bewusst und zu einer Zeit, in der eine Abmeldewelle niemanden überrascht.

DSGVO: verschlüsselt, in der EU, mit einer Löschregel

In einer authentik-Datenbank stehen Namen, E-Mail-Adressen, Gruppenzugehörigkeiten und Anmeldezeitpunkte. Das sind personenbezogene Daten, und ein Backup davon ist eine Verarbeitung wie jede andere. Art. 32 DSGVO nennt dazu zwei Punkte, die hier direkt greifen: die Fähigkeit, Verfügbarkeit und Zugang nach einem Zwischenfall rasch wiederherzustellen, und ein Verfahren zur regelmäßigen Überprüfung der Wirksamkeit dieser Maßnahmen. Der Restore-Test aus dem letzten Abschnitt ist nicht nur gute Technik, er ist der Nachweis für den zweiten Punkt. Schreiben Sie das Datum des letzten erfolgreichen Tests auf.

Drei Entscheidungen ergeben sich daraus. Das Backup liegt verschlüsselt, und zwar clientseitig verschlüsselt, bevor es den Server verlässt. Der Zielspeicher liegt in der EU, und mit dessen Betreiber besteht ein Auftragsverarbeitungsvertrag. Und es gibt eine Aufbewahrungsfrist, die Sie aussprechen können, etwa: tägliche Sicherungen sieben Tage, wöchentliche vier Wochen, monatliche sechs Monate, danach automatisch gelöscht. Ohne diese Frist überlebt ein gelöschtes Benutzerkonto unbegrenzt in Ihren Archiven. Welche Punkte Sie beim Anbieter vorher klären, steht in der Checkliste für Storage-VPS und Datenschutz, und die technische Seite behandelt die Verschlüsselung der Daten auf einem Storage-VPS.

Den Zeitplan an restic übergeben

Manuelle Backups brechen in dem Monat ab, in dem Sie im Urlaub sind. Übergeben Sie den Ablauf an restic, das clientseitig verschlüsselt und dedupliziert. Ein Skript, das erst den Dump zieht und dann sichert, reicht:

restic backup /opt/authentik/authentik-postgres-backup.sql /opt/authentik/.env /opt/authentik/compose.yml /opt/authentik/data /opt/authentik/custom-templates
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

Die forget-Zeile ist Ihre Löschregel in ausführbarer Form, --prune gibt den Platz anschließend frei. restic check --read-data-subset liest einen Teil der Daten wirklich zurück und prüft die Prüfsummen, statt nur den Index anzusehen. Repository-Pfad und Passwort setzen Sie über RESTIC_REPOSITORY und RESTIC_PASSWORD_FILE in einer Datei mit Modus 600, die nur root lesen darf. Legen Sie das restic-Passwort außerdem irgendwo ab, wo es einen Totalverlust des Servers überlebt, denn ohne dieses Passwort ist das Repository nicht mehr zu öffnen. Ob restic oder BorgBackup besser zu Ihrem Aufbau passt, klärt der direkte Vergleich von restic und BorgBackup.

Den Aufruf hängen Sie an einen systemd-Timer, nicht an cron, weil Sie so journalctl -u authentik-backup.service zur Fehlersuche haben. Und weil authentik selten allein auf dem Server steht, lohnt es sich, den gleichen Ablauf auf die übrigen Container auszudehnen: einen kompletten Compose-Stack sichern und aktualisieren folgt derselben Reihenfolge aus Dump, Archiv und Test.

FAQ

Reicht ein VPS-Snapshot als Backup für authentik?

Als alleinige Sicherung nicht. Ein Snapshot entsteht, während PostgreSQL schreibt, und entspricht damit einem Stromausfall. Die Wiederherstellung hängt daran, dass der Snapshot in einem Zug über das gesamte Dateisystem gezogen wurde und PostgreSQL sein WAL nachspielen kann. Ein Dump mit pg_dump ist dagegen eine logische Kopie, die Sie prüfen und auf einem anderen Server einspielen können. Nutzen Sie den Snapshot für den schnellen Rückweg nach einem Upgrade und den Dump als eigentliches Backup.

Muss AUTHENTIK_SECRET_KEY beim Wiederherstellen derselbe sein?

Ja, nehmen Sie dieselbe .env mit. Laut Dokumentation signiert der Schlüssel Cookies, und eine Änderung macht alle aktiven Sitzungen ungültig. Mit einem neuen Schlüssel startet der wiederhergestellte Stack zwar und die Anmeldung funktioniert, aber jede bestehende Browsersitzung landet wieder im Login-Flow, ohne dass ein Fehler im Log erscheint. Auf Installationen älter als Version 2023.6.0 diente derselbe Schlüssel zusätzlich der Bildung eindeutiger Benutzer-IDs und darf deshalb gar nicht geändert werden.

Wie spiele ich den Dump in einen frischen Stack ein?

Starten Sie zuerst nur die Datenbank mit docker compose up --force-recreate -d postgresql und warten Sie, bis der Healthcheck healthy meldet. Dann leiten Sie den Dump hinein: cat authentik-postgres-backup.sql | docker compose exec -T postgresql psql -U authentik -d postgres -v ON_ERROR_STOP=1. Die Verbindung geht auf postgres, weil ein mit -cC erzeugter Dump die Datenbank authentik löschen und neu anlegen will, was aus einer Sitzung innerhalb dieser Datenbank nicht möglich ist. Danach starten Sie mit docker compose up --force-recreate -d den vollständigen Stack.

Wie lange darf ich Backups mit Identitätsdaten aufbewahren?

So lange, wie Sie es begründen können, und keinen Tag länger. Da eine authentik-Datenbank personenbezogene Daten enthält, brauchen Sie eine Aufbewahrungsfrist, die automatisch durchgesetzt wird, zum Beispiel sieben tägliche, vier wöchentliche und sechs monatliche Sicherungen. In restic schreiben Sie genau das als restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune und lassen es bei jedem Lauf mitlaufen. Ohne diese Zeile überlebt ein gelöschtes Konto unbegrenzt im Archiv.