9f5f8bfc11
Includes CACC/FINMA legal processes, updated AGB with PowerOn AG stammdaten, and internal legal and best-practice analysis report. Co-authored-by: Cursor <cursoragent@cursor.com>
74 lines
3.4 KiB
Markdown
74 lines
3.4 KiB
Markdown
# Backup und Wiederherstellung
|
|
|
|
**Dokumenttyp:** Konzept & Prozess
|
|
**Geltungsbereich:** Alle Kundendaten auf `db.poweron.swiss`
|
|
**Version:** 1.0
|
|
**Status:** Entwurf zur internen Freigabe
|
|
**Owner:** Betrieb / DevOps
|
|
**Letzte Aktualisierung:** 02.06.2026
|
|
**Deckt ab (CACC):** 75, 87
|
|
**Verweist auf:** `datenbank-handling.md`, `bcm_runbook.md`
|
|
|
|
---
|
|
|
|
## 1. Backup-Strategie (mehrschichtig)
|
|
|
|
PowerOn sichert Daten auf zwei Ebenen (vgl. `datenbank-handling.md` Abschnitt 4):
|
|
|
|
| Ebene | Mechanismus | Verantwortung |
|
|
|---|---|---|
|
|
| **Infrastruktur** | Snapshots der Infomaniak Managed PostgreSQL | Infomaniak / Betrieb |
|
|
| **Anwendung** | Vollständiger JSON-Export aller 13 Datenbanken via Admin-UI oder Script | Betrieb (SysAdmin) |
|
|
|
|
Token- und AuthEvent-Tabellen sowie die Testdatenbank werden vom Export ausgeschlossen.
|
|
|
|
## 2. Anforderung #75 — die drei Pflichtelemente
|
|
|
|
Punkt #75 verlangt explizit drei Dinge. Stand und Massnahmen:
|
|
|
|
### 2.1 Angemessener Schutz der gesicherten Daten
|
|
- Backup-Dateien enthalten alle Kundendaten und sind als vertraulich klassifiziert.
|
|
- **Offen:** Export-Dateien aktuell unverschlüsselt → Verschlüsselung einführen (siehe Dok 04).
|
|
- Ablage nur auf gesicherten Speichern, nicht auf persönlichen Geräten/Cloud (vgl. `datenbank-handling.md` Abschnitt 6).
|
|
|
|
### 2.2 Überwachung der Datensicherung
|
|
- **Offen / [ZU PRÜFEN]:** Werden Infomaniak-Snapshots automatisch überwacht (Erfolg/Fehler-Alerting)?
|
|
- **Massnahme:** Automatisiertes Alerting bei fehlgeschlagenem Backup einrichten; Backup-Status mindestens wöchentlich kontrollieren.
|
|
|
|
### 2.3 Test der Wiederherstellungsverfahren
|
|
- Das technische Restore-Verfahren ist in `bcm_runbook.md` Abschnitt 2 vollständig dokumentiert (pg_dump/pg_restore + Migrations-Tool).
|
|
- **Offen:** Es fehlt ein dokumentierter, regelmässiger Restore-Test.
|
|
- **Massnahme:** Mindestens **vierteljährlich** einen Restore-Test auf der INT-Umgebung durchführen und protokollieren (Datum, getestete DB, Dauer, Ergebnis, Tester).
|
|
|
|
## 3. Backup-Frequenz und Aufbewahrung
|
|
|
|
| Anlass | Aktion | Aufbewahrung |
|
|
|---|---|---|
|
|
| Vor jedem Deployment | Export via Admin-UI | bis zum nächsten erfolgreichen Deployment |
|
|
| Vor DB-Migrationen | Export + beschriftet archivieren | mind. 90 Tage |
|
|
| Wöchentlich | Archiv-Export | [ZU PRÜFEN: Aufbewahrungsdauer festlegen, z. B. 90 Tage] |
|
|
| Infrastruktur-Snapshot | automatisch (Infomaniak) | [ZU PRÜFEN: Intervall & Retention bei Infomaniak] |
|
|
|
|
## 4. Wiederherstellungsziele (RTO/RPO)
|
|
|
|
| Parameter | Zielwert | Bemerkung |
|
|
|---|---|---|
|
|
| RTO (Recovery Time Objective) | [ZU PRÜFEN, Vorschlag: ≤ 4 h] | Restore dauert lt. Runbook „wenige Minuten bis 1 Stunde" |
|
|
| RPO (Recovery Point Objective) | [ZU PRÜFEN, Vorschlag: ≤ 24 h] | Abhängig von Snapshot-/Export-Frequenz |
|
|
|
|
> Hinweis: RTO/RPO müssen zu den im SLA gegenüber Kunden zugesagten Werten passen (AGB Anhang B). Aktuell im AGB-Entwurf RTO ≤ 4 h / RPO ≤ 1 h — das erfordert häufigere Sicherungen als die aktuelle wöchentliche Praxis. **Abgleich nötig.**
|
|
|
|
## 5. Restore-Test-Protokoll (Vorlage)
|
|
|
|
| Datum | Getestete DB | Quelle (Backup) | Dauer | Ergebnis | Tester |
|
|
|---|---|---|---|---|---|
|
|
| | | | | | |
|
|
|
|
## 6. Stand der Umsetzung / Lücken
|
|
|
|
| Thema | Status | Massnahme |
|
|
|---|---|---|
|
|
| Backup-Verschlüsselung | Offen | siehe Dok 04 |
|
|
| Backup-Monitoring/Alerting | [ZU PRÜFEN] | Einrichten |
|
|
| Regelmässiger Restore-Test | Offen | Vierteljährlich + Protokoll |
|
|
| RTO/RPO mit SLA abgleichen | Offen | Werte festlegen & Frequenz anpassen |
|