OpenShip-Datenbank-Backup: Managed oder selbst verwaltet?

Die OpenShip-Preisseite weist am 02.08.2026 darauf hin, dass die Pläne pausiert sind und der Preis für OpenShip Cloud noch nicht angekündigt wurde. (OpenShip-Preisseite) Deshalb sollten Sie ein OpenShip-Datenbank-Backup nicht anhand eines scheinbar günstigen Monatspreises auswählen: Bei geringer Betriebsverantwortung oder klaren Wiederherstellungszielen ist Managed Backup meist die sicherere Wahl. Selbst verwaltete Sicherungen lohnen sich erst, wenn Sie Speicher, Überwachung, Berechtigungen und Wiederherstellung regelmäßig selbst betreiben können.

Symptom: Das Backup meldet „erfolgreich“, aber niemand kann sagen, ob PostgreSQL, Redis, Dateien und Agent-Zustände gemeinsam wieder anlaufen.

Schnellste Lösung: Definieren Sie zuerst RPO und RTO, berechnen Sie danach die vollständigen Betriebskosten und führen Sie vor dem Produktionsstart eine isolierte Wiederherstellung durch.

Diese Analyse richtet sich an Sie, wenn Sie eine OpenShip-Anwendung aus dem Prototyp in den produktiven Betrieb überführen. Sie ist besonders relevant, wenn Ihr AI SaaS Agent-Sitzungen, Benutzerdateien, Abrechnungsdaten oder laufende Aufgaben speichern muss. Auch technische Verantwortliche, die zwischen einem verwalteten Dienst und eigener Serververantwortung abwägen, finden hier eine belastbare Entscheidungsstruktur.

OpenShip-Datenbank-Backup nach Teamphase einordnen

OpenShip beschreibt Cloud, Self-Hosting und hybride Bereitstellungen als unterschiedliche Betriebsformen. Auf der offiziellen Plattformseite werden unter anderem PostgreSQL, Redis, Objektspeicher und Hintergrundaufgaben als Bestandteile einer vollständigen Anwendung genannt. Für die Cloud werden Backups, Überwachung und Warnmeldungen aufgeführt; bei eigenen Servern bleibt die Infrastruktur grundsätzlich in Ihrer Verantwortung. (Offizielle OpenShip-Plattformbeschreibung)

Das bedeutet jedoch nicht, dass jede selbst verwaltete Datenbank automatisch mit derselben Frequenz oder Aufbewahrung gesichert wird wie ein verwalteter Dienst. Die Backup-Eigenschaften der einen Bereitstellungsform dürfen Sie nicht auf die andere übertragen. Prüfen Sie deshalb vor dem Kauf oder der Migration die am Tag der Entscheidung gültige OpenShip-Dokumentation und die Planbeschreibung.

Für die Auswahl genügt folgende erste Einordnung:

• Persönlicher Prototyp: Selbst verwaltet kann ausreichen, wenn die Daten reproduzierbar sind und keine echten Kundendaten enthalten. Eine exportierte Konfiguration und mindestens eine geprüfte Wiederherstellung bleiben trotzdem erforderlich.
• Einzelentwickler mit zahlenden Nutzern: Managed Backup ist oft sinnvoller, wenn Sie nicht regelmäßig Skripte, Speicherziele und Warnmeldungen kontrollieren können.
• Kleines Team: Eine hybride Lösung kann passen: Anwendung und sensible Daten auf eigener Infrastruktur, weniger kritische Dienste oder Wiederherstellungskopien in einem verwalteten Bereich.
• Dauerhaft laufendes AI SaaS: Entscheidend sind RPO, RTO, Datenstandort, Zugriffskontrolle und ein dokumentierter Wiederanlauf. Der reine Speicherpreis ist nur ein Teil der Rechnung.
• DSGVO-sensible Anwendung: Sie benötigen Nachweise zu Verschlüsselung, Zugriffen, Löschung, Aufbewahrung und Verantwortlichkeiten. Fehlen diese Informationen, ist ein kontrollierbarer eigener Speicherort unter Umständen geeigneter.

