Passwortmanager weg, Backup auch? So sicherst du Passbolt, bevor es knallt

Du kennst das: Der Passwortmanager läuft seit Monaten stabil, alle Zugangsdaten sind drin – und irgendwo im Hinterkopf meldet sich die Frage, was eigentlich passiert, wenn der Server morgen nicht mehr hochkommt. Genau da wird ein selbst gehostetes Passbolt zum Klumpenrisiko: Ohne sauberes Passbolt Backup sind nicht nur die Passwörter weg, sondern auch die, die du für die Wiederherstellung bräuchtest.

In meinem Fall läuft Passbolt per Docker auf einem gemieteten Server. Ich sichere es jede Nacht, verschlüssele das Backup so, dass der Server es selbst nicht mehr lesen kann, lasse es von der NAS zu Hause abholen – und teste die Wiederherstellung, ohne den laufenden Betrieb anzufassen. Damit du (oder dein zukünftiges Ich) das schnell nachbauen kannst, hier der komplette Ablauf.

Ziel

• Nächtliches Backup von Datenbank, Server-GPG-Schlüssel, JWT-Schlüssel und Compose-Datei.
• Verschlüsselt mit age; auf dem Server liegt nur der öffentliche Schlüssel.
• Die NAS holt die Backups ab – mit einem SSH-Schlüssel, der auf dem Server nur lesen darf.
• Ein erprobter Wiederherstellungstest in einer abgeschotteten Testumgebung.

Voraussetzungen

• Passbolt CE mit Docker Compose (offizielles Setup: Dienste db mit MariaDB und passbolt), hier unter /opt/passbolt.
• Root-Zugang per SSH zum Server (im Beispiel ssh server, Adresse 203.0.113.10).
• Eine Synology-NAS mit SSH-Zugang für deinen Benutzer (im Beispiel ssh nas, Benutzer admin) und einem Ordner für Backups, z. B. /volume1/backup.
• Ein Mac oder Linux-Rechner als Arbeitsplatz.

Was muss eigentlich ins Passbolt Backup?

Nicht ins Server-Backup gehört dein persönlicher Passbolt-Schlüssel (Wiederherstellungs-Kit). Den hast du beim Einrichten heruntergeladen – der gehört an einen sicheren Ort außerhalb des Servers.

Schritt 1: age installieren und Schlüsselpaar erzeugen

age ist ein kleines, modernes Verschlüsselungswerkzeug. Auf dem Server (Ubuntu/Debian):

apt-get install -y age

Das Schlüsselpaar erzeugen wir so, dass der private Schlüssel nie auf der Platte des Servers landet. age-keygen läuft auf dem Server, die Ausgabe wird aber direkt auf deinen Rechner geschrieben:

umask 077
mkdir -p ~/.config/age
ssh server 'age-keygen 2>/dev/null' > ~/.config/age/passbolt-backup.key
grep '^# public key:' ~/.config/age/passbolt-backup.key | sed 's/# public key: //' > ~/.config/age/passbolt-backup.pub

Auf den Server kommt nur der öffentliche Schlüssel:

ssh server 'mkdir -p -m 700 /etc/passbolt-backup && cat > /etc/passbolt-backup/recipient.txt && chmod 600 /etc/passbolt-backup/recipient.txt' \
  < ~/.config/age/passbolt-backup.pub

Schritt 2: Den privaten Schlüssel an mehreren Orten sichern

Jetzt kommt die Henne-Ei-Falle: Legst du den Entschlüsselungsschlüssel nur in Passbolt ab, kommst du nach einem Totalausfall nicht mehr daran. Deshalb mindestens zwei Orte außerhalb des Servers:

1. In Passbolt als verschlüsselte Notiz – praktisch, solange Passbolt läuft.
2. Unabhängig vom Server, z. B. in der App Passwörter von Apple (immer Ende-zu-Ende-verschlüsselt) oder in einem anderen Passwortmanager.
3. Offline: ausgedruckt oder auf einem USB-Stick in der Schublade.

Den Schlüssel dabei nicht anzeigen, sondern über die Zwischenablage einfügen und sie danach leeren:

