Vaultwarden: Backup und Wiederherstellung

Aus maxTechCorner
(Weitergeleitet von Vaultwarden Restore)

Auf einen Blick

Gilt fürVaultwarden 1.37.x mit SQLite im Docker-Container; Sicherung mit Bordmitteln, restic oder vorhandener Backup-Software
BereichIT-Security
DauerEinrichtung ca. 1 Stunde; Restore-Test ca. 30 Minuten
RechteRoot auf dem Docker-Host
StandOktober 2026

Vaultwarden sichern und wiederherstellen ist schnell eingerichtet, wird aber oft unterschätzt: Fällt der Passwortserver ohne funktionierendes Backup aus, verliert das Unternehmen nicht nur Daten, sondern auch den Zugang zu Firewalls, Banking und Cloud-Diensten. Diese Anleitung zeigt, welche Dateien gesichert werden müssen, wie die Datenbank im laufenden Betrieb konsistent gesichert wird, wie die Sicherung verschlüsselt außer Haus gelangt und wie ein Wiederherstellungstest abläuft.

Backup von Vaultwarden: Datenordner data mit db.sqlite3 (Pflicht), attachments (Pflicht), sends (optional), config.json und rsa_key-Dateien (empfohlen), icon_cache (nicht nötig); SQLite konsistent sichern mit /vaultwarden backup oder sqlite3 .backup statt Dateikopie; täglich per Cron, verschlüsselt mit restic, Kopie außer Haus nach 3-2-1-Regel; Wiederherstellung: Container stoppen, Dateien zurückkopieren, starten; Restore-Test mindestens vierteljährlich; zusätzlich verschlüsselter Export der Organisation für den Notfall.

Was bei Vaultwarden gesichert werden muss

Datei / Ordner in data/ Inhalt Sicherung
db.sqlite3 (mit -wal, -shm) Benutzer, verschlüsselte Tresore, Organisationen, Geräte, Einstellungen Pflicht – nicht einfach kopieren, siehe unten
attachments/ Datei-Anhänge (verschlüsselt) Pflicht
sends/ Dateien in Bitwarden Send optional – nur kurzlebig
config.json im Admin-Panel gespeicherte Einstellungen, auch Admin-Token-Hash und SMTP-Passwort im Klartext empfohlen, verschlüsselt
rsa_key* Schlüssel zum Signieren der Anmelde-Token empfohlen – ohne sie müssen sich alle neu anmelden und offene Einladungen verfallen
icon_cache/ zwischengespeicherte Website-Symbole nicht nötig

Zusätzlich compose.yaml und .env sichern, sonst muss die Konfiguration im Notfall neu erarbeitet werden. Bei MySQL/MariaDB oder PostgreSQL kommt ein Datenbank-Dump hinzu, siehe PostgreSQL.

Gut zu wissen: Die Tresorinhalte in der Datenbank sind mit den Schlüsseln der Benutzer verschlüsselt. Wer das Backup stiehlt, kann aber Metadaten (E-Mail-Adressen, Namen, Organisationen, Gerätelisten, Zeitstempel) lesen und offline Master-Passwörter erraten. Deshalb das Backup zusätzlich verschlüsseln.

Schritt 1: Datenbank konsistent sichern

SQLite schreibt laufend in die Datenbank und das Write-Ahead-Log. Eine einfache Dateikopie im laufenden Betrieb kann unbrauchbar sein. Drei richtige Wege: 

# a) Eingebauter Befehl (ab 1.32.1), schreibt data/db_JJJJMMTT_HHMMSS.sqlite3 (UTC)
docker exec vaultwarden /vaultwarden backup

# b) sqlite3 auf dem Host (Paket sqlite3), Online-Backup-API
sqlite3 /opt/vaultwarden/data/db.sqlite3 ".backup '/var/backups/vaultwarden/db-$(date +%Y%m%d-%H%M).sqlite3'"

# c) Container kurz stoppen und alle Dateien kopieren
docker compose stop vaultwarden && cp -a data /var/backups/vaultwarden/data-$(date +%F) && docker compose start vaultwarden

Das Docker-Image enthält weder sqlite3 noch cron – Zeitpläne deshalb auf dem Host einrichten.

Schritt 2: Sicherungsskript

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

#!/bin/bash
set -euo pipefail
DATA=/opt/vaultwarden/data
STAGE=/var/backups/vaultwarden/stage
mkdir -p "$STAGE"

# Datenbank konsistent sichern und in den Staging-Ordner verschieben
OUT=$(docker exec vaultwarden /vaultwarden backup)
FILE=$(echo "$OUT" | sed -n "s/^Backup to '\/data\/\(db_[0-9_]*\.sqlite3\)'.*/\1/p")
[ -n "$FILE" ] || { echo "Backup fehlgeschlagen: $OUT" >&2; exit 1; }
mv "$DATA/$FILE" "$STAGE/db.sqlite3"

