Speicher

Der Bereich Storage verwaltet zwei Arten von Ressourcen. Eine Speicherverbindung erfasst den Zugriff auf Objekt- oder Dateispeicher, der anderswo läuft. Verwalteter Speicher ist S3-kompatibler Objektspeicher, den Opfield auf einem Storage Node bereitstellt und betreibt; neue Cluster verwenden SeaweedFS. Beide erfordern Personal oder höher. Speicherressourcen dienen als Ziele für Datenbank-Backups, und verwalteter Speicher kann Workloads privaten, auf Buckets beschränkten Zugriff geben.

Frage	Speicherverbindung	Verwalteter Speicher
Wer den Dienst betreibt	Der Anbieter oder Ihr Speicherteam	Opfield, als SeaweedFS auf einem Storage Node mit begrenzter Festplatte oder in Business und Enterprise auf mehreren
Protokolle	S3 (AWS S3, Cloudflare R2, MinIO, andere S3-kompatible Dienste), SFTP, FTP, FTPS	S3
Objektbrowser	Ja	Ja
Backup-Ziel	Ja	Ja
Zugriffsschlüssel und Workload-Verbindungen	Nein	Ja
Öffentliche Erreichbarkeit	Nicht zutreffend	Standardmäßig privat; ein öffentlicher S3-Listener ist optional
Löschen	Entfernt nur die in Opfield gespeicherte Verbindung	Entfernt den Dienst und löscht seine Daten

Speicherverbindungen

Wählen Sie Add Storage und einen Anbieter:

Anbieter	Verbindungsdaten
AWS S3, Cloudflare R2, MinIO, Other (S3-compatible)	Region, Access Key ID und Secret Access Key; ein Endpunkt für alles außer AWS; optional Session Token, Standard-Bucket und Path-Style-Adressierung (bei MinIO standardmäßig aktiviert)
SFTP	Host, Port (standardmäßig 22), Benutzername, Passwort oder privater Schlüssel mit optionaler Passphrase und der SHA-256-SSH host key fingerprint des Servers, der erforderlich ist und bei jeder Verbindung geprüft wird
FTP, FTPS	Host, Port (21 bzw. 990 bei implizitem FTPS), Benutzername und Passwort; FTPS unterstützt explizites oder Implicit TLS und prüft das Serverzertifikat immer mit dem System-Truststore oder einem CA Certificate, das Sie angeben

Bei FTP, FTPS und SFTP erscheinen Verzeichnisse unterhalb des konfigurierten Base Path als Buckets. SMB wird nicht unterstützt.

Um eine gespeicherte Verbindung zu ändern, öffnen Sie Storage Settings auf ihrer Seite. Test connection in der Fußzeile des Dialogs prüft die gespeicherte Verbindung und meldet die Antwortzeit; Save Changes speichert das Formular.

Opfield speichert Secrets, Host-Key-Fingerabdrücke und CA-Zertifikate verschlüsselt und gibt Secrets nie an das Formular zurück: Wird ein Secret-Feld leer gelassen, bleibt der gespeicherte Wert erhalten, aber eine Änderung von Endpunkt, Host, Benutzername, Protokoll oder Vertrauenseinstellungen erfordert die erneute Eingabe des Secrets. Das Anzeigen gespeicherter Zugangsdaten erfordert storage:credentials:reveal. storage:credentials:use lässt Datenbank-Backups und Kopieraufträge die gespeicherten Zugangsdaten verwenden, ohne sie anzuzeigen. Ein Bucket, auf den Backup-Richtlinien oder der Backup-Verlauf verweisen, kann nicht gelöscht werden; zu Speicherverbindungen siehe Speicher löschen, auf den Backups verweisen.

Die Registerkarte Objects durchsucht Buckets und Objekte, öffnet und bearbeitet Dateien, lädt Dateien hoch, erstellt Ordner und löscht Dateien und Ordner. Sie ist nicht verfügbar, solange der Speicher offline ist. Das Erstellen eines Buckets erscheint, wenn eine Verbindung keine Buckets hat, und erfordert storage:objects:admin. Die API löscht zusätzlich Buckets und erstellt vorsignierte Download-Links; vorsignierte Links sind weder für privaten verwalteten Speicher verfügbar, der über Opfield heruntergeladen werden muss, noch für FTP, FTPS und SFTP. Die Anfrage nach einem Objekt oder Bucket, das nicht existiert, liefert STORAGE_NOT_FOUND. Siehe Berechtigungen.

MCP-Clients verschieben große Objekte ohne Base64 in Werkzeugaufrufen: download_storage_object prüft storage:objects:read und liefert einen einmaligen, 15 Minuten gültigen Link mit einem fertigen curl-Befehl, der das Objekt über Opfield streamt, und upload_storage_object lädt in Blöcken hoch, die Opfield prüft. Ein Download-Link wird bei der Verwendung erneut gegen die aktuellen Berechtigungen des Eigentümers geprüft und funktioniert einmal.

Verwalteter Objektspeicher