Wichtig: Ein Snapshot, eine Replikation und ein Backup lösen unterschiedliche Probleme. Eine Replik kann einen laufenden Fehler oder eine versehentliche Löschung schnell weitertragen. Ein Backup muss deshalb zeitlich getrennt, geschützt und wiederherstellbar sein.

Erste Kostenstufe: Was bei einem Prototyp wirklich gesichert werden muss

In der frühen Phase ist die wichtigste Frage nicht „Wie billig ist der Speicher?“, sondern „Welche Daten kann ich erneut erzeugen?“

Ein AI-SaaS-Prototyp enthält häufig mehrere Datenklassen:

1. Reproduzierbare Daten: Testkonten, automatisch erzeugte Embeddings oder temporäre Agent-Ausgaben können unter Umständen neu erstellt werden.
2. Nicht reproduzierbare Daten: Benutzerprompts, hochgeladene Dateien, Zahlungsereignisse, manuelle Freigaben und Gesprächsverläufe dürfen Sie nicht ohne Weiteres als entbehrlich behandeln.
3. Betriebsdaten: Umgebungsvariablen, Domain-Konfiguration, Datenbankmigrationen, Jobdefinitionen und externe Webhook-Ziele sind für den Wiederanlauf genauso wichtig wie die Tabellen selbst.
4. Kurzlebige Zustände: Redis kann nur ein Cache sein, aber auch Warteschlangen, Sessions, Rate-Limit-Zustände oder Agent-Fortschritte enthalten.

Wenn sämtliche Daten neu erzeugt werden können und keine realen personenbezogenen Informationen verarbeitet werden, dürfen Sie die Backup-Komplexität zunächst reduzieren. „Kein Backup“ ist aber keine Kostenstrategie. Sie sparen dann lediglich den sichtbaren Speicherposten und akzeptieren bewusst den vollständigen Wiederaufbau.

Für einen Prototyp genügt häufig ein kleinerer Sicherungsumfang:

• Export der OpenShip-Konfiguration und Umgebungsvariablen, jedoch ohne Geheimnisse im Klartext.
• PostgreSQL-Dump oder ein gleichwertiger Datenbankexport.
• Export der Objektpfade und der verwendeten Buckets.
• Dokumentation der Redis-Rolle: Cache, Session-Speicher, Queue oder persistenter Zustand.
• Eine isolierte Testwiederherstellung vor dem ersten echten Nutzerzugriff.

Die PostgreSQL-Dokumentation unterscheidet SQL-Dumps, Dateisystem-Sicherungen und kontinuierliche Archivierung. Jede Methode hat andere Eigenschaften bei Granularität, Geschwindigkeit und Point-in-Time-Recovery. (PostgreSQL-Dokumentation zur Datensicherung)

Zweite Kostenstufe: Warum Selbstverwaltung beim Einzelentwickler oft teurer wird

Ein selbst verwaltetes Backup besteht nicht nur aus einem Cronjob. Sie benötigen mindestens einen Ablauf, der die Sicherung erstellt, an einen getrennten Speicherort überträgt, den Erfolg prüft, alte Dateien löscht und bei Fehlern alarmiert.

Die wichtigsten versteckten Kosten sind:

• Skripterstellung: Befehle für PostgreSQL, Redis, Objektspeicher und Konfigurationsdateien müssen abgestimmt werden.
• Überwachung: Ein erfolgreicher Prozessstart bedeutet nicht, dass eine vollständige und lesbare Datei entstanden ist.
• Speicherbereinigung: Ohne Löschregel wächst das Backup-Archiv kontinuierlich.
• Schlüsselverwaltung: Zugriffsschlüssel für den Backup-Speicher benötigen minimale Rechte, Rotation und einen sicheren Aufbewahrungsort.
• Versionskompatibilität: Datenbank-Upgrades können Export- und Importverfahren verändern.
• Fehleranalyse: Netzwerkfehler, volle Datenträger, fehlende Berechtigungen oder beschädigte Archive erfordern manuelle Untersuchung.
• Wiederherstellungsübung: Erst ein Import in eine getrennte Umgebung zeigt, ob das Verfahren tatsächlich funktioniert.

