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>
1.9 KiB
1.9 KiB
Backup & Restore — Übersicht
Stand: 2026-07-24. Die ausführliche Betriebsanleitung steht in docs/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
- Lokaler Container-Backup (
backup-Service): täglich, im Volumebackups_data, 30 Tage. Schützt vor Bedienfehlern/Korruption, nicht vor Geräteausfall (gleiches Gerät). - 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.
- Aktuelles verschlüsseltes Backup vom Ziel laden.
- Mit
scripts/decrypt-backup.js+ Passphrase entschlüsseln →tar.gz. - In einer Testumgebung DB + Dateien wiederherstellen (siehe
docs/BACKUP.md). - Stichprobe: Login, ein Projekt, ein Journal, ein hochgeladenes Symbol prüfen.
- Ergebnis in der Tabelle in
docs/BACKUP.mdprotokollieren. - Häufigkeit: mindestens halbjährlich.
Es wird nicht behauptet, dass eine Wiederherstellung funktioniert, solange kein Restore-Test durchgeführt und protokolliert wurde.