Wählen Sie Deploy managed storage, um Objektspeicher auf einem Storage Node bereitzustellen, optional in einem Speicherordner; die Ordnerauswahl bietet nur Ordner an, in denen Sie Speicher erstellen dürfen. Neue Cluster laufen mit SeaweedFS 4.47, festgelegt auf einen unveränderlichen Image-Digest; einen Versionswechsel an Ort und Stelle gibt es nicht. Der Storage Node bezieht den eigenen Build von SeaweedFS 4.47 von Opfield aus der GitHub Container Registry (ghcr.io); gelingt das nicht, verwendet er das Upstream-Image, zuerst vom Opfield-Mirror auf ghcr.io und dann von Docker Hub, wobei er in beiden Fällen seinen Digest prüft. Funktioniert keine Quelle, bricht die Bereitstellung mit MANAGED_STORAGE_IMAGE_PULL_FAILED ab.

Ein Cluster läuft auf einem Storage Node. In Business und Enterprise kann er auch auf 2 bis 5 Storage Nodes mit einem Primary und Kopien laufen, die übernehmen, wenn er verloren geht; siehe Datenbanken und Speicher auf mehreren Servern. Legen Sie bei der Bereitstellung Limits für CPU, Arbeitsspeicher (mindestens 512 MiB) und Festplatte fest; die Konsole begrenzt die Festplatte auf den freien Speicher des Nodes abzüglich seiner Reserve. Die Festplatte ist ein vorab zugewiesenes, begrenztes Image auf dem Storage Node, wie der Speicher verwalteter Datenbanken: Jeder Cluster belegt dort ein Loop-Device, und der Docker-Daemon startet die Engine erst, nachdem dieses Image gemountet ist; siehe Details für Betreiber: Speicher und direktes TLS. Opfield erzeugt die Root-Zugangsdaten, und ihr Anzeigen erfordert storage:credentials:reveal.

Nach der Bereitstellung können Sie Name, Tags, CPU, Arbeitsspeicher, Swap, Festplattengröße und S3-Veröffentlichung ändern. Die Festplatte kann nur wachsen, und eine Änderung wird abgelehnt, solange eine vorherige noch angewendet wird. Das Vergrößern der Festplatte sowie das Ein- oder Ausschalten der Veröffentlichung oder die Änderung ihres Ports erstellen den Speichercontainer neu; Daten und Schlüssel bleiben erhalten. Restart und das Wiederholen einer fehlgeschlagenen Bereitstellung sind ebenfalls verfügbar.

Namen von verwaltetem Speicher sind auf jedem Storage Node eindeutig. Das Erstellen oder Umbenennen von verwaltetem Speicher mit einem Namen, den ein anderer verwalteter Speicher auf demselben Node bereits verwendet, schlägt mit 409 MANAGED_STORAGE_NAME_IN_USE fehl; ist die Bereitstellung dieses anderen Speichers fehlgeschlagen, wiederholen oder löschen Sie ihn zuerst. Ein Name wird frei, sobald das Löschen seines Speichers beginnt. Beim Update von Opfield auf 2.11 wurden spätere Cluster, die sich auf einem Node einen Namen teilten, zusammen mit ihrer Speicherverbindung mit dem ersten freien Suffix -2, -3, … umbenannt; siehe Durch das Update auf 2.11 gelöste Konflikte.

Verwalteter Speicher ist standardmäßig privat. Opfield erreicht ihn über authentifizierte Relay-Routen. Sie können zusätzliche Zugangswege ausdrücklich aktivieren:

• Publish S3 endpoint stellt die S3-API auf einem Host-Port bereit, standardmäßig 9000.
• TLS verschlüsselt den S3-Endpunkt mit einem Zertifikat der Opfield Storage CA. Es wird beim Erstellen des Clusters gewählt und kann später nicht eingeschaltet werden. Clients müssen dieser CA vertrauen: Der Dialog mit den Zugangsdaten zeigt ihren SHA-256-Fingerabdruck und lässt Sie sie als storage-ca.pem herunterladen oder kopieren. Über die API liefert GET /api/managed-storage/{id}/ca-certificate das Zertifikat und den Fingerabdruck an jeden, der den Cluster ansehen darf, oder MANAGED_STORAGE_TLS_DISABLED (409), wenn TLS aus ist; das MCP-Werkzeug manage_managed_storage bietet dasselbe als Aktion ca_certificate.

SeaweedFS-Cluster bieten nur S3; sie haben keine FTP- oder SFTP-Listener.

Datenbank-Backups und Kopieraufträge erreichen verwalteten Speicher über einen lokalen Listener und prüfen sein Zertifikat als localhost oder 127.0.0.1. Opfield fügt diese Namen den Zertifikaten von Clustern, die mit einem früheren Release erstellt wurden, automatisch hinzu. Während das neue Zertifikat angewendet wird, warten Backups mit angezeigtem Grund in der Warteschlange und versuchen es selbstständig erneut; sie schlagen nur dann mit BACKUP_STORAGE_CERTIFICATE_OUTDATED fehl, wenn das Zertifikat nicht innerhalb von 7 Stunden ausgeliefert wird. Opfield ändert keine Host-Firewalls. Öffnen Sie nur die Ports, die ein identifizierter Client benötigt.