Bei Redis müssen Sie besonders klar zwischen flüchtigem Cache und persistentem Geschäftszustand unterscheiden. Redis unterstützt unter anderem RDB-Snapshots, AOF und eine Kombination aus beiden. Ein Snapshot kann Datenverlust zwischen zwei Sicherungspunkten zulassen; AOF kann eine feinere Wiederherstellung ermöglichen, verursacht aber eigene Ressourcen- und Betriebsanforderungen. (Redis-Dokumentation zur Persistenz)

Berechnen Sie den Personalaufwand daher mit:

Jährliche Selbstverwaltungskosten =
Speicher + Übertragung + zusätzliche Infrastruktur
+ (Wartungsstunden × interner Stundensatz)
+ regelmäßige Wiederherstellungstests
+ erwarteter Ausfall- und Fehleraufwand

Der interne Stundensatz muss kein offizieller Marktpreis sein. Verwenden Sie Ihren tatsächlichen Kalkulationswert. Wenn Sie nur außerhalb der Arbeitszeit prüfen können, ist eine nominell kostenlose Speicherlösung nicht automatisch wirtschaftlich.

Ist ein selbst verwaltetes OpenShip-Datenbank-Backup automatisch aktiv?

Nein. OpenShip kann Datenbankdienste wie PostgreSQL und Redis bereitstellen, aber daraus folgt nicht automatisch, dass Ihre konkrete selbst verwaltete Instanz mit einem geprüften Backup, einer definierten Aufbewahrung und einem Wiederherstellungsalarm ausgestattet ist. Die Plattformseite nennt für verwaltete Dienste Backup-Funktionen, während die Self-Hosting-Variante Ihre eigenen Maschinen und deren Betrieb voraussetzt.

Prüfen Sie auf Ihrem Server mindestens:

• Existiert ein tatsächlich ausgeführter Zeitplan?
• Wird die Datei außerhalb des ursprünglichen Servers gespeichert?
• Wird die Dateigröße oder Prüfsumme kontrolliert?
• Gibt es eine Warnung bei fehlgeschlagenen Übertragungen?
• Kann eine zweite Person die Wiederherstellung durchführen?
• Sind Datenbankpasswort, Verschlüsselungsschlüssel und Speicherzugang getrennt geschützt?

Wenn Sie diese Fragen nicht beantworten können, ist das selbst verwaltete Verfahren noch kein belastbares Disaster-Recovery-Konzept.

Dritte Kostenstufe: Aufbewahrung, RPO und RTO vor dem Preis festlegen

Die Aufbewahrungsdauer darf nicht aus einer allgemeinen Empfehlung kopiert werden. Sie hängt davon ab, wie lange ein Fehler unentdeckt bleiben kann, welche gesetzlichen Pflichten bestehen und wie weit Sie bei einer Fehlbedienung zurückgehen müssen.

Definieren Sie zwei Variablen:

• RPO: Wie viel Datenverlust ist nach einem Ausfall akzeptabel? Das National Institute of Standards and Technology beschreibt RPO als den Zeitpunkt, bis zu dem Daten nach einer Störung wiederhergestellt werden müssen. (NIST-Definition des Recovery Point Objective)
• RTO: Wie lange darf die Wiederherstellung dauern, bevor das Geschäft oder der Dienst erheblich beeinträchtigt wird? (NIST-Definition des Recovery Time Objective)

Danach können Sie die Backup-Strategie festlegen:

