Resistro Cloud liefert Backup-Baseline, Monitoring und Restore-Nachweise für kleine selbst verwaltete Postgres-Setups ohne eigenes Backup-Ops-Team.
Postgres ist der Produktanker. MySQL/MariaDB sind begrenzte Logical-Dump-Pfade, keine PITR- oder physische Backup-Parität.
Resistro begann als Open-Source-CLI und Engine, nicht als SaaS-Dashboard. Resistro Cloud ergänzt die Betriebsebene für kleine Postgres-Setups: Setup-Prüfung, Agent-Anbindung, Monitoring, Restore-Drills und Nachweise. MySQL/MariaDB bleiben Anfrage- und Grenzfälle ohne Paritätsversprechen.
Die Community-Plattform hinter unserem Amateurfunk-Projekt 11m-band.de speichert ihre Live-PostgreSQL-Datenbank als gewöhnlichen Resistro-Cloud-Tenant — über denselben Produktpfad, den wir verkaufen, nicht über ein separates internes Setup. Die Backups laufen im Stundentakt, überwacht auf stille Ausfälle, mit demselben Agent, derselben Verschlüsselung und demselben Standard-Speicherpfad über Hetzner-Rechenzentren in Deutschland/EU, den jeder Kunde bekommt. Wenn der Restore-Pfad bräche, würden wir es als Erste merken.
Ein kundengesteuerter Restore-Drill erzeugt einen datierten Ergebnisdatensatz und ein Restore-Nachweis-PDF: gewähltes Backup, Restore-Ziel, Ergebnis und Operator-Notizen. Das ist ein Nachweis für den getesteten Restore-Pfad, keine rechtliche Zertifizierung oder SLA-Zusage.
Software, Agent-Anbindung und Monitoring statt Managed-Retainer-Versprechen.
Tägliche Backups in Solo und Starter, stündlich ab Business. Der Agent fragt in jedem Tarif mit 1h-Standardintervall nach Arbeit; wie oft tatsächlich gesichert wird, entscheidet der Tarif.
Anfrage-only für selbst verwaltete Datenbanken; kein Paritäts-, PITR- oder physisches Backup-Versprechen.
PITR ist nachgewiesen, aber kein aktuelles Produktversprechen, keine laufende Garantie und keine harte RTO/RPO-Zusage.
Restore-Tests als laufende Betriebsprüfung des definierten Restore-Pfads.
Kundengesteuerte Drills mit Restore-Nachweis-PDF und operator-gestütztem Ergebnis.
AES-256-GCM client-seitig vor dem Upload; der Server erhält nur einen SHA-256-Hash des Schlüssels, nie Schlüssel oder Klartextdaten.
Hetzner-Rechenzentren in Deutschland/EU; Backups werden verschlüsselt gespeichert. Rechtliche Rollen, Subprozessoren und Transfers sind im Datenschutzpaket zu prüfen.
Alarmierung nach rund einem Tag; aktueller Monitoring-Schwellwert: 28h.
Täglicher `/healthz`-Smoke-Test für öffentliche Produktpfade.
Diese Punkte sind bewusst als Roadmap markiert. Sie sind kein heutiges Betriebsversprechen, aber sie zeigen, welche Evaluierungsfragen Resistro als Nächstes schließen muss.
Heute bleiben Backup-Schlüssel auf Kundenseite. Der nächste Enterprise-Schritt ist ein sauberer BYOK-Flow mit prüfbarer Schlüsselrotation, Key-Status und klarer Verantwortung bei Schlüsselverlust.
SOC 2 Type II ist für Enterprise-Einkauf und regulierte Kunden der belastbare Nachweis für laufende Kontrollen. Resistro behandelt SOC 2 Type II als Roadmap-Punkt, nicht als vorhandene Zertifizierung.
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.
Resistro Cloud passt, wenn du selbst verwaltete Postgres-Datenbanken betreibst, kein eigenes Backup-Ops-Team hast und Restore-Verifikation als laufenden Prozess brauchst. MySQL/MariaDB passt nur als begrenzte Logical-Dump-Unterstützung. Es passt nicht, wenn du harte Uptime- oder Support-Garantien, gehosteten Datenbankbetrieb oder vollautomatisches Self-Service-Restore benötigst.