TLS-Zertifikatsverlängerung

Opfield verlängert das Zertifikat eines TLS-Clusters automatisch und prüft stündlich: wenn zwei Drittel seiner Laufzeit verstrichen sind, 30 Tage oder weniger verbleiben, ein erforderlicher Name fehlt oder das Zertifikat von einer anderen CA stammt. Der Daemon des Storage Nodes schreibt das neue Zertifikat, und die Engine lädt es ohne Neustart neu; Opfield wechselt erst dann dazu, wenn der Cluster es ausliefert. Die Storage CA ändert sich nicht, daher funktionieren Clients weiter.

• Die Connection Details des Speichers zeigen eine unauffällige Zeile TLS Certificate mit dem Ablaufdatum und entweder „renewed automatically“ oder „needs attention“. Ein Hinweis erscheint auf der Seite nur, wenn Handlungsbedarf besteht – die Verlängerung ist fehlgeschlagen, 7 Tage oder weniger verbleiben, das verlängerte Zertifikat ist noch nicht geladen, die Verlängerung wartet auf den Node-Daemon oder die CA begrenzt die Laufzeit –, mit dem Grund, dem Ablaufdatum und Renew now für Benutzer, die den Speicher bearbeiten dürfen. Das Dashboard listet außerdem jeden verwalteten Speicher und jede verwaltete Datenbank auf, deren Zertifikat Handlungsbedarf hat und die Sie ansehen dürfen. Über die API und MCP können Sie jederzeit verlängern.
• Ein Neustart wird nur verwendet, wenn 7 Tage oder weniger verbleiben, wenn Sie ihn bei einer manuellen Verlängerung erlauben oder wenn Sie auf einem Node, dessen Daemon Zertifikate noch nicht neu laden kann, manuell verlängern. Andernfalls behält ein solcher Node das aktuelle Zertifikat, bis sein Daemon aktualisiert wird.
• SeaweedFS-Cluster, die vor 2.11 erstellt wurden, lesen ihre Zertifikatsdateien nur alle paar Stunden erneut ein, daher kann es so lange dauern, bis eine Verlängerung ausgeliefert wird; erlauben Sie einen Neustart, um sie früher anzuwenden.
• Solange die Verlängerung weiter fehlschlägt, löst Opfield das Benachrichtigungsereignis Managed Service Certificate Renewal Failed aus, das nach einer erfolgreichen Verlängerung aufgehoben wird. Erstellen Sie dafür eine Alarmregel. Verlängerungen werden im Audit-Log erfasst.
• API: GET /api/managed-storage/{id}/certificate und POST /api/managed-storage/{id}/certificate/renew mit optionalem allowRestart; MCP und Assistent: manage_managed_storage mit den Aktionen certificate_status und renew_certificate. Das Verlängern erfordert storage:edit und funktioniert auch nach dem Ende einer Lizenz-Kulanzfrist weiter.

Kapazität

Jeder Bucket wird in mindestens einem eigenen Daten-Volume gespeichert, und Opfield dimensioniert die Volumes anhand der Festplatte; planen Sie also etwa ein Daten-Volume pro Bucket ein und bevorzugen Sie eine moderate Anzahl von Buckets. Ist die Festplatte voll, schlagen Schreibvorgänge mit HTTP 500 fehl, während bestehende Objekte lesbar bleiben; geben Sie Speicher frei, indem Sie Objekte löschen, oder vergrößern Sie die Festplatte in den Einstellungen, was den Container neu erstellt, und Schreibvorgänge werden fortgesetzt.

Zugriffsschlüssel und Workload-Verbindungen

Auf der Detailseite des Speichers stellt die Registerkarte IAM Keys S3-Zugangsdaten aus, mit optionalem Namen, Lese- oder Lese-Schreib-Zugriff, bis zu 64 Buckets (keiner bedeutet alle Buckets) und optionalem Ablauf. Jeder Schlüssel ist ein eigener IAM-Prinzipal in der Engine, beschränkt auf seine Buckets: Er kann nur diese Buckets auflisten, Objekte lesen und – mit Lese-Schreib-Zugriff – Objekte schreiben und löschen, aber keine Buckets erstellen oder löschen. Die Engine setzt den Ablauf selbst durch, und das Widerrufen eines Schlüssels entfernt seinen Prinzipal sofort. Der Secret Key wird beim Erstellen des Schlüssels einmal angezeigt. Das Erstellen und Widerrufen von Schlüsseln erfordert storage:iam.

Der Dialog mit den Zugangsdaten zeigt Schnellstart-Befehle für AWS CLI und rclone. Bei einem TLS-Cluster übergeben sie die heruntergeladene CA als --ca-bundle storage-ca.pem (AWS CLI) bzw. --ca-cert storage-ca.pem (rclone). Mit einem auf Buckets beschränkten Schlüssel benötigt rclone no_check_bucket = true (im Schnellstart enthalten); andernfalls versucht es, den Bucket zu erstellen, und schlägt mit 403 fehl.