• Bei einem Testsystem kann ein längerer RPO akzeptabel sein, wenn der gesamte Datenbestand neu erzeugt werden kann.
• Bei Agent-Sitzungen und Benutzerdateien muss der RPO zu den tatsächlichen Erwartungen Ihrer Kunden passen.
• Bei Zahlungen, Kontingenten oder Abonnementstatus ist ein älterer Datenstand potenziell geschäftskritisch.
• Bei einer Queue müssen Sie entscheiden, ob Aufgaben erneut erzeugt, verworfen oder exakt fortgesetzt werden.
• Bei langen Aufbewahrungszeiten müssen Verschlüsselung, Löschung und Zugriff regelmäßig überprüft werden.

Die DSGVO schreibt keine pauschale einheitliche Backup-Aufbewahrung vor. Sie müssen begründen können, wie lange personenbezogene Daten benötigt werden, und dürfen sie nicht unbegrenzt „vorsichtshalber“ speichern. Hinweise zur Speicherbegrenzung und zum Umgang mit Sicherungskopien finden Sie in der Leitlinie zur Speicherbegrenzung und Löschung in Backups.

Wie lange sollte ein Datenbank-Backup aufbewahrt werden?

So lange, wie es Ihr Wiederherstellungsrisiko, Ihre Geschäftsanforderungen und Ihre Datenschutzpflichten rechtfertigen. Für einen Prototyp kann eine kurze technische Rückfallebene genügen. Für ein produktives AI SaaS benötigen Sie dagegen meist mehrere Generationen, damit ein unbemerkter Fehler nicht alle brauchbaren Sicherungen überschreibt.

Legen Sie mindestens drei Regeln schriftlich fest:

1. Welche Datenklasse wird wie lange aufbewahrt?
2. Wer genehmigt die Löschung alter Sicherungen?
3. Wie wird eine Löschung personenbezogener Daten auch in Backup-Systemen berücksichtigt?

Die Datenschutzaufsicht weist darauf hin, dass Daten in Backups unter Umständen nicht sofort physisch gelöscht werden können, aber außer Gebrauch gesetzt und nach dem vorgesehenen Zyklus entfernt werden müssen. (Leitlinie zum Recht auf Löschung)

Vierte Kostenstufe: Der vollständige Wiederherstellungsumfang eines AI SaaS

Eine Datenbank ist nur ein Teil Ihres Systems. Für eine nutzbare Wiederherstellung müssen Sie vier Bereiche gemeinsam betrachten.

PostgreSQL

Sichern Sie Tabellen, Rollen, Berechtigungen, Migrationen und gegebenenfalls Point-in-Time-Informationen. Ein Dump ohne passende Datenbankversion oder ohne erforderliche Erweiterungen kann beim Import scheitern.

Redis

Dokumentieren Sie, ob Redis nur als Cache dient. Wenn Sessions, Agent-Zustände, Streams oder Aufgaben darin liegen, muss Redis Bestandteil des Wiederanlaufs sein. Eine Sicherung außerhalb des ursprünglichen Servers oder Rechenzentrums reduziert das Risiko, dass ein einzelner Vorfall Produktivdaten und Backup gleichzeitig zerstört.

Objektspeicher

Benutzerdateien, Dokumente, Audioaufnahmen und generierte Ergebnisse liegen häufig nicht in PostgreSQL. Sichern Sie Bucket-Inhalte, Schlüsselpfade, Metadaten, Lebenszyklusregeln und Zugriffsrechte.

Externe Aufgaben und Integrationen

Webhook-Ziele, Zahlungsanbieter, E-Mail-Zustellung, Modellanbieter, geplante Jobs und externe Queue-Systeme müssen nach der Wiederherstellung erneut erreichbar sein. Ein reparierter Hauptdatensatz hilft wenig, wenn die Anwendung keine neuen Aufgaben annehmen kann.

Erfahrung aus der Planung: „Backup erfolgreich“ beschreibt einen abgeschlossenen Sicherungsvorgang. „Restore erfolgreich“ bedeutet, dass ein definierter Datenstand in einer getrennten Umgebung importiert wurde, die Anwendung startet, Berechtigungen funktionieren und ein realer Geschäftsablauf abgeschlossen werden kann.