pbcopy < ~/.config/age/passbolt-backup.key   # in Passbolt einfügen
pbcopy < /dev/null

Für Apple Passwörter reicht die eine Zeile, die mit AGE-SECRET-KEY- beginnt – sie passt ins Passwortfeld:

grep '^AGE-SECRET-KEY-' ~/.config/age/passbolt-backup.key | tr -d '\n' | pbcopy
pbcopy < /dev/null   # nach dem Einfügen

Wichtig: In Passbolt nie in die Beschreibung – die ist nicht verschlüsselt. Nur in die Notiz bzw. das Geheimnis.

Schritt 3: Das Backup-Skript

/usr/local/sbin/passbolt-backup.sh:

#!/bin/bash
# Passbolt-Backup: DB-Dump, Server-GPG-Schlüssel, JWT-Schlüssel und Compose-Datei,
# verschlüsselt mit age (nur der öffentliche Schlüssel liegt auf dem Server).
set -euo pipefail
umask 077

DEST=/root/backups/passbolt
KEEP_DAYS=14
RECIPIENT_FILE=/etc/passbolt-backup/recipient.txt
COMPOSE_DIR=/opt/passbolt
DB_CONTAINER=passbolt-db-1
APP_CONTAINER=passbolt-passbolt-1
VOLUMES=/var/lib/docker/volumes

log() { logger -t passbolt-backup "$*"; echo "$(date -u +%FT%TZ) $*"; }
fail() { log "FEHLER: $*"; exit 1; }

[ -s "$RECIPIENT_FILE" ] || fail "Empfängerschlüssel fehlt: $RECIPIENT_FILE"
mkdir -p "$DEST"
stamp=$(date +%Y%m%d-%H%M)
work=$(mktemp -d)
trap 'rm -rf "$work"; rm -f "$DEST/.passbolt-$stamp.tmp"' EXIT

# Zugangsdaten bleiben im Container: das Skript kennt das DB-Passwort nicht
docker exec "$DB_CONTAINER" sh -c \
  'MYSQL_PWD="$MYSQL_PASSWORD" exec mariadb-dump --single-transaction --routines --triggers -u"$MYSQL_USER" "$MYSQL_DATABASE"' \
  > "$work/passbolt.sql" || fail "Datenbank-Dump fehlgeschlagen"
tail -n 1 "$work/passbolt.sql" | grep -q "Dump completed" || fail "Datenbank-Dump unvollständig"

mkdir "$work/gpg" "$work/jwt"
cp -a "$VOLUMES/passbolt_gpg_volume/_data/." "$work/gpg/"
cp -a "$VOLUMES/passbolt_jwt_volume/_data/." "$work/jwt/"
[ -s "$work/gpg/serverkey_private.asc" ] || fail "Server-GPG-Schlüssel fehlt"
cp -p "$COMPOSE_DIR/docker-compose.yaml" "$work/"

{
  echo "Erstellt: $(date -u +%FT%TZ) auf $(hostname)"
  echo "Passbolt-Image: $(docker inspect -f '{{.Config.Image}} {{.Image}}' "$APP_CONTAINER")"
  echo "DB-Image: $(docker inspect -f '{{.Config.Image}}' "$DB_CONTAINER")"
  echo "Tabellen im Dump: $(grep -c '^CREATE TABLE' "$work/passbolt.sql")"
  (cd "$work" && find . -type f ! -name MANIFEST.txt -exec sha256sum {} + | sort -k2)
} > "$work/MANIFEST.txt"

tar -C "$work" -czf - . | age -R "$RECIPIENT_FILE" > "$DEST/.passbolt-$stamp.tmp" \
  || fail "Verschlüsseln fehlgeschlagen"
mv "$DEST/.passbolt-$stamp.tmp" "$DEST/passbolt-$stamp.tar.gz.age"
size=$(stat -c %s "$DEST/passbolt-$stamp.tar.gz.age")

old=$(find "$DEST" -maxdepth 1 -name 'passbolt-*.tar.gz.age' -mtime +"$KEEP_DAYS" -print -delete | wc -l)
log "OK: passbolt-$stamp.tar.gz.age ($size Bytes), alte gelöscht: $old"