Eine Verbindung zu verwaltetem Speicher gibt einem Container oder Deployment privaten Zugriff auf 1–32 Buckets. Fügen Sie sie auf der Registerkarte Environment des Workloads hinzu; Compose-Dienste werden nicht unterstützt. Opfield stellt einen auf diese Buckets beschränkten Schlüssel aus, bindet den Workload an ein kleines eigenes privates Netzwerk für die Verbindung an, das der gemeinsame Secure-Link-Connector seines Docker Nodes bedient, und speichert die Werte als verwaltete Secrets in Umgebungsvariablen, die standardmäßig S3_ENDPOINT, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, S3_BUCKET (der erste Bucket) und AWS_REGION heißen. Der Schlüssel erreicht nur die aufgeführten Buckets, sodass ein kompromittierter Workload den Rest des Speichers nicht lesen kann. Buckets, die die Verbindung aufführt und die noch nicht existieren, werden beim Erstellen der Verbindung angelegt, weil der eigene Schlüssel der Verbindung sie nicht erstellen kann. Das Erstellen einer Verbindung erfordert storage:bind (in storage:iam enthalten) und die Berechtigung, Umgebung und Secrets des Workloads zu bearbeiten; eine Verbindung an einem Deployment erfordert außerdem docker:containers:manage darauf sowie docker:containers:edit, wenn sie die Umgebung des Deployments ändert.

Eine Verbindung hat kein festes Verbindungslimit: Die Relay-Zulassung begrenzt sie nach Last und verteilt die Kapazität fair zwischen den Routen, und ungenutzte gepoolte Verbindungen bleiben offen. Die Übersicht des Workloads zeigt die Laufzeit der Verbindung neben seinen Datenbankverbindungen. Siehe Verbindungskapazität und Verbindungspools.

Ab 2.11.1 laufen Speicherverbindungen auf dem gemeinsamen Connector, wie Datenbank-Bindings und Container-Links, ohne Connector-Container pro Verbindung. Eine vor 2.11.1 erstellte Verbindung wechselt dorthin, nachdem der Docker-Daemon des Workloads aktualisiert wurde, und Opfield erstellt den verbundenen Workload direkt nach dem Wechsel einmal neu: Ein Deployment wird ohne Ausfallzeit per Blue/Green ausgerollt, ein Container startet einmal neu. Auf 2.11.1 erstellte Verbindungen benötigen keine Neuerstellung. Ein Rollback des Docker-Daemons auf 2.11.0 schaltet die Verbindungen selbstständig zurück, wieder mit einer Neuerstellung pro Workload.

Der Workload muss nicht laufen: Eine Verbindung kann einen Container oder ein Deployment ansteuern, das gestoppt ist, in einer Absturzschleife hängt, fehlgeschlagen ist oder noch nicht bereitgestellt wurde, und Opfield speichert sie, ohne auf den Workload zu warten. Bis der Workload mit der Verbindung läuft, wird die Verbindung als pending angezeigt (observedState: "target_applied" in der API und MCP); sie wird aktiv, wenn der Workload das nächste Mal startet oder seinen aktuellen Rollout abschließt, und das Wiederholen eines fehlgeschlagenen Git-Builds stellt sie bereit. Über die API, MCP oder den Assistenten kann ein Container mit Git-Quelle außerdem vor seinem ersten Build über seinen Namen verbunden werden, den dieser dann mit der Verbindung startet. Ein Rollback eines Deployments oder eine Slot-Umschaltung behält die aktuellen Verbindungen. Der Docker Node des Workloads muss online sein.

Für erweiterte nginx-Konfigurationen kann eine Route außerdem ein zusätzliches Secure-Link-Binding zu bereitem verwaltetem Objektspeicher verwenden, ohne gemeinsames Docker-Netzwerk und ohne veröffentlichten S3-Port; Clients benötigen weiterhin S3-Zugangsdaten. Verwalteter Speicher kann nicht der Haupt-Upstream einer Route sein. Das Erstellen des Bindings erfordert Bearbeitungszugriff auf die Route und Lesezugriff auf den Speicher; siehe Sichere Upstreams.

Das Löschen von verwaltetem Speicher löscht seine Daten und entfernt seine Workload-Verbindungen automatisch. Es wird abgelehnt, solange Secure-Link-Bindings von Routen oder ein aktiver Kopierauftrag darauf verweisen, und Backup-Referenzen werden wie unten beschrieben behandelt.

Von Opfield verwaltete Speichernetzwerke (opfield-storage-*; gateway-storage-* bei Netzwerken, die vor 2.12.1 erstellt wurden) sind für Docker-Netzwerkaktionen ausgeblendet: Benutzer können keine Container verbinden oder trennen, diese Netzwerke nicht entfernen und keine Container darauf erstellen.

Daten zwischen Speichern kopieren

