Datenbank-Backups

Opfield erstellt native Backups von PostgreSQL-, Key-Value- und ClickHouse-Datenbanken und schreibt sie in eine Speicherverbindung. Backups funktionieren sowohl für verwaltete Datenbanken als auch für externe Verbindungen und sind ab Personal verfügbar. Jedes Backup und jede Wiederherstellung läuft als Job auf einem Storage Node, den Sie als Ausführenden wählen, nicht auf dem Opfield-Host.

Ein Backup schützt Anwendungsdaten. Es ersetzt nicht das Wiederherstellungsset der Opfield Control Plane, das unter Updates, Backups und Wiederherstellung beschrieben ist, und es ist keine Point-in-Time-Recovery: Der Zeitplan bestimmt, wie viele Daten Sie verlieren können.

Bevor Sie beginnen

• Eine Speicherverbindung mit einem bestehenden Ziel-Bucket. Opfield schreibt in den Bucket und das Präfix, die Sie auswählen; es erstellt den Bucket nicht. Bucket-Namen müssen den S3-Namensregeln folgen, auch bei FTP-, FTPS- und SFTP-Zielen, bei denen Buckets Verzeichnisse unterhalb des Basispfads sind.
• Ein Storage Node, der einen aktuellen Daemon ausführt und sowohl die Datenbank als auch den Speicherendpunkt erreichen kann. Für private verwaltete Datenbanken und verwalteten Objektspeicher öffnet Opfield für die Dauer des Laufs vorübergehende private Routen.
• Ein verwaltetes Speicherziel mit TLS muss ein Zertifikat ausliefern, das localhost und 127.0.0.1 enthält. Opfield fügt diese Namen Clustern, die mit einem früheren Release erstellt wurden, automatisch hinzu; bis das neue Zertifikat ausgeliefert wird, warten Läufe mit angezeigtem Grund in der Warteschlange, versuchen es selbstständig erneut und schlagen nach 7 Stunden mit BACKUP_STORAGE_CERTIFICATE_OUTDATED fehl. Siehe TLS-Zertifikatsverlängerung.
• Solange bei einem verwalteten Speicherziel die Schreibvorgänge für eine Migration eingefroren sind, werden Backups und Wiederherstellungen, die dorthin schreiben würden, mit STORAGE_WRITES_FROZEN abgelehnt; verschieben oder pausieren Sie zuerst ihre Richtlinien.
• Bei einer externen Datenbank, die TLS verwendet, wenden die Backup- und Wiederherstellungsjobs die Einstellung zur Zertifikatsprüfung der Verbindung und ihre eigene CA an. Ein Ausführender, dessen Docker-Daemon älter als 2.11 ist, kann keine Zertifikate prüfen, daher schlägt ein Lauf für eine geprüfte Verbindung mit BACKUP_EXECUTOR_TLS_VERIFICATION_UNSUPPORTED fehl; aktualisieren Sie den Storage Node oder schalten Sie die Prüfung für diese Verbindung aus.
• Der Storage Node muss das Image des Backup-Runners aus der GitHub Container Registry beziehen können. Der Runner wird mit dem Opfield-Release ausgeliefert und ist per Digest festgelegt; für PostgreSQL wählt er die Client-Werkzeuge, die zur Serverversion passen. Der Runner wird nur für ein Backup oder eine Wiederherstellung gestartet und ist wie andere interne Opfield-Container in Containerlisten und für Benutzer-Lebenszyklusaktionen ausgeblendet. Er enthält feste native Werkzeuge; API-Clients können keine Befehle, Skripte, SQL oder andere Images übergeben.
• Die Berechtigung, Backup-Richtlinien auf der Datenbank zu verwalten, nodes:backups:execute für den ausführenden Node und die unter Berechtigungen aufgeführten Speicherberechtigungen. Die integrierte Gruppe operator enthält nicht alle davon.

Eine Backup-Richtlinie erstellen

