Wie werden meine Daten gesichert?

Backup-Strategie verstehen

Auf einen Blick

Wann	Was	Wo gespeichert
Mo–Sa, 03:00 UTC	Differential-Backup (nur Änderungen seit letztem Voll-Backup)	Hetzner Storage Box, Datacenter Falkenstein
Sonntags, 02:00 UTC	Voll-Backup (komplette Datenbank)	Hetzner Storage Box, Datacenter Falkenstein
Permanent (alle 16 MB Datenänderung)	WAL-Archiv (Transaction-Log)	Hetzner Storage Box, sofort beim Schreiben
alle 6 Stunden	Status-Snapshot ins Operations-Log	Haupt-VM (Operations)

Restore-Horizont: 8 Wochen rückwärts, taggenauer Wiederherstellungspunkt für jeden Tag innerhalb der letzten 8 Wochen.

Was bedeutet welcher Backup-Typ?

Voll-Backup (jeden Sonntag)

Die komplette Datenbank wird ausgelesen und auf die Storage Box hochgeladen. Bei aktueller Größe (~50 MB unkomprimiert) dauert das ca. 4 Minuten. Nach Komprimierung + Verschlüsselung landet ein Voll-Backup bei ~6–8 MB auf der Storage Box.

Zweck: Basis für die nachfolgenden Diff-Backups + ist auch ohne weitere Bausteine alleine wiederherstellbar.

Differential-Backup (Mo–Sa)

Nur die Änderungen seit dem letzten Voll-Backup. Ein Diff-Backup vom Mittwoch enthält alle Änderungen von Sonntag-Abend bis Mittwoch-Morgen. Diff-Backups sind klein (~1–5 MB), schnell (~30 Sekunden) und billig zu speichern.

Zweck: Tägliche Datensicherung mit sehr geringem Speicheraufwand. Restore eines Diffs erfordert das passende Voll-Backup als Basis.

WAL-Archiv (kontinuierlich)

PARITY.med PostgreSQL schreibt jede Datenbank-Änderung zuerst in ein Write-Ahead-Log (WAL). Sobald ein 16-MB-WAL-Segment voll ist, wird es sofort an die Storage Box hochgeladen. Bei normaler Last passiert das alle paar Minuten, bei viel Last sekündlich.

Zweck: Punktgenauer Restore. Mit den WAL-Archiven kann ein Restore auf jeden Zeitpunkt der letzten 8 Wochen wiederhergestellt werden — minutiös, nicht nur tageweise. Beispiel: „Stelle den Stand wieder her wie er am Dienstag um 14:23 Uhr war" → kein Problem.

Status-Log (alle 6 Stunden)

