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

Current operational status

API uptime (24h)

Health uptime (24h)

Live data from status.resistro.org — updated in real time, not cached by this page.

1h Standard-Postgres-Backup-Baseline

Resistro Cloud sichert Postgres-Datenbanken mit einem 1h Standard-Agent-Intervall für kleine selbst verwaltete Postgres-Setups im definierten ICP.

Umfang: Konfigurierter Backup-Rhythmus für unterstützte selbst verwaltete Postgres-Setups; das Standard-Agent-Intervall beträgt 1h.

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 rund jede Stunde ein neuer Backup-Lauf erstellt.

Nicht abgedeckt: Keine Point-in-Time-Recovery und keine Garantie bei Netzwerk-, Host- oder kundenseitigen Ausfällen.

MySQL/MariaDB-Backup- und Restore-Pfad

Resistro Cloud unterstützt Backup-Upload, Download, Entschlüsselung und Restore-Drill-Verifikation für kleine selbst verwaltete MySQL- und MariaDB-Setups im definierten ICP.

Umfang: Logischer Dump- und Restore-Pfad über den Resistro-Agent für unterstützte 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: Für unterstützte selbst verwaltete MySQL- und MariaDB-Setups funktioniert der Backup- und Restore-Drill-Pfad über Resistro Cloud.

Nicht abgedeckt: Keine Point-in-Time-Recovery, keine physische/native Backup-Garantie, keine Datenbankversions-Migration 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.

EU-only Speicherung ohne US-Provider-CLOUD-Act-Pfad

Resistro speichert Backup-Daten bei Hetzner in der EU statt bei einem US-Cloud-Provider mit bloßer EU-Region.

Umfang: Backup-Speicherpfad über Hetzner als deutschen Anbieter mit EU-Rechenzentrumsstandorten.

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: Für DACH-Prüfungen gibt es keinen US-Provider-CLOUD-Act-Pfad wie bei AWS, Azure oder Google Cloud mit EU-Region.

Nicht abgedeckt: Keine Rechtsberatung, keine Immunität gegen rechtmäßige deutsche oder europäische 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, Telegram-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.

Alarmierung nach mehr als 25 Stunden ohne gültigen Backup-Status

Resistro alarmiert, wenn es mehr als 25 Stunden keinen gültigen Backup-Status gegeben hat.

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

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

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

Kundenerwartung: Ein stiller Backup-Ausfall sollte 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.

Ziel-RPO von rund einer Stunde

Das Ziel-RPO beträgt im Normalbetrieb rund eine Stunde.

Umfang: Ein Zielwert, der sich aus dem konfigurierten Backup-Intervall und dem Monitoring ergibt.

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

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

Kundenerwartung: Möglicher Datenverlust im Normalbetrieb ist 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, Compliance-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.

Compliance-PDF-Export

Nach einem Restore-Drill generiert Resistro ein herunterladbares Compliance-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 Prüfungs- oder interne Compliance-Zwecke.

Nicht abgedeckt: Keine rechtliche Zertifizierung. Deckt keine produktiven Restore-Ergebnisse oder PITR ab.

Deduplizierte Agent-Uploads

Der Resistro-Agent dedupliziert wiederholte Backup-Daten vor dem Upload und reduziert so Speicher- und Transfervolumen.

Umfang: Clientseitige Deduplizierung für wiederholte Datenblöcke über mehrere Backup-Läufe.

Voraussetzungen: Erfordert den Resistro-Agent in einer Version, die Deduplizierung unterstützt.

Nachweis: Deduplizierter Agent-Upload-Pfad in Produktion aktiv.

Kundenerwartung: Unveränderte Datenblöcke werden bei nachfolgenden Backup-Läufen nicht erneut hochgeladen.

Nicht abgedeckt: Keine Komprimierungsgarantie über Deduplizierung hinaus. Gilt nicht für Erstläufe oder vollständig veränderte Datensätze.

Grenzen

Explizit nicht abgedeckt

Keine Point-in-Time-Recovery heute
Keine Uptime-Garantie mit Service-Credits
Keine Support-Reaktionszeitgarantie
Keine Datenbankversions-Migration im Restore-Pfad
Keine MySQL/MariaDB-Point-in-Time-Recovery und keine physische/native Backup-Garantie heute
Keine Aussage für verwaltete Datenbankplattformen wie RDS oder Supabase
Keine harten Anforderungen außerhalb des definierten ICP
Keine Rechtsberatung zur CLOUD-Act-, DSGVO- oder Drittlandtransfer-Bewertung

Operator context

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.