1. Öffnen Sie die Datenbank und wählen Sie die Registerkarte Backups.
2. Wählen Sie Add policy.
3. Wählen Sie unter Destination die Storage-Verbindung, den Bucket und ein Prefix. Das Präfix ist erforderlich und lautet standardmäßig database-backups; jeder Lauf schreibt seine Artefakte und eine manifest.json unterhalb von <prefix>/<run ID>/. Fügen Sie bei ClickHouse S3 staging-Speicher hinzu, wenn die Engine nicht direkt in das Ziel schreiben kann; siehe Wie jede Engine gesichert wird.
4. Wählen Sie unter Execution den Storage node, der die Jobs ausführt.
5. Lassen Sie die Richtlinie unter Schedule manuell oder geben Sie einen numerischen Cron-Ausdruck mit fünf Feldern und eine Timezone ein. Die Konsole schlägt 0 2 * * * in der Zeitzone Ihres Browsers vor.
6. Legen Sie unter Retention die Anzahl der Completed backups to keep fest. Ältere abgeschlossene Backups werden aus dem Ziel entfernt.
7. Passen Sie unter Resource limits Arbeitsbereich, Timeout, CPU und Arbeitsspeicher für den Job an, wenn die Standardwerte nicht zur Datenbank passen.
8. Speichern Sie die Richtlinie, verwenden Sie dann einmal Run now und warten Sie, bis der Lauf abgeschlossen ist, bevor Sie sich auf den Zeitplan verlassen.

In der Konsole können Sie außerdem den Zeitplan einer Richtlinie aktivieren oder deaktivieren und die Richtlinie löschen. Andere Richtlinieneinstellungen lassen sich über die API ändern.

Einstellung	Erlaubter Bereich	Standard
Completed backups to keep	1–365	7
Arbeitsbereich (GiB)	1–1024	20
Timeout (Sekunden)	60–86.400	3.600
CPU-Kerne	1–32	1
Arbeitsspeicher (MiB)	128–262.144	1.024

Wie jede Engine gesichert wird

Engine	Backup	Wiederherstellung
PostgreSQL	Nativer Dump im Custom-Format	In eine leere Datenbank
Key-Value-Store	Nativer RDB-Snapshot, erfasst mit seiner Engine (Redis oder Valkey)	Nur in dieselbe Engine: ein Redis-Backup in einen Store, der Redis ausführt, oder in einen neuen Store, ein Valkey-Backup in einen Store, der Valkey ausführt, oder in einen neuen Store. Die geprüfte RDB wird in einen temporären Server dieser Engine geladen, vollständig in ein leeres Ziel repliziert und dann getrennt. Ein externes Ziel benötigt Replikations- und Konfigurationsrechte und muss sich zurück zum Ausführenden verbinden können
ClickHouse	Natives BACKUP und RESTORE über S3	In ein leeres Ziel über denselben S3-Pfad

ClickHouse schreibt sein Backup über S3, daher muss der ClickHouse-Server selbst den S3-Endpunkt erreichen. Bei einem privaten verwalteten S3-Ziel ohne Staging muss die Quelle eine verwaltete ClickHouse-Datenbank sein und ihr Storage Node der Ausführende. Ein externer ClickHouse-Server benötigt eine S3-Staging-Verbindung, die er direkt erreichen kann. FTP-, FTPS- und SFTP-Ziele erfordern ebenfalls eine S3-Staging-Verbindung und einen Bucket; Opfield überträgt die Artefakte zwischen Staging und endgültigem Ziel, behält die native Verzeichnisstruktur von ClickHouse bei und löscht die Staging-Kopie anschließend.

Bei einem externen Key-Value-Ziel führt die Wiederherstellung einen temporären, passwortgeschützten Server im Host-Netzwerk des Ausführenden auf einem zufälligen Port zwischen 20000 und 39999 aus, und das Ziel repliziert von der Dienstadresse des Ausführenden. Erlauben Sie diese Verbindung vom Ziel zum Ausführenden für die Dauer der Wiederherstellung.

Läufe, Warteschlange und Zeitpläne

Ein ausführender Storage Node führt jeweils ein Backup oder eine Wiederherstellung aus. Ein Lauf, der zugelassen wird, während der Node beschäftigt ist, bleibt Queued und startet in Erstellungsreihenfolge, wenn der Node frei ist; ein eingereihter Lauf kann sofort abgebrochen werden. Der Abbruch eines laufenden Jobs wartet auf die Bestätigung des Ausführenden; Force cancel beendet den Lauf ohne diese Bestätigung, während Opfield den Job im Hintergrund weiter abgleicht. Ein Lauf, der sein Timeout um mehr als 15 Minuten überschreitet, wird als fehlgeschlagen markiert. Eine Richtlinie hat höchstens ein eingereihtes oder laufendes Backup: Run now, während ein Backup der Richtlinie aktiv ist, wird mit 409 BACKUP_ALREADY_RUNNING abgelehnt, das den aktiven Lauf nennt, und ein geplanter Lauf wird übersprungen, mit einem Fehler an der Richtlinie. Ebenso kann jeweils nur eine Wiederherstellung in denselben Namen einer neuen verwalteten Datenbank eingereiht sein oder laufen; eine weitere wird mit 409 BACKUP_RESTORE_ALREADY_RUNNING abgelehnt. Die Datenbank erzwingt beide Regeln, sodass sie auch über mehrere Opfield-Prozesse hinweg gelten. Hatte eine Richtlinie beim Update von Opfield auf 2.11 mehrere aktive Backups, lief eines weiter – ein laufendes Backup vor einem eingereihten, andernfalls das neueste –, und die anderen wurden als fehlgeschlagen markiert und abgebrochen; siehe Durch das Update auf 2.11 gelöste Konflikte. War Opfield ausgefallen, als ein geplanter Zeitpunkt verstrich, führt es nur den jüngsten verpassten Termin innerhalb der letzten 24 Stunden aus statt eines Rückstaus.