Ein paar Details, die sich lohnen:

• Das Backup wird erst unter einem temporären Namen geschrieben und am Ende umbenannt. Ein abgebrochener Lauf hinterlässt also nie eine halbe Datei, die wie ein gutes Backup aussieht.
• MANIFEST.txt enthält Prüfsummen aller Teile. Damit lässt sich später prüfen, ob beim Entpacken alles heil ist.
• Die Container- und Volume-Namen (passbolt-db-1, passbolt_gpg_volume) ergeben sich aus dem Compose-Projektnamen. Prüfe sie bei dir mit docker ps und docker volume ls.

Hochladen und ausführbar machen:

ssh server 'cat > /usr/local/sbin/passbolt-backup.sh && chmod 700 /usr/local/sbin/passbolt-backup.sh' < passbolt-backup.sh
ssh server /usr/local/sbin/passbolt-backup.sh

So prüfst du das Backup

Entschlüsseln, ohne den privaten Schlüssel auf dem Server zu speichern: Er wird per Standardeingabe durchgereicht, entpackt wird nur im Arbeitsspeicher (/dev/shm):

ssh server 'set -e; d=$(mktemp -d -p /dev/shm); trap "rm -rf $d" EXIT
  f=$(ls -t /root/backups/passbolt/passbolt-*.tar.gz.age | head -1)
  age -d -i /dev/stdin "$f" | tar -xz -C $d
  cd $d && tail -n +5 MANIFEST.txt | sha256sum -c --quiet && echo "Prüfsummen OK"
  tail -1 passbolt.sql' < ~/.config/age/passbolt-backup.key

Erwartet: Prüfsummen OK und -- Dump completed on ….

Schritt 4: Jede Nacht per Cron

/etc/cron.d/passbolt-backup:

# Passbolt-Backup (Log: journalctl -t passbolt-backup)
SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAILTO=""
30 1 * * * root /usr/local/sbin/passbolt-backup.sh >/dev/null 2>&1

Viele Server laufen in UTC (timedatectl). 01:30 UTC ist 02:30 bzw. 03:30 Uhr deutscher Zeit.

Tipp zum Testen: Trag zuerst eine Uhrzeit zwei Minuten in der Zukunft ein, warte den Lauf ab und prüfe ihn mit journalctl -t passbolt-backup. Danach die echte Uhrzeit setzen.

Schritt 5: Die NAS holt die Backups ab

Warum holen statt schicken? So muss zu Hause kein Port geöffnet werden, und der Server hat keinen Zugang zur NAS. Damit ein gekaperter NAS-Schlüssel auf dem Server keinen Schaden anrichten kann, darf er dort nur einen Ordner lesen.

Auf der NAS einen eigenen Schlüssel ohne Passphrase anlegen (er muss nachts unbeaufsichtigt laufen):

ssh nas 'ssh-keygen -q -t ed25519 -N "" -C nas-passbolt-pull -f ~/.ssh/passbolt_pull_ed25519'
ssh nas 'mkdir -p -m 700 /volume1/backup/passbolt'

Auf dem Server den öffentlichen Schlüssel mit Einschränkung in /root/.ssh/authorized_keys eintragen (vorher Sicherungskopie der Datei anlegen):

restrict,command="/usr/bin/rrsync -ro /root/backups/passbolt/" ssh-ed25519 AAAA… nas-passbolt-pull

restrict schaltet Weiterleitungen, Terminal & Co. ab, rrsync -ro erlaubt nur lesendes rsync in genau diesem Ordner. rrsync gehört unter Ubuntu zum Paket rsync.

Hostschlüssel des Servers auf der NAS hinterlegen. Synology bringt kein ssh-keyscan mit. Nimm den Eintrag aus der known_hosts deines Arbeitsrechners – dort hast du den Fingerabdruck schon einmal bestätigt:

ssh-keygen -F 203.0.113.10 | awk '$2=="ssh-ed25519"{print "203.0.113.10 "$2" "$3}' \
  | ssh nas 'cat > ~/.ssh/known_hosts_passbolt_pull && chmod 600 ~/.ssh/known_hosts_passbolt_pull'

