Trust-Modell

Trust

Diese Seite definiert das aktuelle Betriebsversprechen für Resistro Cloud. Jede öffentliche Aussage hier ist direkt der genehmigten Promise-Matrix zugeordnet und sollte zusammen mit den expliziten Grenzen gelesen werden.

Live-Status

Aktueller Betriebsstatus

API-Uptime (24h)

Health-Uptime (24h)

Live-Daten von status.resistro.org — in Echtzeit aktualisiert, nicht von dieser Seite gecacht.

Tarifabhängige Postgres-Backup-Baseline

Resistro Cloud sichert Postgres-Datenbanken mit tarifabhängiger Kadenz für kleine selbst verwaltete Postgres-Setups im definierten ICP: täglich in Solo und Starter, stündlich ab Business.

Umfang: Konfigurierter Backup-Rhythmus für unterstützte selbst verwaltete Postgres-Setups. Der Agent fragt in jedem Tarif mit 1h-Standardintervall nach Backup-Arbeit; der aktive Tarif entscheidet, wie oft ein Backup angenommen wird — täglich in Solo und Starter, stündlich in Business und Pro.

Voraussetzungen: Das Kundensystem muss erreichbar, korrekt angebunden, technisch kompatibel sein und das konfigurierte Backup-Intervall muss im aktiven Tarif erlaubt sein.

Nachweis: Laufende Backup-Jobs, Heartbeat-Monitoring, Prometheus-Metriken.

Kundenerwartung: Im Normalbetrieb mit dem Standard-Agent-Setup wird in Solo und Starter rund einmal täglich und in Business und Pro rund stündlich ein neuer Backup-Lauf erstellt.

Nicht abgedeckt: Postgres-Point-in-Time-Recovery ist nachgewiesen, aber kein aktuelles Produktversprechen; keine automatisierte, laufende PITR-Garantie für alle Kunden-Datenbanken und keine Garantie bei Netzwerk-, Host- oder kundenseitigen Ausfällen.

MySQL/MariaDB als Anfrage-only-Grenzfall

MySQL/MariaDB ist kein gleichwertiger Hauptfit. Resistro behandelt selbst verwaltete MySQL- und MariaDB-Setups nur als begrenzten Anfragepfad ohne Paritätsversprechen.

Umfang: Begrenzter logischer Dump- und Restore-Pfad über den Resistro-Agent für einzeln geprüfte selbst verwaltete MySQL- und MariaDB-Datenbanken.

Voraussetzungen: Das Kundensystem muss erreichbar, korrekt angebunden, technisch kompatibel sein und das konfigurierte Backup-Intervall muss im aktiven Tarif erlaubt sein.

Nachweis: Produktions-E2E am 27. Juni 2026 deckte MySQL- und MariaDB-Backup, verschlüsselten Upload, Download, Entschlüsselung, Restore und Checksum-Match ab.

Kundenerwartung: MySQL/MariaDB kann im Einzelfall geprüft werden; öffentlich gilt kein Gleichrang mit Postgres.

Nicht abgedeckt: Keine Point-in-Time-Recovery, keine physische/native Backup-Garantie, keine Datenbankversions-Migration, keine MySQL/MariaDB-Parität und keine Aussage für verwaltete Datenbankplattformen.

AES-GCM-Verschlüsselung mit Schlüssel auf Kundenseite

Backup-Daten werden vor der Speicherung mit AES-GCM verschlüsselt und der Schlüssel bleibt auf der Kundenseite.

Umfang: Verschlüsselte Backup-Speicherung ohne serverseitigen Klartext-Zugriff.

Voraussetzungen: Der Kunde muss den Schlüssel korrekt bereitstellen und verwalten.

Nachweis: Implementierter Verschlüsselungspfad; kein serverseitiger Zugriff auf Backup-Klartextdaten.

Kundenerwartung: Backup-Daten im Resistro-Speicherpfad werden nicht unverschlüsselt gespeichert.

Nicht abgedeckt: Kein Schlüssel-Recovery und keine darüber hinausgehende Sicherheitsgarantie.

Standard-Speicherpfad Hetzner Deutschland/EU