Kein Backup, sondern ein Health-Check. Das System schreibt alle 6 Stunden den aktuellen Backup-Stand ins Operations-Log. Damit kann der PARITY-Operator jederzeit erkennen, ob die Pipeline läuft. Zusätzlich greift bei Problemen die Watchdog-Alarmierung (siehe „Backup-Health-Probe" weiter unten).

Wo liegen die Backups?

Hetzner Storage Box, Datacenter Falkenstein.

PARITY.med Haupt-VM (mit Postgres + Anwendung) läuft in Nürnberg. Die Backups liegen in einem anderen Datacenter (Falkenstein, ~150 km Luftlinie) — das ist die Basis-Anforderung an „Off-Site-Backup":

Bei Komplettausfall des Nürnberg-Datacenters (Stromnetz, Brand, Hochwasser) bleiben die Backups erhalten
Bei einem Ransomware-Angriff auf die Haupt-VM kommt der Angreifer nicht an die Backups (separater Account, separater Login)

Beide Datacenter werden von Hetzner Online GmbH (Gunzenhausen, Deutschland) betrieben — DSGVO-konform, keine Drittland-Übermittlung.

Wie sind die Backups geschützt?

Verschlüsselung

Alle Backup-Dateien sind mit AES-256-CBC verschlüsselt. Der Schlüssel (Cipher-Passphrase) liegt ausschließlich auf der PARITY.med Haupt-VM und parallel im PARITY-internen Passwort-Manager. Hetzner sieht nur Ciphertext — selbst Hetzner-Mitarbeiter können den Inhalt nicht lesen.

Auch wenn jemand den Storage-Box-Zugang kompromittiert (gestohlene Anmeldedaten, kompromittiertes Hetzner-Konto), erhält er nur unbrauchbare Bytes. Ohne den Cipher-Schlüssel sind die Backups praktisch wertlos.

Authentifizierung

Der Zugriff auf die Storage Box erfolgt ausschließlich über einen SSH-Key auf der Haupt-VM (kein Passwort-Login). Ein Angreifer müsste damit zuerst die Haupt-VM kompromittieren, um überhaupt mit der Storage Box sprechen zu können.

Schreibrechte vs. Löschrechte

Die Backups werden permanent gemäß der Retention-Policy automatisch gelöscht (siehe nächster Abschnitt). Eine manuelle, sofortige Löschung aller Backups wäre nur über den Hetzner-Konsole-Login (Admin-Account von PARITY-Software) oder durch Kompromittierung der Haupt-VM möglich.

Hinweis Schutz vor Ransomware: Ein Angreifer, der die Haupt-VM kompromittiert, könnte theoretisch auch die Backups zerstören. Mitigation: Hetzner Storage Box hat kein „delete protection" — als Folge-Maßnahme prüfen wir die Aktivierung von Hetzner-Snapshot-Funktion auf Storage-Box-Ebene.

Retention — wie lange werden Backups aufgehoben?

Backup-Typ	Retention	Ergebnis
Voll-Backup	8 Stück = 8 Wochen	Du kannst auf jeden Sonntag der letzten 8 Wochen zurückgehen
Differential-Backup	7 pro Voll = 7 Wochentage	Du kannst auf jeden Tag der letzten 8 Wochen zurückgehen
WAL-Archiv	so lange das passende Voll-Backup existiert	Du kannst auf jede Sekunde der letzten 8 Wochen zurückgehen

Effektiver Restore-Horizont: 8 Wochen, mit minutengenauer Auflösung.

Speicheraufwand: ~150–200 MB total bei aktueller Datengröße. Im Hetzner-Storage-Box-Free-Tier (1 TB inklusive) jahrelang ausreichend.

Längere Retention (z.B. 12 Monate Monatssicherungen für Audits): kommt mit Phase B Wave 4 als Erweiterung. Aktuell genügt der 8-Wochen-Horizont für den dev-/Pilot-Betrieb.

Was passiert bei einem Ausfall?

Szenario 1: Datenbank ist hin (Korruption, versehentlich gelöschte Tabelle)

PARITY-Operator stoppt das Backend (verhindert weitere Schreibvorgänge auf der kaputten DB)
Postgres wird in einen frischen Container restored aus dem letzten passenden Voll-Backup + dazugehörigen Diffs + WAL-Archive bis zum gewünschten Zeitpunkt
Backend wird wieder gestartet, Anwender können weiterarbeiten

Erwartete Wiederherstellungszeit (RTO): 30–60 Minuten für ~50 MB DB. Maximaler Datenverlust (RPO): < 1 Minute (durch das WAL-Archiving).

Szenario 2: Komplettausfall der Haupt-VM (Hetzner-Datacenter Nürnberg down)

Neue VM bei Hetzner provisionieren (in einem anderen Datacenter — Falkenstein oder Helsinki)
PARITY-Stack komplett aufsetzen (Docker-Compose-Files sind im git-Repository versioniert)
Postgres aus letztem Backup auf der Storage Box wiederherstellen
DNS-Eintrag aktualisieren (api.dev.parity.med zeigt auf die neue VM)
Backend startet, Mandanten arbeiten weiter

Erwartete Wiederherstellungszeit: 2–4 Stunden je nach Komplexität.

Szenario 3: Mandant löscht aus Versehen Daten (z.B. einen großen Auftragsblock)

Heute (V1): PARITY-Operator restored gezielt diese Daten aus einem Backup vor der Löschung. Mandant arbeitet weiter, die Lücke wird per Support-Ticket geschlossen.

Später (V2): Self-Service-„Time-Travel"-Funktion im Suite-Portal — Mandanten-Admin wählt Datum + Zeit und stellt einzelne Datensätze wieder her, ohne PARITY-Support kontaktieren zu müssen.

Backup-Health-Überwachung

Die PARITY-Operations-Plattform überwacht automatisch, dass die Backup-Pipeline läuft:

Alle 6 Stunden schreibt das System den Backup-Status ins Log
Geplant (Folge-PR nach Wave 3): Watchdog-Probe alarmiert per Mail/Teams/ntfy, wenn das letzte Voll-Backup älter als 8 Tage ist oder der letzte Diff älter als 26 Stunden
Automatischer Restore-Drill (Wave 3): wöchentlich wird ein zufälliges Backup auf einer Test-Instanz wiederhergestellt und gegen die Original-Daten verglichen — Backup nutzt nur, wenn der Restore-Pfad funktioniert

Damit greift das System sofort bei einem stillen Ausfall der Backup-Pipeline und alarmiert den PARITY-Operator, statt erst beim ersten Restore-Versuch festzustellen, dass die Backups defekt waren.

Häufige Fragen

F: Werden meine Daten zusammen mit denen anderer Mandanten gesichert?

A: Ja. PARITY.med läuft als Suite-Architektur mit einem gemeinsamen Postgres-Cluster (siehe ADR 0007). Das Backup enthält alle Mandanten-Daten in einer Datei — getrennt durch das Row-Level-Security-Modell (jede Tabelle hat eine tenant_id-Spalte mit RLS-Policy).

Bei einem Restore werden alle Mandanten-Daten gemeinsam auf den Wiederherstellungs-Stand zurückgesetzt. Pro-Mandant-Restore ist heute nicht möglich — kommt mit V2 (siehe Szenario 3 oben).

F: Kann ich ein eigenes Backup meiner Daten herunterladen?

A: Heute nicht direkt — Backups gehören PARITY und sind verschlüsselt. Was Du selbst exportieren kannst (über das Suite-Portal):

CSV-Export pro Geschäftspartner-Liste (kommt mit Sprint 4)
DATEV-Export pro Buchungsperiode (heute live)
SEPA-XML pro Mandat (heute live)
GKV-§300-Datei pro Abrechnung (heute live)

Diese Exports decken die typischen Auskunfts- und Portabilitäts-Anforderungen (DSGVO Art. 20) ab. Bei Sonderbedarf (z.B. komplette Datenbank-Kopie für eigene Archivierung) können wir nach Absprache ein verschlüsseltes Voll-Backup auf einen Storage-Bereich Deiner Wahl liefern.

F: Wie lange werden Backups bei Vertragsende aufgehoben?

A: 30 Tage für Datenexport-Aufgaben. Danach werden alle Mandanten-Daten DSGVO-konform aus der Live-Datenbank gelöscht — der PARITY-Operator führt das Skript aus. Der Lösch-Vorgang ist atomar: alle Mandanten-Tabellen + Tenant-Eintrag werden in einer Transaktion entfernt, ein nachvollziehbarer Audit-Log-Eintrag mit Begründung bleibt zurück, und ein frisches Voll-Backup wird ausgelöst.

Backup-Inhalte mit Mandanten-Daten verbleiben anschließend bis zum Ablauf der Retention-Policy (8 Wochen Voll-Backup-Historie + 7 Diffs pro Voll). Erst danach sind die Daten physisch unwiederherstellbar — Hetzner Storage-Box-Operatoren sehen nur Ciphertext, ohne Cipher-Pass kein Zugriff.

Wenn Du vor Ablauf der Retention bestätigt haben möchtest, dass keine Daten mehr von Dir vorliegen: das ist eine bewusste Risiko-Entscheidung — ein sofortiger pgbackrest expire würde die Restore-Möglichkeit aus der aktuellen Backup-Periode für alle Mandanten zerstören. Wir besprechen das im Einzelfall mit Geschäftsführung + ggf. externer DSGVO-Beratung.

Aufbewahrungspflicht beachten: Wenn Du PARITY für Rechnungs- oder Buchhaltungs-Daten genutzt hast, gelten die gesetzlichen 10-Jahres-Aufbewahrungsfristen (§ 147 AO, § 257 HGB) — diese Daten dürfen wir auch auf Deinen Wunsch hin nicht sofort hart löschen. In dem Fall wird Dein Mandant deaktiviert (read-only) und die Daten verbleiben bis Frist-Ablauf, danach automatischer Hard-Delete.

F: Kann ich einen sofortigen Backup auslösen, bevor ich eine größere Migration mache?

A: Ja — sprich uns an. PARITY-Support löst dann ein Sofort-Voll-Backup aus, bevor Du z.B. einen großen Stammdaten-Import startest. Im Notfall ist dieses Backup der Wiederherstellungs-Punkt, falls der Import schiefgeht.

Self-Service-Sofort-Backup (per Knopfdruck im Suite-Portal) ist V2-Item — die Funktionalität existiert technisch, das UI fehlt noch.

F: Sind Backup-Inhalte revisionssicher (für Aufbewahrungsfristen)?

A: Die Backups sind zeitstempel-versehen + verschlüsselt + auf einem separaten System. Sie erfüllen damit die typischen Anforderungen an „Geschäftsdaten-Sicherung" nach §147 AO und §257 HGB. Strenge Revisionssicherheit (WORM-Storage, Immutability-Bonded) liegt aktuell nicht vor — das wäre V2-Erweiterung mit Hetzner-Snapshots oder einem dedizierten Compliance-Storage.

F: Was ist mit den Datei-Anhängen (PDFs, GKV-Exporte)?

A: Datei-Anhänge liegen in MinIO (S3-kompatibler Object-Storage). MinIO-Daten sind aktuell noch nicht im Backup-Schema enthalten — kommt mit Phase B Wave 4. Praktisch: bis dahin lassen sich PDFs + Exporte aus den Quelldaten neu erzeugen (Postgres-DB enthält die Geschäftsdaten, PDF ist nur die Render-Form), so dass auch ohne MinIO-Backup keine echten Daten verloren gehen.

F: Kann ich die Backup-Frequenz erhöhen (z.B. alle 4 Stunden)?

A: Heute pauschal nicht — die Pipeline ist auf das tägliche Schedule abgestimmt. Bei besonderem Bedarf (z.B. Mandant mit hohem Schreibvolumen) lässt sich die Cron-Konfiguration anpassen. Sprich uns an, wir bewerten das im Pilot-Kontext.

Hintergrund: Die WAL-Archive sorgen ohnehin für minutiöse Wiederherstellbarkeit zwischen den Diff-Backups — eine erhöhte Diff-Frequenz brächte praktisch nur einen kleineren Restore-Recovery-Path, nicht mehr Datensicherheit.