Warum ein erfolgreiches Backup trotzdem nicht wiederherstellbar sein kann

Die häufigsten Ursachen liegen nicht im fehlenden Backup-Befehl, sondern in der fehlenden Anschlussprüfung:

• Die Sicherungsdatei ist unvollständig oder beschädigt.
• Der Export enthält keine Rollen, Erweiterungen oder Migrationen.
• Ein benötigtes Objekt liegt außerhalb der Datenbank.
• Redis wurde als Cache behandelt, enthält aber tatsächlich Aufgaben oder Sitzungen.
• Der Speicherzugang funktioniert im Produktionssystem, nicht jedoch in der isolierten Umgebung.
• Geheimnisse, DNS, Webhooks oder externe Dienste wurden nicht neu eingerichtet.
• Die Sicherung ist vorhanden, aber niemand kennt ihren Erstellungszeitpunkt und Datenstand.

Deshalb müssen Sie nach jeder wichtigen Änderung nicht nur die Sicherung erzeugen, sondern auch die Wiederherstellung in einem getrennten Ziel testen.

Fünfte Kostenstufe: Rollen, Schlüssel und Datenstandort prüfen

Für kleine Teams ist die Verantwortungsfrage oft wichtiger als die Speichergebühr. Bei einem verwalteten Dienst prüfen Sie:

• Welche Rollen dürfen Backups anzeigen, exportieren oder wiederherstellen?
• Gibt es eine getrennte Freigabe für eine produktive Wiederherstellung?
• Werden Zugriffe protokolliert?
• Wo liegen Daten und Sicherungskopien?
• Wie wird ein Vertragsende behandelt?
• Welche Verantwortung verbleibt bei Ihnen als Betreiber?

Bei einer selbst verwalteten Lösung prüfen Sie zusätzlich:

• Wer besitzt den Schlüssel zum Backup-Speicher?
• Kann ein kompromittierter Produktionsserver auch die Sicherungen löschen?
• Gibt es ein getrenntes Administratorkonto?
• Sind Backups verschlüsselt, bevor sie übertragen werden?
• Liegt mindestens eine Kopie außerhalb des Primärservers?
• Kann eine zweite Person die Wiederherstellung ohne den ursprünglichen Entwickler durchführen?

Anforderungen an Vertraulichkeit, Integrität und Verfügbarkeit gelten auch für Sicherungssysteme. Eine Übersicht zu Datenschutz und Datensicherheit bei Kvmkit kann Ihnen als Ausgangspunkt für die getrennte Prüfung Ihrer Mietumgebung dienen. Eine technische Umgebung ersetzt jedoch keine Prüfung von Auftragsverarbeitung, Datenstandort oder Zugriffskonzept Ihrer OpenShip-Anwendung.

Sechster Schritt: In fünf Etappen zur belastbaren Entscheidung

1. Datenbestand inventarisieren

Erstellen Sie eine Liste aller persistenten Komponenten: PostgreSQL, Redis, Objektspeicher, Agent-Sitzungen, Dateien, externe Aufgaben und Konfiguration. Markieren Sie jede Komponente mit „reproduzierbar“, „geschäftskritisch“ oder „personenbezogen“.

2. RPO und RTO festlegen

Schreiben Sie nicht „schnelle Wiederherstellung“, sondern konkrete Akzeptanzbedingungen. Welcher Datenverlust ist für eine Agent-Sitzung vertretbar? Ab wann wird ein Ausfall für zahlende Nutzer kritisch?

3. Kostenvariablen einsetzen

Vergleichen Sie beim Managed-Modell Planentgelt, enthaltene Sicherungen, Speicher, Wiederherstellung, Datenübertragung und mögliche Zusatzkosten. Beim Self-Hosting addieren Sie Server, getrennten Speicher, Überwachung, Wartungszeit, Sicherheitsprüfungen und Übungen.