Der Standard-Speicherpfad nutzt Hetzner-Rechenzentren in Deutschland/EU; Backups werden verschlüsselt gespeichert.

Umfang: Backup-Speicherpfad über Hetzner-Infrastruktur in Deutschland/EU.

Voraussetzungen: Der Kunde nutzt den Standard-Resistro-Speicherpfad; abweichende Sonderarchitekturen müssten separat geprüft werden.

Nachweis: Aktueller Speicheranbieter Hetzner Online GmbH; öffentliche Datenschutzhinweise nennen Hetzner als Hostinganbieter.

Kundenerwartung: Speicherort, Verschlüsselung, AVV/TOMs und Subprozessoren sind dokumentierbare Prüfpunkte für Kundeneinsatz.

Nicht abgedeckt: Keine Rechtsberatung, keine pauschale Datenschutz- oder Risikofreiheitszusage, keine Zusage zu Behördenzugriffs- oder Drittlandrisiken, keine Immunität gegen rechtmäßige Behördenanfragen und keine Zusage für kundenseitige Fremdspeicher.

Täglicher Restore-Test

Resistro führt täglich einen Restore-Pfad-Test als Betriebsprüfung durch, damit der definierte Restore-Pfad nicht stillschweigend bricht.

Umfang: Eine tägliche Betriebsprüfung des definierten Restore-Pfads.

Voraussetzungen: Restore-Test-Jobs müssen planmäßig laufen und die Betriebsumgebung muss verfügbar sein.

Nachweis: Geplanter Restore-Test-Job, Monitoring, Alarmierung bei Ausfall.

Kundenerwartung: Resistro prüft regelmäßig, dass der Restore-Mechanismus noch wie vorgesehen funktioniert.

Nicht abgedeckt: Keine tägliche vollständige Notfallvalidierung jeder Kundendatenbank und keine Konsistenzprüfung auf Anwendungsebene.

Stale-Backup-Alarmierung nach rund einem Tag

Resistro alarmiert, wenn das Monitoring länger als den aktuell auf 28 Stunden gesetzten Stale-Schwellwert keinen erfolgreichen Backup-Status sieht.

Umfang: Backup-Ausfall-Alarmierung basierend auf Heartbeat- und Monitoring-Daten.

Voraussetzungen: Heartbeat, Monitoring und Alarmierungsinfrastruktur müssen alle funktionieren.

Nachweis: Alert-Regeln, Heartbeat-Checks, monitoring-basierte Alarmierung.

Kundenerwartung: Ein stiller Backup-Ausfall sollte im überwachten Pfad nicht länger als rund einen Tag unbemerkt bleiben.

Nicht abgedeckt: Kein 24/7-Support, keine Reaktionszeitgarantie und keine Garantie gegen Ausfälle außerhalb des Resistro-Monitoring-Pfads.

Täglicher /healthz-Smoke-Test

Öffentliche Produktpfade werden täglich auf grundlegende Erreichbarkeit geprüft.

Umfang: Ein täglicher Smoke-Test gegen den öffentlichen Health-Endpunkt.

Voraussetzungen: Die Infrastruktur und der Health-Endpunkt müssen erreichbar sein.

Nachweis: Täglicher Smoke-Test gegen `/healthz`.

Kundenerwartung: Die grundlegende Erreichbarkeit zentraler öffentlicher Produktpfade wird täglich geprüft.

Nicht abgedeckt: Keine Uptime-Garantie und keine umfassende End-to-End-Garantie für alle Kundenfunktionen.

Tarifabhängiges Ziel-RPO

Das Ziel-RPO beträgt im Normalbetrieb rund einen Tag in Solo und Starter und rund eine Stunde in Business und Pro.

Umfang: Ein Zielwert, der sich aus der tarifabhängigen Backup-Kadenz und dem Monitoring ergibt.

Voraussetzungen: Backups müssen ohne längere Unterbrechungskette erfolgreich laufen.

Nachweis: Tarifabhängiger Backup-Rhythmus plus Monitoring, ohne harte Garantiesprache.

