5f360480ae
All checks were successful
Build and Push Docker Image / build-and-push (push) Successful in 53m24s
Compliance-Runde 2 (ohne Doppelstrukturen; baut auf v1.7–v1.9 auf): FKS/FEUKOS (dokumentierte schriftliche Genehmigung 17.02.2026): - legal.ts: fksAttribution (exakte Quellenangabe, Genehmigungsdatum, Nutzungshinweis) + operatorType - Neue Seite /quellen-und-lizenzen (+ Footer/Sitemap-Link) - FKS-Abschnitt in Nutzungsbedingungen (§10a); Quellenangabe im Symbol-Panel und in PDF/PNG-Export - Terminologie entschärft: "offizielle FKS/BABS-Signaturen" -> "FEUKOS-Symbole der FKS" (keine Partnerschaft/Zertifizierung/Empfehlung suggeriert) - FKS_ATTRIBUTION als Dokumenttyp (Migration-Seed, LegalDocumentType), Kontexte erweitert - licenses-and-attributions.md aktualisiert; .gitignore: private-legal-evidence/ Datenschutz/Transparenz: - [REGION]-Platzhalter in der Subprozessorenliste durch öffentlich bekannte Firmensitze ersetzt (keine Platzhalter mehr öffentlich sichtbar) - Journal-Freitext-Warnung (keine schutzwürdigen Daten) Docs: current-state-audit, international-data-transfers, backup-and-restore, privacy-risk-assessment, manual-action-checklist Tests: Krypto-Round-Trip (crypto-secret); legal-config-Test aktualisiert; 17 grün. tsc+build ok. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
38 lines
1.9 KiB
Markdown
38 lines
1.9 KiB
Markdown
# 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.
|