# Backup & Restore — Übersicht

Stand: 2026-07-24. Die ausführliche Betriebsanleitung steht in [`docs/BACKUP.md`](../BACKUP.md).
Dieses Dokument fasst den datenschutz-/compliance-relevanten Stand zusammen.

## Was wird gesichert
- **Datenbank** (PostgreSQL): Konten, Organisationen, Pläne, Journale, Zustimmungen usw.
- **Hochgeladene Dateien** (MinIO): Pläne, Logos, Symbole.
- **Nicht** im Backup: Zahlungsdaten (bei Stripe), E-Mails (beim SMTP-Anbieter), Secrets.

## Zwei Mechanismen
1. **Lokaler Container-Backup** (`backup`-Service): täglich, im Volume `backups_data`, 30 Tage.
   Schützt vor Bedienfehlern/Korruption, **nicht** vor Geräteausfall (gleiches Gerät).
2. **GUI-Backup, verschlüsselt & extern** (`Administration → Backup`): SFTP oder Nextcloud/WebDAV,
   AES-256-GCM mit Passphrase, Zeitplan + Aufbewahrung. **Off-site** → deckt Geräteausfall ab.

| Aspekt | Zustand |
|---|---|
| Frequenz | täglich (konfigurierbar) |
| Verschlüsselung (extern) | ✅ AES-256-GCM (Passphrase) |
| Verschlüsselung (lokal) | ⚠️ nein (nur lokales Sicherheitsnetz) |
| Aufbewahrung | 30 Tage (konfigurierbar) |
| Zugriffsschutz | Ziel-Zugangsdaten verschlüsselt in DB; Passphrase separat aufbewahren |
| Off-site | ✅ via GUI-Backup (sofern konfiguriert) |

## Restore-Testplan (verbindlich)
Ein Backup gilt erst als funktionierend, wenn ein Restore **nachweislich** geklappt hat.

1. Aktuelles verschlüsseltes Backup vom Ziel laden.
2. Mit `scripts/decrypt-backup.js` + Passphrase entschlüsseln → `tar.gz`.
3. In einer **Testumgebung** DB + Dateien wiederherstellen (siehe `docs/BACKUP.md`).
4. Stichprobe: Login, ein Projekt, ein Journal, ein hochgeladenes Symbol prüfen.
5. Ergebnis in der Tabelle in `docs/BACKUP.md` protokollieren.
6. **Häufigkeit:** mindestens halbjährlich.

> Es wird **nicht** behauptet, dass eine Wiederherstellung funktioniert, solange kein Restore-Test
> durchgeführt und protokolliert wurde.