Kundenerwartung: Möglicher Datenverlust im Normalbetrieb ist in Solo und Starter auf rund einen Tag und in Business und Pro auf rund eine Stunde begrenzt.

Nicht abgedeckt: Keine harte Uptime- oder Datenverlustgarantie bei Ausfällen zwischen Backup-Fenstern oder bei längeren Störungen.

Manueller operator-gestützter Restore

Der Restore ist ein kontrollierter manueller Vorgang mit Operator-Unterstützung, kein Self-Service-Workflow.

Umfang: Manuelle Restore-Abwicklung, wenn ein gültiges Backup vorhanden und ein operativer Restore möglich ist.

Voraussetzungen: Ein gültiges Backup muss vorhanden sein und der Restore muss operativ durchführbar sein.

Nachweis: Restore-Prozess und täglicher Restore-Pfad-Test.

Kundenerwartung: Der Restore ist ein überwachter operativer Vorgang und kein Self-Service-Knopfdruck.

Nicht abgedeckt: Keine Support-Garantie, keine feste RTO und kein Self-Service-Restore-Portal.

Kundengesteuerte Restore-Drills

Kunden können auf Anfrage Restore-Drills auslösen, um den Restore-Pfad für ihre eigenen Datenbanken zu prüfen.

Umfang: On-Demand-Drill-Auslösung gegen die eigenen Backup-Daten des Kunden.

Voraussetzungen: Ein gültiges Backup für die ausgewählte Datenbank muss vorhanden sein.

Nachweis: Drill-Auslöse-Endpunkt, Drill-Ergebnis-Logging, Restore-Nachweis-PDF-Generierung.

Kundenerwartung: Ein Restore-Drill prüft, dass der Restore-Pfad für die Daten des Kunden zum Zeitpunkt des Drills funktioniert.

Nicht abgedeckt: Ein Drill ist kein produktiver Restore und stellt keine Backup-Garantie über den verifizierten Restore-Pfad hinaus dar.

Restore-Nachweis-PDF

Nach einem Restore-Drill generiert Resistro ein herunterladbares Restore-Nachweis-PDF, das das Ergebnis dokumentiert.

Umfang: PDF-Export des Drill-Ergebnisses als Prüfungsnachweis.

Voraussetzungen: Ein Restore-Drill muss erfolgreich abgeschlossen worden sein.

Nachweis: PDF aus Drill-Ergebnisdaten generiert, einschließlich Zeitstempel, Datenbank und Ergebnis.

Kundenerwartung: Das PDF liefert strukturierten Nachweis eines abgeschlossenen Restore-Drills für interne Prüfung oder Kundennachweis.

Nicht abgedeckt: Keine rechtliche Zertifizierung, kein Compliance-Zertifikat, kein produktiver Restore-Nachweis und keine PITR-Zusage.

Grenzen

Explizit nicht abgedeckt

Postgres-Point-in-Time-Recovery ist nachgewiesen, aber kein aktuelles Produktversprechen; keine automatisierte, laufende PITR-Garantie für alle Kunden-Datenbanken
Keine Uptime-Garantie mit Service-Credits
Keine Support-Reaktionszeitgarantie
Keine Datenbankversions-Migration im Restore-Pfad
Keine MySQL/MariaDB-Point-in-Time-Recovery, keine physische/native Backup-Garantie und kein Paritätsversprechen heute
Keine Aussage für verwaltete Datenbankplattformen wie RDS oder Supabase
Keine harten Anforderungen außerhalb des definierten ICP
Keine Rechtsberatung zu Behördenzugriffs-, Datenschutz- oder Drittlandtransfer-Bewertungen

Operator-Kontext

Wer das betreibt

Alexander Renz ist Linux-Administrator, Gründer von Resistro Cloud und seit dem 28. April 2026 Kleinunternehmer. Er betreibt die Infrastruktur selbst und hält das öffentliche Versprechen bewusst auf das begrenzt, was heute in Produktion real ist.

Versprechen-Grenzen

Wenn eine Aussage auf dieser Seite nicht vertreten ist, sollte sie nicht als Teil des aktuellen Versprechens gelesen werden.