Ein Backup ist erst abgeschlossen, wenn sein Manifest validiert wurde. Das Manifest erfasst Quellidentität, Serverversion, Größen und SHA-256-Prüfsummen der Artefakte; ein erfolgreicher Upload allein zählt nicht. Die Aufbewahrung behält die neuesten abgeschlossenen Backups pro Richtlinie und entfernt nur ältere Artefakte unter dem Präfix der Richtlinie, wobei Artefakte übersprungen werden, die eine Wiederherstellung verwendet.

Geplante Läufe und die Aufbewahrung handeln als Eigentümer der Richtlinie – der Benutzer, der die Richtlinie zuletzt gespeichert hat –, und Opfield prüft vor jedem Lauf erneut die Berechtigungen dieses Benutzers. Verliert der Eigentümer den Zugriff oder wird er gelöscht, werden geplante Läufe übersprungen, und die Richtlinie zeigt den Fehler, bis ein Benutzer mit den erforderlichen Berechtigungen die Richtlinie speichert und ihr Eigentümer wird.

Ein Backup wiederherstellen

1. Öffnen Sie auf der Registerkarte Backups die Backup history und wählen Sie bei einem abgeschlossenen Lauf Restore.
2. Wählen Sie den Storage node, der die Wiederherstellung ausführt, geben Sie einen Namen für die neue verwaltete Datenbank ein und wählen Sie optional einen Datenbankordner dafür. Wo die Engine einen Datenbanknamen verwendet, können Sie den Namen der Zieldatenbank ändern. Passen Sie bei Bedarf Storage (GB), CPU cores, Memory (MB) und Swap (MB) an.
3. Verfolgen Sie den Wiederherstellungslauf bis zum Abschluss und prüfen Sie dann die neue Datenbank mit Anwendungsabfragen, bevor Sie Clients darauf umstellen.

Eine Wiederherstellung aus der Konsole erstellt eine neue verwaltete Datenbank auf dem ausführenden Storage Node und überschreibt niemals bestehende Datenbanken. Sie erfordert die Berechtigung, Datenbanken auf diesem Node oder im gewählten Ordner zu erstellen. Opfield verwendet die neueste Katalogversion mit der Hauptversion der Engine des Backups und schlägt fehl, wenn keine existiert. Die neue Datenbank erhält keine TCP-Veröffentlichung und aktiviertes TLS. Speicher, CPU, Arbeitsspeicher und Swap entsprechen standardmäßig der Größe der verwalteten Quelldatenbank; andernfalls und bei leeren Feldern erhält sie 1 CPU, 1024 MB Arbeitsspeicher (2048 MB bei ClickHouse), keinen Swap und Speicher von 20 GB oder dem Dreifachen der Backup-Größe, je nachdem, was größer ist. Der Wiederherstellungsjob selbst verwendet die Standard-Ressourcenlimits – 20 GiB Arbeitsbereich und ein Timeout von einer Stunde – statt der Limits der Richtlinie; die API kann sie überschreiben.

Über die API können Sie ein verwaltetes oder externes Backup außerdem in eine bestehende, leere Datenbankverbindung derselben Engine wiederherstellen, die nicht die Quelle ist. Das erfordert die Wiederherstellungsberechtigung auf der Datenbank des Backups und Bearbeitungsberechtigung auf dem Ziel. Eine native Vorabprüfung bestätigt, dass das Ziel leer ist, und Opfield prüft unmittelbar vor der Wiederherstellung erneut. Eine Wiederherstellung in die eigene Quellverbindung des Backups wird abgelehnt, bevor ein Lauf erstellt wird, mit 409 BACKUP_RESTORE_SOURCE_REJECTED; stellen Sie stattdessen in eine andere leere Verbindung oder eine neue verwaltete Datenbank wieder her.

Berechtigungen