Abhol-Skript /volume1/backup/passbolt/abholen.sh (die Backups landen im Unterordner backups/):

#!/bin/sh
# Holt die verschlüsselten Passbolt-Backups vom Server ab (dort nur lesend per rrsync).
set -u
BASE=/volume1/backup/passbolt
DEST=$BASE/backups
KEEP_DAYS=60
KEY=$HOME/.ssh/passbolt_pull_ed25519
KNOWN=$HOME/.ssh/known_hosts_passbolt_pull
LOG=$BASE/abholen.log
umask 077
mkdir -p "$DEST"
ts() { date -u +%FT%TZ; }

rsync -a --ignore-existing --include='passbolt-*.tar.gz.age' --exclude='*' \
  -e "ssh -i $KEY -o IdentitiesOnly=yes -o UserKnownHostsFile=$KNOWN -o StrictHostKeyChecking=yes -o HostKeyAlgorithms=ssh-ed25519 -o BatchMode=yes -o ConnectTimeout=30" \
  root@203.0.113.10:/ "$DEST/" >>"$LOG" 2>&1
rc=$?
if [ $rc -ne 0 ]; then
  echo "$(ts) FEHLER: Abholung fehlgeschlagen (rsync exit $rc)" >>"$LOG"
  exit 1
fi

old=$(find "$DEST" -name 'passbolt-*.tar.gz.age' -mtime +$KEEP_DAYS -print -delete | wc -l)
total=$(find "$DEST" -name 'passbolt-*.tar.gz.age' | wc -l)
newest=$(find "$DEST" -name 'passbolt-*.tar.gz.age' | sort | tail -n 1)
if [ -z "$(find "$DEST" -name 'passbolt-*.tar.gz.age' -mtime -2)" ]; then
  echo "$(ts) WARNUNG: kein Backup jünger als 2 Tage (neuestes: ${newest##*/})" >>"$LOG"
  exit 1
fi
echo "$(ts) OK: neuestes ${newest##*/}, gesamt $total, alte gelöscht $old" >>"$LOG"

$HOME ist im DSM-Aufgabenplaner nicht immer gesetzt – trag dort im Zweifel den vollen Pfad deines Home-Ordners ein (/var/services/homes/<benutzer>).

Zeitplan in DSM: Systemsteuerung → Aufgabenplaner → Erstellen → Geplante Aufgabe → Benutzerdefiniertes Skript.

Reiter Allgemein: Name der Aufgabe und als Benutzer dein normaler Benutzer – nicht root, der braucht es nicht.

Reiter Zeitplan: täglich, Start 04:00 Uhr – mit genug Abstand zum Backup auf dem Server.

Reiter Aufgabeneinstellungen: unter Benutzerdefiniertes Skript der Pfad zum Abhol-Skript. Wenn DSM Mails verschicken kann, oben „Ausführungsdetails per E-Mail senden“ und „nur bei abnormaler Beendigung“ aktivieren – das Skript endet bei Fehlern und bei zu alten Backups mit Exit-Code 1.

Zum Testen die Aufgabe markieren und auf Ausführen klicken, danach ins Log schauen.

So prüfst du die Abholung

ssh nas '/volume1/backup/passbolt/abholen.sh; echo "exit=$?"; tail -2 /volume1/backup/passbolt/abholen.log'

Prüfsummen auf beiden Seiten vergleichen:

ssh server 'sha256sum /root/backups/passbolt/*.age'
ssh nas 'sha256sum /volume1/backup/passbolt/backups/*.age'

Und dass der NAS-Schlüssel wirklich nichts anderes darf – alle drei Versuche müssen scheitern:

O="-i ~/.ssh/passbolt_pull_ed25519 -o IdentitiesOnly=yes -o UserKnownHostsFile=~/.ssh/known_hosts_passbolt_pull -o HostKeyAlgorithms=ssh-ed25519"
ssh $O root@203.0.113.10 id                         # Befehl ausführen
rsync -e "ssh $O" /tmp/test.txt root@203.0.113.10:/ # schreiben
rsync -e "ssh $O" root@203.0.113.10:/../            # aus dem Ordner ausbrechen