4. Einen isolierten Restore durchführen

Importieren Sie PostgreSQL in eine getrennte Umgebung. Stellen Sie Redis nach seiner tatsächlichen Rolle wieder her. Kopieren Sie Objektdateien. Setzen Sie Geheimnisse neu, starten Sie die Anwendung und führen Sie einen realistischen Benutzerablauf aus.

5. Verantwortlichkeit dokumentieren

Legen Sie fest, wer den Alarm erhält, wer die Wiederherstellung freigibt, wer die Schlüssel verwaltet und wann die nächste Übung stattfindet. Ohne Eigentümer ist auch ein technisch gutes Backup nur eine unbeaufsichtigte Datei.

Entscheidungshilfe für Managed, Self-Hosting und Hybrid

Nutzen Sie die folgende Tabelle nicht als Preisblatt, sondern als Kostenmodell. Die OpenShip-Preisseite nennt aktuell keine verbindlichen Cloud-Preise; daher sind keine erfundenen Monatsbeträge eingetragen.

Die Wiederherstellungs-Checkliste vor dem Produktionsstart

• [ ] Alle persistenten OpenShip-Dienste sind inventarisiert.
• [ ] PostgreSQL-Export oder kontinuierliche Sicherung wurde erstellt.
• [ ] Die Rolle von Redis ist dokumentiert: Cache, Session, Queue oder Geschäftszustand.
• [ ] Objektspeicher und Benutzerdateien sind im Wiederherstellungsumfang enthalten.
• [ ] Eine Sicherung liegt außerhalb des Primärservers.
• [ ] Verschlüsselung und Zugriffsschlüssel wurden geprüft.
• [ ] Aufbewahrung und Löschung personenbezogener Daten sind dokumentiert.
• [ ] Ein Alarm für fehlgeschlagene Sicherungen wurde ausgelöst und empfangen.
• [ ] Eine isolierte Umgebung wurde mit einem echten Datenstand aufgebaut.
• [ ] Die Anwendung konnte sich nach dem Restore mit PostgreSQL und Redis verbinden.
• [ ] Ein realer Agent- oder Benutzerablauf wurde erfolgreich ausgeführt.
• [ ] Wiederherstellungsdauer und Datenverlust wurden protokolliert.
• [ ] Eine verantwortliche Person und ein Stellvertreter sind benannt.

Wenn Ihre derzeitige Lösung nur einen einzelnen Server, lokale Volumes und manuelle Skripte verwendet, bestehen drei reale Nachteile: Ein Serverausfall kann Produktivdaten und Backups gleichzeitig treffen, die Wiederherstellung hängt an wenigen Personen und der tatsächliche Datenstand bleibt bis zur Übung unbewiesen. Ein Managed-Modell kann diese Verantwortung reduzieren, ist aber nur anhand der gültigen OpenShip-Planbedingungen bewertbar.

Für temporäre Tests, getrennte Entwicklungsumgebungen oder zusätzliche Rechenkapazität kann eine gemietete Mac-Umgebung für den US-Osten sinnvoller sein, als einen weiteren dauerhaft betriebenen Server aufzubauen. Sie ersetzt kein Datenbank-Backup, kann aber die Test- und Wiederherstellungsumgebung entkoppeln.

Bevor Sie eine Managed-Funktion buchen oder eigene Backup-Knoten vorbereiten, führen Sie eine vollständige Wiederherstellung mit Ihren echten Datenklassen durch. Wenn Sie den Ablauf nicht innerhalb Ihres festgelegten RTO nachvollziehbar schaffen, ist die billigere Speicheroption noch nicht die günstigere Betriebsentscheidung. Für den Aufbau eines länger laufenden Systems können Sie anschließend die laufenden Infrastrukturkosten und Bereitstellungsoptionen mit Ihrer eigenen Server- oder Mietstrategie abgleichen.