# 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 |