Scope	Erlaubt
databases:backups:view	Richtlinien und Laufverlauf ansehen
databases:backups:manage	Richtlinien erstellen, ändern und löschen sowie Laufverlauf entfernen
databases:backups:run	Läufe starten und abbrechen
databases:backups:restore	Ein abgeschlossenes Backup wiederherstellen
nodes:backups:execute	Einen Storage Node als Ausführenden verwenden

Ziel- und Staging-Speicher werden separat geprüft. Das Erstellen oder Ändern einer Richtlinie, das Starten oder Abbrechen eines Laufs, die Aufbewahrung, das Löschen von Backup-Dateien und das Wiederherstellen erfordern nur storage:credentials:use auf dem Ziel und, falls verwendet, auf dem Staging-Speicher. Dieser Scope lässt den Backup-Runner die gespeicherten Speicher-Zugangsdaten erhalten, ohne sie dem Benutzer zu zeigen, und öffnet den Objektbrowser nicht; storage:credentials:reveal schließt ihn ein. Kein storage:objects:*-Scope ist erforderlich.

Die integrierten Gruppen admin und operator enthalten storage:credentials:use. Die Gruppe operator kann Richtlinien erstellen und Backups ausführen, enthält aber nicht databases:backups:restore. Eingeschränkte API-Tokens und OAuth-Freigaben behalten ihre eigene engere Befugnis. Siehe die Scope-Referenz.

Regeln für Löschung und Aufbewahrung

Das Löschen einer Richtlinie stoppt künftige Läufe. Um einen abgeschlossenen Lauf aus der Backup history zu entfernen, wählen Sie, was mit seinen Dateien im Speicher geschieht:

• Ein Lauf ohne verbleibende Dateien, zum Beispiel nachdem die Aufbewahrung sie entfernt hat, wird direkt entfernt.
• Delete backup and files löscht die Backup-Dateien und dann den Verlaufseintrag; das Backup kann danach nicht mehr wiederhergestellt werden. Das erfordert storage:credentials:use auf dem Ziel. Verweigert der Speicher das Löschen, bleibt der Eintrag erhalten, der Grund wird angezeigt, und Sie können es erneut versuchen oder den Eintrag stattdessen vergessen.
• Forget entry entfernt nur den Verlaufseintrag und belässt die Dateien im Speicher; das Audit-Log erfasst ihren Bucket und ihr Präfix.

Über die API akzeptiert DELETE /api/databases/{id}/backups/runs/{runId} den Parameter artifacts=delete oder artifacts=forget. Ohne ihn wird ein Lauf, dessen Dateien noch existieren, mit BACKUP_HISTORY_HAS_ARTIFACTS (409) abgelehnt; ein fehlgeschlagenes Löschen der Dateien liefert BACKUP_ARTIFACT_DELETE_FAILED (502) und behält den Eintrag; ein Lauf, dessen Dateien eine Wiederherstellung noch liest, liefert BACKUP_ARTIFACT_IN_USE. Das Backup-Werkzeug von AI Workspace und MCP akzeptiert dieselbe Wahl als config.artifacts. Eingereihte und laufende Läufe können nicht entfernt werden.

Ein Bucket, auf den Backup-Richtlinien oder der Backup-Verlauf verweisen, kann nicht gelöscht werden. Auch eine Speicherverbindung, auf die eine Backup-Richtlinie oder ein aktiver Lauf verweist, kann nicht gelöscht werden; verweist nur abgeschlossener Backup-Verlauf darauf, können Sie sie löschen, indem Sie diesen Verlauf vergessen; siehe Speicher.

Eine Datenbank kann nicht gelöscht werden, solange eines ihrer Backups oder eine ihrer Wiederherstellungen läuft. Wird eine Datenbank gelöscht, werden ihre Richtlinien deaktiviert und entfernt, und ihr Backup-Verlauf bleibt erhalten: Backups of deleted databases auf der Seite Databases listet diese Backups auf und stellt eines in eine neue Datenbank wieder her. In MCP erledigen die Aktionen list_orphaned_runs, restore_orphaned, cancel_orphaned und delete_orphaned_run von manage_database_backups dasselbe; sie benötigen die databases:backups:*-Scopes ohne Datenbankeinschränkung, weil das Löschen einer Datenbank die Berechtigungen entfernt, die sie benennen. Planen Sie Verschlüsselung, Aufbewahrung und Zugriffskontrolle auf der Zielseite im Speichersystem selbst und bewahren Sie mindestens eine Kopie außerhalb der Fehlerdomäne der Datenbank und ihres Storage Nodes auf.

Testen Sie Wiederherstellungen regelmäßig auf einem separaten Ziel. Ein Backup, das nie wiederhergestellt wurde, ist kein Wiederherstellungsnachweis; siehe die Wiederherstellungsübung.