Ein Kopierauftrag kopiert Objekte serverseitig von einem S3-Speicher in einen anderen, verwaltet oder extern – zum Beispiel von einem älteren MinIO-Cluster zu SeaweedFS oder von einem externen Bucket in verwalteten Speicher. Kopieraufträge haben keinen Konsolenbildschirm: Starten Sie sie über den integrierten Assistenten, MCP oder die REST API.

• Modi: copy fügt Objekte hinzu und überschreibt sie und löscht nie. sync löscht außerdem Objekte im Ziel, die die Quelle nicht hat; verwenden Sie es nur für einen bewussten letzten Durchlauf. dryRun schreibt nichts und meldet, was sich unterscheidet.
• Aktive Ziele: Ein sync in verwalteten Speicher, den Workload-Verbindungen oder beschreibbare Zugriffsschlüssel noch verwenden und dessen Schreibvorgänge nicht eingefroren sind, wird mit STORAGE_COPY_DESTINATION_LIVE abgelehnt, weil er Objekte löschen könnte, die diese Clients geschrieben haben. Frieren Sie die Schreibvorgänge des Ziels ein, verwenden Sie copy oder übergeben Sie allowLiveDestination: true, wenn Sie dieses Risiko akzeptieren.
• Buckets: "all" oder eine Liste von Namen. Jeder Bucket behält im Ziel seinen Namen. Fehlende Ziel-Buckets werden erstellt, wenn Sie storage:objects:admin auf dem Ziel besitzen; übergeben Sie createBuckets: false, um bestehende Buckets zu verlangen. Bucket-Versionierung, Lebenszyklusregeln und Bucket-Richtlinien werden nicht kopiert.
• Ausführung: Der Backup-Runner auf einem Storage Node streamt die Objekte mit rclone, bewahrt Objektmetadaten wie den Content-Type und vergleicht danach beide Seiten. Opfield wählt einen Storage Node, der online ist und dessen Daemon Kopieraufträge unterstützt, oder Sie wählen einen mit executorNodeId. Privater verwalteter Speicher wird über Relay-Routen pro Auftrag erreicht, sodass kein Port veröffentlicht und kein Container neu erstellt wird. Zugangsdaten bleiben innerhalb von Opfield und beim Ausführenden. Optionale limits: timeoutSeconds (standardmäßig ein Tag, höchstens sieben), cpuCores, memoryMb und transfers.
• Prüfbericht: Ein abgeschlossener Auftrag meldet pro Bucket und insgesamt Objektanzahl und Bytes auf beiden Seiten, die Anzahl fehlender, abweichender und (bei sync) überzähliger Objekte mit Beispielschlüsseln sowie clean. Nur ein abgeschlossener Auftrag mit clean: true weist die Kopie nach; ein abgeschlossener Auftrag kann dennoch Unterschiede melden, zum Beispiel Objekte, die Clients während seiner Ausführung geschrieben haben. Wird derselbe Auftrag erneut ausgeführt, überträgt er nur, was sich geändert hat, und das Vertauschen von Quelle und Ziel kopiert zurück.
• Grenzen: Ein aktiver Auftrag darf in einen Speicher schreiben, kein Auftrag darf einen Speicher lesen, in den ein anderer Auftrag schreibt, und ein Ausführender führt höchstens zwei Kopieraufträge gleichzeitig aus.

Aktion	REST API	MCP und Assistent
Einen Auftrag starten	POST /api/storage/copy-jobs mit sourceStorageId, destinationStorageId, buckets, mode, dryRun und optional createBuckets, allowLiveDestination, executorNodeId und limits	manage_storage_connection copy_data_start
Einen Auftrag verfolgen und seinen Bericht lesen	GET /api/storage/copy-jobs/{id}	copy_data_status
Aufträge auflisten	GET /api/storage/copy-jobs	copy_data_list
Einen Auftrag abbrechen	POST /api/storage/copy-jobs/{id}/cancel	copy_data_cancel

Kopieraufträge verwenden IDs von Speicherverbindungen. Verwenden Sie bei verwaltetem Speicher die ID seiner Speicherverbindung (objectStorageConnectionId in den Details des verwalteten Speichers, die die API und MCP liefern), nicht die ID des verwalteten Speichers.

Ein abgebrochener oder abgelaufener Auftrag hinterlässt nie einen Runner-Container, und sein Endstatus wird gespeichert, bevor er gemeldet wird, sodass er einen unmittelbar folgenden Neustart des Daemons übersteht.

Das Starten eines Auftrags erfordert storage:objects:read und storage:credentials:use auf der Quelle, storage:objects:write und storage:credentials:use auf dem Ziel sowie nodes:backups:execute auf dem ausführenden Node. Opfield prüft die Berechtigungen des Auftragseigentümers erneut, wenn es den Auftrag versendet. Das Starten eines Auftrags erfordert einen aktuellen Tarif ab Personal; das Verfolgen, Auflisten und Abbrechen von Aufträgen funktioniert auch nach dem Ende einer Lizenz-Kulanzfrist weiter.

