Ein Backup, das nie zurückgespielt wurde, ist eine Behauptung.

Resistro Cloud ist für kleine self-managed Postgres-Setups, typisch 1 bis 10 Datenbanken: Solo-Devs, kleine Agenturen und kleine SaaS auf eigenem Linux-Host. Ein tägliches Backup in Solo oder Starter — oder stündlich ab Business — reicht, Restore-Nachweis zählt, kein eigenes Backup-Ops.

Eine Postgres-Backup-Baseline mit tarifabhängiger Kadenz — täglich in Solo und Starter, stündlich ab Business — AES-GCM-Verschlüsselung, Schlüssel auf Kundenseite, Standard-Speicherpfad über Hetzner-Rechenzentren in Deutschland/EU, ein täglicher Restore-Pfad-Check, Stale-Backup-Alarmierung nach rund einem Tag mit aktuellem 28h-Monitoring-Schwellwert und ein täglicher `/healthz`-Smoke-Test. MySQL/MariaDB ist Anfrage-only ohne Paritätsversprechen.

Nein. Der tägliche Restore-Test ist eine Betriebsprüfung des definierten Restore-Pfads. Er stellt sicher, dass der Restore-Mechanismus nicht stillschweigend bricht, bedeutet aber nicht, dass jede Kundendatenbank täglich einzeln in einem vollständigen Notfallszenario validiert wird.

PITR ist für Postgres nachgewiesen, aber kein aktuelles Produktversprechen. Es gibt keine laufende PITR-Garantie, keine real-size-Zusage und keine harte RTO/RPO. MySQL/MariaDB-PITR ist nicht abgedeckt.

Der Speicherort allein ist nicht die ganze Jurisdiktionsfrage. Der Standard-Speicherpfad nutzt Hetzner-Rechenzentren in Deutschland/EU; Backups werden verschlüsselt gespeichert. AVV/TOMs, Subprozessoren und Drittlandtransfers sind vor Kundeneinsatz im Datenschutzpaket zu prüfen. Das ist keine Rechtsberatung und keine Zusage zu Behördenzugriffs- oder Drittlandrisiken.

Es richtet sich nach dem Tarif: rund ein Tag in Solo und Starter, rund eine Stunde ab Business. Der Agent fragt in jedem Tarif mit 1h-Standardintervall nach Backup-Arbeit, aber der aktive Tarif entscheidet, wie oft ein Backup angenommen wird. Der Zielwert ergibt sich aus dieser Kadenz und ist keine harte Garantie.

Der Restore ist manuell und operator-gestützt. Es gibt keinen Self-Service-Button. Kunden können auf Anfrage Restore-Drills auslösen, um den Restore-Pfad zu überprüfen, und ein Restore-Nachweis-PDF herunterladen.

Das Restore-Nachweis-PDF dokumentiert Zeitpunkt, Scope und Ergebnis eines konkreten Restore-Drills. Es ist ein strukturierter Nachweis für den getesteten Restore-Pfad, keine rechtliche Zertifizierung und kein Compliance-Zertifikat.

Nein. Es gibt keine Support-Garantie, keine Uptime-Garantie, kein Service-Credit-Modell und keine feste RTO-Verpflichtung.

Resistro verwendet Heartbeat- und Prometheus-basiertes Monitoring. Der aktuelle Stale-Backup-Alarm-Schwellwert liegt bei 28 Stunden ohne erfolgreichen Backup-Status.

Backup-Daten werden mit AES-GCM verschlüsselt und der Schlüssel bleibt auf der Kundenseite. Das ist das vollständige Versprechen — einschließlich der Tatsache, dass kein Schlüssel-Recovery möglich ist, wenn der Kunde den Schlüssel verliert.

Gehostete oder verwaltete Datenbankplattformen wie Managed MySQL/MariaDB, RDS oder Supabase, Anforderungen außerhalb des definierten kleinen Postgres-ICP und jede MySQL/MariaDB-Anforderung jenseits begrenzter Logical Dumps. MySQL/MariaDB-heavy ist kein gleichwertiger Hauptfit.

Nein. Er prüft die grundlegende Erreichbarkeit zentraler öffentlicher Produktpfade, keine vollständige Uptime- oder End-to-End-Garantie.

Weil Resistro Cloud nur das verkauft, was heute eng belegbar ist: begrenzte Versprechen, Restore-Verifikation und klare Grenzen statt breiter Sicherheitsrhetorik oder implizierter Garantien.

Nein. Dieselbe resistro-Engine. Andere Betriebsform: Die Management Console und die Backups laufen in eurer eigenen Infrastruktur statt bei uns. Die Console ist dabei bewusst eine Teilmenge der CLI: sie löst Backup, Restore-Test, Drill und PITR-Restore aus und ist sonst nur lesend.

Nein. Cloud bleibt der SaaS-Pfad. Enterprise ist für Teams, die die Management Console selbst betreiben und Backups nicht in den SaaS-Speicher legen wollen oder dürfen.