3.4 KiB
3.4 KiB
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.mdAbschnitt 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.mdAbschnitt 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 |