Migration von MinIO

MinIO wird von seinem Hersteller nicht mehr vertrieben, daher läuft neuer verwalteter Speicher mit SeaweedFS. Verwaltete MinIO-Cluster, die mit früheren Releases erstellt wurden, laufen als ältere Engine weiter und sind in der Konsole mit Legacy MinIO engine gekennzeichnet:

• Sie bedienen weiterhin S3, ihre Zugriffsschlüssel, Workload-Verbindungen, Secure-Link-Bindings und etwaige FTP- oder SFTP-Listener, und der Alltagsbetrieb läuft weiter, solange das MinIO-Image noch auf dem Storage Node vorhanden ist.
• Neue MinIO-Cluster können nicht erstellt werden.
• Eine Operation, die den Container neu erstellen und daher das Image beziehen muss – zum Beispiel eine Änderung der Veröffentlichung, das Vergrößern der Festplatte oder die Wiederherstellung eines verlorenen Containers –, schlägt mit MANAGED_STORAGE_ENGINE_IMAGE_UNAVAILABLE fehl, wenn das Image nicht mehr auf dem Node vorhanden ist, weil es nicht mehr heruntergeladen werden kann. Opfield meldet das, bevor es den Container oder seine Daten anrührt.

Mit dem Assistenten migrieren

Es gibt keine Migrationsschaltfläche. Um einen Cluster zu SeaweedFS zu verschieben, bitten Sie den integrierten Assistenten darum, zum Beispiel: Migrate managed storage “files” from MinIO to SeaweedFS. Der Assistent folgt Schritt für Schritt der Migrationsanleitung von Opfield, meldet das Ergebnis jedes Schritts und fragt vor der Umschaltung und vor der Außerbetriebnahme des MinIO-Clusters nach. Er handelt mit Ihren Berechtigungen, daher benötigen Sie die unter Migrationsaktionen aufgeführten Scopes. Ein MCP-Client wie Codex oder Claude Code kann dieselbe Migration über dieselben Werkzeuge ausführen.

1. Vorabprüfung (nur lesend). Der Assistent prüft, dass der Cluster bereit ist, listet seine Buckets, den belegten Speicher, Zugriffsschlüssel, Workload-Verbindungen, Secure Links sowie Backup-Richtlinien und -Verlauf auf und prüft, dass der Ziel-Node mindestens das 1,2-Fache des belegten Speichers frei hat und einen aktuellen Daemon ausführt. Er bricht ab, wenn der Cluster FTP oder SFTP verwendet, was SeaweedFS nicht bietet.
2. Das Ziel aufbauen. Er erstellt einen SeaweedFS-Cluster, standardmäßig privat. Auf Wunsch verwendet er die MinIO-Root-Zugangsdaten weiter, damit Clients, die sie verwenden, weiter funktionieren.
3. Online kopieren. Ein Kopierauftrag kopiert jeden Bucket, während Anwendungen weiter in MinIO schreiben. Der Bericht kann Unterschiede zeigen, solange Clients schreiben, daher wird die Kopie wiederholt, bis sich nur noch neue Objekte unterscheiden; jeder Durchlauf überträgt nur, was sich geändert hat.
4. Umschalten. Schreibvorgänge pausieren für ein kurzes Fenster; Lesevorgänge funktionieren weiter.
   • Zuerst Backups verschieben: Backup-Richtlinien, die in den MinIO-Cluster schreiben, werden auf den neuen Cluster verschoben oder, wenn Sie es vorziehen, pausiert, und laufende Backup- und Wiederherstellungsjobs, die ihn verwenden, müssen abgeschlossen oder abgebrochen werden.
   • Schreibvorgänge einfrieren: Jeder Zugriffsschlüssel und jeder Schlüssel einer Workload-Verbindung, den Opfield auf dem MinIO-Cluster ausgestellt hat, wird schreibgeschützt, einschließlich Schlüsseln, die während des Einfrierens ausgestellt werden. Opfield hört außerdem auf, dorthin zu schreiben: Uploads, Löschungen und Bucket-Änderungen über den Objektbrowser, Speicherwerkzeuge und MCP schlagen mit STORAGE_WRITES_FROZEN fehl, und Backups oder Wiederherstellungen, die dorthin schreiben würden, werden abgelehnt. Das Einfrieren wird abgelehnt, solange ein Backup oder eine Wiederherstellung läuft, die den Cluster verwendet. Die Root-Zugangsdaten und Kopieraufträge schreiben weiterhin, sodass die Kopie fortgesetzt wird. Schlüssel, die Opfield nicht ausgestellt hat, werden aufgeführt, damit Sie diese Clients stoppen können. Die Detailseite des Speichers zeigt, dass Schreibvorgänge pausiert sind.
   • Letzter Durchlauf: Ein sync-Kopierauftrag läuft, bis sein Bericht sauber ist. Vorher wird nichts umgeschaltet.
   • Zugriffsschlüssel importieren: Zugriffsschlüssel werden auf SeaweedFS mit derselben ID und demselben Secret neu erstellt, sodass ihre Clients nur den Endpunkt ändern. Ablaufende Schlüssel und IDs, die SeaweedFS nicht akzeptiert, werden zum Ersetzen aufgeführt.
   • Workload-Verbindungen verschieben: Jede Verbindung wechselt mit demselben Schlüssel, Alias und denselben Umgebungsvariablen auf den neuen Cluster. Der Workload wird nicht neu erstellt; nur seine private Route ändert sich, und sein Connector wird ersetzt, wenn sich die Cluster bei TLS unterscheiden. Jeder Bucket der Verbindung muss auf dem neuen Cluster existieren, sonst wird der Wechsel mit MANAGED_STORAGE_BINDING_BUCKETS_MISSING abgelehnt. Ein fehlgeschlagener Wechsel wird zurückgesetzt, und die Verbindung bleibt auf MinIO; kann sie nicht zurückgeschaltet werden, bleibt die Verbindung auf dem neuen Cluster, wird als fehlgeschlagen markiert und gemeldet.
   • Secure Links neu ausrichten: Secure-Link-Bindings von Routen wechseln auf den neuen Cluster und behalten ihre ID und ihren Namen, sodass Routenkonfigurationen, die sie verwenden, weiter funktionieren. Antwortet der neue Cluster nicht oder kann die Routenkonfiguration nicht angewendet werden, wird das alte Ziel wiederhergestellt.
   • Backups prüfen: Für jede verschobene Richtlinie wird ein Backup ausgeführt, und pausierte Richtlinien werden nach dem Verschieben wieder eingeschaltet.