(Diese Befehle auf der NAS ausführen.) Erwartete Antworten: SSH_ORIGINAL_COMMAND does not run rsync, sending to read-only server is not allowed, do not use .. in arg.

Schritt 6: Der Wiederherstellungstest

Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung. Wir spielen es in eine zweite, komplett abgeschottete Passbolt-Instanz auf demselben Server ein. Drei Regeln dafür:

1. Eigener Compose-Projektname, damit nichts mit der echten Instanz kollidiert.
2. Internes Docker-Netz ohne Internetzugang. Die Datenbank enthält die SMTP-Einstellungen – ohne Abschottung könnte die Testinstanz echte Mails verschicken.
3. Alles im Arbeitsspeicher (/dev/shm) und hinterher restlos entfernen.

Backup entpacken – vom Arbeitsrechner aus, damit der private Schlüssel wieder nur per Standardeingabe auf den Server kommt:

ssh server 'B=/dev/shm/pbrestore; mkdir -m 700 $B $B/restore
  f=$(ls -t /root/backups/passbolt/passbolt-*.tar.gz.age | head -1)
  age -d -i /dev/stdin "$f" | tar -xz -C $B/restore' < ~/.config/age/passbolt-backup.key

Alles Weitere auf dem Server. Zuerst ein Testpasswort für die Test-Datenbank erzeugen:

B=/dev/shm/pbrestore
chmod 644 $B/restore/passbolt.sql   # sonst kann der MariaDB-Container ihn nicht lesen
printf "TESTPW=%s\n" "$(head -c 24 /dev/urandom | base64 | tr -dc A-Za-z0-9)" > $B/.env

$B/compose.yaml:

name: pbrestoretest
services:
  db:
    image: mariadb:10.11
    environment:
      MYSQL_RANDOM_ROOT_PASSWORD: "true"
      MYSQL_DATABASE: passbolt
      MYSQL_USER: passbolt
      MYSQL_PASSWORD: ${TESTPW}
    volumes:
      - ./restore/passbolt.sql:/docker-entrypoint-initdb.d/passbolt.sql:ro
    networks: [isoliert]
  passbolt:
    image: passbolt/passbolt:latest-ce
    depends_on: [db]
    environment:
      APP_FULL_BASE_URL: https://passbolt.example.org   # dieselbe Adresse wie live, siehe Stolperstellen
      DATASOURCES_DEFAULT_HOST: db
      DATASOURCES_DEFAULT_USERNAME: passbolt
      DATASOURCES_DEFAULT_PASSWORD: ${TESTPW}
      DATASOURCES_DEFAULT_DATABASE: passbolt
    volumes:
      - ./restore/gpg:/etc/passbolt/gpg
      - ./restore/jwt:/etc/passbolt/jwt
    command: ["/usr/bin/wait-for.sh", "-t", "0", "db:3306", "--", "/docker-entrypoint.sh"]
    networks: [isoliert]
networks:
  isoliert:
    internal: true

Zuerst nur die Datenbank starten – sie spielt den Dump beim ersten Start automatisch ein. Danach die Mail-Warteschlange der Test-Datenbank leeren:

cd $B
docker compose up -d db
docker compose logs -f db     # warten auf „init process done“, dann Strg+C
docker compose exec -T db sh -c 'MYSQL_PWD=$MYSQL_PASSWORD mariadb -u$MYSQL_USER passbolt -e "delete from email_queue"'
docker compose up -d passbolt

Healthcheck in der Testinstanz. Bei docker exec fehlt dem Healthcheck der Fingerabdruck des Server-Schlüssels, deshalb wird er vorher ermittelt und mitgegeben:

docker exec pbrestoretest-passbolt-1 sh -c '
  FP=$(su -s /bin/sh -c "gpg --homedir /var/lib/passbolt/.gnupg --list-secret-keys --with-colons" www-data | awk -F: "/^fpr/{print \$10; exit}")
  PASSBOLT_GPG_SERVER_KEY_FINGERPRINT=$FP su -m -s /bin/sh -c "/usr/share/php/passbolt/bin/cake passbolt healthcheck" www-data'

