Business Continuity (BCP) und Disaster Recovery (DRP)
Dokumenttyp: Konzept & Plan
Geltungsbereich: PORTA-Plattform und zugehörige Infrastruktur
Version: 1.0
Status: Entwurf zur internen Freigabe
Owner: Geschäftsführung / Betrieb
Letzte Aktualisierung: 02.06.2026
Deckt ab (CACC): 3, 79, 87
Verweist auf: bcm_runbook.md, 05_Backup_und_Wiederherstellung.md, drittanbieter-inventar.md
1. Zweck
Dieser Plan stellt die kontinuierliche Leistungserbringung und die Wiederherstellung der PORTA-Plattform im Katastrophen- und Störfall sicher. Die operativen Schritte sind im bcm_runbook.md dokumentiert; dieses Dokument liefert den organisatorischen Rahmen (Szenarien, Rollen, Ziele, Tests).
2. Kritische Komponenten und Abhängigkeiten
Aus dem Drittanbieter-Inventar ergeben sich die geschäftskritischen Abhängigkeiten:
| Komponente |
Anbieter |
Auswirkung bei Ausfall |
| VM-Hosting & DB |
Infomaniak (CH) |
Totalausfall der Plattform |
| Primärer LLM-Provider |
OpenAI (USA) |
KI-Features (Chat, Agent, Automation) nicht verfügbar — Ausweichen auf Anthropic/Mistral möglich |
| Auth |
Microsoft Azure AD / Google OAuth |
Login für betroffene Nutzer nicht möglich |
| Zahlungen |
Stripe |
Neue Abos/Zahlungen schlagen fehl |
| System-E-Mail |
Azure Communication Services (CH) |
Einladungen/Benachrichtigungen werden nicht zugestellt |
3. Szenarien und Reaktion
| # |
Szenario |
Reaktion |
Referenz |
| 1 |
API antwortet nicht / Timeouts |
Service-Neustart |
bcm_runbook.md §1 |
| 2 |
Datenverlust / fehlerhafte Migration |
Backup-Restore |
bcm_runbook.md §2 |
| 3 |
Fehlerhaftes Release |
Rollback (Git/Forgejo) |
bcm_runbook.md §3 |
| 4 |
Ausfall LLM-Primärprovider |
Umschalten auf alternativen Provider (Anthropic/Mistral) |
[ZU PRÜFEN: Failover-Konfiguration dokumentieren] |
| 5 |
Totalausfall Infomaniak-Region |
Wiederaufbau aus Export-Backup |
siehe unten |
4. Verfügbarkeitsüberwachung (#79)
- Health-Check-Endpunkt:
GET /api/admin/health (liefert 200 OK bei intaktem Betrieb).
- [ZU PRÜFEN: Existiert ein automatisiertes Uptime-Monitoring, das den Health-Check periodisch prüft und bei Ausfall alarmiert? Falls nicht: einrichten (z. B. externer Monitor + Alert an Betrieb).]
5. Wiederherstellungsziele
| Parameter |
Zielwert |
Quelle |
| RTO |
[ZU PRÜFEN, Vorschlag ≤ 4 h] |
mit SLA abgleichen |
| RPO |
[ZU PRÜFEN, Vorschlag ≤ 24 h] |
abhängig von Backup-Frequenz |
6. Geografische Trennung / Backup-Standort
Offener Punkt: Punkt #3 / FINMA verlangt angemessene Redundanz. Aktuell liegen Prod und Backup in der Infomaniak-Umgebung. [ZU PRÜFEN: Liegen Snapshots/Backups in einer getrennten Infomaniak-Region oder einem getrennten Rechenzentrum? Falls nicht, geografisch getrennte Backup-Ablage als Massnahme aufnehmen.]
7. Tests und Überprüfung
| Test |
Häufigkeit |
Status |
| Restore-Test (DB) |
Vierteljährlich |
siehe Dok 05 — neu einzuführen |
| Rollback-Übung |
Halbjährlich |
[ZU PRÜFEN] |
| LLM-Failover-Test |
Halbjährlich |
[ZU PRÜFEN] |
| BCP-Review (Aktualität) |
Jährlich |
neu |
8. Kommunikation im Notfall
| Rolle |
Kontakt |
| Betrieb / DevOps (Server-Zugang) |
Patrick Motsch — p.motsch@poweron.swiss |
| Drittdienste / Eskalation |
Patrick Motsch — p.motsch@poweron.swiss |
| Kundeninformation (bei Vorfall) |
siehe 07_Incident_Response_und_Meldewesen.md |
9. Stand der Umsetzung / Lücken
| Thema |
Status |
Massnahme |
| Automatisiertes Uptime-Monitoring |
[ZU PRÜFEN] |
Einrichten + Alerting |
| Geografisch getrenntes Backup |
[ZU PRÜFEN] |
Klären / umsetzen |
| Dokumentierte Tests |
Offen |
Testplan etablieren |
| LLM-Failover dokumentieren |
Offen |
Konfiguration festhalten |