Resistro Enterprise: dieselbe Backup-Baseline, in eurer Infrastruktur
Resistro Enterprise ist die dritte Betriebsform — kein neues Produktversprechen, sondern derselbe Backup-Weg, installiert bei euch.
Resistro Cloud sichert selbst verwaltete Postgres-Setups über einen Agenten, mit Schlüssel auf Kundenseite und Restore-Nachweis. Das bleibt. Zusätzlich gibt es jetzt Resistro Enterprise: eine Management Console, die Unternehmen in der eigenen Infrastruktur betreiben — für Datenbank-Backups, die das Rechenzentrum nicht verlassen sollen.
Damit ist das Portfolio vollständig:
- CLI — Open Source, für alle, die Backup und Restore selbst steuern.
- Resistro Cloud — SaaS-Sicherung mit Agent, Monitoring und Restore-Drill.
- Resistro Enterprise — dieselbe Betriebsebene, installiert beim Unternehmen.
Enterprise steht zur Cloud wie ein anderer Plan, nicht wie ein anderes Produkt. Gleiche Idee: Backup, das sich wiederherstellen lässt. Anderer Betriebsort: eure Infrastruktur statt cloud.resistro.org.
Was die Console auslösen kann — und was nicht
Die Console ist bewusst eine Teilmenge der CLI, keine CLI-Parität. Sie löst Backup, Restore-Test, Drill, PITR-Restore, Retention-Änderungen und Schlüsselverwaltung aus. Alles andere — verify, catalog, chain, forecast, estimate, WAL-Archiv-Steuerung, encryption rotate — läuft agentseitig oder nur im Terminal; dort bleibt die Console lesend oder zeigt es gar nicht.
Was Enterprise heute ist
Resistro Enterprise ist eine Management Console für den Self-Hosted-Betrieb, die ihr auf eigener Infrastruktur installiert. Heute deckt sie ab:
- Identity-Provider: OIDC, SAML und SCIM — rollenbasierte Zugriffe über IdP-Mappings, automatische Benutzer-Provisionierung.
- BYOK/KMS: kundeneigener Master-Key für Backup-Verschlüsselung (Envelope-Encryption), Provider wahlweise lokale Datei, HashiCorp Vault Transit oder AWS KMS.
- Air-Gap-Betrieb: zentraler Egress-Guard (
RESISTRO_AIRGAP=1) sperrt alle ausgehenden Verbindungen; MFA/TOTP-QR wird lokal erzeugt, kein externer Dienst nötig. - Audit-Export: CSV oder PDF, plus maschinenlesbarer Retentions- und Recoverability-Report.
- Alerting: eingebaute Regeln (Backup fehlgeschlagen/überfällig, Drill, PITR, Agent offline, Lizenz, Anomalie-Erkennung) mit Kanälen E-Mail, Webhook (Slack, Teams, PagerDuty).
- Hochverfügbarkeit (Active/Passive): zwei Console-Instanzen gegen dieselbe PostgreSQL, automatische Übernahme bei Ausfall der Console-Instanz. Leader-Wahl über PostgreSQL-Advisory-Lock, Split-Brain konstruktiv ausgeschlossen. Übernahme im Normalfall ≤ ~2 s nach Verbindungsabbau (Default-Poll 2 s). Ausfall der Datenbank selbst ist nicht abgedeckt — dafür wird ein PostgreSQL-Standby empfohlen (Streaming-Replication, z. B. Patroni).
- Incident-Runbook: Triage über
/healthund/admin/doctor(Datenbank, Schema, Lizenz, Air-Gap), Support-Bundle als ZIP über/admin/supportoderresistro-console doctor(Secrets geschwärzt), Restore-Pfad über/admin/recoverabilitymit Nachweis-PDF. - Eigenes Branding: Firmenlogo und Farbschema in der Console.
Daten und Schlüssel bleiben in eurem Netz. Es gibt keinen Pflicht-Upload in den Resistro-SaaS-Speicher.
Das ist der Unterschied, der für viele Einkäufer zählt: nicht „mehr Features", sondern Datenresidenz und Betriebsverantwortung beim Unternehmen.
Was es nicht ist
Enterprise ist kein Hard-SLA, kein SOC-2-Siegel und kein Ersatz für eure eigene Betriebsführung. Die Console ersetzt weder den Linux-Host noch den Restore-Drill selbst — der läuft wie beim Binary über die resistro-Engine, nicht über ein Dashboard. Enterprise macht Zugriff, Nachweis und Betriebsdaten sichtbar und steuerbar, in eurem Netz.
Wer Cloud nutzt, weil er kein eigenes Backup-Ops will, bleibt bei Cloud. Wer Backups nicht aus dem eigenen Netz lassen darf oder die Console selbst betreiben will, nimmt Enterprise.
Das Portfolio in einem Satz
Die CLI ist das Werkzeug. Cloud ist der betriebene Dienst. Enterprise ist derselbe Dienst, den ihr selbst betreibt.
Open Source bleibt Open Source. Cloud bleibt der schmale SaaS-Pfad für kleine self-managed Postgres-Setups. Enterprise schließt die Lücke für Unternehmen, die die Management-Ebene intern brauchen.
Installation, Upgrade und Evaluation
Die Console wird über einen Installer (install-console.sh) ausgerollt: Release-Artefakt herunterladen, SHA256-Hash gegen das Manifest prüfen, Binary und Systemd-Unit installieren. Der Agent-Installer (install-agent.sh) folgt demselben Muster auf den Datenbank-Hosts. Beide Installer sind idempotent — bei Reinstallation bleibt die bestehende Config erhalten.
Updates laufen über resistro-console upgrade: vor jeder Migration wird ein vollständiger pg_dump gezogen, schlägt eine Migration fehl, bricht der Lauf ab und die Datenbank bleibt im Stand vor dem Upgrade. Der Upgrade-Pfad ist über zwei Versionsschritte getestet (N-2).
Für die Evaluation gibt es ein parametrisiertes Eval-Bundle (make eval-bundle KUNDE=... LIMIT=... DAYS=...): ein Aufruf erzeugt Release-Tarball, signierte Eval-Lizenz und Kurzanleitung. Bei Conversion zur Voll-Lizenz wird dasselbe CA-Schlüsselpaar wiederverwendet — kein neues Binary nötig.
Für wen es passt
Enterprise passt, wenn:
- Datenbanken self-managed laufen (typisch Postgres; MySQL/MariaDB wie bisher als begrenzter logischer Pfad),
- Backup und Restore nachweisbar sein sollen,
- Speicherung und Steuerung in der eigenen Infrastruktur liegen müssen,
- jemand intern die Console betreiben kann.
Es passt nicht, wenn ihr eine verwaltete Datenbank (RDS, Supabase & Co.) sichern wollt oder ein Versprechen braucht, das über den Trust-Rahmen hinausgeht.
Nächster Schritt
Cloud bleibt unter cloud.resistro.org testbar, 14 Tage, ohne Karte. Enterprise ist der andere Plan: Installation der Management Console in eurer Infrastruktur.
Wer prüfen will, ob der Fit stimmt, liest zuerst das Trust-Modell — dieselben Grenzen gelten, nur der Betriebsort ändert sich.