Erwartet: alle GPG-, Datenbank- und Metadaten-Prüfungen [PASS]. Drei [FAIL] sind in der Testumgebung normal und harmlos: Die eigene Adresse ist nicht erreichbar, kein Versionscheck (kein Internet) und SSL wird nicht erzwungen.

Zum Schluss die Daten mit der echten Instanz vergleichen – beide Zeilen müssen gleich sein:

Q='select count(*) from users where deleted=0; select count(*) from resources where deleted=0; select count(*) from folders; select max(modified) from resources;'
for c in passbolt-db-1 pbrestoretest-db-1; do
  docker exec $c sh -c "MYSQL_PWD=\$MYSQL_PASSWORD mariadb -u\$MYSQL_USER passbolt -N -e '$Q'" | paste -sd' '
done

Aufräumen:

cd $B && docker compose down -v
cd / && rm -rf /dev/shm/pbrestore

Rückweg

• Cron abschalten: rm /etc/cron.d/passbolt-backup.
• NAS-Zugang entziehen: die Zeile mit nas-passbolt-pull aus /root/.ssh/authorized_keys löschen, die Aufgabe im DSM-Aufgabenplaner deaktivieren.
• Alles andere (Skript, /etc/passbolt-backup, /root/backups/passbolt) lässt sich einfach löschen – die laufende Passbolt-Instanz wird nicht verändert.

Stolperstellen aus der Praxis

• Den age-Schlüssel nur in Passbolt ablegen ist die klassische Falle: Ist der Server weg, ist auch der Schlüssel zum Backup weg. Mindestens ein Ort muss vom Server unabhängig sein.
• „REMOTE HOST IDENTIFICATION HAS CHANGED“ auf der Synology, obwohl sich nichts geändert hat: Das ältere OpenSSH der NAS bevorzugt den ECDSA-Hostschlüssel, hinterlegt ist aber nur ED25519. Fingerabdruck mit dem bekannten vergleichen, dann -o HostKeyAlgorithms=ssh-ed25519 setzen. Nicht einfach StrictHostKeyChecking=no!

– ssh-keyscan fehlt auf Synology. Den Hostschlüssel deshalb vom Arbeitsrechner übernehmen, wo er schon geprüft ist.
– Healthcheck meldet „The server metadata private key is not valid“ in der Testinstanz: Passbolt prüft dabei die Adresse. Mit einer Platzhalter-URL schlägt der Test fehl, mit der echten APP_FULL_BASE_URL klappt er. Durch das interne Netz ist das trotzdem ungefährlich.
– Alte Mails in der Warteschlange: In der Datenbank können ungesendete Mails liegen, z. B. aus der Zeit, bevor der Mailversand eingerichtet war. Eine Testinstanz mit Internetzugang würde sie unter Umständen verschicken. Deshalb internes Netz und Warteschlange leeren.
– Healthcheck per docker exec meldet lauter GPG-Fehler: Dort fehlt die Umgebungsvariable mit dem Fingerabdruck. Mit su -m und dem ermittelten Fingerabdruck läuft er sauber durch.
– Der Dump ist für den MariaDB-Container nicht lesbar, wenn er mit umask 077 entpackt wurde. Für den Test chmod 644 auf die Datei (der Ordner darüber bleibt 700).
– Leeres Backup, das nach Erfolg aussieht: Ein abgebrochener mariadb-dump liefert trotzdem eine Datei. Deshalb prüft das Skript die letzte Zeile auf Dump completed.
– Zeitzone: Cron auf dem Server rechnet in Server-Zeit (oft UTC), der DSM-Aufgabenplaner in Ortszeit. Die Abholung mit genug Abstand nach dem Backup planen.

Fazit

Ein Passwortmanager ist der eine Dienst, den du nach einem Ausfall als Erstes zurückhaben willst – und genau deshalb braucht er ein Backup, das nicht vom selben Server abhängt. Mit age, einem kleinen Cron-Skript und einer NAS, die nur lesen darf, ist das an einem Abend erledigt. Der wichtigste Teil bleibt aber der Restore-Test: Erst wenn du einmal gesehen hast, dass alle Einträge in einer frischen Instanz wieder auftauchen, ist dein Passbolt Backup mehr als ein gutes Gefühl.