5. Prüfen und außer Betrieb nehmen. Nachdem Sie bestätigt haben, dass die Anwendungen fehlerfrei laufen, verschiebt der Assistent den abgeschlossenen Backup-Verlauf zu SeaweedFS. Nur Läufe, deren Dateien dort alle mit ihren erfassten Größen gefunden werden, werden verschoben; die anderen bleiben auf MinIO und werden gemeldet und müssen erneut kopiert oder vergessen werden, bevor MinIO gelöscht werden kann. Der Assistent löscht dann den MinIO-Cluster, und ein veröffentlichter S3-Port kann auf den neuen Cluster wechseln.

Bis MinIO gelöscht ist, kann der Assistent zurücksetzen: den neuen Cluster einfrieren, nach der Umschaltung vorgenommene Schreibvorgänge mit sync zurück nach MinIO kopieren, bis der Bericht sauber ist, Verbindungen, Secure Links und Backup-Richtlinien zurückverschieben und MinIO wieder freigeben. MinIO-Zugriffsschlüssel, die erstellt wurden, bevor Opfield jedem Schlüssel eine Richtlinie zuordnete, hatten den vollen Zugriff des Root-Benutzers; nach einem Einfrieren und Freigeben behalten sie nur Lese- und Schreibzugriff auf ihre Buckets.

Starten Sie den MinIO-Cluster während einer Migration niemals neu, aktualisieren Sie ihn nicht, wiederholen Sie nichts an ihm und ändern Sie nicht seine Veröffentlichung: Jede dieser Aktionen erstellt seinen Container neu, und das Image kann möglicherweise nicht mehr heruntergeladen werden. Ressourcenbezogene storage:*-Berechtigungen und die Ordnerplatzierung werden nicht auf den neuen Cluster übertragen; vergeben Sie sie erneut. Auch Bucket-Versionierung, Lebenszyklusregeln und Bucket-Richtlinien werden nicht kopiert.

Migrationsaktionen

Um ohne den Assistenten zu migrieren, rufen Sie dieselben Aktionen in der obigen Reihenfolge über die REST API oder MCP auf. Aktionen für verwalteten Speicher verwenden IDs des verwalteten Speichers; Kopieraufträge verwenden IDs von Speicherverbindungen.

Schritt	REST API	MCP und Assistent	Berechtigung
Daten kopieren	POST /api/storage/copy-jobs	manage_storage_connection copy_data_start	Siehe Daten zwischen Speichern kopieren
Schreibvorgänge einfrieren	POST /api/managed-storage/{id}/freeze-writes	manage_managed_storage freeze_writes	storage:iam
Schreibvorgänge freigeben	POST /api/managed-storage/{id}/unfreeze-writes	unfreeze_writes	storage:iam; auch nach dem Ende einer Lizenz-Kulanzfrist erlaubt
Zugriffsschlüssel importieren	POST /api/managed-storage/{targetId}/iam-keys/import mit sourceStorageId und optional keyIds	import_access_keys	storage:iam auf beiden Clustern
Eine Workload-Verbindung verschieben	POST /api/managed-storage/{id}/bindings/{bindingId}/move mit targetStorageId	move_binding	storage:iam auf beiden Clustern und die Workload-Berechtigungen, die zum Erstellen einer Verbindung nötig sind
Einen Secure Link neu ausrichten	POST /api/proxy-hosts/{routeId}/additional-secure-links/{bindingId}/retarget mit upstreamKind: "managed_storage" und managedStorageId	manage_additional_secure_link retarget	proxy:edit auf der Route und storage:view auf dem neuen Cluster
Backup-Verlauf verschieben	POST /api/managed-storage/{id}/backup-history/rehome mit targetStorageId und optional dryRun	rehome_backup_history	storage:edit auf beiden Clustern