# Restliche Dateien (ohne Live-Datenbank und Icon-Cache)
rsync -a --delete --exclude 'db.sqlite3*' --exclude 'db_*.sqlite3' --exclude icon_cache \
  "$DATA/" "$STAGE/data/"
cp /opt/vaultwarden/compose.yaml /opt/vaultwarden/.env "$STAGE/"

# Verschlüsselt und versioniert ins Repository
export RESTIC_REPOSITORY=sftp:backup@nas.firma.lan:/backup/vaultwarden
export RESTIC_PASSWORD_FILE=/root/.restic-vaultwarden
restic backup "$STAGE" --tag vaultwarden
restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

chmod 700 /usr/local/sbin/vaultwarden-backup.sh
# täglich 02:30 Uhr
echo '30 2 * * * root /usr/local/sbin/vaultwarden-backup.sh >> /var/log/vaultwarden-backup.log 2>&1' > /etc/cron.d/vaultwarden-backup
  • restic verschlüsselt, dedupliziert und versioniert. Alternativen sind rustic, Borg oder eine vorhandene Backup-Software, die das Staging-Verzeichnis sichert.
  • Das restic-Passwort nicht nur in Vaultwarden speichern – sonst ist es im Notfall mit verloren. Ausgedruckt im Tresor oder bei der Geschäftsführung hinterlegen.
  • Mindestens eine Kopie außer Haus oder unveränderbar halten (3-2-1-Regel), siehe Offsite-Backup und Immutable Backup.
  • Erfolg überwachen: Log auswerten oder eine Monitoring-Prüfung auf das Alter des letzten Snapshots einrichten.

Schritt 3: Wiederherstellen

  1. Neuen Host mit Docker vorbereiten, gleiche Vaultwarden-Version wie im Backup oder neuer.
  2. Snapshot zurückholen: restic restore latest --target /tmp/restore
  3. compose.yaml und .env nach /opt/vaultwarden kopieren.
  4. Datenordner anlegen: Inhalt von data/ zurückkopieren und die gesicherte Datenbank als data/db.sqlite3 ablegen. Alte db.sqlite3-wal und -shm dürfen nicht liegen bleiben.
  5. Rechte setzen (bei Nicht-Root-Betrieb chown -R 1000:1000 data) und docker compose up -d.
  6. DNS bzw. Reverse Proxy auf den neuen Host umstellen und Anmeldung, Anhänge und Organisationen prüfen.

Restore-Test

  • Mindestens vierteljährlich und nach größeren Updates eine Wiederherstellung auf einem isolierten Testsystem durchspielen, siehe Backup-Verifizierung.
  • Testinstanz ohne SMTP und ohne Push starten, damit keine E-Mails an Benutzer gehen.
  • Prüfen: Anmeldung mit einem Testkonto, ein Eintrag mit Anhang, eine Organisation.
  • Dauer und Ergebnis dokumentieren – das ist zugleich ein Nachweis für Audits und Versicherer.

Zusätzliche Notfallkopie: verschlüsselter Export

Gegen den schlimmsten Fall – Server und Backups unbrauchbar – hilft ein Export auf Anwendungsebene:

  • Eigentümer exportieren die Organisation im Web-Tresor über Admin-Konsole › Tresor exportieren im Format .json (Verschlüsselt) mit einem eigenen Dateipasswort.
  • Den Export auf einem verschlüsselten USB-Stick im Safe aufbewahren und regelmäßig erneuern.
  • Nie unverschlüsselte CSV- oder JSON-Exporte dauerhaft speichern.
  • Der Export lässt sich in jede Bitwarden- oder Vaultwarden-Instanz importieren.

Hinweise

  • Keine Snapshots als einziges Backup: VM- oder Dateisystem-Snapshots sind laut Projekt fehleranfälliger als die Sicherung der Dateien; ergänzend sind sie in Ordnung.
  • Offline-Kopien in den Clients: Desktop-App und Smartphone halten eine verschlüsselte lokale Kopie des Tresors. Sie ist kein Backup, hilft aber, während eines Ausfalls weiterzuarbeiten.
  • Bei Planung und Betrieb von verschlüsselten Offsite-Backups unterstützt Sie das Cloud-Backup von m.a.x. it.

Siehe auch

Links und Quellen


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen

Abgerufen von „http://techcorner.max-it.de/index.php?title=Vaultwarden:_Backup_und_Wiederherstellung&oldid=4931“