Das Einfrieren von Schreibvorgängen erfordert einen aktuellen Daemon auf dem Storage Node des MinIO-Clusters; das Aktualisieren des Daemons erstellt den MinIO-Container nicht neu. Verschieben oder pausieren Sie zuerst Backup-Richtlinien, die in den Cluster schreiben: Das Einfrieren wird abgelehnt, solange ein Backup oder eine Wiederherstellung läuft, die den Cluster verwendet, und sein Ergebnis meldet Richtlinien, die ihn noch verwenden. Ein teilweises Einfrieren liefert einen Fehler und lässt den Cluster eingefroren; führen Sie es erneut aus, um die übrigen Schlüssel anzuwenden. Das Verschieben des Backup-Verlaufs wird abgelehnt, solange Backup-Läufe aktiv sind, und ändert nie Richtlinien. Die Aktionen erfordern einen aktuellen Tarif ab Personal, außer dem Freigeben, damit ein Einfrieren immer aufgehoben werden kann. Jede Aktion wird im Audit-Log erfasst.

Speicher löschen, auf den Backups verweisen

Backup-Richtlinien und aktive Backup-Läufe blockieren immer das Löschen einer Speicherverbindung oder eines verwalteten Speichers; löschen oder verschieben Sie die Richtlinien und warten Sie, bis die Läufe abgeschlossen sind. Verweist nur abgeschlossener Backup-Verlauf auf den Speicher, wird das Löschen mit STORAGE_BACKUP_HISTORY_EXISTS (409) abgelehnt, bis Sie Forget history and delete bestätigen. Das Vergessen entfernt diesen Verlauf aus Opfield, sodass diese Backups nicht mehr über Opfield wiederhergestellt oder gelöscht werden können, und das Audit-Log erfasst, wo ihre Dateien liegen. Die Dateien einer Speicherverbindung bleiben in ihren Buckets; die Dateien in verwaltetem Speicher werden mit ihm gelöscht.

Übergeben Sie über die API backupHistory=forget an DELETE /api/object-storage/{id} oder DELETE /api/managed-storage/{id}. Die Speicherwerkzeuge von AI Workspace und MCP akzeptieren dieselbe Bestätigung als config.backupHistory. Um einzelne Backups zuerst zusammen mit ihren Dateien zu löschen, verwenden Sie den Backup-Verlauf.

Berechtigungen

Scope	Erlaubt
storage:view	Speicherverbindungen, verwalteten Speicher, Zugriffsschlüssel und Verbindungen ansehen
storage:create	Speicherverbindungen und verwalteten Speicher erstellen
storage:edit	Einstellungen ändern, neu starten und Bereitstellung wiederholen
storage:delete	Speicherverbindungen und verwalteten Speicher löschen
storage:credentials:reveal	Gespeicherte Zugangsdaten anzeigen; schließt storage:credentials:use ein
storage:credentials:use	Datenbank-Backups und Kopieraufträge gespeicherte Zugangsdaten verwenden lassen, ohne sie anzuzeigen
storage:iam	Zugriffsschlüssel erstellen, widerrufen und importieren, Schreibvorgänge einfrieren und freigeben und Workload-Verbindungen verschieben; schließt storage:bind ein
storage:bind	Workload-Verbindungen erstellen und löschen, ohne Zugriffsschlüssel auszustellen
storage:objects:read	Objekte durchsuchen und herunterladen sowie vorsignierte Download-Links erstellen
storage:objects:write	Hochladen, Präfixe erstellen und Objekte löschen
storage:objects:admin	Buckets erstellen und löschen
storage:folders:manage	Speicherordner organisieren

Scopes können auf eine Speicherressource oder einen Ordner beschränkt werden. Datenbank-Backups benötigen auf ihrem Ziel nur storage:credentials:use, keinen Objektzugriff. Siehe die Scope-Referenz.

Betriebliche Grenzen

• Speicherressourcen erfordern Personal oder höher; die Registrierung eines Storage Nodes nicht. Siehe Tarife und Leistungsumfang.
• Storage Nodes betreiben verwaltete Datenbanken, verwalteten Speicher und Backup-Jobs; allgemeine Anwendungscontainer und Builds laufen auf Docker Nodes und Build Workern. Siehe Node-Rollen.
• Verwalteter Speicher liegt auf einem Host, sofern Availability ihn nicht auf mehreren Storage Nodes betreibt. Bewahren Sie Backups und andere wichtige Kopien außerhalb seiner Fehlerdomäne auf.
• Halten Sie Verschlüsselung, Aufbewahrung und Zugriffsrichtlinien auf der Zielseite in dem Speichersystem, das die Daten hält.